Subject: Semantics of shared reservations (with RSVP)

From: David Charlap <[email-masked]>
Date: Tue, 21 Mar 2000 17:00:16 -0500

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)

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.

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?

-- David

---

From: Jayesh V Shah <[email-masked]>
Date: Tue, 21 Mar 2000 17:38:33 -0500

Hi David,

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

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

> So, am I missing something here?  Is this an as-yet-unsolved problem

I hope it is clear.

Regards,
Jayesh
-- 
__________________________________________
Jayesh V. Shah
GlobeSpan, Inc.
Tel:  (732) 283-2770  x321
Fax:  (732) 283-2848
E-mail: [email-masked]
Web:    http://www.ficon-tech.com/home.htm

---

From: David Charlap <[email-masked]>
Date: Tue, 21 Mar 2000 17:49:59 -0500

Jayesh V Shah wrote:
>> 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 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
> 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.

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

>> 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?
>>

---

From: Jayesh V Shah <[email-masked]>
Date: Tue, 21 Mar 2000 18:56:41 -0500

> it doesn't then it is signalling two separate resource-sharing groups.

What do we mean by multiple resource sharing groups within the same
session ? 

> If a switch assumes sharing when this specification is not present, it

R1 would get two different Resv, both with SE style with individual
filter specs. R1 would make reservations accordingly, as the outgoing
interfaces for the two flows are different. However, when forwarding the
Resv to H1, the Resv Merge would result in a single SE style Resv, with
two filter specs, one corresponding to each sender. As a matter of fact,
R1 can as well forward two different Resv., one for each filter spec,
without changing the interpretation for H1, because the style is SE.

The senders should be explicitly specified for the switch to share
reservation in the case of SE, but they need not belong to the same Resv
message.

Regards,
Jayesh

---

From: David Charlap <[email-masked]>
Date: Tue, 21 Mar 2000 19:07:19 -0500

Jayesh V Shah wrote:
>>>> 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)
>>>>
>>>> (indicated by different tunnel IDs) are to use shared resources.
>>>> The flow descriptor looks something like:
>>>>
>>>>         FLOWSPEC
>>> 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.
> 

Two flows (as defined by session-filterspec pairs) that share resources
together.

Either the two flows share resources, or they do not.

If they share resources, the flows are described by a single flow
descriptor.  If they do not, they are described by two separate flow
descriptors.

>>>> 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).
>>
>> If a switch assumes sharing when this specification is not present,
>> it is in error.
> 
> interfaces for the two flows are different. However, when forwarding
> the Resv to H1, the Resv Merge would result in a single SE style Resv,
> with two filter specs, one corresponding to each sender.

But these two filterspecs should be in one flow descriptor.  If they are
placed in separate flow descriptors, then resources are no longer shared
along the common link from H1 to R1.

Regardless, I got my answer from Andi's post.  The answer is that the
flow descriptors are not broken up in the first place, so R1 doesn't
lose the resource-sharing information.

> As a matter of fact, R1 can as well forward two different Resv., one
> for each filter spec, without changing the interpretation for H1,
> because the style is SE.

Only if the two filterspecs are in separate flow descriptors.  If they
are sharing resources, then you can not reserve them in two separate
Resv messages - to do so would create two distinct reservations.

> reservation in the case of SE, but they need not belong to the same
> Resv message.

No.  If two filterspecs are specified in two separate Resv messages,
then they can not share resources unless the style is WF.

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

This was my incorrect assumption.  R6 doesn't break up the flow
descriptor.  Both Resv messages contain the flow descriptor that
specifies both senders.  R1 receieves two Resv messages, each of which
describes both senders.  And that maintains the resource sharing.

-- David

---

From: Jayesh V Shah <[email-masked]>
Date: Tue, 21 Mar 2000 20:23:59 -0500

> descriptor.  If they do not, they are described by two separate flow

But SE style doesn't allow multiple flow descriptors. You can only have
a single FlowSpec, followed by a list of filter specs. Look at the BNF
notation for SE style Resv message 

If you follow the steps for RESV REFRESH sequence in RFC 2209 (Message
Processing), specifically step # 5, regardless of the fact whether you
receive all the filter specs in a single or multiple Resvs, it will
result in a single resv refresh to the PHOP, with a merged FlowSpec and
a list of FilterSpecs, which is the union of all the Filter Specs,
across all the Resvs you have received for this session, sharing the
same PHOP.

> Resv messages - to do so would create two distinct reservations.

I don't agree with you here. Going by the message processing rule, I
don't think it would result in two distinct reservations.

Assuming the case that you receive two different SE style reservations,
for the same session, encompassing different filter specs, coming from
the same NHOP, it would result in just a single RSB, with a single
FlowSpec, and a list of FilterSpecs equal to the union of those in the
two Resvs. Look at Page 11 of RFC2209.

My question still remains, is it possible to have multiple resource
sharing groups within the same session for SE style reservations ?

> describes both senders.  And that maintains the resource sharing.

No. The flow descriptor list is broken. Refer to examples given at the
beginning of RFC 2205. However, Andi's post makes it clear that even if
they are not, there is no harm, because extra filter specs will get
ignored at the PHOP. And even if R6 does not split the filter Spec list,
the Resv coming out of R3 will contain just a single filter spec,
according to step 3 in Andi's post.

Regards,
Jayesh