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

From: "Abes, Andi" <[email-masked]>
Date: Tue, 21 Mar 2000 18:30:34 -0500

The following is quoted from RFC2209 - processing rules, Page 10.
(I'll first paraphrase for the short of breath -
  when a resv message arrives, you scan the list of all the Path State
blocks for a matching FilterSpec. If any is found, that's not in error,
you add the PHop for that Path state to the list of PHop's that need to be 
updated with the new Resv).

        Process the flow descriptor list to make reservations, as
        follows, depending upon the style.  The following uses a filter
        spec list struct Filtss of type FILTER_SPEC* (defined earlier).

        For FF style: execute the following steps independently for each
        flow descriptor in the message, i.e., for each (FLOWSPEC,
        Filtss) pair.  Here the structure Filtss consists of the
        FILTER_SPEC from the flow descriptor.

        For SE style, execute the following steps once for (FLOWSPEC,
        Filtss), with Filtss consisting of the list of FILTER_SPEC
        objects from the flow descriptor.

        For WF style, execute the following steps once for (FLOWSPEC,
        Filtss), with Filtss an empty list.

        o    Check the path state, as follows.

             1.   Locate the set of PSBs (senders) that route to OI and
                  whose SENDER_TEMPLATEs match a FILTER_SPEC in Filtss.

                  If this set is empty, build and send an error message
                  specifying "No sender information", and continue with
                  the next flow descriptor in the RESV message.

             2.   If the style has explicit sender selection (e.g., FF
                  or SE) and if any FILTER_SPEC included in Filtss
                  matches more than one PSB, build and send a RERR
                  message specifying "Ambiguous filter spec" and
                  continue with the next flow descriptor in the RESV
                  message.

             3.   If the style is SE and if some FILTER_SPEC included in
                  Filtss matches no PSB, delete that FILTER_SPEC from
                  Filtss.

             4.   Add the PHOP from the PSB to Refresh_PHOP_list, if the
                  PHOP is not already on the list.

(end of qoute)

Thus what will happened with both Resv messages (as split by R6) is almost
the same - one will match the first LSP and the other the second. Such that
both Resv messages will end up being sent upstream (Most likely, after the
initial RSB has been setup, it will only be updated periodically, and the 2
might end up being combined).

At R1, by your diagram, this however is meaningless, since the 2 LSP's do
not share the same outgoing interface, and can not share the same
reservation (at least on the output side). H1 will have to have the smarts.

> -----Original Message-----
> From: David Charlap [mailto:[email-masked]]
> Sent: Tuesday, March 21, 2000 5:50 PM
> To: Jayesh V Shah
> Cc: [email-masked]; [email-masked]
> Subject: Re: Semantics of shared reservations (with RSVP)
> 
> 
> Jayesh V Shah wrote:
> >> 
> >> I've got a question about how shared (SE) style reservations get
> >> propagated in the RSVP/MPLS world.
> >>
> >> In a simple multipoint-to-point scenario with shared resources:
> >>
> >>      H1 ---- R1
> >>                \
> >>                 R3 ---- R4 --- H3
> >>                /
> >>      H2 ---- R2
> >>
> >> H3 should will send out a Resv mesage to R4.  The flow 
> descriptor of
> >> this Resv will look like:
> >>
> >>         FLOWSPEC
> >>         FILTERSPEC (for H1)
> >>         FILTERSHEC (for H2)
> >>
> >> R3, when sending out its Resv messages, will break up this flow
> >> descriptor, and will send out
> >>
> >>         FLOWSPEC
> >>         FILTERSPEC (for H1)
> >>
> >> to R1, and
> >>
> >>         FLOWSPEC
> >>         FILTERSPEC (for H2)
> >>
> >> to R2.
> >>
> >> Right?
> >>
> >> OK.  The problem shows up when H1 and H2 are two different tunnel
> >> endpoints on the same physical box.  This can happen in the MPLS
> >> world if an ingress router is signalling multiple redundant
> >> (failover) paths to a single destination.  For instance:
> >>
> >>                R2 ---- R3
> >>               /          \
> >>     H1 ---- R1            R6 ---- R7 ---- H2
> >>               \          /
> >>                R4 ---- R5
> >>
> >> H1 sends out two Path messages (with different explicit route
> >> objects) to H2.
> >>
> >> H2 sends out a Resv message indicating that the two "senders"
> >> (indicated by different tunnel IDs) are to use shared 
> resources.  The
> >> flow descriptor looks something like:
> >>
> >>         FLOWSPEC
> >>         FILTERSPEC (for tunnel 1)
> >>         FILTERSPEC (for tunnel 2)
> > 
> > The senders will be distinguished by different Sender Address and/or
> > LSP Id in the Sender Template, and not the tunnel Id, which 
> by virtue
> > of being a part of session, has to be same for both the flows, to
> > allow the shared explicit reservation, we are talking about here.
> 
> Yes.  But if H2 is going to issue a shared reservation for the two, it
> must specify filterspecs for both senders in the same Resv object.  If
> it doesn't then it is signalling two separate resource-sharing groups.
> 
> >> R6, when receiving this, breaks the flow descriptor up for the two
> >> paths, sending out
> >>
> >>         FLOWSPEC
> >>         FILTERSPEC (for tunnel 1)
> >>
> >> to R3, and
> >>
> >>         FLOWSPEC
> >>         FILTERSPEC (for tunnel 2)
> >>
> >> to R5.
> >>
> >> This works great until those two Resv messages both arrive at R1.
> >>
> >> How does R1 know that these two tunnels are supposed to be sharing
> >> resources.  Normally, a router would know this from the multiple
> >> filterspecs in a single flow-descriptor, but R1 doesn't 
> see this.  It
> >> receives two separate Resv messages from two different next-hop
> >> nodes.
> > 
> > R1 knows that it needs to share resources among the two 
> flows, because
> > they belong to the same session (the session object is the same).
> 
> No.  This is SE style, not WF.
> 
> In WF style, all senders in a single session share the same resources.
> 
> In SE, the senders that share resources must be explicitly specified. 
> If a switch assumes sharing when this specification is not present, it
> is in error.
> 
> The recipient (H2) knows this and will explicitly state the sharing in
> its flow-descriptor list (one flow descriptor containing two flowspecs
> and two labels.)  The problem is that this information is 
> lost after the
> flow descriptors are broken up at R6.
> 
> >> I suppose R6 could send both filterspecs to both PHOPs, 
> but R3 and R5
> >> could (probably would) reject those Resv messages, wouldn't they?
> >> After all, those two routers each only processed one of 
> the two Path
> >> messages - they don't know about the other one.
> >>
> >> For that matter, how does H1 tell H2 that these two paths are
> >> supposed to be sharing resources?  Must it be configured across the
> >> network?
> >>
> >> So, am I missing something here?  Is this an 
> as-yet-unsolved problem
> >> with RSVP and MPLS?
> > 
> > I hope it is clear.
> > 
> > Regards,
> > Jayesh
>

---

From: Dimitry Haskin <[email-masked]>
Date: Thu, 23 Mar 2000 10:10:15 -0500

> David,
> 
> Thanks for taking the trouble to explain to me.  But I must admit I am
> still unconvinced.  There are two "scenarios" at issue: failover vs.
> load balancing, which have completely different semantics.  I would
> expect that all the nodes (at least the ingress and egress) must be
> solidly configured for one or the other of these "scenarios", and
> the scenario will imply the correct reservation style.
> 
A small but important correction: it is not necessary "one or the other" --
a load balancing reservation may be protected by a failover path.

Dimitry

---

From: Bob Braden <[email-masked]>
Date: Thu, 23 Mar 2000 16:35:57 GMT

*> From [email-masked] Thu Mar 23 07:10:49 2000
  *> From: Dimitry Haskin <[email-masked]>
  *> To: Bob Braden <[email-masked]>, [email-masked], [email-masked], [email-masked]
  *> Subject: RE: Semantics of shared reservations (with RSVP)
  *> Date: Thu, 23 Mar 2000 10:10:15 -0500
  *> MIME-Version: 1.0
  *> X-Mailer: Internet Mail Service (5.5.2650.21)
  *> X-Lines: 13
  *> 
  *> > David,
  *> > 
  *> > Thanks for taking the trouble to explain to me.  But I must admit I am
  *> > still unconvinced.  There are two "scenarios" at issue: failover vs.
  *> > load balancing, which have completely different semantics.  I would
  *> > expect that all the nodes (at least the ingress and egress) must be
  *> > solidly configured for one or the other of these "scenarios", and
  *> > the scenario will imply the correct reservation style.
  *> > 
  *> A small but important correction: it is not necessary "one or the other" --
  *> a load balancing reservation may be protected by a failover path.
  *> 
  *> Dimitry
  *> 
I which case you use reservation style (SE+FF)/2, I suppose.

Your comments seems orthogonal to my point.

Bob

---

From: Dimitry Haskin <[email-masked]>
Date: Thu, 23 Mar 2000 12:10:34 -0500

Bob,

I just tried to point out that configuring the nodes for one or the other
scenarios may not be a solution and when RSVP is used for MPLS some kind of
additional RSVP signaling may be needed to insure that the working and
failover paths are set correctly. However I might have diverted from the
subject of the thread.

Dimitry