The MPLS WG Archive

[David Charlap <david.charlap@marconi.com>]

James_Huang@Mitel.COM wrote:
> 
>      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?

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
>          message, or

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.

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

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