Subject: latency control for TDM pseudo-wires and ATM-CES

From: Alik Shimelmits <[email-masked]>
Date: Thu, 27 Mar 2003 20:09:51 +0200

Guys,
in the ongoing discussion of TDM drafts in the PWE3 WG the 
need/ lack of interworking with ATM Circuit Emulation 
(ATM-CES for short) was mentioned as the requirement alternating
the need to have controlled latency. That rather surprised me 
and I came to conclusion that ATM-CES interworking has not been 
really discussed in PWE3 WG. 

Below I try to give my answer to the following questions:
a) what exactly "interworking with ATM-CES" means?
b) how draft-anavi / draft-davari answers to this requirement.

1. The following use case requires some solution for interworking 
with ATM-CES:
- A pair of PEs provide a PW carrying some TDM payload between 
  a couple of CEs
- The attachment circuit between PE-1 and its local CE-1 is a classic 
  TDM circuit (e.g., T1 over copper)
- The attachment circuit between PE-2 and its local CE-2 is a TDM 
  circuit carried over ATM AAL1 [AAL1] as described in [ATM-CES].

I am not aware of any other use case for the ATM-CES interoperability 
problem.

2. The obvious way to support such a PW would be:
- Terminate AAL1 and ATM-CES in PE-2 extracting the relevant TDM 
  circuit (ATM-CES payload). This functionality is performed by an 
  ATM-CES IWF acting as an appropriate NSP in PE-2, and the TDM 
  circuit is fed into the PW IWF
- Create the PW between the IWF in PE-1 (which is fed by a native 
  TDM attachment circuit) and its counterpart in PE-2.

Such an approach is fully consistent with the PWE3 architecture.
It was selected as solution for interworking with ATM attached 
circuits for Frame Relay and Ethernet application as well as the 
solution for, say, T1 attachment circuits multiplexed in T3.

This straightforward approach mandates termination of  AAL1 and  
ATM-CES in the device (PE-2) that acts as a gateway between ATM 
and PSN networks. 

IMO, an alternative solution should only be considered if it is very 
simple and straightforward.

3. draft-davari presents another approach:
- Extend the AAL1 circuit over PSN from PE-2 to PE-1 
- terminate an AAL1oPSN PW, AAL1 and ATM-CES in an appropriate NSP 
  in PE-1.
 
This approach mandates termination of AAL1 and  ATM-CES in a device 
(PE-1) that is not a gateway  between  ATM and PSN networks.
(I do not see any logic in it).

The approach presented in draft-anavi is IMO different from 
draft-davari, because the former does not provide for any 
demarcation between the AAL1/ATM-CES function and an ATM PW IWF. 
This difference can be clearly when it comes to methods of handling 
lost PW packets in the two drafts:
- draft-davari (with the modifications presented in SF) mainly 
discusses the ways to allow the AAL1 path terminator to handle 
the resulting loss of (consecutive) cells 
- draft-anavi speaks about the need to "preserve correct 
synchronization bits". 

Hence I do not think that draft-anavi really addresses the ATM-CES 
interworking issue.

4. Another important item that IMO has not been discussed till 
now is how (native) ATM-CES deals with the segmentation latency 
(analog of the packetization delay in the PSN world).

As far as I know:

a)  ATM-CES deals separately with emulation of structured and 
unstructured TDM circuits.

b) Segmentation latency in unstructured TDM emulation is ~0.25 
milliseconds for T1 and ~0.184 milliseconds fot E1. In other words, 
it is low enough to ignored.

c) For emulation of structured TDM services 
(i.e. NxDS0 and NxDS0 with CAS) ATM-CES supports two modes:

  * Fully filled cells. In this case the segmentation latency 
    is a function of N. Not only does it result in high latencies, 
    but the fact that the latency varies for different N
    is often unacceptable.
  * Partially filled cells. In this mode the user specifies the 
    (fixed) number of bytes that are used to carry the TDM payload 
    in each cell. This mode allows full control of segmentation 
    latency and, if necessary,  makes it independent of N, but it 
    carries with it a heavy price - the BW efficiency becomes low. 
    E.g., if you want to support 1 ms segmentation latency for a 
    4xDS0 circuit, you only use 32 bytes out of 47/46
    available in each cell, i.e 50% overhead.
 *  While the ATM Forum spec defines the partial fill mode for 
    emulation of structured TDM as OPTIONAL, de-facto most ATM-CES 
    processors implement it - because the need to provide low 
    segmentation latency and its independence of N are well recoginzed. 
    And (not surprisingly) there are people who use this mode.

To sum it up:
- interworking with ATM attached circuits differs for structured and 
unstructured services;
- for structured services implementing "partial fill" approach extending 
AAL1 circuit over PSN is extremely BW-ineffective;
- ATM-CES termination block must support "partial fill" mode.

My 2c (rather long may be ;-)
	Alik