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

From: Max Riegel <[email-masked]>
Date: Mon, 20 Jan 2003 16:32:28 +0100

Dear Alik,

sorry for the late response. I missed your mail when browsing through the 
PWE3 list on Christmas but discovered it now when cleaning up my inbox.

At 23.12.2002 10:02 +0100, Alik Shimelmits wrote:

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?

In the former case a whole E1 or T1 frame is transmitted in a aligned 
fashion, in the latter just a set of DS0 channels eventually associated 
with CAS signals are transmitted.

- about n x DS0: Q2. Is there requirement for DS0s in the bundle to be
consecutive or not?

What do you mean with DS0s to be consecutive?

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?

Putting individual DS0 channels into a higher order TDM framing can be 
considered as part of the NSP (Native Service Processing) being outside the 
scope of the PW emulation for nx DS0s.

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?

This seems for me also being an issue of the NSP outside the scope of 
emulation of PW for nxDS0.

Q5. Is it possible to connect n
x DS0 bundle residing on T1 with the n x DS0 residing on E1?

It should be possible if you are applying appropriate NSP functions.

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

I wouldn't draw such a conclusion. You never cant be sure what is 
transported in a DS0 channel, even might be somebody is using data-over-voice.

Each voice channel should be synchronized
with its own signalling but there is no requirement for
synchronization between channels! And this is extremely important.

Probably this is the case for applying structured E1 / T1 emulation.

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

It's a typo. Please have a look on Ron's posting on 2002-12-22.

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.

There was a presentation of Yaakov in Atlanta, how to deal with 
transmission errors, and there was a conclusion to put the related 
information in a BCP (best current practicies) document, as it is not part 
of the PWE3 specification but seemed to be very useful for equipment designers.

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?

Keeping end2end delay constant in case of transmission of voice signals 
looks reasonable for me. But taking into account that we are only dealing 
with a part of the end2end transmission path (the pseudo wire emulation 
edge2edge) I wouldn't put any requirements for the end2end behaviour into 
our document.

Bye
Max