Re: Clarification Required regarding LSP Encoding Type

[Zhi-Wei Lin <zwlin@lucent.com>]

Hi Vishal, Manoj,

Right, for "digital wrapper" (BTW, our draft re-named this OTN to be
consistent with the terms used in ITU), new signal types need to be
added to extend current text to include optical networks.

draft-lin-ccamp-ipo-common-label-request-01.txt contains an extension
for the G.709 (digital wrapper) signal types.

draft-fontana-gmpls-control-g709-00.txt also has extensions for G.709. I
have some concerns with this extension because of the introduction of
"OOS". I don't believe OOS is needed since it was not needed for the
other technology layers. It is also incorrect, since the "reduced
functionality" defined in G.709 states that it does not include
non-associated overhead, nothing regarding "limited overhead". I also do
not believe in the "transparency" field. In the OTN (and any other layer
networks such as SONET), each layer above is carried transparently by
the layer below, and thus to carry as transparent, simply specify the
lower layer signal type with an appropriate G-PID. 
The other issue is that OTN muxing is currently not standardized (but
will be soon), so we should at most specify fields as placeholders for
muxing capability, but not to define what it is since there could be
many ways of getting muxing capability (e.g., 16 ODU1 into ODU3, 8 ODU1
and 2 ODU2 into ODU3, 4 OTU2 into OCh, etc.)


Zhi


Vishal Sharma wrote:
> 
> Manoj,
> 
> Your understanding is correct.
> 
> > -----Original Message-----
> > From: manoj juneja [mailto:manojkumarjuneja@hotmail.com]
> > Sent: Monday, March 19, 2001 3:08 PM
> > To: ccamp@ops.ietf.org
> > Subject: Clarification Required regarding LSP Encoding Type
> >
> >
> > Hi All,
> >         The draft "draft-ietf-mpls-generalized-signalling-02.txt"
> > defines different values for LSP encoding type. How does the
> > implementation of a control plane differ if it receives the
> > LSP encoding
> > type packet/SDH/Digital Wrapper/Lamda/Fiber etc.
> >
> > My understanding is that if the LSP encoding type is either
> > packet/ethernet,
> > then label is just a 32 bit integer (as we already have in
> > traditional
> > MPLS). But if LSP encoding type is SDH, SONET then the label
> > has to be in
> > the form of {S, U, K, L, M} format. If the LSP encoding type
> > is Lamda then
> > the label represents the lamda (specific frequency). If LSP
> > encoding type is
> > fiber, then label is the fiberId itself.  Please comment on
> > whether my
> > understanding is correct or I am overlooking something.
> 
> > Can u please describe a scenario in which the LSP encoding type
> > will be used as a "digital wrapper" ?
> 
> I am not sure that an LSP encoding type of "digital wrapper" by
> itself is enough. Looking at some of the Optical Transport Network
> concepts, I would suspect that one would need an LSP encoding type
> corresponding to the various layers defined in the OTN, but
> I'll leave it to my colleagues from Lucent to comment on this.
> (Maarten, Yuangang, Zhi?)
> 
> -Vishal