Subject: Re: [IP-Optical] RE: GMPLS - Lable

From: Yangguang Xu <[email-masked]>
Date: Tue, 19 Dec 2000 14:01:56 -0500

Eric,

Please see my comments below:

> 
> When an upsteam LSR ask some bandwidth to a downstream LSR, in most of the
> cases the upstream LSR does NOT include any label (but it could, see
> "suggested label" section in GMPLS for instance). Anyway, the bandwidth
> parameter is the one used to request some bandwidth, NOT the label.
> 

The only reason (I can see) why upstream LSRs not include label in label request
is because MPLS signaling (both RSVP and LDP) don't do that way. However, this
is not a valid reason. There is tremendous benefit for upstream node to indicate
label at request time(please refer to gmpls architecture draft for details). If
we forget MPLS first, what we need is a create request and a create response as
acknowledgment. Suggested label is not only useful for bi-directional LSP
creation. It should be used whenever it is possible. 

> A virtual link is between an ingress node and an egress node (not adjacent
> in most of the cases). Intermediate nodes don't see the signaling messages
> when you want to provision a circuit (LSP) inside that virtual link. The
> label allocated for a VC-12 in that virtual link is ONLY relevant to the
> ingress and egress nodes. It is NOT seen by the intermediate nodes. The
> virtual link bandwidth is in that case VC-4 and the label for a VC-12 in
> that VC-4 don't care about the number of the STM-x. The virtual link may
> span several physical links. A virtual link is an LSP and can be advertised
> as a Forwarding Adjacency (please, read the corresponding drafts).
> 

I think intermediate nodes need to see the signaling messages when provision a
lower order LSP. In this case, higher order LSPs will be treated as FAs or
tunnels. Explicit routing calculates the lower order LSP and puts higher order
LSPIDs in ERO. Labels then indicate which low order time slot within the higher
order LSPID. 

Thanks,

Yangguang

---

From: Yangguang Xu <[email-masked]>
Date: Tue, 19 Dec 2000 14:15:26 -0500

Eric,

Correction on my comment, if intermediate node only support high order
switching, then you are right that only end points need to be involved. (It's
like ATM VP switching). If intermediate nodes also support low order switching
(like ATM VC switching), then they need to be involved for low order LSP
creation.

Regards,

Yangguang

---

From: "Mannie, Eric" <[email-masked]>
Date: Tue, 19 Dec 2000 13:44:30 +0100

Hi Heiles,

The label is used to indicate a time-slot. Since each time-slot correspond
to a specific bandwidth, by transitive effect or by coincidence, the label
indicates a bandwidth.

But there is an explicit bandwidth parameter used to request to bandwidth in
GMPLS, e.g. you ask for a VC-12 circuit (LSP). It can be encoded in a
"signal type" field or inside a traffic parameter TLV/object (solution used
by GMPLS today). The label is NOT used to request the bandwidth and the
label is LOCAL between each pair of node (and can be different between each
pair of node).

> On the other hand if the VC-4 links are really fixed, the VC-12 connection
and routing should be only interested in the end-points of these VC-4
connections and not in the specific STM-n signals and intermediate nodes
that are used for the fixed VC-4 connection. 

Note that using terms like virtual links or physical links is better in that
case than using "fixed" or "flexible". Indeed all links are flexible in the
sense that once you open a circuit you can structure it as you like.

> One other point on the numbering scheme. You extended the basic K,L,M
scheme and introduced different number ranges for each VC type (e.g. VC-2=1,
VC-12=4-6, VC-11=7-10). So you have combined slot and bandwidth information
(VC type).

It is similar to SDH, except that we code it differently. We have a unique
code space for M (from zero to 10), instead of having multiple code spaces
for M in SDH (0 for VC-2, or 1 to 3 for VC-12, or 1 to 4 for VC-11).

Indeed you have two major approaches (there were discussed in several draft
already), either you use a flat numbering, independent of the time-slot, and
in that case you need extra parameters in the signaling to map the label to
a time-slot. Or, you use a smarter approach where the label indicates
directly the (relative) time-slot (by coincidence).

The second approach has advantages, for debugging for instance. If you sniff
the signaling flow, by looking at the label you know directly for which
time-slot is the label. With a flat approach you need to have access to the
mapping table of a node to understand for which time-slot is the label. From
the operational point of view (don't forget that operators will have to run
such networks), our approach is better and this is one of the reasons why we
decided to use it in GMPLS. Once again, there is no significant advantage of
trying to hide the time-slot information in the signaling protocol.

Kind regards,

Eric

-----Original Message-----
From: Heiles Juergen [mailto:[email-masked]]
Sent: Monday, December 18, 2000 2:18 PM
To: Mannie, Eric; Heiles Juergen
Cc: [email-masked] '; [email-masked] '
Subject: RE: GMPLS - Lable

Hi Eric,

thank you for the clarification. I agree that it is a possible solution and
a better description is needed in the text. However this solution requires
some specific knowledge about the link-connection. For the sepcific case of
a VC-12 transported via a VC-4 connection it has to be known if the VC-4
connection is fixed or flexible (virtual link). If it is fixed all fields
are used, if it is flexible (the VC-4 is a LSP of its own) only the M field
should be used. On the other hand if the VC-4 links are really fixed, the
VC-12 connection and routing should be only interested in the end-points of
these VC-4 connections and not in the specific STM-n signals and
intermediate nodes that are used for the fixed VC-4 connection. 
One other point on the numbering scheme. You extended the basic K,L,M scheme
and introduced different number ranges for each VC type (e.g. VC-2=1,
VC-12=4-6, VC-11=7-10). So you have combined slot and bandwidth information
(VC type). For what is the additonal bandwidth (VC-type) information needed.
For the LSP the bandwidth information is a property for the overall LSP and
not for a single link. If you use it to identify the specific link
connection (e.g. VC-3/4) the same applies as above. If it is a fixed STM-n
link the structure is fixed by the interface and cannot change. So you don't
have to specify it explicity as it is an implicit part of the interface. If
the STM-n interface however is flexible (e.g. VC-3 or VC-4), the VC-3/4
should be a LSP of its own that is setup and teared down and you only have
to specify the specific VC-3/4 and the slot within the VC-3/4 you use.

Regards

Juergen

> -----Original Message-----
> From:	Mannie, Eric [SMTP:[email-masked]]
> Sent:	Friday, December 15, 2000 6:36 PM
> To:	'Heiles Juergen '
> Cc:	[email-masked] '; [email-masked] '
> Subject:	RE: GMPLS - Lable
> 
> Hi Juergen,
> 
> The label is indeed relative to a link or a virtual link (could be a
> forwarding adjacency). 0 is used to encode a field (S, U, K, L or M) that
is
> not significant (as stated in the draft). So, if the link is a virtual
VC-3
> link between two SDH/SONET LSRs, the highest part of the label is set to
> zero (not significant), while the lowest part indicates the time-slot
> (bandwidth) (e.g. a VC-11) requested in that virtual link. In the same
way,
> the lowest part of a label is set to zero for an STM-1/STS-1 LSP.
> 
> Having one label per SDH/SONET "layer" (or bandwidth level), i.e. a flat
> label, is not a solution, since in that case when you want to allocate a
> VC-11 in an STM-1 for instance, you have to request and attribute one
label
> for each intermediate "bandwidth level", e.g one LSP per bandwidth level.
	[Heiles Juergen]  If each hierachy is a LSP of its own and provides
flexible connectivity you have to request a label for each "bandwidth
level". If not, you are not interested in the lower layer structure and only
in the VC-4 connectivity.
>   
> I saw that there was an editorial bug in the draft ("S=0 is invalid").
> Thanks for having indicated that. I'll sent an updated version of the
> section to the editor as soon as I go back to my office. I'll add also a
> small text to better explain how it works.
> 
> Kind regards,
> 
> Eric
> 
> -----Original Message-----
> From: Heiles Juergen
> To: [email-masked]; [email-masked]
> Sent: 12/11/00 1:45 PM
> Subject: GMPLS - Lable
> 
> draft-ietf-mpls-generalized-signaling-01 defines a hierachical lable
> field for SDH SONET (e.g. S+U+K+L+M) in order to define the specific
> position of an VC in the STM-n interface signal. In my view is not the
> correct approach to include the full multiplex stack down to the
> interface layer in the lable.
> The lable is used for the link-connection of a LSP between two LSRs. As
> such it should include only information relevant to this link> 
> connection. What is need is inforamtion aboout the position of the LSP
> in the server layer only, but not in all other layers below. If a VC-12
> is transported via a VC-4 link connection the time slot of the VC-12
> within the VC-4 is important in order to acces the correct VC-12 at the
> next VC-12 LSR. The position of the VC-4 within the STM-N signal however
> is not important as it is not fixed. The VC-4 is a LSP of its own and
> can be routed via VC-4 LSRs. It can change its time slot within a STM-N
> signal at any VC-4 LSR. The time slot of the VC-4 within the STM-n
> signal could therefore be different at the two VC-12 LSRs. This
> multiplex structure should therefore be handled by hierachical LSPs
> instead of a hierachical label field.
> 
> The lable inforamtion is therfore valid for a certain cleitn/server
> relationship, but not for a certain interface. For a lower order VC-12
> within a VC-4  the parameters KLM are required. For a VC-4 within an
> STM-n signal the parameter S is required, not more not less.
> 
> Regards
> 
> Juergen