Subject: RE: Interworking of TDM PWs with ATM-CES (was: RE: I-D ACT ION: draft-johnson-pwe3-tdm-00.txt)

From: Shahram Davari <[email-masked]>
Date: Thu, 27 Mar 2003 11:32:09 -0800

Sasha,

> Regarding point 4, I prefer ease of interworking with ATM 
>> CES. The reason is 
>>
>Is this the reason for your preference? 

Yes.

>>
>> that if pointer is not supported, then it 
>> becomes impossible to interwork with ATM CES, without first 
>> converting the TDM emulated packets to TDM and then 
>> converting it back to ATM CES. 
>>
>I assume you mean structured ATM-CES here. My comments below are
>based on this assumption.

Yes.

>
>I also do not understand which use case you have in mind.
>If you have ATM-CES attachment circuits at two ends of the PW,
>then you do not need any conversion at all. 

Correct, but only if I use draft-davari-pwe3-aal12-over-psn-01.txt.

>
>If you have an ATM-CES attachment circuit at one end of 
>a PW and any other TDM attachment circuit at the other 
>end, then you need an NSP block converting ATM-CES to 
>TDM and back at one end.

Have a look at my presentation in Atlanta. I showed that if
TDMoPSN (or whatever name you have) is properly designed,
all you need to convert from TDMoPSN to ATM CES is a simple SAR,
which is much simpler than converting to TDM and back to ATM-CES.

>t seems absolutely logical and 
>fully consistent with the PWE3 architecture to have such an 
>NSP in the PE that interfaces to an ATM network. 

You need an NSP to do the SAR. 
>
>AFAIK, the share of FR traffic that is carried over ATM AAL5 
>in the total FR traffic exceeds by far the share of TDM traffic
>that is carried over ATM-CES in the total TDM traffic. But
>this does not prevent us from terminating ATM and AAL5 in an
>appropriate NSP before we feed FR traffic into a FRoPSN PW.

Probably no one required for that interworking to be optimized.

>>
>>
>> However, I don't think adding a pointer to the header 
>complicates the 
>> protocol that much. Also if the pointer is present then off course 
>> constant delay for every N 
>> could also be achieved. 
>>
>Constant delay for every N can be handled with or without pointer.

Correct. Just wanted to mention that Adding a pointer does not remove this property.

>>
>> So I think mandating the pointer 
>> solves 2 problems:
>> 
>> a) Ease of interworking with ATM CES
>>
>IMO it does not - because the CEP-TDM pointer does 
>not eliminate the need for full-fledged 
>generation/termination of structured AAL1 in both
>"full cells" and "partial cell fill" modes for 
>interworking with structured ATM-CES. 
>And this, IMO, is not easy. 

Please see my Atlanta presentation

>
>The situation differs substantially for unstructured 
>TDM emulation because generation/termination of 
>unstructured AAL1 is trivial and there is no 
>partial cell fill mode there. 
>
>The remaining text explains why generation/termination 
>of structured AAL1 cannot be avoided.

Again. Have a look at my presentation.

-Shahram

>
>The protocol stack for structured ATM-CES looks like following:
>
>----------------------------------------------------------------------
>Layer   |                     Function 
>        |-------------------------------------------------------------
>        |     Basic NxDS0                | NxDS0 with CAS
>----------------------------------------------------------------------
>Payload |    TDM data and frame clock as extracted from an 
>        |    E1 or T1 trunk by an appropriate framer
>----------------------------------------------------------------------
>ATM-CES | Creates a stream of fixed      | Creates a stream of fixed 
>        | size structures - NxDS0 frames | size structures ("superframe
>        |                                | structures with signaling")
>----------------------------------------------------------------------
>AAL1    | Maps the stream of fixed size structures to AAL1 SDUs by
>        | using 8-cell chains and structure pointers (one per cell,
>        | always in an even cell of the chain). May insert invalid
>        | pointers. Supports both full cell fill (the amount of 
>        | payload per cell varies) and partial cell fill (fixed
>        | amount of payload per cell), with the pointer spanning
>        | all the octets in the cell payload.  
>----------------------------------------------------------------------
>
>Now, how is this related to structured TDM emulation in draft-johnson?
>
>Its protocol stack looks like following:
>
>----------------------------------------------------------------------
>Layer   |                     Function 
>        |-------------------------------------------------------------
>        |     Basic NxDS0                | NxDS0 with CAS
>----------------------------------------------------------------------
>Payload |    TDM data and frame clock as extracted from an 
>        |    E1 or T1 trunk by an appropriate framer
>----------------------------------------------------------------------
>CEP-TDM | Creates a stream of fixed      | Creates a stream of fixed 
>payload | size structures - 16*NxDS0 or  | size structures ("superframe
>layer   | 24*NxDS0 frames (?)            | structures with signaling")
>----------------------------------------------------------------------
>CEP-TDM | Maps the stream of fixed size structures to packets of 
>encapsu-| arbitrary fixed (?) size using the structure pointer that 
>lation  | always points to the beginning pf the first structure in
>layer   | the packet.
>----------------------------------------------------------------------
>
>Note that the middle layers of the two stacks differ for basic NxDS0
>(without CAS). I have already pointed to this problem in a message
>to the list.
>
>Even if we only consider NxDS0 with CAS, we see that 
>interworking between
>the two protocols involves:
>
>o In the direction from ATM-CES to CEP-TDM - termination of 
>structured AAL1
>  and generation of CEP-TDM. This operation can be simplified 
>for the "full 
>  cells" mode if you force the payload of TDM packets to 
>7*47+46=375 bytes 
>  ignoring any latency problems that may occur. If the 
>"partial fill" mode
>  is used, it can be simplified if the packet payload size is 
>a multiple
>  of the number of used bytes per cell. In any case it must cope with
>  the case of invalid pointer in a specific chain.
>o In the direction from CEP-TDM to ATM-CES - termination of CEP-TDM and
>  generation of AAL1. I do not see any substantial "shortcuts" 
>in this case
>  even if you use some "preferntial" packet payload size.     
>>
>... stripped to the end ...
>

---

From: Sasha Vainshtein <[email-masked]>
Date: Thu, 27 Mar 2003 22:15:23 +0200

Shahram and all,
Please see some comments inline.

----------------------------------------------------------------------------
--------
With best regards,
                          Sasha Vainshtein
email:   [email-masked] <mailto:[email-masked]> 
phone:  +972-3-7659993 (office)
            +972-8-9254948 (home)
            +972-58-674833 (cellular)

> -----Original Message-----
> From: Shahram Davari [mailto:[email-masked]]
> Sent: Thursday, March 27, 2003 9:32 PM
> To: Sasha Vainshtein
> Cc: [email-masked]'; [email-masked]
> Subject: RE: Interworking of TDM PWs with ATM-CES (was: RE: 
> [PWE3] I-D ACT ION: draft-johnson-pwe3-tdm-00.txt)
> 
> 
> Sasha,
> 
I intended to ask "is the pointer you reason for preferring
interworking with ATM-CES interworking to latency control?
I was probably misunderstood...
... snipped ...
> You need an NSP to do the SAR. 
Which SAR? If you mean packetization and
de-packetization, this is not SAR and this is not
part of an NSP either. Please see Section 4.2 of the
latest Architecture draft for details.
... snipped...
> Please see my Atlanta presentation
Unless I am mistaken, your Atlanta presentation did not
discuss CEP-TDM (among other things, because it has 
been only published later...)
> Again. Have a look at my presentation.
Do you mean your SF presentation or your Atlanta one?
... snipped to the end ...

---

From: Shahram Davari <[email-masked]>
Date: Thu, 27 Mar 2003 12:22:51 -0800

Here is my Atlanta presentation. Check slides 4, 5.

-Shahram

>From: Sasha Vainshtein [mailto:[email-masked]]
>Sent: Thursday, March 27, 2003 3:15 PM
>To: Shahram Davari

---

From: Sasha Vainshtein <[email-masked]>
Date: Thu, 27 Mar 2003 22:31:50 +0200

Shahram and all,
As I have said already, your Atlanta presentation
deals with TDMoIP (aka draft-anavi) but not with 
CEP-TDM (aka draft-johnson). 
AFAIK, draft-anavi does not deal with pointers etc.

> Sent: Thursday, March 27, 2003 10:23 PM
> To: Sasha Vainshtein

---

From: Shahram Davari <[email-masked]>
Date: Thu, 27 Mar 2003 12:55:23 -0800

Sasha,

The only difference between interworking ATM CES with TDMoIP
and CEP-TDM is the requirement for pointer conversion from ATM-CES to CEP-TDM and
vice versa, which is straight forward. It just requires an offset for the P-cell to be
added to the ATM-CES structure pointer.

-Shahram

>Sent: Thursday, March 27, 2003 3:32 PM
>To: Shahram Davari

---

From: Sasha Vainshtein <[email-masked]>
Date: Fri, 28 Mar 2003 11:19:58 +0200

Shahram and all,
I believe that the conversion of pointers is required 
in both directions. The method you have described
(ATM-CES PTR --> TDM CEP PTR) will work for the "full cell"
mode with 375 bytes per packet (and associated packetization
latencies). But the reverse conversion is not simple;
and without it there is no interworking. 

> Sent: Thursday, March 27, 2003 10:55 PM
> To: Sasha Vainshtein