Subject: Re: Semantics of shared reservations (with RSVP)

From: Bob Braden <[email-masked]>
Date: Wed, 22 Mar 2000 21:14:31 GMT

*> 
  *>                R2 ---- R3
  *>               /          \
  *>     H1 ---- R1            R6 ---- R7 ---- H2
  *>               \          /
  *>                R4 ---- R5
  *> 
  *> H1 sends out two Path messages (with different explicit route objects)
  *> to H2.
  *> 

This seems a little strange.  How/why would an end host H1 know about
the failover path in the middle of the network??  It seems to me more
likely that R1 knows about this magic for Path messages, and can also
do magic for Resv messages.

Note that Explicit Route objects were pasted onto RSVP by someone
other than the RSVP WG, and I don't know that anyone has thoroughly
investigated the consequences.

Bob Braden

---

From: David Charlap <[email-masked]>
Date: Wed, 22 Mar 2000 17:13:22 -0500

Bob Braden wrote:
>>
>>                R2 ---- R3
>>               /          \
>>     H1 ---- R1            R6 ---- R7 ---- H2
>>               \          /
>>                R4 ---- R5
>>
>> H1 sends out two Path messages (with different explicit route
>> objects) to H2.
> 

Sorry for the confusion here (I've been saying that a lot recently - I
must start using terminology that everybody else understands).  I chose
to call the ends "H" because they perform the role that hosts do in a
straight-RSVP environment - initiating and terminating RSVP messages.

In the scenario I was thinking of, H1 and H2 are actually MPLS edge
routers (LERs).  They know about the full topology (and therefore know
about the failover path).  They are differentiated from the "R" routers
in that they initiate the RSVP signalling when establishing LSPs between
each other.

> investigated the consequences.

Understood.  This is the reason I posted my question to both the RSVP
and MPLS lists.  I figure that what one group doesn't know, the other
may be able to answer.

After reading replies messages by others, it appears that my
understanding of how SE works was flawed, and the perceived problem does
not actually exist.

The one problem remaining, which doesn't appear to be covered by RSVP-TE
or MPLS is how the ingress node (host or router) can tell the egress
node that two paths are meant to share resources.

I suppose this is a more generic RSVP issue as well.  If it is desired
that the sender choose the reservation style, this choice can not be
signalled through any standard object in the Path message.  It must be
signalled out-of-band, or through a non-standard extension - in either
case, something beyond the RSVP spec must be supported by both ends for
this.

It seems to me that it would be a good idea to have a mechanism for the
sender to request a style of the recipient.  (Of course, the recipient
would still be free to ignore this request - to do otherwise would break
existing implementations.)  Perhaps via a new service type in the ADSPEC
or something similar.

-- David

---

From: "Ganesh Murugesan" <[email-masked]>
Date: Wed, 22 Mar 2000 17:26:43 -0800

> existing implementations.)  Perhaps via a new service type in the ADSPEC

I am not sure if this is what you are asking for.  The RSVP Extension for
LSP
tunnels draft has this section about the Session Attributes Object:

     0x04 = Ingress node may reroute
           This flag indicates that the tunnel ingress node may
           choose to reroute this tunnel without tearing it down.
           A tunnel egress node SHOULD use the SE Style when
           responding with a Resv message.

The above sentence seems to indicate that the Ingress can indeed signal to
the egress
as to whether it should choose SE style or not.

thanks
ganesh