Subject: RE: Traffic engineering and RSVP

From: Eyad Saheb <[email-masked]>
Date: Thu, 19 Oct 2000 19:20:11 -0400

>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]]On Behalf Of David
>>Charlap
>>Sent: Thursday, October 19, 2000 5:36 PM
>>To: [email-masked]
>>Subject: Re: Traffic engineering and RSVP
>>
>>
>>Rajeev Manur wrote:
>>
>> I never said anybody would or would not do 5 tuple lkup in the core.
>> All i am saying is that your statement "Hence data path becomes slow"
>> does not make any sense, because as far as i know today's packet
>> processors can handle this without affecting the line-rate
>> performance..
>
>What do you define as "line rate"?
>
>OC-3?  OC-12?  OC-48?  OC-192?  Faster?
>
>And how many ports per switching fabric?  4? 16? 256? more?
>
>No matter how fast the chips in your switching/routing processor can do
>5-tuple lookups, there are environments where they are not fast enough.
>And these environments are what you typically find in the core of major
>networks.
>
>Customers are looking for ever-increasing line rates, and increasing
>port densities.  And their demands are increasing faster than the
>ability of chip vendors to implement IP routing-table lookups. 
>Especially if those lookups involve more than just matching destination
>addresses.
>
>-- David

I have to concur.  5-tuple lkups have their limitations, not the least of
which is speed.  Doing "TE" the way that Mike Badil suggested would also
make the other benefits of MPLS harder to do (ex. tunneling, n->1 fast path
protection, etc...).

Eyad

---

From: Eric Gray <[email-masked]>
Date: Thu, 19 Oct 2000 18:06:48 -0700

Debanjan,

	Many, as we know, means "more than a few".
Few means "more than a couple and less than many".
Therefore, "many" means at least 4 and "many, many"
equates to at least 16.

	Underwhelming, isn't it? :-)

--
Eric Gray

> From: Debanjan Saha [mailto:[email-masked]]
> Sent: Thursday, October 19, 2000 6:00 PM
> To: Bora Akyol
> Cc: Sudheer Dharanikota; [email-masked]
> 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 curious -- what is the line rate and what does "many, 
> many" stand for? :-)
> 
> Regards,
> Debanjan
>

---

From: "Mike Badil" <[email-masked]>
Date: Fri, 20 Oct 2000 10:48:11 EDT

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
> > 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...
> > > >
> > > > From: Sudheer Dharanikota [mailto:[email-masked]]
> > > > Sent: Thursday, October 19, 2000 7:21 AM
> > > > To: Mike Badil
> > > > Cc: [email-masked]
> > > > 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: Shahram Davari <[email-masked]>
Date: Fri, 20 Oct 2000 10:43:32 -0700

Hi David,

> 
> Note, however, that nothing in the RSVP-TE draft explicitly 
> forbids the
> use of an explicit route object with non-LSP sessions. 

Label and Label-objects are mandatory in RSVP-TE. This means you have to use
the RSVP-TE for MPLS purpose.

Regards,
-Shahram

---

From: Shahram Davari <[email-masked]>
Date: Fri, 20 Oct 2000 10:44:57 -0700

Hi David,

> use of an explicit route object with non-LSP sessions. 

Label-request and Label objects are mandatory in RSVP-TE. This means you
have to use the RSVP-TE for MPLS purpose.

Regards,
-Shahram