The MPLS WG Archive

[David Charlap <david.charlap@marconi.com>]

"Feng, Mark" wrote:
> 
> IMO, tunnel Id has "global" significance, within some particular
> MPLS domain, synonym to well-known ports in classical RSVP. I think
> that it is unlikely the operator will assign a LSP some tunnel Id
> without knowing what other potential ingress routers might share
> the resources.

If an operator is going to hand-assign tunnel IDs, yes.  And in this
situation, the operator can choose whether multiple LSPs sharing the
tunnel ID should share resources or not by directing the switch to use a
zero or non-zero value for extended tunnel ID

It is also possible for an ingress router to automatically create LSPs
based on topology information of some kind.  In which case, the tunnel
IDs would be automatically generated.  Of course, in this situation,
resource sharing would be a bad thing, and so a non-zero value would be
used for extended tunnel ID.

> Also, the fact that the egress router is the one who decides what
> style to use implies that some out-of-band mechanism is used to
> ensure the proper operation between the ingress routers and the
> egress routers.

No.  RSVP has always been egress driven.  The egress router is free to
try and reserve with any style it wants, and using any amount of
resources it wants.  This is all perfectly legal and part of the design
of RSVP.

Of course, a router that completely ignores the information requested in
the Path message is one that nobody will be interested in buying.  But
it does mean that two Paths in the same session, requesting different
reservation styles and different amounts of resources will not result in
any kind of self-contradictory state.

> The only reason I can think of to have the tunnel Id and extended
> tunnel Id is to tailor different needs. For example, there might be
> some pre-determined mechanism to assign the tunnel Id at each
> ingress router. If one router decides not to join the sharing,
> though it is assinged a particular tunnel Id, it can add its own IP
> in the extended tunnel Id, to exclude itself in the sharing.

This is one possible scenario.  There are others as well.

-- David