Subject: RE: Summary for draft-vainshtein-cesopsn-03.txt

From: "Prayson Pate" <[email-masked]>
Date: Wed, 4 Sep 2002 13:33:19 -0400

Shahram,

I agree with Sasha's remarks regarding the consistency 
of the drafts.

I would like to add to the remarks on implementation.  
While someone might have to write the software for a 
CPU or the VHDL for an FPGA, the format specified in 
[CESoPSN] is computationally simple, and the rates are 
low, making the job easier.  The complexities of SONET
and ATM AAL1/2 are avoided for simple point to point 
applications carrying one or a few circuits.

The approach specified in [SONET-VT] comes into its 
own in the carriage and/or cross-connection of multiple 
circuits, or when one or both ends are connected to 
SONET networks - a very common situation.  Also, the 
availability of commercial silicon to do a lot of the 
work (e.g. mapping/unmapping) means that the new or 
custom work is limited, facilitating ease of 
implementation and interworking.

Regards,
Prayson

> -----Original Message-----
> 
> From: Sasha Vainshtein <[email-masked]>
> To: "'Shahram Davari'" <[email-masked]>
> Cc: "Danny McPherson (E-mail)" <[email-masked]>,
>    "PWE3 WG (E-mail)"
> 	 <[email-masked]>
> Subject: RE: [PWE3] (no subject)

> 
> 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.)
>  
> 
> 
> > -----Original Message-----
> > From: Shahram Davari [mailto:[email-masked]]
> > Sent: Wednesday, September 04, 2002 5:29 PM
> > To: 'Sasha Vainshtein'; PWE3 WG (E-mail)
> > Cc: Danny McPherson (E-mail)
> > Subject: RE: [PWE3] (no subject)
> > 
> > 
> > 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.
> >
> 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.
> > 
> > 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,
> > > 
> > > 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.t
> > > xt [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-tdmsoneta
> > > pp-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-l
> > > ayer-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-o
> > > ver-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.)
> > > _______________________________________________
> > > pwe3 mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/pwe3
> > > 
> > 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3

---

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

>Whether this is important or not is probably a matter of taste.

An FPGA plus a few off the shelf parts can have the same results. The
relative cost, complexity and time to market of such a solution, compared to
a CPU solution, are out of scope I guess.

Bob

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

Shahram and all,

With best regards,
                                   Sasha Vainshtein