The MPLS WG Archive

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

Wushao Wen wrote:
> 
> Sure you are right. What we started with is without the implementation
> of MPLS, what can RSVP do. This means that we can not use RSVP-TE. So
> for RSVP itself, it is an resource reservation protool without
> affecting the basic routing mechanism.

Ah.  OK.  I must've missed the beginning of the thread.

The only real concern with using straight RSVP is that it may be
overkill, depending on your application.  RSVP was designed to
accomodate the presence of non-RSVP routers along the path, and
many-to-many multicast sessions.  If thse are not issues for you, you
may prefer to use something lighter-weight for making reservations.

> The use of RSVP-TE must come together with MPLS, otherwise, RSVP-TE
> itself can not implement explicit routing. If we sent IP packet
> directly to the router, even though RSVP-TE was previous used, it will
> not follow the explicit route.
>      Correct me if I miss anything.

Sounds about right.

Note, however, that nothing in the RSVP-TE draft explicitly forbids the
use of an explicit route object with non-LSP sessions.  If someone would
implement such support, the router would have to use the explicit route
when forwarding packets that match the packet's 5-tuple (dest addr, src
addr, protocol, dest port, src port).  This could be done on some
routers by adding policy-based routing information (possibly in
conjunction with /32 routing table entries) in the router's forwarder.

After all, a label is really just a mechanism to eliminate the need to
re-classify data packets at every hop.

But this is now well beyond the scope of MPLS.

-- David