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

From: Sasha Vainshtein <[email-masked]>
Date: Tue, 1 Apr 2003 19:24:56 +0200

Tom, Tim, Yaakov and all,
I would like to add some comments both to Tim's analysis of the
issue with mandatory vs. optional structure pointer and 
to the possible resolution(s) of contention.

I would highly appreciate TECHNICAL answers to 
questions/objections raised below. And I apologize
in advance for rather a long text. But I did not have much 
choice because most of the questions raised have
never been presented before.

1. IMO, no one has really defined what exactly a "mandatory
    structure pointer" means. This does not contribute to the
    technical level of the discussion. Below I will try to explain why
    making the structure pointer mandatory carries with it a substantial
    price tag without solving any real problems. Hopefully this (in 
    addition to an already asked question - why should we go
    forward with violation of the PWE3 architectural principles) 
    would be helpful for whoever still wants to address this problem
    as a technical one.

2. What is the cost of making the structure pointer mandatory? 
    Please note that while POINTER GENERATION has been
    defined (point to the first encounter of the beginning of the 
    structure in the packet, or set the pointer to INVALID if the 
    packet payload does not contain beginning of the structure),
    POINTER PROCESSING (part of the packet play out) has NOT 
    been specified. Here are some issues related to pointer
    processing:

    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). 
        
        Note also that the stateless play out approach has been de-facto 
        accepted for all the non-TDM PWs: e.g., 

        * The PW fragmentation mechanism for the packet payload type(s) 
          (draft-ietf-pwe3-fragmentation-00.txt) is OPTIONAL and has been 
          intentionally designed in such a way that unfragmented packets 
          are indistinguishable from the packets generated by the PE that 
          does not support fragmentation
        * All the encapsulations for the cell payload type always carry 
          one or more cells per packet (never split the cells between 
          the packets).

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

    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. 

        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.

    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. 

   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. 

    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.

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

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

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

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.)
 
    These limitations are not relevant for TDM PWs carried 
    over a PSN. 

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

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

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

With best regards,
                                   Sasha Vainshtein
email:     [email-masked] <mailto:[email-masked]> 
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)