[PWE3] TDM draft comparison

[Tim.Frost@Zarlink.Com]

There were a spate of emails about a month or so ago (thread "TDM draft 
consolidation") that eventually fizzled out without ever coming close to a 
consolidation. I've been back over the thread to try and pull out what the 
main issues were, since the thread got fairly confused.  I've concentrated 
on the differences between draft-vainshtein and draft-anavi, since this is 
what the thread largely concentrated on.


There seem to be three main arguments:

1. Data encapsulation format
----------------------------
draft-anavi uses data format borrowed from AAL1 or AAL2 for encapsulating 
TDM data
draft-vainshtein uses a "raw" data format, placing the bits straight into 
the packet as they arrive, using an integer number of native (TDM) frames 
in each packet.

The use of ATM format (AAL1 and AAL2) seems to be an additional complexity 
over the use of a "raw" data format, and involves more manipulation of 
data (albeit not much more for the simpler, AAL1 type encapsulation).

The claimed benefits are improved behaviour under packet loss, and the 
simplification of CAS signalling.
(Yaakov - are there any others that I have missed?)


2. Effect of packet loss
------------------------
draft-anavi uses a structure pointer (from AAL1 and AAL2) to identify the 
native frame boundaries.
draft-vainshtein uses a packet comprised of an integer number of native 
frames

Hence it is possible using draft-anavi for a single lost packet to render 
a number of subsequent packets unusable, if the lost packet contained the 
structure pointer. On the other hand, a lost packet in draft-vainshtein 
loses solely the data in the lost packet.

Against that, Yaakov Stein contends that loss of one or more packets in 
draft-vainshtein would cause loss of lock to the superframe or multiframe 
structure in any downstream framing devices. The use of the structure 
pointer concept allows the multiframe position to be re-established as 
soon the next packet containing the structure pointer arrives.

However, provided the phase of the stream remains constant (ensured by 
having an integer number of frames in the packet), then most framers 
should be able to handle up to 50ms of lost data before going to re-sync. 
(although there is some dispute as to whether all TDM equipment will 
really handle this length). Of course a network outage leading to >50ms of 
lost packets is a possible event, but presumably this will cause the same 
effect with draft-anavi as with draft-vainshtein, since all the structure 
pointers will be lost too. 


3. Handling of CAS signalling
-----------------------------
draft-anavi handles CAS signalling by using AAL1 or AAL2 formats for 
encoding CAS
draft-vainshtein handles CAS by encoding it into separate packets 
according to RFC2833

The argument for draft-anavi is that carriage of the signalling within the 
data packet is straightforward, and provides for minimum intervention 
since the signalling is not extracted out into a single packet.

The counter to this argument is that in order to gain this benefit, you 
have to include an ATM SAR function in the PE. Of course, as Yaakov Stein 
points out, this does ease the inter-working with ATM networks 
(particularly when extending ATM CES over a PSN). However, it does seem a 
little perverse to demand that everyone has to include an ATM SAR function 
whether inter-working with ATM or not. If you are inter-working with ATM, 
then it is reasonable to assume that an ATM SAR function is required, but 
not if working purely over a non-ATM packet switched network. 

Its a moot point as to which breaches the "principle of minimum 
intervention" most. My preference is to keep the dataplane as clean and 
simple as possible to make for easy, fast, high-thoughput implementation, 
and pass control traffic such as signalling up to a processor for 
handling. Including ATM functionality in the dataplane doesn't achieve 
this.


SUMMARY
-------
The whole argument in the thread basically comes down to the first point: 
the rationale for including ATM style formats in the encapsulation. 

Yaakov Stein has a good point, in that these are tried and tested 
technologies, which have been developed over several years. Against this, 
it introduces significant extra cost in the inter-working function, in the 
shape of an ATM SAR function. Similar criticisms were aimed at draft-pate 
at the Salt Lake City meeting, with the contention that it introduced 
SONET formatting that was not required unless inter-working with SONET 
networks.

I guess it is obvious where my preferences lie from the tone of this 
email, but we also want to achieve a single way forward here. To do that 
we need a consensus. Its frustrating that the only contributions to the 
debate so far appear to be the main protagonists (Sasha and Yaakov), and a 
relatively small number of other people. I appeal to anyone else 
interested in TDM pseudo-wires to let us have your views so that we can 
see what everyone else thinks. Otherwise we'll still be debating the pros 
and cons of draft-anavi and draft-vainshtein this time next year!

Best regards,
Tim


Tel.:  +44 1752 693840
Email: tim.frost@zarlink.com

_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3