Subject: TDM draft comparison

From: [email-masked]
Date: Thu, 13 Jun 2002 15:52:27 +0100

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: [email-masked]

---

From: Shahram Davari <[email-masked]>
Date: Fri, 14 Jun 2002 08:03:08 -0700

Hi Tim,

> 1. Data encapsulation format

It is true that AAL1 method needs somewhat more processing. But there
are a number of advantages to it:

1) AAL1 was designed to do unstructured, structured and structured W/CAS emulations for T1/E1/T3/E3. It is a proven technology that works perfectly fine. So why invent a new protocol? It is always possible to invent new protocols that are better optimized to specific scenario, but then we will end up with tons of protocols and their
N^2 interworking headache.

2) AAL1 hardware and software are already developed and available, so taking advantage of this fact means no need for new development, verification, validation, lab and field testing. Which translates to faster time to market and better chance of being adopted by vendors.

3) AAL1 can do very nice SRTS time recovery that is easy and proven.

4) ATM's weakest point (i.e., cell tax) is not present. 

Yours,
-Shahram

---

From: Stephen Thomas <[email-masked]>
Date: Fri, 14 Jun 2002 12:59:09 -0400

I'm not enough of a TDM or ATM expert to provide credible details, but it 
seems like it ought to be possible to create a protocol header that is 
sufficiently flexible to accommodate both encapsulation methods. 
Conceptually, include the ATM-style fields in the protocol header but add a 
flag that indicates whether they are used (or set them to zero for 
non-use). There is a lot of precedent for this (see UDP checksum), and, 
ultimately, it allows the market to decide whether or not the additional 
capabilities are justified.

---

From: Yaakov Stein <[email-masked]>
Date: Thu, 20 Jun 2002 08:29:33 +0300

> -----Original Message-----
> From: Stephen Thomas [mailto:[email-masked]]
> Sent: Friday, June 14, 2002 7:59 PM
> To: [email-masked]; [email-masked]
> Cc: Sasha Vainshtein; Yaakov Stein
> Subject: Re: [PWE3] TDM draft comparison
> 
> 
> I'm not enough of a TDM or ATM expert to provide credible 
> details, but it seems like it ought to be possible to create a protocol 
> header that is sufficiently flexible to accommodate both encapsulation
methods. 
> Conceptually, include the ATM-style fields in the protocol 
> header but add a flag that indicates whether they are used (or set them to
zero for 
> non-use). There is a lot of precedent for this (see UDP 
> checksum), and, ultimately, it allows the market to decide whether or not
the 
> additional capabilities are justified.

Not only is it POSSIBLE, I have suggested this on multiple occassions,
and held a reserved FORMID value (FORMID=0) in the TDMoIP control word 
to accomodate this.

Unfortunately, for reasons I can not fathom,
there has been no response to this suggestion.

Since someone else has brought this up,
I am now going to add the CESoPSN option to the next update of my draft.

Since the new Martini header now leaves me only 4 bits for the control word,
I propose the following instead of the present text in Section 2.4

FORMID    payload type
 0000   raw (unadapted) frames
 0100   AAL1 unstructured
 0101   AAL1 structured 
 0110   AAL1 structured w/ CAS
 1000   AAL2
 1111   HDLC for CCS signaling

Y(J)S

---

From: Yaakov Stein <[email-masked]>
Date: Thu, 20 Jun 2002 08:59:43 +0300

Tim,

My comments are interleaved.

Y(J)S

> 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.

The additional processing power for the AAL1 mode is almost zero.
Certainly much less than that required to handle the CAS bits by the
method proposed in the latest CESoPSN draft.

There are, in addition, three other benefits.
1) The use of tried and true technologies.
2) The ability to handle dynamic timeslot allocation
    using AAL2 (which CESoPSN can not handle).
3) Simplified service interworking with access networks
   and cellular networks.
 
> 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. 

You are missing an essential point.
If TDMoIP does not receive a number of packets, 
then we can replay the previous multiframes and 
hence retain the previous signaling bits.

Were CESoPSN try to spoof it would send incorrect
CAS bits and cause incorrect hookings.
People do not like their phones hanging up on them
in the middle of a call.

> The argument for draft-anavi is that carriage of the 
> signalling within the data packet is straightforward, 
> and provides for minimum intervention 
> 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 
> 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. 

I haven't seen any new efficiency figures from Sasha since
he has added the new CAS signaling packets. Let's see,
he is proposing to send a special packet with 4 bytes for every timeslot
and all the IP/UDP/RTP overhead. And this packet is sent three times
for redundancy. So, assuming that this packet is collected per the draft
every 5 milli we are talking about over 30 percent additional overhead! 

Also, 5 millisec of storing up CAS signaling bits will not work
in some cases (e.g. fast pulse dialing).

> intervention" most. My preference is to keep the dataplane as 
> clean and simple as possible to make for easy, fast, high-thoughput 
> implementation, 
> handling. Including ATM functionality in the dataplane 
> doesn't achieve this.

> 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.
> 
> 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 
> 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 

Tim - Of course you are a protagonist as well,
being a co-author of the latest CESoPSN draft.
So we still don't have anyone else commenting!

---

From: [email-masked] (Amnon Ilan)
Date: Sun, 23 Jun 2002 11:28:47 +0200

Hi All,

Here is an opinion from someone more objective (didn't write any draft yet).
I'll start with the bottom line: when trying to choose between an already
stable protocol and a new protocol
there should be some very strong advantages on the new one in order to
choose it.
IMHO this is not the case here. CESoPSN may have some minor advantages, as
well as some
disadvantages.
Looking from the market perspective (customers, not equipment
manufacturers), there is no reason to invent
a new protocol from scratch when you can use something that is already
working.
As you all know, it takes several years for a protocol to become stable.
VoATM is already behind this evolution.
In fact, looking at CESoPSN evolution you may find many similarities to
VoATM: in the beginning it was a very
simple, strait-forward AAL1, than CAS support was added, than dynamic
bandwidth,  and than AAL2 was developed
in order to support switched voice services. Why go through all this again?
Now for some more practical points in favor of TDMoIP:
1.  Most of the vendors producing voice-over-packet solutions are supporting
VoIP and VoATM (AAL1/AAL2). Taking
their AAL1/2 packets and send it on RTP is much simpler. From market
perspective this means faster time-to-market,
higher stability of new products etc.
2.  The main market is ILECs. ILECs are conservative. ILECs are starting to
know VoATM and VoIP. It would be much easier
to make use of this knowledge.
3.  Interoperability with existing and new VoATM/VoDSL networks is very
important (see cellular expected roadmap
as an example).

Regards,

Amnon Ilan,
Optical Access.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Yaakov
Stein
Sent: Thu 20 June 2002 8:00
To: [email-masked]'; [email-masked]
Subject: RE: [PWE3] TDM draft comparison

Tim,

Y(J)S

structure
arrives.
framers
equipment will
will

network.

aimed
introduced

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3

---

From: Shahram Davari <[email-masked]>
Date: Mon, 24 Jun 2002 07:04:47 -0700

Hi All,

I (also not one of the authors of these drafts) would like to second Amnon's
opinion. Unless there is strong advantages we should not invent new protocols
that do exactly what existing protocols do. 

We should try to reuse proven technologies. This is beneficial to both vendors and
operators. It reduces cost and improves time to market. 

In my opinion the two reasons that were raised against AAL1 solution are not strong enough to warrant a new protocol:

- AAL1 SAR is easily done today at 2.5G and 10G rates, so there is no technical issue here.

- In case of a packet drop that contains a pointer, on AVERAGE only ~ 3.5 cells will be unused from the next packet. This is not a major issue, because EF-PHB should not drop packets.

Also as I understand the TDMoIP (AAL1) is already operational in the field without any problem for over 2 years.

The choice is yours. 

Thanks,
-Shahram  

> From: [email-masked] [mailto:[email-masked]]
> Sent: Sunday, June 23, 2002 5:29 AM
> To: 'Yaakov Stein'; [email-masked]'; [email-masked]

---

From: "Prayson Pate" <[email-masked]>
Date: Mon, 24 Jun 2002 22:40:42 -0400

Amnon,

Please see my comments below.

Prayson

> From: [email-masked] [mailto:[email-masked]]On Behalf Of Amnon
> Ilan
Prayson - Like beauty, objectivity is in the eye of the beholder.  ;-)

> higher stability of new products etc.
Prayson - While this may be true, I don't think that the solutions being
offered by the VoATM vendors support transparent emulation of an entire T1,
E1 or T3.  I think that these rates are an important part of the application
space.

> to make use of this knowledge.
Prayson - I agree that the ILECs are conservative, but I don't think that
their small degree of familiarity with VoATM will translate into easier
acceptance of PWE3 solutions because they are based on AAL1/2.  I think that
encapsulation will be the least of their concerns.

> important (see cellular expected roadmap
Prayson - The number of existing SONET networks dwarfs the number of
VoATM/VoDSL networks.  If ease of implementation of the
encapsulation/adaptation function of the PE is of interest, then a SONET/VT
encapsulation should be used (as described in draft-pate-pwe3-tdm-03.txt).

---

From: "Prayson Pate" <[email-masked]>
Date: Mon, 24 Jun 2002 22:46:28 -0400

Shahram,

You mentioned that "AAL1 SAR is easily done today at 2.5G and 10G rates" in
response to an argument against AAL1.  Whose objection were you addressing?
I seem to have missed it on the mailing list.

Thanks,
Prayson

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Shahram Davari
> Sent: Monday, June 24, 2002 10:05 AM
> To: [email-masked]'; 'Yaakov Stein'; [email-masked]';
> [email-masked]
> In my opinion the two reasons that were raised against AAL1
> solution are not strong enough to warrant a new protocol:
>
> - In case of a packet drop that contains a pointer, on AVERAGE
> only ~ 3.5 cells will be unused from the next packet. This is not
> a major issue, because EF-PHB should not drop packets.
>
> Also as I understand the TDMoIP (AAL1) is already operational in
> the field without any problem for over 2 years.
>
> The choice is yours.
>
> Thanks,
> -Shahram

---

From: [email-masked] (Amnon Ilan)
Date: Tue, 25 Jun 2002 19:23:54 +0200

Prayson,

Please see my comments bellow.

Regards,
Amnon.

-----Original Message-----
From: Prayson Pate [mailto:[email-masked]]
Sent: Tue 25 June 2002 4:41
To: [email-masked]; 'Yaakov Stein'; [email-masked]';
[email-masked]

Amnon,

Prayson

Amnon - Says another TDMoPSN draft writer... ;-)

Amnon - This is what basic AAL1 is about: circuit emulation of the entire
T1/E1/T3.
AAL2 has these capabilities as well with grater flexibility in voice channel
switching
(transparent emulation of entire trunk is a private case of AAL2).

Amnon - Then what are their main concerns?
What are the advantages you see in your VT draft that meet these concerns?
I'm sure some of their concerns are:
- To have a stable and working protocol soon (encapsulation is not the only
issue here).
- To have many vendors with such a solution (as I said AAL1/2 migration to
RTP is easy for current vendors).
- To have the solution as interoperable as possible (AAL1/2 will
interoperate easily with VoATM and run on SONET/SDH).

Amnon - AAL1/2 supports both VoATM networks and SONET networks (since ATM
runs on SONET).
There is the overhead of ATM to SONET but this is done already by low cost
chips and IP cores (no
need to reinvent anything here).