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

From: Bob Braden <[email-masked]>
Date: Wed, 22 Mar 2000 22:32:08 GMT

*> 
  *> 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.

If I understand your problem, it is not really the reservation style
you want to signal -- both ends KNOW that SE is to be used -- but some
resource-sharing identifier tag.  Is this correct?

Bob

---

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

Bob Braden wrote:
>>
>> 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.
> 

OK.  Let me see if I can explain my assumptions and my question more
clearly.

Based on what others here have written, I understand that all paths in a
single session that are reseved with SE style must share resources,
right?

This means that if a tunnel-ingress node sets up two different paths in
the same session (differing only by their ERO), the decision on whether
these two tunnels will share resources will be made by the egress node
when it chooses a style for the reservation - SE for sharing, FF for no
sharing.

Sharing makes sense if the two paths are to be used for a primary/backup
fail-over scenario.  Where one carries all data until it fails, then the
ingress node immediately starts sending data over the backup path.  This
way, it doesn't have to wait for a new path to be signalled.  (Note that
this is not the make-before-break scenario of the MPLS-RSVP draft.  That
scenario doesn't set up the backup tunnel until it is time move traffic
to it.)

In other situations, not sharing makes sense.  For instance, if the two
paths are to be used for a load-balancing scenario.  Where the ingress
node sends packets over both tunnels.  (Hopefully, with enough
intelligence so that TCP doesn't end up breaking.)  In this scenario, FF
would be the preferred style.  (Of course, this effect could also be
created by using two sessions and either style.)

In short, I can see reasons why it would make sense for two tunnels in
the same session from a single sender node to use FF or SE style.  But
the ingress node has no standard way of indicating in its Path message
that it wants to use one style or another.  The decision depends on
something else (probably administrative configuration of the egress
nodes.)

I hope this is clearer.

-- David

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 22 Mar 2000 19:55:33 -0500

> something else (probably administrative configuration of the egress

David, Bob,

Hope this helps:

  Internet Draft   draft-ietf-mpls-rsvp-lsp-tunnel-05.txt    February 2000

  ...

  2.4.3. Shared Explicit (SE) Style

   The Shared Explicit (SE) style allows a receiver to explicitly
   specify the senders to be included in a reservation.  There is a
   single reservation on a link for all the senders listed.  Because
   each sender is explicitly listed in the Resv message, different
   labels may be assigned to different senders, thereby creating
   separate LSPs.

   SE style reservations can be provided using multipoint-to-point
   label-switched-path or LSP per sender.  Multipoint-to-point LSPs may
   be used when path messages do not carry the EXPLICIT_ROUTE object, or
   when Path messages have identical EXPLICIT_ROUTE objects.  In either
   of these cases a common label may be assigned.
   Path messages from different senders can each carry their own ERO,
   and the paths taken by the senders can converge and diverge at any
   point in the network topology.  When Path messages have differing
   EXPLICIT_ROUTE objects, separate LSPs for each EXPLICIT_ROUTE object
   must be established.

The next section explains how to use this to reroute tunnels.  It
explains when reservation amounts can be shared when doing
make-before-break rerouting.

A further restriction is found in another draft.

  Internet Draft   draft-ietf-mpls-rsvp-lsp-tunnel-05.txt    February 2000

  3.6 E-LSP Merging

   In an MPLS domain, two or more LSPs can be merged into one LSP at
   one LSR. E-LSPs are compatible with LSP Merging under the following
   condition:

        E-LSPs can only be merged into one LSP if they support the
        exact same set of BAs.

  ...

  4.6 L-LSP Merging

   In an MPLS domain, two or more LSPs can be merged into one LSP at
   one LSR. The proposed support of Diff-Serv in MPLS is compatible
   with LSP Merging under the following condition:

        L-LSPs can only be merged into one L-LSP if they support the
        same PSC.

This seems clear enough once you find it.

Curtis