Subject: Re: I-D ACTION:draft-riegel-pwe3-tdm-requirements-01.txt

From: Maarten Vissers <[email-masked]>
Date: Mon, 13 Jan 2003 15:40:01 +0100

Sasha,

see in-line for some more notes...

Sasha Vainshtein wrote:
... snipped ...
>
> > The basic PW provides a connection over which a stream of
> > bits is transparently
> > transported. This is similar to e.g. transporting a stream of
> > bits over PDH,
> > SDH/SONET or OTN; e.g. 34 Mbit/s over SDH, STM-16 over OTN.
> > To guarantee interworking and the performance of a connection,
> > jitter/wander, clock and PLL bandwidth specifications have been developed.
> See e.g.
> > 15.2/G.783 and G.8251.
> >
> I think that this analogy is correct for unstructured TDM emulation.
> Structured TDM
> emulation seems to be somewhat different e.g., similar to bit-synchronous
> mapping
> of 1544 kbit/s into VC-11 and of 2048 kbit/s into VC-12. Is this correct?

The difference between async and bit/byte-synchronous mappings is that
- in the async mapping case you map the client signal into a server signal which
has a clock independent of the client clock. The frequency difference between
the client and server signals is coded into justification information and mapped
into the server signal as well.
- in the bit/byte-sync mapping the server signal's clock is locked to the client
signal's clock and there is no justification information needed between client
and server signal. The server signal may now have a frequency difference with
its server signal (e.g. case of bit/byte-sync mapping of 1544/2048 kbit/s into
VC-11/VC-12) and this will be coded into justification info and mapped into the
server's server signal. 

E.g. 2048 async mapping into VC-12 into VC-4 creates 2048 kbit/s justification
information (C and S bits) which is mapped into the C-12 with the data bits; as
the VC-12 and Vc-4 frequencies are locked (come from same SEC) the TU-12 pointer
will have a fixed value and there will be no use of TU-12 pointer adjustment
capability. The byte-sync mapping into VC-12 (note bitsync mappings are not
deployed in SDH) into VC-4 locks the VC-12 frequency to the 2048 kbit/s
frequency (no C+S bits in the mapping as such); the VC-12 now will be
independent of the VC-4 frequency and you will see a variable TU-12 pointer
value and TU-12 pointer adjustments to cope with the frequency difference
between the 2048 kbit/s signal and the SEC signal (creating the VC-4 signal).

If you map a number of consecutive bits from a client signal into a PW packet
without any justification control added in the mapping process, then the mapping
looks like a bitsync, bytesync or framesync mapping. The justification control
is then implicit in the time of packet generation. With additional delay
variation in the network, its will be hard to recover client signal timing at
the egress of the PW.

If you include justification control in the packet itself, you will have a
mapping that looks like an async mapping. The additional complexity compared to
async mappings in PDH, sDH, OTN is the delay  each packet can get crossing the
network, which results in a much larger jitter/wander component than
traditionally present when using PDH, SDH or OTN as carrier for the mapped
signal.

I would not relate structured TDM emulation with a particular mapping type. E.g.
take the example of a DS3 with DS1s inside and DS1 PWs. The ingress of the PSN
terminates the DS3 and extracts the DS1 signals. Those DS1s are now mapped into
PWs and PWs are multiplexed. I.e. this is much like async or bitsync mapping of
individual
DS1 signals into PWs.

For SDH structured TDM signals (VC-12 into VC-4 into STM-N) the case is similar. 
However, as VC-12 and VC-4 signals have been transported so far only within
(synchronous) STM-N, sSTM-2n/1k and G.832 34/140 Mbit/s frames there are no VC-n
jitter/wander, clock and PLL specifications written. And with the pointer
buffers around, such specifications would have a different format than for the
PDH signals. A VC-n signal coming out of a PW enters a pointer buffer with a
pointer generator; the pointer generator must generate pointer sequences
compliant to those specified in clause 15/G.783. Delay variation can be
accommodated to a certain level. The best person (in my opinion) to look into
the jitter/wander requirements of this PW is Geoff Garner.

For structured 1544/2048 kbit/s signals with 64 kbit/s (DS0) trib signals the
same is true. DS0 trib signals can be mapped async in a MPLS PW packet, or
bit/byte sync. If you would like to map DS0's from multiple 1544/2048 kbit/s
input signals into one MPSL PW packet, then you have to perform DS0 multiplexing
before mapping. Delay variations through the network result in slip/skip when
the 64
kbit/s signals are mapped into another 1544/2048 kbit/s signal. Jitter/wander
spec's can be written as well for this case, based on a defined buffer size.

In general transport of a CBR stream via an MPLS network can be based on a
common mapping method. This method is independent on the ingress/egress signals
carrying the to be transported client signal. In functional modelling you will
notice that the atomic functions that have to deal with demuxing before the PW
and muxing after the PW already exist and thus don't belong to the PW operation
itself. The PW should be concerned with mapping and demapping of the client's
characteristic information only, not with the presentation of this CI on a
physical interface at the edge of the network.

As such, PW should address mapping/demapping of the following CI
- P12x_CI (E1 unstructured)
- P11x_CI (T1 unstructured)
- P31x_CI (E3 unstructured)
- P32x_CI (T3 unstructured)
- P0x_CI (DS0 unstructured)
- P0s_CI (DS0 with byte identification)
  Note - CAS is a particular implementation of a signalling channel. 
  Besides CAS we have e.g. TR303 and V5.1/V5.2 implementations.
- P0s-Xc_CI (NxDS0)
- S3_CI (STS-1/VC-3)
- S4/4-4c/4-16c/4-64c_CI 
- S11/12_CI (VT-3, VT-6/VC-2 are not deployed in the network)
- S11/12/3/4-Xv_CI (virtual concatenation)

If you use these client signal indications, you don't have to bother about all
the PDH or SDH/SONET processing between the physical interface connector and the
PW; all components can be found in ITU-T recommendations. It is a manufacturer
and/or operator responsibility to define which variations will be offered/is
required between connector and PW edge.

Regards,
Maarten