Subject: GMPLS - Lable

From: Heiles Juergen <[email-masked]>
Date: Mon, 11 Dec 2000 13:45:12 +0100

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

---

From: Heiles Juergen <[email-masked]>
Date: Mon, 18 Dec 2000 14:18:08 +0100

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

---

From: John Drake <[email-masked]>
Date: Tue, 19 Dec 2000 11:33:00 -0800

As documented in the GMPLS signalling draft, suggested label is used in the
downstream direction, i.e., from ingress to egress.  There is nothing that
says that the LSP being established has to be a bidirectional LSP.
Bidirectionality is determined through the presence of a label for the
upstream direction, which is independent of the suggested label for the
downstream direction.

Thanks,

John

-----Original Message-----
From: Yangguang Xu [mailto:[email-masked]]
Sent: Tuesday, December 19, 2000 11:02 AM
To: Mannie, Eric
Cc: 'Heiles Juergen'; [email-masked] '; [email-masked] '
Subject: Re: [IP-Optical] RE: GMPLS - Lable

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: "Mannie, Eric" <[email-masked]>
Date: Tue, 19 Dec 2000 19:46:22 +0100

Hi Maarten,

>The VC-11 is not converted into a VC-12 (header text of 10.1.6/G.707 is
>not accurately reflecting the process). A VC-11 is transported via a
>TU-12 time slot, but it stays a VC-11 signal. The text in G.707
>(10/2000) indicates this:

Yes, I know this why I used "converted" between quotes.
The important point is that the VC-11 looks like a VC-12 in a TU-12 and that
intermediate switches don't care about the VC-11.

> Note that in SDH "lower order timeslots" are called :"TU",
> whereas the "signal" being transported via such TU timeslot
> is called a "VC". Idem for higher order timeslots (AU) and
> signals (VC).
 
It is even "worst" than that since a time slot is indeed a part of a TU (see
TS numbering).
In addition, the term "signal" is used to designate almost everything in
SDH, including an STM-N "signal", a VC-X signal, to designate what can be
transported into a VC-x (e.g. G.702 signal), i.e. client signals (IP, PDH,
ATM,, etc).

The vocabulary is loosely used/defined :-)

Kind regards,

Eric

---

From: John Drake <[email-masked]>
Date: Wed, 20 Dec 2000 08:11:07 -0800

Label bindings are exchanged between adjacent nodes as part of the link
initialization procedures of LMP, so I think we're doing exactly what you're
saying we're not doing, but should be doing.  

Thanks,

John    

-----Original Message-----
From: Yangguang Xu [mailto:[email-masked]]
Sent: Wednesday, December 20, 2000 6:48 AM
To: LEI YAO
Cc: [email-masked] '
Subject: Re: [IP-Optical] RE: GMPLS - Lable

Here is the difference between circuit switches and data LSRs. An circuit
switch
builds up label association with its neighbor at the system initiation time.
The
port association table is the label association table (not exactly). It's
known
before connection time. Please refer to ietf-xu-mpls-ipo-gmpls-arch-00.txt
for
details.

Yangguang

LEI YAO wrote:
> 
> Also, the label is locally significant. There is no way for the upstream
LSR to know and suggest label value for the downstream LSR.
> From:   John Drake [SMTP:[email-masked]]
> Sent:   Tuesday, December 19, 2000 2:33 PM
> To:     'Yangguang Xu'; Mannie, Eric
> Subject:        RE: [IP-Optical] RE: GMPLS - Lable
>

---

From: LEI YAO <[email-masked]>
Date: Wed, 20 Dec 2000 12:31:57 -0500

RSVP uses downstream-on-demand for label assignment. The upstream LSR does not keep free labels for downstream LSR. 

-----Original Message-----
From:	Kireeti Kompella [SMTP:[email-masked]]
Sent:	Wednesday, December 20, 2000 11:57 AM
To:	[email-masked]; [email-masked]
Cc:	[email-masked]
Subject:	Re: [IP-Optical] RE: GMPLS - Lable

> LSR to know and suggest label value for the downstream LSR.

Actually, there is.  Locally significant means that both ends of a link
know what's going on, but others LSRs in the path don't.  Suggested labels
work fine.

Note that the above is true for point-to-point links only.  On multipoint
links, suggesting labels doesn't work as well, as one could have label
conflicts.  Fortunately, non-packets links are (to date) point-to-point.

Yangguang wrote:

> Here is the difference between circuit switches and data LSRs. An circuit switch
> builds up label association with its neighbor at the system initiation time. The
> port association table is the label association table (not exactly). It's known
> before connection time. Please refer to ietf-xu-mpls-ipo-gmpls-arch-00.txt for
> details.

I don't get it.  Do you mean using LMP or similar mechanism for
establishing the mapping?

If a "data LSR" tells its neighbor to use label 272, the neighbor
knows exactly what is meant.  If a SONET LSR tells its neighbor, use
label foo, where foo is an encoding of the time slot to use, the
neighbor knows exactly which time slot to use.  However, if a PXC tells
its neighbor to use label bar, the mapping between "bar" and port number
has to first be established.  The distinction is not data and non-data,
but defined semantics for labels vs. dynamically established semantics.

Kireeti.

---

From: Kireeti Kompella <[email-masked]>
Date: Wed, 20 Dec 2000 11:17:01 -0800 (PST)

> RSVP uses downstream-on-demand for label assignment. The upstream LSR
> does not keep free labels for downstream LSR. 

"Does not keep" is different from "cannot keep".  On point-to-point
links, the upstream LSR can easily do this.  If the upstream LSR is
motivated enough to use suggested labels, it makes sense to track
which are available.  Note that unlike "data labels", lambdas and
ports usage will be tracked carefully; i.e., the upstream LSR should
know which labels (ports) are free in any case.

Kireeti.