Subject: RE: Mandatory Structure Pointer for TDM PWs (was: RE: I-D ACTION:draft-johnson-pwe3-tdm-00.txt)

From: "Yaakov Stein" <[email-masked]>
Date: Tue, 1 Apr 2003 20:08:29 +0300

Sasha, 

Thanks for your insightful and technically relevant comments.

I respond partially below, 
but due to the late hour here, will respond more fully tomorrow.

You will forgice me if I snip a little,
in order to make the reading easier.

Y(J)S

> 1. IMO, no one has really defined what exactly a "mandatory
>     structure pointer" means. 

My original statement to the TDM DT was clear, but perhaps not repeated on the list.
When transmitting you can choose to send 125 microsec
packets, in which case the pointer is identically zero.

However, the receiver MUST be able to properly interpret
a packet which is not precisely 125 microseconds in length.

>     a) Play out of the packet payload becomes STATEFUL. 
>         Or, in other words, independent play out of payload of a 
>         single packet is not possible any more. 
>         This is an explicit contradiction both to the TDM requirements 
>         document (draft-ietf-pwe3-tdm-requirements-00.txt, Section 7.3.1) 
>         and to the recommendations of RFC 2736 (which is explicitly 
>         referenced in the PWE3 Charter). 

The playout is no different then when full-frames are used.
When a packet arrives, its contents are appended to a jitter buffer,
which is played out independently of the arrival rate.

This is not a consequence of using the pointer,
this is a requirement for the TDM service
which requires timing to be preserved.

>         Note also that the stateless play out approach has been de-facto 
>         accepted for all the non-TDM PWs: e.g., 

The other services you detail do not have the real-time constraints
of TDM, and hence the comparison is not exact.

You can play out ATM cells or FR frames whenever you want,
you needn't hold them until their time comes.

>     b) As a consequence of (a), handling of lost packets becomes 
>         more complicated ( the lost pointer must be reconstructed as 
>         part of this handling)

Once again, there is no essential difference between 
the pointer-free and the pointer-used cases
from the data play-out point of view.

In both cases, TDM data must be inserted, 
at least in order to preserve the TDM clock
(and perhaps to conceal the packet loss event).

In the pointer-free case you have to calculate the
number of lost packets times the number of frames per packet
times the number of octets per frame, and play-out that
number of interpolated octets.

In the pointer-used case you have to play out octets
until the octet the pointer points to is reached,
or alternatively, until the first correctly received octet,
which can be determined relative to the pointer by a single subtraction.

> 
>     c) The pointer processing must define detection and 
> handling of the pointer "jumps",  i.e., the situations when the 
> segment between the two pointers cannot be broken into structures of the 
>         specified size. 

What size? The whole idea of the pointer
is to change the "frame-stream" into a byte-stream.
You can then use any size you want.

> 
>         Note that this situation can be detected when part of the segment 
>         has been already played out, so its handling is non-trivial. 
>         Note also that detection of pointer jumps is stateful and must 
>         cover the situation when one or more INVALID pointers have 
>         been encountered between two valid values.

Yes, the problem of an incorrect pointer is a valid one.

This is one reason I prefer the draft-anavi method to the draft-johnson one.
In draft-anavi the pointer is strongly protected by an error correcting code.

>     d) If the TDM (or TDM-like) structures are not homogeneous, the fact that 
>         they may be spread between several packets adds to the complexity 
>         of the play out. E.g., if your "CAS signaling" substructure is spread 
>         between two packets, when exactly should it be played out? Another 
>         example could be adding a kind of Path Overhead Monitoring
>         (POM) function at egress of SONET PWs.

The TDM requirements draft does not talk about TDM-like structures,
only true TDM structures, which by definition are quite homogenous.
 
> 
>    So much for the cost of a mandatory structure pointer. 
> 
> 3. Which problems can be solved with the structure pointer?
>     AFAIK, using the structure pointer solves one and only one 
>     problem: decoupling between the fixed size of structures 
>     constituting the structured bit-stream payload and fixed size 
>     of the PW packets' payload. 

That is precisely the idea.

> 
>     I can identify three cases when this problem may be encountered:
> 
>     a) The TDM structures exceed Path MTU and hence must be 
>         fragmented between several packers. This is definitely NOT 
>         the case for basic (aka without CAS) NxDS0, where the size 
>         of the structure is just N. 
>         I will discuss the case of NxDS0 with CAS below.
>         (IMO this answers Lloyd's remark.)
> 
>    b) The TDM structures take too long to packetize. This 
>        situation is not relevant for basic NxDS0 (just 125 uS 
>        to packetize the structure in question). 
>        I will discuss the case of NxDS0 with CAS below.

I don't see either of these cases as being important.

The true reason is to allow maximum flexibility
in the overhead vs. latency trade-off.

>    c) The packet payload size must meet some conditions that 
>        stem neither from the nature of the TDM traffic (case  "b" above) 
>        nor from the nature of the PSN (case "a" above).

Quite the contrary, the reason can be exactly the nature of the PSN.
For example, in multi-access wireless applications, there is a strong requirement
to completely fill up the packet (since you have no idea how long you
will have to wait until getting permission to transmit again).

This translates to a precise number of bytes in the payload.

Unfortunately, this number of bytes does not correspond to
125 microseconds.

I have given several other examples in the past.

> 
>        I am aware of exactly one such use case: the declared 
>        "simple interworking" between structured ATM-CES and 
>        CEP-TDM.  And      I am afraid that, while such limitations 
>        may be NECESSARY, they are  NOT SUFFICIENT 
>        for this purpose - a well-known logical error. This really 
>        bothers me because, AFAIK, no one has ever specified 
>        how this "simple interworking"  works, i.e. how a stream of 
>        AAL1 cells is converted into CEP-TDM packets and 
>        vice versa - with the same level of detail it has been done 
>        for packetization and de-packetization of TDM streams. 

I think you should look at Shahram's draft.

In any case, as you know the method has been widely deployed
and implemented by multiple vendors.
This is an existence proof to its definability.
    
>        (If somebody wants to know why it is NOT SO SIMPLE, 
>        please consider how loss of an AAL1 cell should be detected
>        and handled by the packetizer. Somehow no one has 
>        bothered to define this aspect of interworking as if we 
>        are discussing just the "special case" when the ATM-CES 
>        engine resides directly in the PE device.  IMO this "special 
>        case" has nothing in common with interworking with ATM-CES.

This point too has been discussed at length with regards to Shahram's draft.

It is true that using atm-encap with AAL1 is inferior to using draft-anavi
when multiple (i.e. 8 or more) cells are lost.
 
>        I strongly suspect that if we really look into this issue we shall 
>        find out that the AAL1 sublayer of ATM-CES must be fully 
>        terminated/regenerated for any robust interworking with ATM-CES. 
>        If you take into account that off-the-shelf available HW usually 
>        terminates both AAL1 and ATM-CES sub-layers, simplicity 
>        of a solution that must fully terminate just AAL1 becomes 
>        highly problematic.) 

Full termination is not required.
Once again I refer to draft-davari.

> 4. As I have said already, the structures (TDM frames) associated 
>     with the basic NxDS0 are neither long (just N octets) nor take 
>     long time to packetize (just 125 microseconds).
>     So what about NxDS0 with CAS? The "superframe structure 
>     with signaling" described in draft-johnson is not too long 
>     (up to 588 bytes) but, maybe, it takes too much time
>     to packetize (2 ms for E1 and 3 ms for T1)?
> 
>     IMO this is a MISUNDERSTANDING because the 
>     "superframe structure with signaling" DOES NOT EXIST 
>     anywhere in the TDM traffic. It has been first invented by 
>     the ATM-CES designers because they had to overcome 
>     the limitation of structured AAL1. ( The latter
>     has been designed to carry streams of structures of 
>     arbitrary, but FIXED size over ATM.)

Superframes DO exist in the TDM,
and the 2-3 ms only depends on their existence,
not on the repetition of the signaling.

The signaling substructure is indeed an artificial
construct, designed to simplify handling of the fractional
E1/T1 case.

>     These limitations are not relevant for TDM PWs carried 
>     over a PSN. 

But they are!  For many applications (the most notable being CAS)
the superframes MUST be preserved.

>     Yes, there is an important and valid requirement to carry 
>     fixed amount of TDM data per TDM PW  packet - 
>     because this allows to generate the correct amount 
>     of "replacement data" if a PW packet has been lost 
>     in a stateless way. And, yes, if you only carry TDM 
>     data in the PW packets, it is equivalent to having the 
>     packet payload size fixed. But if you spread 
>     "superframe structures with signaling" among 
>     several PW packets with fixed  payload size you 
>     VIOLATE this requirement (because in the common case
>     each packet would carry a variable amount of TDM data 
>     and a variable amount of CAS signaling; only the sum 
>     of the two would be fixed).

Unfortunately, when sending full frames,
but not full superframes, you violate the requirement
of being able to reconstruct the TDM information stream
(which includes the signaling) based only on the packet.

And no one was suggesting spreading signaling substructures
over several packets. So there was no reason to set up this
strawman just in order to knock it over.

>     On the other hand,  I do not see any problem with a 
>     solution for NxDS0 with CAS that:

You don't ?
> 
>     a) Carries fixed amount of TDM data (agreed upon at 
>         the PW setup) per PW packet 
>     b) From time to time, appends a CAS signaling substructure 
>        to these packets (so that the packet payload size varies!)

This is a clear violation of the principle you keep reminding us
about, the reconstruction of the information based only
on the present packet.

In addition, the loss of the packet with the signaling
substructure becomes a much more critical event
than the loss of a signal-less packet.

>     c) Indicates the presence of these substructures in some 
>         way in the PW header (the exact method is TBD).
> 
>     Such a mechanism would be compatible with the default 
>     mode for NxDS0 with CAS described in draft-johnson-pwe3-tdm-00.txt 
>     without introducing problems in non-default modes already 
>     discussed at this list.

Such a mechanism IS draft-johnson,
and is insufficient for the reasons we have discussed at length in the past.

1) It does not robustly carry CAS or CCS signaling
2) It does not enable flexible tradeoff of overhead for latency
3) It does not enable satisfying specific PSN requirement (see above)
4) It needlessly complicates interworking with existing CES
    which could be accomodated by the mere introduction of a pointer
   that you need not transmit if you don't need it.

---

From: Sasha Vainshtein <[email-masked]>
Date: Wed, 2 Apr 2003 19:26:30 +0200

Yaakov and all,
Thank you for a really prompt response.
Please see some comments 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: Yaakov Stein [mailto:[email-masked]]
> Sent: Tuesday, April 01, 2003 7:08 PM
> To: Sasha Vainshtein
> Cc: [email-masked]
> Subject: RE: Mandatory Structure Pointer for TDM PWs (was: 
> RE: [PWE3] I-D ACTION:draft-johnson-pwe3-tdm-00.txt)
> 
> 
> Sasha, 
> 
... snipped ...
>
> You will forgive me if I snip a little,
OK with me (even if you have forgotten to mark your snips...)
> a packet which is not precisely 125 microseconds in length.
Sorry, but I do not see "not precisely 125 microseconds" as a 
technical specification.
> which is played out independently of the arrival rate.
If you imply that pointers can be ignored at playout of packets,
then why should anybody bother to put them in?
If they are not ignored (as I suspect), then their processing 
must be defined. I do not see this definition in your text.
... snipped...
> which can be determined relative to the pointer by a single 
AFAIK, in emulation of NxDS0 you do not play out "octets":
you play out frames, i.e. you take care to play out N octets 
that have been received, each from its specific DS0 channel, 
in the same 125 microseconds frame at ingress within the same 
125 microseconds frame at egress; and you take care that each
packet goes to its appropriate DS0 channel as well. This is
called "frame integrity", and NxDS0 emulation MUST preserve that.
If the packet is aligned with the NxDS0 frames, your playout and 
replacement (in the case of packet loss) are simple. 
If the packet is NOT aligned with NxDS0 frames, you must handle 
incomplete frames at two ends of the packet; the incomplete frame
from the last received packet becomes the state for playing out the
next one. And if you cannot "glue" the incomplete frame at the end of
the previous packet with the incomplete frame at the start of the
next one into a single frame, you have a problem.
> You can then use any size you want.
You may be surprised, but structured TDM emulation is about
preserving structures across the PSN, and these structures have
size, and you do not have much control over it. E.g., the structure
to be preserved for emulation of NxDS0 is a single TDM frame, and
its size is N. We may have different opinions wrt the structure that
must be preserved for emulation of NxDS0 with CAS, and it is worth
to specify it explicitly.
... snipped...
> In draft-anavi the pointer is strongly protected by an error 
AFAIK draft-anavi does not define pointer processing. 
It relegates this to structured AAL1. And, BTW,  adding an 
even parity bit to a 7-bit AAL1 pointer does not enable any 
error correction. 
> only true TDM structures, which by definition are quite homogenous.
Is the "superframe structure with signaling" homogeneous? 
I agree, though, that it is neither part of the TDM stream nor is 
mentioned in the TDM requirements draft...
> > 3. Which problems can be solved with the structure pointer?
... snipped ...
> I don't see either of these cases as being important.
The first case is definitely encountered with SONET emulation.
And that is (AFAIK) the source of the structure pointer in draft-johnson.
> in the overhead vs. latency trade-off.
I believe you do NOT imply that, for NxDS0, the single byte 
granularity of the packet size is that much more flexible than 
the granulalrity of N bytes?
> will have to wait until getting permission to transmit again).
How do you run IP/MPLS over such a network? Do you pad all your
IP packets (e.g., TCP ACKs) to the full packet? 
How do you run FRoPSN over such a network? The Martini CW
supports only padding to 64 bytes, right? 
IMO, something is fundamentally wrong with your example.
... snipped ...
> I think you should look at Shahram's draft.
Shahram's draft defines ONLY a method to carry AAL1 cell streams over PSN. 
And, BTW, I am OK with this method for this application.
> This is an existence proof to its definability.
As I have said already, draft-anavi does not define any
pointer processing: it relegates it to AAL1.   And, AFAIK, 
draft-johnson has NEVER been implemented. Hence I doubt that
your "proof of definability by existence" is applicable and think
that the definition must be present in the spec. 
> This point too has been discussed at length with regards to 
I suggest you take a careful look at Shahram's draft: it does not say 
anything at all about it. 
> when multiple (i.e. 8 or more) cells are lost.
AFAIK, atm-encap and draft-anavi discuss two different things:
one deals with ATM cell streams while the other - with TDM.
So your comparison is totally out of context.  
> Once again I refer to draft-davari.
You can refer to draft-davari as much as you wish: it does not say
ANYTHING on the subject. It simply explains how the ATM-ENCAP
mentod can be applied to AAL1 cell streams.
> construct, designed to simplify handling of the fractional
I agree with your position presented on this list that there 
is no need to preserve MF strcutures because native 
TDM equipment (DS0 cross-connect) does not preserve them. 
So, let's do the following evident step and ask:
Why should we try to carry "artifical constructs" over PSN?
> the superframes MUST be preserved.
I think that you contradict yourself (see above) wrt preservation of MF. 
And the limitations I have been speaking about have been ones of AAL1, 
not of TDM.
But if we must preserve MF synchronization - which I doubt - then 
I would ask: " what is the best way to do that?" 
> (which includes the signaling) based only on the packet.
Glad to know that this requirement is important to you. 
And no, it is not violated.  Please re-read the text in the original 
email. 
> strawman just in order to knock it over.
The issue is not what is someone suggesting. The question is 
what is (or is not) defined. The current revision of draft-johnson  
does not provide any  guidelines for generation of packets in 
non-default modes. This is the place that definetely
needs clarification to avoid misinterpretation problems. 
And this MUST be done before requesting that the structure 
pointer becomes mandatory.
So this may be a strawman, but I did not set it up;
rather, you did (and still do) by requesting the pointer being 
mandatory. 
> about, the reconstruction of the information based only
I have answered this already. I think that the proposal is clear enough.
> than the loss of a signal-less packet.
No it is not - depends on how often you send your packets
with the signaling substructure.
... snipped ...
>    that you need not transmit if you don't need it.
Which CES? I believe you have said in a previous mail that the pointer
only marginally helps in interworking with ATM-CES.