The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2000-Dec> msg00371



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

[IP-Optical] RE: GMPLS - Lable

  • From: LEI YAO <lei.yao@wcom.com>
  • Date: Tue, 19 Dec 2000 22:04:41 -0500
  • Cc: "'Heiles Juergen'" <Juergen.Heiles@icn.siemens.de>, "'mpls@UU.NET '" <mpls@UU.NET>

Also, the label is locally significant. There is no way for the upstream LSR to know and suggest label value for the downstream LSR.

-----Original Message-----
From:	John Drake [SMTP:jdrake@calient.net]
Sent:	Tuesday, December 19, 2000 2:33 PM
To:	'Yangguang Xu'; Mannie, Eric
Cc:	'Heiles Juergen'; 'mpls@UU.NET '; 'ip-optical@lists.bell-labs.com '
Subject:	RE: [IP-Optical] RE: GMPLS - Lable

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:xuyg@lucent.com]
Sent: Tuesday, December 19, 2000 11:02 AM
To: Mannie, Eric
Cc: 'Heiles Juergen'; 'mpls@UU.NET '; 'ip-optical@lists.bell-labs.com '
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