Subject: question on reservation styles

From: Subhakar K S <[email-masked]>
Date: Fri, 1 Feb 2002 23:20:40 -0800 (PST)

I have question on reservation styles.

In RSVP, how does the egress node decide on which
reservation style to use.

thanks,
S.

__________________________________________________
Do You Yahoo!?
Great stuff seeking new owners in Yahoo! Auctions! 
http://auctions.yahoo.com

---

From: David Charlap <[email-masked]>
Date: Mon, 04 Feb 2002 11:44:01 -0500

> reservation style to use.

In classical RSVP, there is no way for it to know.  The choice is beyond
the scope of RSVP.

In RSVP-TE, the ingress node can request SE style by setting the
appropriate bit in the SESSION_ATTRIBUTE object.  If this bit is set,
then SE style should be used.  If SESSION_ATTRIBUTE is present and this
bit is not set, then FF style should be used.

If SESSION_ATTRIBUTE is not present, then the switch is free to use
either.

Of course, all of the values in SESSION_ATTRIBUTE are advisory, so an
egress router is free to ignore the bits and choose whatever style it
wants, if there is a good reason to do so.  (Possible reasons include
non-support of one style, explicit local policy.)

-- David

---

From: "Osama Farrag" <[email-masked]>
Date: Thu, 14 Feb 2002 19:11:22 -0500

Assume the following Network topology

                                 +--------+
                                 |        |
                                 |        |
                         --------|    I1  |
                        /        |        |
                       /         +--------+
                      /
+------+          +-------+       +-------+
|      |          |       |       |       |
| E1   |----------|  C1   |-------|  I2   |
|      |          |       |       |       |
+------+          +-------+       +-------+
                      \
                       \          +-------+
                        \         |       |
                         ---------|  I3   |
                                  |       |
                                  +-------+

If LER I2 initiates an LSP to E1 using RSVP-TE path message,  with SE bit
set. Then at later point in time LER I1, initiates RSVP LSP tunnel to E1
with SE bit set and same TUNNEL-ID value used by I2 in session object.

A- When the second Path message arrive at E1; assume E1 supports SE style,
Does E1 required to assign a new MPLS label in RSVP response message? or
send the same label used in the previous message?

B- What should happen at C1;

First: when the second Path message is received from I1, should it pass thru
to E1? if not then point A is not an issue, But then C1 must respond with
RESV message and assign a LABEL to I1. I think  RESV must be initaited from
the EGRESS LER.

Second: If C1 passes the Second path message thru to E1, then when it
receives RESV message from E1 and SE bit set, I assume it will merge the
LSPs from I1 and I2. If a new Label is assigned by E1 which Label C1 should
use for traffic bound for E1, can it continue to use them both and refresh
them. I think that C2 must maintain both labels and merge action at C1 only
implies that resevered resources are shared but these two LSPs that are
associated by TUNNEL-ID?

Regards
Osama Farrag

What happens at C2; does CE merges the two LSPs?

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]On Behalf Of David
>Charlap
>Sent: Monday, February 04, 2002 11:44 AM
>To: rsvp-te
>Subject: Re: question on reservation styles
>
>
>Subhakar K S wrote:
>>

---

From: David Charlap <[email-masked]>
Date: Fri, 15 Feb 2002 10:29:07 -0500

Osama Farrag wrote:
> If LER I2 initiates an LSP to E1 using RSVP-TE path message,  with
> SE bit set. Then at later point in time LER I1, initiates RSVP LSP
> tunnel to E1 with SE bit set and same TUNNEL-ID value used by I2 in
> session object.

These two LSPs may or may not be in the same session.

If they have different extended tunnel IDs (which is the normal case,
where the extended tunnel ID is set to match the sender address), then
the two LSPs belong to different sessions, and there should be no
interaction between them whatsoever.

If the two LSPs are sent with identical extended tunnel IDs (which
should be zero, if two senders use identical extended tunnel IDs), then
they may share resources if the egress router requests SE style.

> A- When the second Path message arrive at E1; assume E1 supports SE
> style, Does E1 required to assign a new MPLS label in RSVP response
> message? or send the same label used in the previous message?

E1 can theoretically assign the same label for both LSPs, if C1 supports
label merging.  (POS interfaces are assumed to support label merge.  ATM
interfaces may or may not support it - the LABEL_REQUEST object will
indicate whether it does or not.)

In actual practice, however, it is more likely that E1 will assign
separate labels for the two LSPs, since it is difficult to accurately
determine whether a label merge operation is safe to perform.

> First: when the second Path message is received from I1, should it
> pass thru to E1? if not then point A is not an issue, But then C1
> must respond with RESV message and assign a LABEL to I1. I think 
> RESV must be initaited from the EGRESS LER.

Yes.  All Path messages must be passed to the egress.  This is a
requirement of both FF and SE style.  Please note that SE-style Resv
messages must explicitly identify the senders.  The egress node can't do
this if it doesn't know who those senders are.

The only time it is OK to not forward a Path message is if there is a
WF-style reservation in place.  But WF style is not used with MPLS.

Keep in mind that even if labels are merged, there are still two LSPs in
place on the network.  RSVP is not LDP.  They do not work anything like
each other.

> Second: If C1 passes the Second path message thru to E1, then when
> it receives RESV message from E1 and SE bit set, I assume it will
> merge the LSPs from I1 and I2.

Define "merge" in this context.

If E1 decides to make an SE-style reservation, then both LSPs will get
the same FLOWSPEC (meaning the same service level).  This is a
requirement of SE style.

E1 does now, however, have to assign the same label to both LSPs.  If it
is capable of sharing resources between two connections, then it may
choose to create two separate connections, and have them share
resources.  Label merging is not a mandatory feature.

> If a new Label is assigned by E1 which Label C1 should use for
> traffic bound for E1, can it continue to use them both and refresh
> them. I think that C2 must maintain both labels and merge action at
> C1 only implies that resevered resources are shared but these two
> LSPs that are associated by TUNNEL-ID?

The Path and Resv messages must always be refreshed, even if both LSPs
are using the same label values.

An LSP does not cease to exist simply because it is sharing resources
with another LSP.

-- David