The MPLS WG Archive

[John Drake <jdrake@calient.net>]

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:xuyg@lucent.com]
Sent: Wednesday, December 20, 2000 6:48 AM
To: LEI YAO
Cc: 'mpls@UU.NET '
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.
> 
> -----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