Subject: Comments/ questions to draft-riegel-pwe3-tdm-requirements-01.txt

From: Alik Shimelmits <[email-masked]>
Date: Mon, 23 Dec 2002 11:02:16 +0200

Max and all,
Please, find below some comments and questions. May be some of them are
rather trivial but I think it would be better to deal with them EXPLICITLY.

SECTION 5.2
Q1. What is the difference between structured E1, T1 and nx DS0 as it
mentioned in 5.2?

- about n x DS0:
Q2. Is there requirement for DS0s in the bundle to be consecutive or not?
Q3. Whether PW should support DS0s "cross-connect" over PSN,i.e. whether
DSOs at both sides of PW may be different, e.g. [1,2,3] at the local side
and [7,8,9] at the remote one?
Q4. How many nxDS0 PW end-points may be defined on a single T1 or E1
interface? Actually, whether distributed DS0 cross-connect over PSN may be
implemented using nxDS0 emulated PWs?
Q5. Is it possible to connect n x DS0 bundle residing on T1 with the n x DS0
residing on E1?

- n x DS0 versus n x DS0 with CAS
I see a problem here. I think n x DS0 must maintain frame integrity, i.e.
all DS0s within the bundle should be played out exactly with the same delay.
Frame integrity is the MUST requirement when you carry bundle of DS0s as a
whole (and that happens when you provide just transparent pipe and not aware
about type of running traffic, e.g. data). To some extent this approach is
similar to the notion of concatenated containers in SDH / SONET. This is the
major difference between  n x DS0 and n x DS0 with CAS! When we consider n x
DS0 with CAS we can safely state that we deal with voice channels. Each
voice channel should be synchronized with its own signalling but there is no
requirement for synchronization between channels! And this is extremely
important. Actually, n x DS0 with CAS deals with independent voice channels
that are packed into common packets for bandwidth effeciency only. So, the
next step to improve bandwidth efficiency in this application we usually
activate idle suppression (i.e. not transmit the specific DS0 when it is in
"on-hook") and then VAD (voice activity detection). And so on.. I.e. we
operate per DS0. BTW, that also allows introduction of more gentle
congestion control that may operate at the DS0 level, especially when
"coming back".
	I assume that this fundamental difference in the requirements that
can or cannot to lead to different solutions but I'd propose at least to
include that into requirements document and not to consider these two
different applications under the same application space.

SECTION 5.3
Q1. reference on VC-13 in section 5.3 - is it just a mistyping?
most of the questions below are similar to the questions on the n x DS0
section (above). That is not surprising for me because intuitively both n x
DS0 and n x VC-x look similar (sub-structures of a single server structure).

Q2. what n x VC12/11/2 specifies - concatenated transport or just logical
bundling? Requirements for concatenated are different from simple grouping.
Q3. low order VC-x is always part either of high order VC-3 or VC-4. Whether
the nx VC-x PW should support VC-x "cross-connect" over PSN,i.e. whether
VC-x  at both sides of PW may be different, e.g. [111,112,113] (using KLM
notation) at the local side and [121,122,123] at the remote one?
Q4. Can a n x VC12 PW connect a group of VC12 under high order VC-3 to a
group of VC12 under high order VC-4?

SECTION 7.3.1
I believe there are two different scenarios - occasional and persistent loss
of packets. It looks that the requirements for handling are also different.
E.g. for n x DS0 with CAS - handling of persistent loss of packets should
also include generation of associated signalling, that may require to define
"default" CAS bits that should be transmitted towards TDM line in case of
packet loss. In this case PW end point is aware about specific protocol used
by the provider :)
Handling of the occasional packet loss may be simply re-play of the last CAS
state. 

GENERAL
-The document specifies (section 2) the need to put special emphasis on
minimization of one-way delay. End-2-end delay (that actually is the sum of
packetiztion delay, network delay and delay introduced by the jitter buffer]
is important paramater for network designer. I would propose to include the
requirement for n x DS0 and n x VC-x services - end-2-end delay should be
not depend upon the value of n. 
-I am afraid that there might be an overlap between n x DS0 with CAS and AVT
WG activities:  RFC 2833 defines how to carry telephony signals over the
network, and, at least, in the past(!) a lot of work about
multiplexing/bundling of voice streams was done in AVT WG (e.g.
draft-ietf-avt-aggregation-00.txt  - expired in 1998). What do you think?

Happy New Year to all
         Alik