Subject: RE: Traffic engineering and RSVP

From: Shahram Davari <[email-masked]>
Date: Fri, 20 Oct 2000 08:15:35 -0700

Mike,

As you know RSVP uses hop-by-hop routing in which each hop independently
computes the next hop. 

I think your confusion comes from the fact that in your RSVP example you are
assuming that all nodes (even the interior nodes) are running the constraint
based routing computation, so that there is no need for source routing
(explicit routing), rather their hop-by-hop routing results the same path as
the explicit route. This is in theory possible, but it requires massive
computation by all the nodes. In comparison, MPLS requires the path
computation be done only by one node (the ingress node) and then distribute
the computed path to the downstream nodes. 

Regards,
-Shahram

> -----Original Message-----
> From: Mike Badil [mailto:[email-masked]]
> Sent: Friday, October 20, 2000 10:48 AM
> 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.
> -------------------------------------------------------------------
> 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.
> 
> 
> Thanks anyway
> >
> >MPLS solve this problem by doing label swapping instead  of the
> >destination-based routing. Therefore, it is possible for a 
> data packet to
> >use a
> >very short header to direct the router to send the packet to the
> >pre-selected route.
> >
> >
> >Wushao
> >
> >On Thu, 19 Oct 2000, Bora Akyol wrote:
> >
> > > I would not jump on this so fast, there is at least one 
> router out there 
> >that can
> > > do line rate 5-tuple lookups for many, many rules.
> > >
> > > Just because **you** don't know how to do it, doesn't 
> mean it can't be 
> >done.
> > >
> > > Bora
> > >
> > >
> > >
> > > Sudheer Dharanikota wrote:
> > >
> > > > Yes sir.. you are missing many things.
> > > >
> > > > TE is mainly used for core. In core nobody in right mind
> > > > will do 5 tuple lookup on the the Ip packet :-)
> > > >
> > > > - sudheer
> > > >
> > > > Rajeev Manur wrote:
> > > > >
> > > > > see below...
> > > > >
> > > > > -----Original Message-----
> > > > > From: Sudheer Dharanikota [mailto:[email-masked]]
> > > > > Sent: Thursday, October 19, 2000 7:21 AM
> > > > > To: Mike Badil
> > > > > Cc: [email-masked]
> > > > > Subject: Re: Traffic engineering and RSVP
> > > > >
> > > > > Mike Badil wrote:
> > > > > >
> > > > > > Hi
> > > > > >
> > > > > > I confused  when I read traffic engineering with MPLS.
> > > > > >
> > > > > > My question is:
> > > > > >
> > > > > > MPLS is combination of layer 2 swithing and layer 3 
> routing. 
> >Traffic eng.
> > > > > is
> > > > > > part of layer 3. In MPLS route(LSP) is established 
> in advance 
> >according to
> > > > > > the constraints. in other word, instead of choosing 
> shortest path, 
> >it
> > > > > choose
> > > > > > the path which satisfy its requirments, and to make link 
> >utulization
> > > > > better.
> > > > > > In order to have done this with MPLS there are some 
> works which 
> >say that
> > > > > > OSPF,IS-IS can be modified by adding constraint to it.
> > > > > >
> > > > > > That is clear so far,
> > > > > >
> > > > > > I wondering that whether we can have those traffic 
> engineering 
> >conditions
> > > > > be
> > > > > > satisfied by other tech.
> > > > > >
> > > > > > For example; RSVP-Intserv set up route in advance 
> also. If we use 
> >extended
> > > > > > OSPF,IS-IS etc.algorithm with Intserv-RSVP as we 
> use in MPLS,
> > > > > > we can choose the path which satisfy our 
> constraints instead of 
> >choosing
> > > > > > Shortest path. Link load balancing can be done as 
> in MPLS. So most 
> >of
> > > > > > traffic engineering requirements will be 
> satisfied.(let don't 
> >consider
> > > > > > scalibility problem with RSVP now). Or it can work 
> any other 
> >technology
> > > > > > which use RSVP.
> > > > > >
> > > > >
> > > > > The problem is in applying filter at every node to 
> make sure your IP
> > > > > packet
> > > > > is following the selected path. Hence data path becomes slow.
> > > > >
> > > > > RAJEEV> I thought almost all the boxes today perform 
> complete packet
> > > > > processing at line-rate with or without the 
> application of packet 
> >filters. I
> > > > > don't see the relevence of the above statment. Am i missing 
> >anything..
> > > > >
> > > > > - sudheer
> > > > >
> > > > > > What am I missing here?
> > > > > >
> > > > > > 
> >_____________________________________________________________
> ____________
> > > > > > Get Your Private, Free E-mail from MSN Hotmail at 
> >http://www.hotmail.com.
> > > > > >
> > > > > > Share information about yourself, create your own 
> public profile 
> >at
> > > > > > http://profiles.msn.com.
> > >
> >
> 
> ______________________________________________________________
> ___________
> Get Your Private, Free E-mail from MSN Hotmail at 
http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.

---

From: Wushao Wen <[email-masked]>
Date: Fri, 20 Oct 2000 08:43:12 -0700 (PDT)

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. 

Sincerly,

Wushao

---

From: David Charlap <[email-masked]>
Date: Fri, 20 Oct 2000 12:19:08 -0400

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

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

---

From: Wushao Wen <[email-masked]>
Date: Fri, 20 Oct 2000 09:29:49 -0700 (PDT)

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

---

From: David Charlap <[email-masked]>
Date: Fri, 20 Oct 2000 12:46:21 -0400

Wushao Wen wrote:
> 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.

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

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

---

From: Wushao Wen <[email-masked]>
Date: Sat, 21 Oct 2000 21:25:35 -0700 (PDT)

Hi, Frank,
   In fact, RSVP-TE is appropriate for MPLambdas. With the extension to
the original RSVP protocol, RSVP-TE can be used to carry the label binding
information. In the MPLambdaS, the label is now <port #, wavelength#>. RSVP-TE
 can carry the mapping information in the optical cross-connect
for a connection via its MPLS control component in MPLS over WDM
network (MPLambdaS). After the optical crooss-connect's switch fabic is
changed according the new binding, the data packet can use circuit-switch
to transmit the data backet. 
  In fact, the important thing here is that RSVP is only used to carry the
explicit path request along the path. The OXC then can setup its state
according to the request. The underline data backet transmission is based
on label swapping, not destionation-based routing as used by the IP
network, so RSVP-TE can be used for MPLambdaS.
   Thanks!

Wushao

> If I understand what you say about RSVP, then I have to conclude that it is
> not acceptable for traffic engineering and therefore it is also unacceptable
> for MPLambdaS, given any need for the lambda path to be deterministic from
> the ingress point.
> 
> Am I missing something?
> 
> Frank Hujber
> [email-masked]
> ----- Original Message -----
> From: "Wushao Wen" <[email-masked]>
> To: "Shahram Davari" <[email-masked]>
> Cc: "'Mike Badil'" <[email-masked]>; <[email-masked]>
> Sent: Friday, October 20, 2000 11:43 AM
> Subject: RE: Traffic engineering and RSVP
> 
>

---

From: "Frank Hujber" <[email-masked]>
Date: Sat, 21 Oct 2000 20:05:54 -0400

Wushao, Shahram,

Am I missing something?

Frank Hujber
[email-masked]

---

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

Frank Hujber wrote:
> 
> If I understand what you say about RSVP, then I have to conclude that
> it is not acceptable for traffic engineering and therefore it is also
> unacceptable for MPLambdaS, given any need for the lambda path to be
> deterministic from the ingress point.
> 
> Am I missing something?

You're missing the fact that RSVP (aka RFC 2205) and RSVP-TE
(draft-ietf-mpls-rsvp-lsp-tunnel-*) are two different protocols.

Straight RSVP does not carry any routing information, and therefore can
not do traffic engineering by itself.  (Although it can work in
conjunction with a routing protocol that provides the missing feature.)

RSVP-TE, however, does carry explicit routing information.  It should be
sufficient for MPLambdaS.

-- David