Subject: Questions on RSVP-TE

From: [email-masked]
Date: Mon, 22 Jan 2001 12:33:33 -0800

From:  James Huang@MITEL on 01/22/2001 12:33 PM PST
David,
     Thanks for answering my question.

     I have some more questions about RSVP-TE.
(1) Why do we need both a generic RSVP session object and RSVP-TE specific
LSP_TUNNEL_IPV4 object?
(2) When a edge router of a MPLS domain receives a RSVP PATH message from the
non-MPLS domain, what is the correct behavor?
     (a) Should the edge router convert it into a RSVP-TE PATH message, or
     (b) should the edge router uses CR-LDP to create a LSP (using the
destination IP address in the session object as the FEC) and then label-switched
the RSVP PATH message across the MPSL domain (so that resources will not be
double-booked in the MPLS domain)?

Both of the choices above seems to have scalability problem.
Also in (a), how does the edge router know what should be the other end point of
the RSVP tunnel?

(3) Same question as (2) above for RSVP RESV message.

Thanks in advance for your reply.

-- James Huang

David Charlap <[email-masked]> on 01/22/2001 07:36:11 AM

To:   [email-masked]
cc:    (bcc: James Huang/USA/Mitel)

Subject:  Re: FEC element for RSVP-TE?

[email-masked] wrote:
>
>      I have one question in mind when reading the RSVP-TE draft.  Does
> RSVP-TE define some object similar to FEC element in the LDP draft so
> that we can set up a LSP for traffics belonging to the FEC?

No.

RSVP-TE is not a label-distribution protocol.  It is a tunnel setup
protocol.  This is an important semantic difference.

> If the RSVP path message does not carry such object and it does not
> carry a ER object, then intermediate LSR can only use the destination
> IP address in the session object to determine the next hop.

Correct.

> This means the ingress RSVP initiator need to know exactly who will be
> the egress router when it sends out the RSVP path message.    This
> does not seem to be very pratical to me in the case where RSVP-TE is
> used to set up a LSP tunnel for traffics belonging to a FEC  to meet
> its bandwidth requirements.

RSVP-TE is addressing a different problem from LDP.

LDP's goal is to get labels on all the switches so that they may be used
in lieu of IP best-match algorithms when forwarding traffic.  Its goal
is not to establish tunnels, although that does happen as a result of
label distribution.

RSVP-TE's goal is to establish tunnels between endpoints.  In order to
do so, it must know what those endpoints are.  Its goal is not to
distribute labels, although that does happen as a part of establishing
tunnels.

In other words, there are situations where LDP makes more sense than
RSVP.  One such situation is where you don't know, and can't determine,
where your tunnel endpoints will be.

There are also situations where RSVP makes more sense than LDP.  One
such sitation is where shared reservations (for make-before-break
rerouting) is required.

-- David

---

From: David Charlap <[email-masked]>
Date: Mon, 22 Jan 2001 16:18:53 -0500

[email-masked] wrote:
> (1) Why do we need both a generic RSVP session object and RSVP-TE
> specific LSP_TUNNEL_IPV4 object?

You never use both at once.

The nature of RSVP is that each object class has one or more C-Types,
which may be thought of as subclasses.  You only use one C-Type or
another, not both.

You would use an IP4 session object for an RSVP session that does not
involve MPLS.  You would use an LSP-IP4 session object for an RSVP
session that is being used for MPLS tunnel setup.

> (2) When a edge router of a MPLS domain receives a RSVP PATH message
> from the non-MPLS domain, what is the correct behavor?

If an RSVP message arrives from outside the MPLS cloud, then that
message obviously is not meant for tunnel setup.  It is some application
somewhere (possibly far away on the internet somewhere) that wants to
reserve resources wherever possible along the route to the destination
address.

If you are running a network providing transit to that destination, you
can either choose to reserve those resources, or you can choose not to
reserve them.

If the source, destination and MPLS cloud are all part of the same
enterprise, you will probably want to make the reservation.  If the MPLS
cloud is some third party carrier, you will probably not want to make
the reservation.  I doubt many carriers will want random third parties
from the internet creating LSPs in their network cores.

If you don't want to reserve resources, you just forward the RSVP
messages like any other data packet.  The next RSVP router along the
path will detect your MPLS cloud as a non-RSVP segment and will act
accordingly.

If you want to reserve resources, your best bet is probably to create an
LSP through the cloud with a QoS level similar to those being
requested.  How you do that is beyond the scope of this working group, I
think.

>      (a) Should the edge router convert it into a RSVP-TE PATH

I don't think this will work.

RSVP-TE doesn't work over non-RSVP links, so you'll have to rewrite the
session object's destiation address with the tunnel egress address.  And
when the message gets there, there won't be any way to get back the
original message, to forward on to the original destination.

>          destination IP address in the session object as the FEC) and
>          then label-switched the RSVP PATH message across the MPSL
>          domain (so that resources will not be double-booked in the
>          MPLS domain)?

This is one way.  You can even choose to use RSVP-TE to set up the LSP
if you like.  Once the LSP is established, the data packets (even ones
containing RSVP control traffic) will be labeled and blindly forwarded
through the LSP to the other side of the MPLS cloud.

> Both of the choices above seems to have scalability problem.

Another reason why carriers will probably do nothing and forward the
RSVP message like an ordinary data packet.

-- David