The MPLS WG Archive

[Shen Gangxiang <EGXShen@ntu.edu.sg>]

See my comments between lines.

-----Original Message-----
From: Mike Badil [mailto:hasko10@hotmail.com]
Sent: Friday, October 20, 2000 10:48 PM
To: wswen@ece.ucdavis.edu; mpls@UU.NET
Subject: Re: Traffic engineering and RSVP



Thanks eveybody for answer,
see my comments below,



>In fact, I think the discussion here missed something on the the basic
>operation of the IP network. To send a data packet from a source to a
>destination, we need to refer to  two components--the
>information carried inside the packet and a routing tabel (or switching
>table). Because  the
>conventional IP network's routing is based on the destination address, if
>we want to route the packet via an explicit path, it is necessary for the
>IP header to carry some additional information. IP uses optional header to
>carry the explicit route information so that the router inside the network
>can process the explicit route request instead of   the
>destination-based routing. However, the processing overhead for such
>optional header is prohibiting high and it is not a very good solution for
>traffic engineering.
-------------------------------------------------------------
Yes, I absulutly agree with you. So far it is very clear to me.
-------------------------------------------------------
>Without MPLS, evern though we can use OSPF or other
>link-state routing protocol to distribute the routing information, and use
>the RSVP or other protocols to reserved the network resource, it
>can not eliminate the requirement of the data packet to carrry the
>explicit route information. Otherwise, the data packet will not follow the

>explicit path.
-------------------------------------------------------------------
Mike wrote:

But how does it happened in RSVP, it established the path first then forward

packets over pre-established path. isn,t it explicit path?

I know, since we don't use swithing it will be slower than in case of 
swithing(MPLS).But lets forget about scalibility of RSVP, since in RSVP the 
paths are pre-established, in first router which makes the decision I can 
choose same the path for RSVP and MPLS, because both can use same algorithm 
to calculate the path. but after that MPLS path will be faster than the RSVP

path because it use swithing.

My question is; when you say RSVP will not use the explicit path what you 
mean, what today's RSVP doing? I think it established the path first then 
all the packets belongs to same flow follow same path. If this case true, 
then by using RSVP for pre-established path, we can satisfy TE requirments, 
such as lightly loaded path, link utilization etc.
Lets forget about scalibility and packet processing time at this moment.

Conventional RSVP doesn't support explicit path. In fact, it find its path
based on the route table provided by those routing protocols hop by hop
(e.g.OSPF). So it can't support traffic engineering. However,in MPLS people
extended RSVP to let it support explicit path, that is RSVP-TE, so it can
support traffic engineering now. Besides RSVP-TE, CR-LDP also have the
functionlity to support traffic engineering.
 

Thanks anyway
>