The MPLS WG Archive

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

I think I can answer one of these....

Philip Matthews wrote:
> 
> 4.1.1.1. Downstream
>   The text says "A node is expected to send a Resv message before its
>   refresh timers expire if the contents of the LABEL object change."
>   When could this happen? Once an LSP is set up, is the downstream
>   node allowed to change the LABEL object in a Resv refresh?

Normally, a downstream node will not change the LABEL object.  But there
are scenarios where it could happen.  For example.  Imagine this
topology:

	A---B---C---D

A Path and Resv go through and an LSP is established from A to D.

Now, the inbound interface on D goes down, but the outbound interface on
C remains up.  (Perhaps it was administratively disabled - obviously,
this wouldn't happen if the fiber was disconnected.)

C thinks the link is still up and continues sending Path refreshes.  D
thinks the link is down and tears its state.

Now, before C misses enough Resv refreshes to presume link failure and
generate a PathErr, the inbound interface on D comes up again.

D receives a Path from C (one of the usual refreshes), but it sees it as
a new Path (since it no longer has the old state in memory).  So it
allocates a new LABEL (which will almost certainly be different from the
one it had before) and sends this to C in its Resv messages.

Admittedly, this is a rare (and a bit contrived) sitation, but it can
happen.

> General
>   Could the draft specify what is allowed to change in a Path or Resv
>   refresh?

In general, in keeping with the soft-state nature of RSVP (see RFC2205),
any parameter can change, unless explicitly stated otherwise.  In actual
practice (especially when used as a part of MPLS), most are unlikely to
actually change.

>   In particular, are the following objects allowed to change:
>     - LABEL
>     - LABEL_REQUEST

These shouldn't, under normal circumstances.  But, in the case where
only one side of a link goes down and later comes back up, a switch can
receive a "refresh" where these objects have changed.

>     - EXPLICIT_ROUTE

In theory.  It is, however, preferred that the ingress node use the
"make before break" procedure to effect a reroute.  While changing the
ERO would, in theory, work, it can create some race conditions - where
the new Path is established, and then another switch (which used to be
on the path) times out and sends out tear messages.

>     - SESSION_ATTRIBUTE

Again, I think it will be unlikely for this to change, but it is
possible.

>     - SENDER_TSPEC

This has always been possible (see RFC 2205).  George Swallow has
stated, however, that it is preferable to do a make-before-break reroute
in the situation where the bandwidth for an LSP must be changed.

-- David