Subject: RE: Traffic engineering and RSVP

From: Shen Gangxiang <[email-masked]>
Date: Sat, 21 Oct 2000 11:02:56 +0800

See my comments between lines.

-----Original Message-----
From: Mike Badil [mailto:[email-masked]]
Sent: Friday, October 20, 2000 10:48 PM
To: [email-masked]; [email-masked]
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

---

From: David Charlap <[email-masked]>
Date: Mon, 23 Oct 2000 10:03:30 -0400

Shen Gangxiang wrote:
> 
> 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).

Traditional RSVP is not a routing protocol.  It isn't supposed to in any
way change the way data packets are routed.  It's only supposed to make
reservations.

> So it can't support traffic engineering.

But it doesn't dictate what other routing protocols might be used.  If
you don't want to use MPLS, you can still use some form of constraint-
based routing to make the data follow a traffic-engineered path.  A
proper RSVP implementation should make reservations along that routed
path, just like it would on any other routed path.

> 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.

RSVP-TE is designed for a completely different purpose.  It is meant to
carry traffic engineering information (labels and explicit paths), in
addition to QoS values.  It is designed to carry this information
through a network where every node is running RSVP-TE.

Straight RSVP is designed to carry QoS values through the internet,
where many nodes will not be running RSVP.  Needless to say, traffic
engineering is impossible if some routers along the data path don't
participate.

-- David