Subject: LSP merge & RSVP

From: Nick Weeds <[email-masked]>
Date: Tue, 18 Jan 2000 16:47:58 -0000

I would like to confirm the mechanics of LSP merging when LSPs are set up
using RSVP.  It appears that this area has been discussed on the mailing
list before, but the mailing list archive and the current drafts don't
appear to state the mechanism to be used.  Interoperability is unlikely
unless a common mechanism is used.

Suppose we have the following setup:

	A
	 \
	  \
	   C===D===E
	  /
	 /
	B

Suppose that both A and B send Path messages.  The Path messages have
identical RSVP SESSION objects specifying tunnel endpoint address E, but
different Sender Templates (specifying different LSP IDs).

Suppose that LSP merging at C is possible
- C is capable of LSP merging
- Shared Explicit style is used
- Both Path messages have "Merge permitted" flag in Session
  Attributes set
- Explicit Route objects in the Path messages are compatible
- QoS parameters are compatible.

I believe that LSP merging is signalled as follows.
- C forwards both Path messages to D.
- D forwards both Path messages to E.
- E decides to merge LSPs.
  It assigns a single incoming label and sends a single
  Resv to D.
  This Resv specifies Shared Explicit style, and a FlowSpec
  suitable for the merged LSP.
  It contains two FilterSpecs, one for A and one for B.
  It contains a Label object for each FilterSpec, but
  specifies identical label values for A and B.
- D assigns a single incoming label and sends a single Resv
  to C.  This Resv also specifies identical label values
  for A and B.
- C is the merge point.
  It assigns two incoming labels, one for A and one for B.
  It sends one Resv to A and one Resv to B.
  Each Resv contains a single FilterSpec and a single Label.

Is this correct?  This approach seems to be consistent with normal RSVP
behaviour, and draft-ietf-mpls-rsvp-lsp-tunnel allows identical label values
in a Resv message.

The alternative would be that C merges the two Path messages and sends a
single Path message to D.
- C forwards a single Path message to D.
- D forwards a single Path message to E.
- E assigns a single incoming label and sends a single Resv
  to D.  This Resv contains a single FilterSpec and a single
  Label.
- D assigns a single incoming label and sends a single Resv
  to C.  This Resv contains a single FilterSpec and a single
  Label.
- C assigns two labels, one for A and one for B.
  It sends one Resv to A and one Resv to B.
  Each Resv contains a single FilterSpec and a single Label.

The alternative approach is less consistent with normal RSVP behaviour (Path
messages are never merged in normal RSVP), but it could probably be made to
work.

The responsibilities of the merge point and the egress point are quite
different with the two approaches, so interoperability is unlikely unless
the two implementations agree on a common approach.

	Nick.

---

From: "Agranoff, Saul" <[email-masked]>
Date: Tue, 18 Jan 2000 13:39:06 -0500

I think there are some problems here...  See below.

> -----Original Message-----
> From: Nick Weeds [mailto:[email-masked]]
> Sent: Tuesday, January 18, 2000 11:48 AM
> To: [email-masked]'; [email-masked]'; [email-masked]'
> Subject: LSP merge & RSVP
> Importance: Low
> 
> 

Shared Explicit is not known in Path messages.  

Furthermore, Shared Explicit is a term for RESOURCE sharing
(i.e. 'reservations'), not for LABEL sharing.  I see no 
reason why FF-styled flows cannot use shared labels, if we
can nail down the rules.

> - Explicit Route objects in the Path messages are compatible

"Compatible" is an interesting term.  The Explicit Route List 
must be IDENTICAL from C onward, and also must contain all
STRICT subobjects, consisting of full 32-bit IP addresses, all
the way to the destination LSR's address.

If there are any loose objects or any subnets in the Explicit 
Route List, or if the Explicit Route List is partially
specified, then all bets are off.

> - QoS parameters are compatible.

Again, "compatible" is interesting.  Can we define "compatibility"
here?

>   It assigns a single incoming label and sends a single

E cannot assign the same label to both flows unless it knows 
that there is at least one merge-capable LSR upstream, where
the two flows are conjoined (not sure if this is the right term,
but in this case E must know that EITHER C or D is merge-capable.)

How does E know this?  It isn't in the protocol, is it?

In fact, unless the RECORD_ROUTE object is used, E doesn't
even KNOW that the upstream links are in common.

Perhaps a way to solve this is to force the use of RECORD_ROUTE
(if merging is to be allowed) AND TO ADD A 'MERGE-CAPABLE' BIT
to the 'Flags' section of the RECORD_ROUTE subobject?

If we did this, then LSR 'E' could do as you say, by analyzing
the RECORD_ROUTE objects in the two Path State Blocks.

>   suitable for the merged LSP.

Again, SE/FF is a decision as to whether both flows are going
to be active at the same time.  If both senders are sending
independently of each other, it is my understanding that
FF style must be used.  But I don't think this changes the
label-merge scenario you're proposing.

> messages are never merged in normal RSVP), but it could 

This approach may work.  It may offend the RFC2205 purists.
It seems like it HELPS the scaling properties of RSVP.

There is still the issue of how to generate the SENDER_TSPEC
for the 'merged Path' message.  The SE/FF question is normally
made at the egress point.  But let's say that we could decide
at node C whether FF or SE style is appropriate.  (In one case
the resulting TSPEC is additive, while in the other case it's
some kind of LUB calculation)

But:  Let's say that one flow is up and established, and the
second 'Path' message starts.  This could cause the SENDER_TSPEC
in the 'Path' messages from C-to-D to 'increase'.  This COULD
result in some resource reservation failing somewhere downstream,
which COULD cut off the already-established LSP.  

Somewhat farfetched?  I'm not sure.

> the two implementations agree on a common approach.

I agree with Nick.  We need guidelines and rules for Label Merging if
any interoperability is a goal.  There are also some 
holes in the operational rules which need to be solved.

Saul Agranoff
Harris & Jeffries, Inc.

---

From: Nick Weeds <[email-masked]>
Date: Tue, 18 Jan 2000 20:12:57 -0000

Saul,

Thanks for your comments.

Key points before launching into details:
- I was under the impression that setup of multipoint-to-point
  LSPs using RSVP is a "solved" problem (and probably even
  supported in some existing products).
  I was trying to understand existing solutions, not propose
  new solutions.
  Maybe I was wrong and it's still an open problem.
- I did realize that there are detailed questions to answer
  whichever approach is followed.  I deliberately avoided
  discussing the details in order to focus on the basic
  question: do we forward all Path messages then send back
  Resvs with FilterSpecs specifying identical labels, or
  do we merge the Paths into a single Path message.

I still want to concentrate on answers to the key questions:
- Is LSP merge using RSVP a "solved" problem ?
- If so, what is the basic mechanism ?

More detailed comments follow below...

> From: Agranoff, Saul [mailto:[email-masked]]
> Sent: 18 January 2000 18:39
> To: [email-masked]'
> Subject: RE: LSP merge & RSVP
> 
> 
 
True enough.  If reservation style is important, then we must
wait until the Resv message to decide what to do.
This is OK with approach #1.
It is a problem for approach #2.

> reason why FF-styled flows cannot use shared labels, if we

I get the impression that label sharing for FF style
reservations isn't really the expected behaviour.
Also, you could argue that FF style bars resource sharing,
that label sharing forces resource sharing, and that FF
style therefore bars label sharing.
 
> specified, then all bets are off.

In fact with approach #1 the merge decision needn't go into such
details.  Suppose that the merge decision is postponed until the
Resv is processed, and that the merge decision "zips back" from
the egress point to the merge point.
- At the egress point the Explicit Route Object is effectively
  empty, so detailed ERO conditions are unnecessary.
- Transit points make merge decisions in order starting at the
  penultimate node and progressing towards the ingress nodes
  (because this is the order that they process the Resv).
- Each transit point will merge the two Paths based on
  - whether the two Paths have the same outgoing interface and
    outgoing label
  - whether the two Paths have the same incoming interface.
  These considerations pretty much determine the LSP merge action.
  Of course, different EROs might well result in different outgoing
  interfaces and therefore no LSP merging - but it's still
  possible that different EROs will end up using the same outgoing
  interface.

With approach #2 the EROs must be checked in detail before merging
the Path messages.

> Again, "compatible" is interesting.  Can we define "compatibility"

Let's come back to this later, when some of the more basic
questions have been answered.
In the meantime, I think it's clear that if one Path specifies
RSVP COS Service and the other specifies IntServ Controlled
Load Service then they aren't compatible.  This would be a
problem even when there is no LSP merging.

> How does E know this?  It isn't in the protocol, is it?

Good question.

I don't think it's in the protocol.  It might be possible
to fiddle around with the "merge permitted" flag in Session
Attributes, but I don't wish to advocate this.
(The "merge permitted" flag claims to control RSVP Session
merging not LSP merging.  I really don't want to introduce
the additional complication of RSVP session merging.)

In the short term, E would probably have to rely on configuration
information and/or rules of thumb.
eg "Don't send back merged labels if the incoming interface is ATM"
or "Don't send back merged labels if unless the incoming interface
is configured to do so."
I agree that it would be nice to do better...
 
> label-merge scenario you're proposing.

The SE/FF question doesn't affect the basic scenario I'm describing.
I agree that using SE for LSP merging is stretching the original
meaning of SE style reservations quite a bit...
 
> It seems like it HELPS the scaling properties of RSVP.

I suspect that approach #2 would involve a variety of nasty
problems because of deviation from RFC2205.

Approach #2 probably doesn't affect the scaling of LSP setup -
even if with Path message merging it would typically be necessary
to send a new merged Path message every time a new ingress is
added.  However, it might help the scaling of soft state refreshes.
 
> Somewhat farfetched?  I'm not sure.

Sounds like a significant problem to me.

---

From: "Abes, Andi" <[email-masked]>
Date: Tue, 18 Jan 2000 16:07:14 -0500

Hi,

I've been batteling the same question for a while, and 
IMHO:

 - if the aim in merging path message is to reduce refresh traffic, 	
   a tunnel (hierarchy) can be used to between C-D-E, 
   so that D is isolated from refresh messages (at least to some extent) 
   made by A and B.
   This, of course, brings up the whole issue of hierarchies through RSVP
   signalling, which is a little neglected in the current draft. 

 - Deciding to merge at any point other than the egress will make
   management and policy control a living hell - any router along 
   the can will have to be configured/signaled if to merge and what.
   In the classic RSVP scheme, only the egress points need to maintain
   policy information regarding mergin. More over, the source of the traffic
   might indicate different policy (temporal or other, that doesn't mandate
   using different Tunnel ID's).

Andi

> Sent: Tuesday, January 18, 2000 3:13 PM
> To: 'Agranoff, Saul'
> Cc: [email-masked]'; [email-masked]'; [email-masked]'