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

From: Bob Braden <[email-masked]>
Date: Wed, 22 Mar 2000 23:26:17 GMT

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.

But then, I am just an academic, what do I know?

As far the original issue is concerned, I had trouble following the
discussion, but here is what seems like a simple way to think about it.
In sending out two paths, H1 is serving as two logical senders,
distinguished by ERO.  I don't know if this is the way it DOES work,
but it OUGHT to work just fine if H2 sends a Resv(SE, Q, (ERO1, ERO2)),
which R6 splits into Resv(SE, Q, (ERO1)) and Resv(SE, Q, (ERO2)) along
the two paths.  These get merged again by R1 into Resv(SE, Q, (ERO1, ERO2)).
This creates one shared reservation at H1, as desired.

Bob Braden

---

From: David Charlap <[email-masked]>
Date: Wed, 22 Mar 2000 18:45:53 -0500

> the scenario will imply the correct reservation style.

Perhps, but it seems to me that only the ingress node (which classifies
the packets into one tunnel or the other) really needs to know anything
special, if the correct reservation style is chosen at the other end.

> discussion, but here is what seems like a simple way to think about
> it.  In sending out two paths, H1 is serving as two logical senders,
> but it OUGHT to work just fine if H2 sends a Resv(SE, Q, (ERO1,
> ERO2)), which R6 splits into Resv(SE, Q, (ERO1)) and Resv(SE, Q,
> (ERO2)) along the two paths.  These get merged again by R1 into
> Resv(SE, Q, (ERO1, ERO2)).  This creates one shared reservation at H1,
> as desired.

Correct.

My original question was based on a gross misunderstanding of SE.  I was
under the impression that a single session under SE could have multiple
flow descriptors - that is, multiple groups of senders that share
resources within the group but not with other groups.

Based on other posts here, which encouraged me to look more closely at
the RFCs, I now believe that I was wrong in that assumption.  So the
original problem (of how R1 can properly re-merge the two single-sender
reservations back into a single shared reservation) no longer exists.

I can go into the details of my original misunderstanding if you're
interested, but I'll take that off the list, since it really isn't
relevant.

-- David