The MPLS WG Archive

["Frank Hujber" <fhujber@optonline.net>]

Wushao, Shahram,

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
fhujber@hotmail.com
----- Original Message -----
From: "Wushao Wen" <wswen@bass.ece.ucdavis.edu>
To: "Shahram Davari" <Shahram_Davari@pmc-sierra.com>
Cc: "'Mike Badil'" <hasko10@hotmail.com>; <mpls@UU.NET>
Sent: Friday, October 20, 2000 11:43 AM
Subject: RE: Traffic engineering and RSVP


> 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
>
> >
> > 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:hasko10@hotmail.com]
> > > Sent: Friday, October 20, 2000 10:48 AM
> > > 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.
> > > -------------------------------------------------------------------
> > > 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:sudheer@nayna.com]
> > > > > > > Sent: Thursday, October 19, 2000 7:21 AM
> > > > > > > To: Mike Badil
> > > > > > > Cc: mpls@UU.NET
> > > > > > > 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.
> >
>
>