Subject: RE: last call comment on draft-ietf-ccamp-gmpls-sonet-sdh-00.txt

From: Heiles Juergen <[email-masked]>
Date: Tue, 29 May 2001 02:36:35 +0200

Alan,

hierachical LSP setup in Sonet/SDH and other transport planes is an issue currently not addressed by GMPLS. The Sonet/SDH naming tree (TDM-LSR link lable) for example doesn't fit with independent higher and lower order VC setup. For example the route of a VC-4 may change (use different STM-N ports at the equipment) while the endpoints are still the same. The VC-12 transported via these VC-4 don't have to care about the STM-N port only about the VC-4 endpoints. The current definition requires the port and full multiplex structure. AS not much thoughts are spent on the issue the current definition might not work with future extensions that support hierachical structures.

Regards

Juergen 

> -----Original Message-----
> From:	Kullberg, Alan [SMTP:[email-masked]]
> Sent:	Thursday, May 24, 2001 5:44 PM
> To:	'Mannie, Eric'; 'Kireeti Kompella'
> Cc:	[email-masked]'; [email-masked]'
> Subject:	last call comment on draft-ietf-ccamp-gmpls-sonet-sdh-00.txt
> 
> The following paragraph is from section 3 of
> draft-ietf-ccamp-gmpls-sonet-sdh-00.txt.
> 
>   When hierarchical SDH/SONET LSPs are used, an LSP with a given
>    bandwidth can be used to tunnel lower order LSPs.  The higher
>    order SDH/SONET LSP behaves as a virtual link with a given
>    bandwidth (e.g. VC-3), it may also be used as a Forwarding
>    Adjacency. A lower order SDH/SONET LSP can be established through
>    that higher order LSP. Since a label is local to a (virtual) link,
>    the highest part of that label is non-significant and is set to
>    zero.
> 
> The LSP Hierarchy draft introduces Link Mux Capability.  There is a value
> defined for TDM Switch Capable.  In order to support the hierarchy in the
> above paragraph, TDM Switch Capable would need to be split into multiple
> values, one for each level of the SDH/SONET multiplexing structure.
> 
> What do you think?
> 
> Alan
>

---

From: "Mannie, Eric" <[email-masked]>
Date: Mon, 28 May 2001 10:12:57 +0200

Hello Alan,

>values, one for each level of the SDH/SONET multiplexing structure.

The text that you indicated don't restrict to only two levels, you could
open an LSP inside an LSP, inside an LSP, etc... The example was given with
two levels. The important point is that whatever is the LSP that you want to
open you have a higher part and a lower part. So we don't have to define
plenty of different labels, not only per layer (higher order versus lower
order) but also as a whole since we could want to directly indicate a VC-11
in the whole multiplex (in that case the full label is significant). Having
different labels makes it much more complex without adding any additional
functionality.

Kind regards,

Eric

-----Original Message-----
From: Kullberg, Alan [mailto:[email-masked]]
Sent: Thursday, May 24, 2001 5:44 PM
To: Mannie, Eric; 'Kireeti Kompella'
Cc: [email-masked]'; [email-masked]'
Subject: last call comment on draft-ietf-ccamp-gmpls-sonet-sdh-00.txt

What do you think?

Alan

---

From: "Mannie, Eric" <[email-masked]>
Date: Tue, 29 May 2001 10:12:55 +0200

Hello Juergen

>hierachical LSP setup in Sonet/SDH and other transport planes is an issue
currently not addressed by GMPLS. The Sonet/SDH naming tree (TDM-LSR link
lable) for example doesn't fit with independent higher and lower order VC
setup.

Sorry, but you misunderstood it completely. In addition this is explained in
the draft. It doesn't make any sense to apply GMPLS to SONET/SDH without a
powerful hierarchical LSP setup. The same apply to other technologies. 

Hierarchical LSP setup is one of the first thing that we thought about. One
of the added-value of MPLS is exactly that it fits very well with
hierarchical LSP setup. This concept is a fundamental one in GMPLS for
SONET/SDH. See after.

>For example the route of a VC-4 may change (use different STM-N ports at
the equipment) while the endpoints are still the same. The VC-12 transported
via these VC-4 don't have to care about the STM-N port only about the VC-4
endpoints. The current definition requires the port and full multiplex
structure. AS not much thoughts are spent on the issue the current
definition might not work with future extensions that support hierachical
structures.

On the contrary this issue requested a lot of thought. Hierarchical LSP
setup is explained in the draft. In addition one of the reasons to introduce
AUG-X and STS Groups was to enable more forms of hierarchical LSP setups
(see after).

About the label don't confuse the coding and the usage. We designed the
label specifically to support hierarchical LSP setup. When you code a label
of course you don't have to encode the full multiplex structure. Either you
code:

 - the higher part
 - the lower part
 - a middle part
 - the full label

Where higher, lower and middle have flexible boundaries and are relative to
the link (forwarding adjacency) in which it is. Per the MPLS definition, a
label is local to an interface/link between two nodes. If this link is a
VC-4 link (i.e. a circuit established with GMPLS and advertised as link in
the routing protocol), you can open a VC-12 circuit through that link. In
that case the label for the VC-12 indicates where is the VC-12 in the VC-4
circuit. As a side effect that will fix the allocation of a TUG-2 and TUG-3
at the interface. It will be the responsibility of a local algorithm to
decide which TUG-2 and which TUG-3 to "allocate". Of course these TUG-2 and
TUG-3 cannot be used anymore to carry a VC-3. The two TUG-3 that left can be
used to carry a VC-3.

This is just an example, you could prefer to open first a TUG-3 circuit,
then a TUG-2 circuit in that TUG-3 and then finally the VC-12 circuit in the
TUG-2 circuit. The way that the user wants to allocate circuits and/or what
is implemented by the manufacturer is of course not defined in the draft.

By the way this is another reason why TUG-3, TUG-2 and VTG are important as
signal types. They allow to specify the allocation in the multiplex level
("layer") per level. The same applies to AUG-X and STS Groups.

Having a 32 bit value for the label allowing to code, in the most complex
case, a position in the full multiplex or in any subtree is very powerful.

If you would like to do it with different label types, you would need a lot
of label types, probably more than 20 different types. Instead we have one
single and simple label.

Please see the explanations in section 3 of the draft.

Kind regards,

Eric