Subject: doubts regarding non-default mode for NxDS0 with CAS in draft-joh nson

From: Alik Shimelmits <[email-masked]>
Date: Thu, 13 Mar 2003 21:31:04 +0200

> Tom,
> 
> please, find below some doubts regarding  non-default mode for NxDS0 woth
> CAS in draft-johnson: 
> Considering an implementation wrt NxDS0 with CAS, I see several
> problematic points with it if you try to support the non-default mode. 
Support of non-default modes for NxDS0 with and without CAS seems important,
because some application will not tolerate 3 ms delay, while some others
will not tolerate 100% overhead (if N is low).
> IMO, the correct way to configure a TDM PW (including NxDS0 with CAS) is
> to specify the packetization latency first (as part of the overall TDM
> network design) and to infer from this the packet payload size (which is
> required by the PW) based on this latency and the service bit-rate. 
> *	This issue has been discussed for some time in the TDM DT and most
> people have agreed that it is important to maintain the same packetization
> latency for different number of timeslots. 
> *	This requirement is satisfied in the default mode, i.e. the
> packetization delay is always 2 or 3 milliseconds and the packet payload
> size changes as a simple function of N accordingly.
> But what if you need less packetization delay?  This may be not trivial or
> even impossible! E.g., suppose you want to carry 8, 10 or 12 timeslots of
> an ESF T1 stream with CAS. This means that you have to send 196, 245 or
> 294 bytes every 3 milliseconds. How should you achieve 1 millisecond
> packetization delay for these three services: 
> *	Peanuts for n=12 - just send 98 bytes every millisecond 
> *	Not so easy for n=10. My best guess is to send 70 bytes every 6/7 of
> a millisecond 
> *	Not so easy for n=8 either. You may go for 49 bytes every 3/4 of a
> millisecond or for 70 bytes every 15/14 of a millisecond 
> *	Even in the simplest case (n=12) you will need some intermediate
> FIFO, because your TDM payload does not produce 98 bytes in 1
> milliseconds, only 96. 
> Of course, these considerations have been based on the assumption that
> each packet has the same payload size - even if the payload is
> non-homogeneous (TDM payload and signaling). If this is not so (and, IMO,
> you do not have to use fixed packet payload size) you can simply (just
> guidelines)    : 
> *	Send a fixed number of TDM payload frames in a PW packet (in
> accordance with the required packetization latency) - similar as you do
> for NxDS0 without CAS 
> *	From time to time, append the signaling sub-structure (somehow
> indicating its presence in the control word) to some of these packets 
> *	E.g., you in the examples above you could always send 8 TDM payload
> frames (each comprising 8, 10 or 12 bytes according to the number of
> timeslots) per frame and append the signaling sub-structure to each 3rd
> frame: 
> *	In the default mode this would coinside with the draft, 
> *	In the non-default ones it would be simpler and looks more
> understandable to the operators 
> *	This would fully use the PSN (as opposed to ATM) capability of
> dealing with packets of arbitrary size
> We have always thought that fixed packet payload size is required in order
> to know how many TDM data has been lost with a single packet. But, I would
> say that if you compare the two approaches one with fixed packets and one
> described here with the variable size packets you will see that recovery
> from the packet loss is simpler in the last case.
> What do you think about this?
> 
> Regards
>          Alik
>