The MPLS WG Archive

[Wushao Wen <wswen@ece.ucdavis.edu>]

Hi, David, 
    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.
    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 wil not follow
the explicit route.   
     Correct me if I miss anything.
    Thanks!


Wushao
   
 
> Wushao Wen wrote:
> > 
> > Yes. Shahram is right. In fact, the major task for RSVP is to reserve
> > the necessary resource along the path for a connection. Explicit
> > routing is not a  concern of the RSVP. RSVP does not change the basic
> > packet routing mechanism--analyze the packet header and then do
> > destination-based routing to select the next hop.
> 
> For straight RFC-2205 RSVP, yes.  RSVP is not a routing protocol.  It
> establishes reservations along whatever path the local routing tables
> will forward similarly-addressed data.
> 
> With RSVP-TE (draft-ietf-mpls-rsvp-lsp-tunnel-*), however, this
> changes.  
> The presence of an explicit route object forces RSVP to reserve
> bandwidth along the specified route instead of where the local routing
> table might otherwise dictate.  And it must make certain that data
> packets for the session follow the reserved route instead of the route
> that the routing tables would otherwise use.  (And when these data
> packets are classified by an MPLS label, we call the result an LSP.)
> 
> In other words, while straight RSVP does not change the basic packet
> forwarding mechanism, RSVP-TE definitely does.
> 
> -- David
>