The MPLS WG Archive

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

Hi, David,

Please see my comments below.

-----Original Message-----
From: David Charlap
To: mpls@UU.NET
Sent: 23/10/00 10:03 PM
Subject: Re: Traffic engineering and RSVP

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.

=>Agree. In fact, I guess you have misunderstood me. I didn't mean that RSVP
is a routing protocol. I just wanted to point out that RSVP needs
information from the routing ptotocols (e.g. PATH message)

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

=>Agree. However, to support traffic engineering, some extentions are still
needed, e.g. ER.

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

-- David