RE: [PCN] RSVP and ECMP

["Jozef Babiarz" <[e-mail]>]

Yes, I think this would be reasonable starting point for PCN.  

Regards, Joe
email:[e-mail]
Telephone:[phone]

-----Original Message-----
From: Anna Charny (acharny) [mailto:[e-mail]] 
Sent: October 24, 2007 10:19 AM
To: Bruce Davie (bdavie); [e-mail]
Cc: [e-mail]
Subject: RE: [PCN] RSVP and ECMP

Hi all,

Bringing this in the context of using RSVP messages for probing.  

If internal pcn nodes are doing the "standard" load-balancing (i.e. use
ip src & dst or the 5-tuple) info from the packet header), then it seems
at least two deployment scenarios are "safe" in terms of sending the
RSVP messages along the same path as the data:

1) a(per flow) intserv-over-diffserv situation - in this case per-flow
rsvp messages will have the appropriate fields used by ecmp the same as
the corresponding data packets of this flow

2) an aggregate rsvp reservation coupled with tunnelling.  (If tunneling
is not used,  then if the core does load balancing based on 5-tuple,
different flows inside the reservation might be forwarded on different
paths)

Not so safe cases arise in general when ecmp looks deeper into the
packet than the granularity of RSVP message (i.e the "flow" granularity
as seen by RSVP is different than the "flow" granularity as seem by
ecmp; e.g. when RSVP is used on an mpls tunnel, but the ecmp looks at
the 5-tuple). One way to move forward (if we wanted to use RSVP as
probes) is to explicitly restrict the deployment scenarios when this is
not an issue and make explicit assumptions on how ecmp algorithms work
in those deployment scenarios.  

On second thought making such assumptions may not be too bad, because
when they are violated, it seems that the system will then behave no
worse than if probing is not used at all.  
Thoughts?

Anna 

> -----Original Message-----
> From: Bruce Davie (bdavie) 
> Sent: Tuesday, October 23, 2007 1:51 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: [PCN] RSVP and ECMP
> 
> Michael,
>   RSVP tries to forward the Path exactly the same way that it 
> would forward the data. Since Path messages are processed 
> outside of the fast path, it is possible for the router to 
> look at anything that is in the path message, including 
> source addr, dest addr, and port numbers, and figure out 
> where a data packet that had those values in its IP header 
> would get forwarded. It sends the Path message out that 
> interface. In practice, this takes care of the vast majority 
> of ECMP algorithms. This approach is implemented today.
> 
>   If ECMP was using something from the IP or higher layer 
> header that was not in the Path message, then a problem would arise.
> 
>   So, practically speaking, if the probe messages have the 
> same addresses and ports as the data, they should get correct 
> ECMP treatment. Or at least, fare no worse than RSVP.
> 
> Bruce
> 
> On Oct 23, 2007, at 12:07 PM, Michael Menth wrote:
> 
> > Hi,
> >
> > I've got a question regarding RSVP. PATH messages need to 
> be carried 
> > over the same path as subsequent data packets. How is this 
> achieved in 
> > the presence of ECMP routing? In theory, PATH messages can take a 
> > different route than data packets if the load balancer 
> takes arbitrary 
> > parts of the header(s) to calculate a suitable hash value, which 
> > decides which route the packet will take.
> >
> > This issue seems to be related to the problem of how to 
> make sure that 
> > PCN probe messages take the same path as subsequent PCN 
> data packets, 
> > provided that they have the same source and destination ports and 
> > addresses.
> >
> > I am interested in how this problem is solved in practice 
> or whether 
> > it is intentionally avoided.
> >
> > Regards,
> >
> >    Michael
> >
> > --
> > Dr. Michael Menth, Assistant Professor University of Wuerzburg, 
> > Institute of Computer Science Am Hubland, D-97074 
> Wuerzburg, Germany, 
> > room B206
> > phone: [phone], fax: [phone] 
> > mailto:[e-mail]
> > http://www3.informatik.uni-wuerzburg.de/research/ngn
> >
> >
> >
> > _______________________________________________
> > PCN mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/pcn
> 
> 
> _______________________________________________
> PCN mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/pcn
> 


_______________________________________________
PCN mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/pcn


_______________________________________________
PCN mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/pcn