Subject: [PCN] RSVP and ECMP

From: Michael Menth <[email-masked]>
Date: Tue, 23 Oct 2007 18:07:56 +0200

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: (+49)-931/888-6644, fax: (+49)-931/888-6632
mailto:[email-masked]
http://www3.informatik.uni-wuerzburg.de/research/ngn

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

---

From: Martin Karsten <[email-masked]>
Date: Tue, 23 Oct 2007 12:45:08 -0400

I'm not sure what's done in reality (if at all), but RSVP PATH messages
have the 'router alert' flag set, so in theory they are processed
differently from a regular IP packet anyway.

Greetings,
Martin

---

From: Michael Menth <[email-masked]>
Date: Tue, 23 Oct 2007 18:44:18 +0200

Hi Martin,

yes you are right, but this is a different issue. The question is: how 
is it achieved that RSVP PATH messages are routed on the same path as 
subsequent data packets in the presence of ECMP?

Regards,

    Michael

---

From: Bruce Davie <[email-masked]>
Date: Tue, 23 Oct 2007 13:50:42 -0400

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

---

From: "Anna Charny (acharny)" <[email-masked]>
Date: Wed, 24 Oct 2007 10:19:08 -0400

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: [email-masked]
> Cc: [email-masked]
> 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
> 
> > parts of the header(s) to calculate a suitable hash value, which 
> > decides which route the packet will take.
> >
> > 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

---

From: "Jozef Babiarz" <[email-masked]>
Date: Wed, 24 Oct 2007 11:32:40 -0400

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

Regards, Joe
email:[email-masked]
Telephone:613-763-6098

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

Hi all,

Anna

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 25 Oct 2007 09:20:12 +0000

Hi Bruce, Hi all

I agree with Bruce! If it is to use probing, then we have to ensure
that the probes should get the similar correct ECMP treatment as the
correct ECMP treatment achieved by RSVP.

This means that the probe messages have to have the same addresses and
ports as the data.
I think tat this is not difficult and not complex to be achieved.

Best regards,
Georgios

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 25 Oct 2007 12:13:42 +0200

The problems obviously show up if the load balancing device does not 
inspect the RSVP traffic.
Then, you cannot ensure that the signaling traffic follows the data 
traffic anymore.

Also with tunnels you need to ensure that at least one of the tunnel 
endpoints is aware of the signaling protocol. This might seem to be a 
simple requirement but I assume in reality it is not that easy. This is 
the area where complexity says HELLO to path-coupled signaling.

Ciao
Hannes

PS: When you still think that it is totally trivial then you might want 
to look at the many tunneling schemes folks use or want to use.

---

From: "Anna Charny (acharny)" <[email-masked]>
Date: Thu, 25 Oct 2007 09:53:00 -0400

Hi Hannes,

> 
> The problems obviously show up if the load balancing device 
> does not inspect the RSVP traffic.
> Then, you cannot ensure that the signaling traffic follows 
> the data traffic anymore.
> 

Sorry, I did not quite understand your point.  Wouldn't a packet
carrying RSVP message be processes just like any other packet in the
node which is not RSVP-capable?  So all that matters for the discussion
on using RSVP message as a probe is whether that packet goes the same
way as the corresponding data packets of the same flow under ecpm
decisions?  Am I missing the point you are making?

Anna

> From: Hannes Tschofenig [mailto:[email-masked]] 
> Sent: Thursday, October 25, 2007 6:14 AM
> To: Georgios Karagiannis
> Cc: [email-masked]
> The problems obviously show up if the load balancing device 
> does not inspect the RSVP traffic.
> Then, you cannot ensure that the signaling traffic follows 
> the data traffic anymore.
> 
> Also with tunnels you need to ensure that at least one of the 
> tunnel endpoints is aware of the signaling protocol. This 
> might seem to be a simple requirement but I assume in reality 
> it is not that easy. This is the area where complexity says 
> HELLO to path-coupled signaling.
> 
> Ciao
> Hannes
> 
> PS: When you still think that it is totally trivial then you 
> might want to look at the many tunneling schemes folks use or 
> want to use.
> 
> header that 
> >>> 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.
> >>>
> >>> Institute of Computer Science Am Hubland, D-97074 Wuerzburg, 
> >>> Germany, room B206

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 25 Oct 2007 16:00:15 +0200

Hi Anna,

Anna Charny (acharny) wrote:
> node which is not RSVP-capable? 

Theoretically yes. It just depends on the behavior of the box. The RSVP 
packet is, however, not a data packet.
It looks different.

>  So all that matters for the discussion
> decisions? 
Correct, and the question is: Is it possible that data traffic travels 
along a different path than the signaling traffic.
The answer is "yes" (unless you have control over the box making the 
decisions).

>  Am I missing the point you are making?
>
>   

Ciao
Hannes

>>> that the probes should get the similar correct ECMP 
>>>       
>> treatment as the 
>>     
>>> This means that the probe messages have to have the same 
>>>       
>> addresses and 
>>     
>>> ports as the data.
>>>> fast path, it is possible for the router to look at 
>>>>         
>> anything that is 
>>     
>>>> 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 
>>     
>>>>> I've got a question regarding RSVP. PATH messages need to 
>>>>>           
>> be carried 
>>