[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [PWE3] TDM draft comparison
Tim,
My comments are interleaved.
Y(J)S
> 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?)
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.
>
>
> 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.
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).
>
> 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!
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!
_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3