Subject: TDM draft comparison - SONET perspective

From: "Ron Cohen" <[email-masked]>
Date: Thu, 18 Apr 2002 21:25:53 +0200

Hi,

Here is the perspective of the VT/SONET encapsulation proposal:

The applicability of the VT/SONET proposal as described in draft-pate
for providing TDM-SONET scenarios and SONET-SONET VT cross connects is
clear.

Here I'd like to describe its applicability to TDM-TDM connections.
Below is a short list of features along the line of your comparison. The
basics observation is that SONET as a transport technology, has to
handle all issues that we are facing in circuit emulation, including the
ability to handle both transparent TDM streams (i.e. clock and data) as
well as provide services for framed services. The SONET guys did a
pretty good job in handing these requirements in a simple way. We are
suggesting to add the minimal delta to carry this information over a
PSN.

1. Unstructured TDM signals: Supported for T1/E1/T3/E3 as well as for
the more bizarre DS-1c and DS-2. This uses the bit-asynchronous
mappings.

2. Structured TDM signals: T1 and E1. Using the byte-synchronous
mappings.

3. Support for carrying multiple T1/E1 lines within a single flow. 

4. N * DS0: Can be supported using 2. There is no definition in draft
pate of dropping the extra bytes from the payload. Is it really needed?
As the locations of the bytes is well known (single pointer in the CEP
header) I don't see any particular problem with the definition of this
mode. There is even the possibility of extracting the robbed bit in CAS
and placing them in the S bits of the byte sync T1.

5. Clocking: Both adaptive and central clock schemes can be used. 

Did I miss any important feature here?

Regards
Ron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of [email-masked]
> Sent: Wednesday, April 03, 2002 10:58 AM
> To: [email-masked]
> Subject: [PWE3] TDM draft comparison
> 
> 
> My name is Geoff Floyd. I attended the IETF PWE3 working
> group at the Minneapolis and have followed relevant 
> discussions on the board for several months. My intention 
> with this Email is to clarify the differences between the 
> three TDM draft proposals and promote discussion, resulting 
> in unified draft proposal. To this end I have generated a 
> comparison of the three TDM drafts.
> 
> Comments and corrections are welcome especially regarding ATM
> and Sonet where my knowledge is more limited.
> 
> Here is my summary of the three drafts:
> TDMoIP - Anavi
> CESoP - Pate
> CESoPSN - Vainshtein
> 
> 1) Transport and demultiplexing protocols:
> All drafts support a wide range of protocols. IP, MPLS, L2TP, UDP etc
> 
> 2) Supported Formats                             Anavi  Pate  
> Vainshtein
> Support unstructured T1/E1                         Yes   Yes    Yes
> Supports fractional T1/E1                          Yes    No    Yes
> Packetization based on ATM cells                   Yes    No     No
> Packetization based on TU/VT Sonet tributaries      No   Yes     No
> Raw data packetization with frame alignment         No    No    Yes
> 
> 3) Header overhead
> Ignoring transport and demultiplexing headers which are
> common to all drafts. Anavi - RTP (12 optional), PW (4) = 
> Total 16 Pate - PW (4), CEP (4) = Total 8 Vainshtein - RTP 
> (12 optional), PW (4) = Total 16
> 
> 4) Payload encapsulation
> Anavi - ATM AAL1 and AAL2 format
> Pate - SONET/SDH format: T1 into VT1.5, E1 into VT2 Vainshtein - 
> Complete TDM frames placed in the packet.
> 
> 5) Payload encapsulation delay (how long to create a packet)
> Anavi - 1 to 30 AAL1 cells in a packet. Therefore delay 
> depends on the number of channels encapsulated. Pate - 
> Insufficient knowledge of Sonet/SDH to comment Vainshtein - 
> Min 1 TDM frame period - 125us.
> 
> 6) Payload encapsulation overhead
> Anavi - Structured AAL1 - 2.1%, Unstructured AAL1 - 2.4%,
> AAL2 - 6.3% Pate - 12.5% for VT2 (E1), 12% for VT1.5 (T1) 
> Vainshtein - None, except for T1 where the payload is padded 
> out to 25 bytes per frame - 3.6%.
> 
> 7) Payload encapsulation "robustness"
> Anavi - Sequence numbers allow detection and recovery from
> missing or out of order packets. Single packet loss will lose 
> more than the data in one packet as the following packets 
> must be searched for a pointer to a frame boundary. Pate - 
> Insufficient knowledge of Sonet/SDH to comment. Vainshtein - 
> Sequence numbers allow detection and recovery from missing or 
> out of order packets. Single packet loss will lose only the 
> data in the packet.
> 
> 8) TDM Clocking support                          Anavi  Pate  
> Vainshtein
> Central Clocking                                   Yes   Yes    Yes
> Clock recovery using synchronous source            Yes    No    Yes
> Adaptive clock recovery                            Yes    No    Yes
> Note: Anavi draft needs more information on use of RTP and
> NTP for adaptive and synchronous source clock recovery to 
> ensure implementations are interoperable.
> 
> 9) Jitter and wander
> Anavi & Vainshtein - Will depend on the implementation.
> Pate - No Jitter or wander as only central clocking mode supported.
> 
> 10) CAS support
> Anavi - AAL2 encapsulation
> Pate - Insufficient knowledge of Sonet/SDH to comment.
> Vainshtein - Sent using RTP packets using different payload 
> type. Uses timestamp for synchronisation with payload.
> 
> Regards
>     Geoff Floyd
> System Architect
> Zarlink Semiconductor
> Plymouth England.
> [email-masked]
> Tel: 44 1752 693322
> 
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>