Subject: (no subject)

From: Sasha Vainshtein <[email-masked]>
Date: Wed, 4 Sep 2002 16:09:07 +0200

Hi all,

As requested by Danny, please find below the summary statement
for draft-vainshtein-cesopsn-03.txt.

-----------------------------------------------------

NAME OF I-D:
http://www.ietf.org/internet-drafts/draft-vainshtein-cesopsn-03.txt 
[CESoPSN]
 
SUMMARY:
This draft describes a method for encapsulating TDM digital signals 
defined in the plesiochronous digital hierarchy (PDH) 
as a pseudo-wire (PW) over various packet-switched networks (PSN). 
In this regard it complements similar work for SONET/SDH circuits. 
Proposed PW encapsulation leverages RTP for sequencing and
synchronization services and, if needed, for application state 
signaling between Customer Edge (CE) devices. 
It does not involve any intermediate technologies for encapsulation
thus allowing simple and BW-effective encapsulations.

RELATED DOCUMENTS:
http://www.ietf.org/internet-drafts/draft-ietf-pwe3-sonet-00.txt [SONET]
http://www.ietf.org/internet-drafts/draft-ietf-pwe3-sonet-vt-00.txt 
[SONET-VT]
http://www.ietf.org/internet-drafts/draft-cohen-pwe3-tdmsonetapp-00.txt 
[APPST]
http://www.ietf.org/internet-drafts/draft-ietf-pwe3-framework-01.txt [FW]
http://www.ietf.org/internet-drafts/draft-ietf-pwe3-protocol-layer-00.txt 
[LAYERS]
http::/www.ietf.org/rfc/rfc2736.txt [RFC 2736]
http::/www.ietf.org/rfc/rfc2833.txt [RFC 2833]
http:://www.ietf.org/internet-drafts/draft-davari-pwe3-aal12-over-psn-00.txt

[AAL]
http:://www.ietf.org/internet-drafts/draft-anavi-tdmoip-04.txt [TDMoIP]
 
WHERE DOES IT FIT IN THE PICTURE OF THE PWE3 WORK:
The following set of drafts provides a complete solution for
the WG work item "TDM (e.g. DS1, DS3, SONET)":
- [SONET] describes how to carry STS-1 and STS-Nc SPEs over
IP and MPLS PSNs.
- [SONET-VT] extends [SONET] to sub-SPE streams. It is
optimized for VT level cross connect applications, for PDH
to SONET/SDH emulation and for carrying PDH circuits across
a PSN.
- [CESoPSN] provides a simple and effective means for transport
of native T1/E1 and E3/T3 circuits over PSNs. It also supports 
transport of lower rates (n*DS0) as well as real-time CE application
signaling.
- [APPST] provides a common applicability statement for the drafts
listed above.
 
WHY IS IT TARGETED AT THIS WG:
The PWE charter calls for encapsulation and emulation/maintenance
document(s) for "TDM (e.g. DS1, DS3, SONET)".
This draft, together with [SONET] and [SONET-VT], describes how 
to transport these streams over IP and MPLS.
 
JUSTIFICATION:
Along with the previously mentioned drafts, this draft addresses
one of the work items in the WG charter, namely "TDM (e.g. DS1,
DS3, SONET)". This is a very important work item for the PWE3 WG.
The following passage is from section 2.1.4 of the framework [FW]:
As packet traffic takes up a larger and larger portion of the
available network bandwidth, it becomes increasingly useful to
optimize public networks for the Internet Protocol. However, many
service providers are confronting several obstacles in engineering
packet-optimized networks. Although Internet traffic is the fastest
growing traffic segment, it does not generate the highest revenue per
bit. For example, Frame Relay traffic currently generates a higher
revenue per bit than do native IP services. Private line TDM
services still generate even more revenue per bit than does Frame
Relay. In addition, there is a tremendous amount of legacy equipment
deployed within public networks that does not communicate using the
Internet Protocol. Service providers continue to utilize non-IP
equipment to deploy a variety of services, and see a need to
interconnect this legacy equipment over their IP-optimized core
networks.

This draft addresses the scenarios described above, and provides the 
following benefits:
1. Simplicity: The technique uses a "raw" encapsulation format, 
without using or referring to any intermediate encapsulation 
technologies. In this it strictly adheres to the Minimum Intervention 
Principle stated in [LAYERS]. As a consequence:
- the payload format is extremely bandwidth efficient 
- the implementation is simple and hence easily scalable to large 
numbers of PW end services
- the protocol is fully defined in the draft, without having to take 
into account numerous different modes of intermediate technologies
- intermediate technologies in the attachment circuit(s) may still be 
handled locally in the appropriate NSP blocks without requiring their 
use to be coordinated between the PEs at either end of the emulated 
circuit.

2. Flexibility: The programmable packets' payload size used in CESoPSN 
allows a trade-off between the bandwidth consumed by a CESoPSN PW and 
its end-to-end delay.

3. Efficiency: Support of n*DS0 services allows BW-effective end-to-end 
emulation of partially populated DS1 and E1 services.

4. Modularity: The transport of application-specific CE state is separate 
from the transport of TDM data. This avoids complicating the data-plane 
for applications that do not require signaling of application-specific 
state. The techniques used for such a separation are aligned with the
the existing IETF standards [RFC 2833].

5. Robustness: The data contained in each CESoPSN packet can be 
interpreted independently as recommended in [RFC 2736]. As a 
consequence, loss of a packet results in loss of solely the data 
carried in that packet. 
(Other techniques may result in the loss of data received in the next
packet(s) due to loss of a packet containing the alignment pointer.) 

The PWE3 WG should move this draft forward for the following reasons:
1. It is a part of a consistent set of drafts: [SONET], [SONET-VT],
[CESoPSN] and [APPST].
2. It strictly adheres to the architectural principles accepted by 
the PWE3 WG 
3. It can be (and actually is) implemented using a combination of 
off-the-shelf available ASICs (PDH framers) and SW running in 
off-the-shelf available CPUs
4. The technology defined in the draft has been tested in the field
5. There are a number of independent implementations in progress 
that are scheduled for interoperability tests in the near future.
 
Alexander ("Sasha") Vainshtein - Axerra Networks
Israel Sasson - Axerra Networks
Akiva Sadovski - Axerra Networks
Eduard Metz - KPNQwest
Tim Frost - Zarlink
Prayson Pate - Overture Networks

-----------------------------------------------------

With best regards,
                                   Sasha Vainshtein
email:     [email-masked]
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)

---

From: Shahram Davari <[email-masked]>
Date: Wed, 4 Sep 2002 08:28:51 -0700

Hi Sasha,

A couple of comments regarding your summary:

1) You mention consistency between your draft and [SONET], [SONET-VT] drafts. What is consistent between your draft and these drafts? I personally see none.

2) You mention that it can be implemented with off the shelf CPU. Off course anything at these rates could be implemented with off the shelf CPUs , but somebody has to write the software/program for the data-plane processing. Is there any off the shelf software too? This is like saying any protocol could be implemented with off the shelf FPGA. Some one should program that FPGA.

Yours,
-Shahram

> -----Original Message-----
> From: Sasha Vainshtein [mailto:[email-masked]]
> Sent: Wednesday, September 04, 2002 10:09 AM
> To: PWE3 WG (E-mail)
> Cc: Danny McPherson (E-mail)
> Subject: [PWE3] (no subject)
> 
> 
> Hi all,
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: Sasha Vainshtein <[email-masked]>
Date: Wed, 4 Sep 2002 19:16:53 +0200

Shahram and all,
Please see some responses inline.

With best regards,
                                   Sasha Vainshtein
email:     [email-masked] <mailto:[email-masked]> 
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)

> From: Shahram Davari [mailto:[email-masked]]
> Sent: Wednesday, September 04, 2002 5:29 PM
> To: 'Sasha Vainshtein'; PWE3 WG (E-mail)
> Subject: RE: [PWE3] (no subject)
> 
> 
> Hi Sasha,
> 
> 1) You mention consistency between your draft and [SONET], 
> [SONET-VT] drafts. What is consistent between your draft and 
> these drafts? I personally see none.
>
To some extent, consistency is in the eye of the beholder. 
However, please note the following common points:

1. The payload of each respective service is either encapsulated
"as is" or, at the very least, optional interference is used 
with discretion for clearly stated optimization purposes
(e.g., that is what SONET-VT does when it drops unused TUs 
from a partially populated SPE or VC-4).
2. The amount of the native service data carried by a
single packet is predefined, and, excluding the case of
very long "native structures" in [SONET], each packet
can be played out independently. As a consequence, handling
of packet loss is consistent and robust. 
3. The three drafts use the same control word structure.
>
> 2) You mention that it can be implemented with off the shelf 
> CPU. Off course anything at these rates could be implemented 
> with off the shelf CPUs , but somebody has to write the 
> software/program for the data-plane processing. Is there any 
> off the shelf software too? This is like saying any protocol 
> could be implemented with off the shelf FPGA. Some one should 
> program that FPGA.
>
IMHO this means that early implementations are flexible enough
to accomodate changes introduced during the standardization 
process, and that it is possible to develop multiple independent
implementations with reasonable ease. 
As you know, availability of multiple independent and interoperable
implementations is necessary for some steps in the IETF process.
Concerning the low rate, let me say that off-the-shelf CPUs
support implementations with quite high density (e.g., 63 E1
per CPU). I do not know if you can have the same results
with an FPGA.
Whether this is important or not is probably a matter of taste.

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 04 Sep 2002 13:11:35 -0400

Shahram,

I thought your second question is a bit specious, to say the 
least.  Sasha's point is that the HW you need to put this in a product is 
generally available off the shelf.  The IETF doesn't require SW to 
implement drafts (or RFCs, for that matter) to be "off the shelf" (although 
there have been a few cases where reference implementations have been made 
available, as was the case with CR-LDP, this is by no means a requirement).

Cheers,
Andy

-------

At 9/4/2002 08:28 AM -0700, Shahram Davari wrote:

>1) You mention consistency between your draft and [SONET], [SONET-VT] 
>drafts. What is consistent between your draft and these drafts? I 
>personally see none.
>
>2) You mention that it can be implemented with off the shelf CPU. Off 
>course anything at these rates could be implemented with off the shelf 
>CPUs , but somebody has to write the software/program for the data-plane 
>processing. Is there any off the shelf software too? This is like saying 
>any protocol could be implemented with off the shelf FPGA. Some one should 
>program that FPGA.
>
>Yours,
>-Shahram
>
> > From: Sasha Vainshtein [<mailto:[email-masked]>mailto:[email-masked]]
> <http://www.ietf.org/internet-drafts/draft-vainshtein-cesopsn-03.txt>http://www.ietf.org/internet-drafts/draft-vainshtein-cesopsn-03.txt 
>
> > [CESoPSN]
> >
> > SUMMARY:
> <http://www.ietf.org/internet-drafts/draft-ietf-pwe3-sonet-00.t>http://www.ietf.org/internet-drafts/draft-ietf-pwe3-sonet-00.t 
>
> > xt [SONET]
> > 
> <http://www.ietf.org/internet-drafts/draft-ietf-pwe3-sonet-vt-00.txt>http://www.ietf.org/internet-drafts/draft-ietf-pwe3-sonet-vt-00.txt 
>
> > [SONET-VT]
> > 
> <http://www.ietf.org/internet-drafts/draft-cohen-pwe3-tdmsoneta>http://www.ietf.org/internet-drafts/draft-cohen-pwe3-tdmsoneta 
>
> > pp-00.txt
> > [APPST]
> > 
> <http://www.ietf.org/internet-drafts/draft-ietf-pwe3-framework->http://www.ietf.org/internet-drafts/draft-ietf-pwe3-framework- 
>
> > 01.txt [FW]
> > 
> <http://www.ietf.org/internet-drafts/draft-ietf-pwe3-protocol-l>http://www.ietf.org/internet-drafts/draft-ietf-pwe3-protocol-l 
>
> > ayer-00.txt
> > [LAYERS]
> > 
> <http::/www.ietf.org/rfc/rfc2736.txt>http::/www.ietf.org/rfc/rfc2736.txt 
> [RFC 2736]
> > 
> <http::/www.ietf.org/rfc/rfc2833.txt>http::/www.ietf.org/rfc/rfc2833.txt 
> [RFC 2833]
> > 
> <http:://www.ietf.org/internet-drafts/draft-davari-pwe3-aal12-o>http:://www.ietf.org/internet-drafts/draft-davari-pwe3-aal12-o 
>
> > ver-psn-00.txt
> >
> > [AAL]
> > 
> <http:://www.ietf.org/internet-drafts/draft-anavi-tdmoip-04.txt>http:://www.ietf.org/internet-drafts/draft-anavi-tdmoip-04.txt 
>
> >  [TDMoIP]
> >
> <https://www1.ietf.org/mailman/listinfo/pwe3>https://www1.ietf.org/mailman/listinfo/pwe3 
>
> >
><https://www1.ietf.org/mailman/listinfo/pwe3>https://www1.ietf.org/mailman/listinfo/pwe3 
>

---

From: Shahram Davari <[email-masked]>
Date: Wed, 4 Sep 2002 11:44:14 -0700

Shasha,

Thanks for you reply. Please see my comments inline.

Thanks,
-Shahram

> From: Sasha Vainshtein [mailto:[email-masked]]
> Sent: Wednesday, September 04, 2002 1:17 PM
> To: Shahram Davari
> Cc: Danny McPherson (E-mail); PWE3 WG (E-mail)

But the SONET-VT first converts the TDM to VT and then
encapsulates it. Also you draft has stuff manipulates the
data such as T1-in-E1. Sorry but I don't see any consistency
here.

> of packet loss is consistent and robust.

But any TDM emulation should have this property, otherwise
you can't bound the delay. TDMoIP has also these properties.
This is a property that must be observed, and therefore
consistency has no meaning here. 

> 3. The three drafts use the same control word structure.

Absolutely wrong. You control word is different from
SONET-VT and SONET drafts. You have actually replaced the
N & P flags with new flags, and are using the D flag in a
different way. You also require that the structure
pointer MUST be set to zero. So there is no common control word.

> implementations with reasonable ease. 

But any operation at these rates could be done by CPU. So what
is the advantage compared to other proposals?

> per CPU).

What about OC-3 worth of T1s or even more? Can you do it in 
off the shelf CPU? 

I do not know if you can have the same results
> Whether this is important or not is probably a matter of taste.

FPGA was an example. The point is that that you can't just claim
it can be done with off the shelf HW, when in fact you need to write codes for
it.

---

From: "Bob Barrett" <[email-masked]>
Date: Wed, 4 Sep 2002 23:46:25 +0100

Andy

I think you missed the Sharam's point here.

The point being that none of the drafts are 'no brainers', and yet some are
being portrayed as requiring less original thought than others by leveraging
existing silicon. That is a matter of opinion and implementers choice ;-).

It is a valid argument to make by proponents of a particular method but it
is not axiomtotic.

Bob
  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On Behalf Of Andrew
G. Malis
  Sent: 04 September 2002 18:12
  To: Shahram Davari
  Cc: Sasha Vainshtein; PWE3 WG (E-mail); Danny McPherson (E-mail)
  Subject: RE: [PWE3] (no subject)

  Shahram,

  I thought your second question is a bit specious, to say the least.
Sasha's point is that the HW you need to put this in a product is generally
available off the shelf.  The IETF doesn't require SW to implement drafts
(or RFCs, for that matter) to be "off the shelf" (although there have been a
few cases where reference implementations have been made available, as was
the case with CR-LDP, this is by no means a requirement).

  Cheers,
  Andy

  -------

    Hi Sasha,

    1) You mention consistency between your draft and [SONET], [SONET-VT]
drafts. What is consistent between your draft and these drafts? I personally
see none.

    2) You mention that it can be implemented with off the shelf CPU. Off
course anything at these rates could be implemented with off the shelf CPUs
, but somebody has to write the software/program for the data-plane
processing. Is there any off the shelf software too? This is like saying any
protocol could be implemented with off the shelf FPGA. Some one should
program that FPGA.

    Yours,
    -Shahram

---

From: Sasha Vainshtein <[email-masked]>
Date: Thu, 5 Sep 2002 12:37:10 +0200

Shahram and all,
Thank you for a prompt response. 
Please see several comments inline.

With best regards,
                                   Sasha Vainshtein

> Sent: Wednesday, September 04, 2002 8:44 PM
> To: 'Sasha Vainshtein'
My understanding is different. SONET-VT describes how a 
VT can be transferred over a PSN. Mapping TDM into a VT 
can be done in an NSP block (if needed), but the method for 
carrying VTs neither depends on this mapping nor 
requires it. In fact, SONET-VT does not even require that 
the VT payload is TDM - it may be, for instance, POS
as specified in RFC 3225.

> consistency has no meaning here. 
AFAIK, the number of TDM payload bytes may vary from packet to
packet in draft-anavi if you carry structured services (because
your structure pointers are inserted at different places).
Am I wrong?
> pointer MUST be set to zero. So there is no common control word.
There are some open issues regarding the usage of the flags, and
we are working on better alignment. IMHO, it is not too difficult
to achieve it better alignment even if it would not, probably,
be complete.
Regarding the pointer - the limitation is on the transmitter,
and the receiver can continue to interpret the pointer value
as if in [SONET] or [SONET-VT]. 
On the other hand, I expect that the pointer in [SONET-VT]
packets will usually be zero, because there is no need to
split a very short structure like VT (104 bytes for VT-1.5 and
140 bytes for VT-2) between multiple packets. From my point
of view this does not introduce any inconsistency between
[SONET] and [SONET-VT].
> What about OC-3 worth of T1s or even more? Can you do it in 
The point is that not what exactly can be done with this 
or other CPU but, rather, that computational difficulty per packet
of CESoPSN is lower than, say, that of TDMoIP. Hence the 
density that can be achived with CESoPSN for any given CPU 
will be higher than the density that can be achieved with 
TDMoIP or, for that matter, SONET-VT.
The same actually applies to FPGA-based implementations.
The fact that you can provide reasonable density with off-the-shelf
CPUs simpy illustrates this point. I think that the same considerations
have been presented by Prayson in his message.
> it can be done with off the shelf HW, when in fact you need 
Please see above.

---

From: Shahram Davari <[email-masked]>
Date: Thu, 5 Sep 2002 08:12:23 -0700

Sasha,

> as specified in RFC 3225.

1) If you read the SONET-VT draft your understanding will change.
Starting from section 1 it focusses on T1/E1/DS3 transport.

2) The same thing could be said about the TDMoIP (and davari) draft.
They specify a method to transport AAL1/2. Mapping of the TDM
to AAL1/2 can be done in an NSP block (if needed), but method for
carrying AAL1/2 neither depends on this mapping nor requires it.
In fact davari and anavi don't even require that the payload
be TDM. Does that mean davari and anavi are also consistent with
SONET-VT draft?

> your structure pointers are inserted at different places).

Yes you are wrong. In anavai/davari the number of TDM payload bytes could be
fixed. The difference is that in anavai/davari a packet may not contain a full
single TDM frame. But that is not an issue, because there is a pointer that
points to the start of the frame.

> of view this does not introduce any inconsistency between

So the conclusion is that they are not exactly the same. When
2 control words are not exactly the same, I don't call them
consistent. TDMoIP also uses pretty much the same fields such
as seq #, length, and flags. Does that mean it is also consistent with
SONET and SONET-VT drafts?

> TDMoIP or, for that matter, SONET-VT.

But nobody is suggesting to do all the TDMoIP in CPU. There are
off the shelf AAL1/2 and SONET-VT chips in the market. In other
words the SARing could be done with off the shelf available
HW, rather than writing SW for it in a CPU, which is also
rate limited to a few T1/E1/DS3s.

-Shahram

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 05 Sep 2002 11:31:06 -0400

Point of order. If this thread is to continue, can someone
please rename the title to include something appropriate?
I have no idea whether to delete the message or to read it
from the blank subject.

         --Tom

>rate limited to a few T1/E1/DS3s.

------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time.

---

From: Sasha Vainshtein <[email-masked]>
Date: Thu, 5 Sep 2002 20:28:49 +0200

Shahram,
Please see short comments inline.

With best regards,
                                   Sasha Vainshtein

> Sent: Thursday, September 05, 2002 5:12 PM
> To: 'Sasha Vainshtein'
I did read the SONET-VT draft and arrived to my understanding as 
a result of this reading.
> They specify a method to transport AAL1/2.
>
IMHO this is absolutely correct for draft-davari and absolutely
wrong for draft-anavi (TDMoIP). If you disagree, please explain
how does TDMoIP support AAL1 with error correction or AAL1 with
SRTS. Or, alternatively, please explain how can draft-davari support
the requirements - stated in draft-anavi - to send correct 
synchronization bits into the outgoing TDM interface if a packet
has been lost?
> Mapping of the TDM
I was under impression that draft-davari does not even require
that the cell stream in question uses AAL1/2 (at least, you
have said once that PEs in draft-davari remain unaware of
AAL1/2).
On the other hand, I am unaware of any non-TDM payload type
for AAL1/2 (as opposed to VT) - but my ATM knowledge is
very limited.
> Yes you are wrong. In anavi/davari the number of TDM payload 
> bytes could be fixed. 
>
"Could be fixed" and "may vary" does not sound as a contradiction
to me.
>
>The difference is that in anavai/davari a packet may 
> not contain a full
Agreed - and I did not raise this issue either. 
> So the conclusion is that they are not exactly the same. 
>
I did not say that they are the same.
>
> When 2 control words are not exactly the same, I don't call them
> consistent. 
>
I think that "consistent" and "the same" have different meaning.
E.g., IMHO the "Martini control word" is used consistently in different
frame-oriented PWs but the meaning of flags is redefined from service
to service. 
>
> TDMoIP also uses pretty much the same fields such
As I have said already, consistency is in the eye of the beholder.
However, TDMoIP uses a unique FORMID field which is not used
anywhere else in PWE3, uses a length field that is not used 
in any of the other approaches and places the flags and the sequence
number in different positions. IMHO calling it consistent with the 
rest of the CWs would stretch the notion of consistency just a bit 
too much.
> rate limited to a few T1/E1/DS3s.
I am not sure I get your point. Do you disagree with the statement
that computational complexity involved with TDMoIP is higher than
that involved with CESoPSN? Or do you want to say that, in spite of
that, you can provide for the same density per given processor with
both methods?

---

From: Shahram Davari <[email-masked]>
Date: Thu, 5 Sep 2002 11:58:43 -0700

Sasha,

> SRTS.

1) Yaakov and I are writing a draft that leverages draft-davari
to do TDM emulation over PSN. The concept is the same as
draft-anavi but it uses AAL1/2 transport as explained in draft
davari. This is no different than SONET-VT draft that explains how
to do VT transport and then leverages it to do TDM emulation.

2) TDMoIP does not require using SRTS and error correction mechanisms of AAL1.

>Or, alternatively, please explain how can draft-davari support

For TDM emulation:

At the ingress 2 blocks are involved here. The first block (A) does TDM emulation over ATM.
It receives TDM and transmits ATM (AAL1/2). The second block (B) does AAL1/2 transport. It
receives ATM cells and transmits IP/MPLS packets.

At the egress also 2 blocks are involved. The first block (C) terminates the PW and extracts
the ATM cells. The second (D) block extracts the TDM stream from AAL1/2.

If a packet is lost, block (C) will detect it and generate ATM AIS. Block (D) upon reception
of such AIS, will generate correct sync bits.

> have said once that PEs in draft-davari remain unaware of

Even better. So based on your logic my draft is even consistent with any 
PSN ATM transport draft.

> for AAL1/2 (as opposed to VT) - but my ATM knowledge is

There can be other types of traffic.

> "Could be fixed" and "may vary" does not sound as a contradiction

It is different. You have 2 choices:

1) Set the payload per packet to a fixed value. If you do so then the
payload will be fixed and does not vary from packet to packet.

2) set the packetization delay to a fixed value. If you do so then
the payload may vary from packet to packet.

What I meant in my previous email was that you could always select the
first option and have no packet by packet payload variance.

> frame-oriented PWs but the meaning of flags is redefined from service

So what is consistent? The seq # and length? If that is your interpretation
of consistency then davari and anavi are both consistent with Martini too.
In fact our goal is to make it exactly identical not "similar" or "consistent".

> As I have said already, consistency is in the eye of the beholder.

Since it is in your eyes only, I suggest not assigning such an attribute to
your draft, in order to make it more appealing.

> anywhere else in PWE3,

The next version will remove this, and will use AAL5 PDU format.

>uses a length field that is not used 
> in any of the other approaches

It will use AAL5 PU mode format and length field.

>and places the flags and the sequence
> number in different positions.

It will use AAL5 PDU mdoe format.

>IMHO calling it consistent with the 

As you said it is in the eyes of beholder. I would say my draft
is consistent and in fact identical to AAL5 PDU. I don't see that
your draft is consistent with any other draft.

> that involved with CESoPSN?

Yes I disagree. You have to do the SARing somewhere. Why invent a new one
when one already exist and HW/SW is available for it.
Plus, the fact that you are extracting the CAS bits and reinserting them,
which is more complex than just encoding them with the TDM stream. 

>Or do you want to say that, in spite of

What I am saying is:

1) You need to built HW/SW to do the SARing for you. While AAL1/2 SARing is
commercially available.

2) If you are thinking of using CPU only, then your processing power is limited to
a few T1s only.

3) An AAL1/2 SAR chip combined with a CPU is much more powerful than a single CPU
handling your draft, and could support many more T1s.

-Shahram

---

From: Sasha Vainshtein <[email-masked]>
Date: Mon, 9 Sep 2002 11:08:38 +0200

Shahram,
Thank you for a prompt response.
Mine has been delayed, but here it comes.
Please see some comments inline. 
I have skipped some fragments (following Lloyd's advice).

With best regards,
                                   Sasha Vainshtein

> Sent: Thursday, September 05, 2002 8:59 PM
> To: 'Sasha Vainshtein'
I will be glad to read it. 
> 2) TDMoIP does not require using SRTS and error correction 
"Does not require" and "cannot carry" sound different to me.
> of such AIS, will generate correct sync bits.
Which of the blocks (A,B,C, D) belong to draft-davari?
And is generation of the "correct sync bits" in response to incoming
ATM AIS part of any standard processing? Can you please provide
any references?
... skipped ...
> There can be other types of traffic.
Can you please give any examples? I am _honestly_ unaware
of these and would be glad to know. 
...skipped...
> first option and have no packet by packet payload variance.
I do not understand how any of these two options apply to draft-anavi and
draft-davari which both postulate that cells/sub-frames are _never_ split
between the packets.
... skipped ...
> The next version will remove this, and will use AAL5 PDU format.
OK 
> your draft is consistent with any other draft.
I agree that draft-davari is consistent with draft-bocci. 
I have some technical problems with your usage of fragmentation
flags I have mentioned earlier, and I would appreciate clarification.
> which is more complex than just encoding them with the TDM stream. 
AFAIK, the "existing HW" to which you refer does exactly the same:
at ingress it extracts the CAS bits and adds them to the end of the 
multiframe-based ATM-CES structures which are then carried 
over AAL1, and at egress it inserts them into the appropriate 
positions in the TDM stream. And, since you mention AAL2, it carries
CAS bits separately and uses the triple redundancy mechanism that is
re-used in RDC 2833 and CESoPSN. Much as I would like to be the
inventor of this method, I am not, nor do I claim the laurels.
And, BTW, extractiona dn insertion is done by the framers (acting as
NSPs) in both cases, not by the CPU or any special HW.
> handling your draft, and could support many more T1s.
Do you see any contradiction between what I have said and what
you say now? 
Of course, if you want to be an original vendor of systems
carrying TDM over PSN you have to do some HW and SW development.
And, of course, increasing the processing power by using a
HW assist ("chip") will improve density. As for "a few" T1s,
just how many is more (not mentioning "many more") than a few?