Subject: Re: [PCN] RSVP and ECMP

From: Tina TSOU <[email-masked]>
Date: Mon, 05 Nov 2007 14:09:14 +0800

Hi Hannes and all,
In my mind, in PCN domain RSVP PATH messages do not need to be carried over the same path as subsequent data packets. It does not impact on the PCN mechanism working.

B. R.
Tina
  ----- Original Message ----- 
  From: Hannes Tschofenig 
  To: Anna Charny (acharny) 
  Cc: [email-masked] 
  Sent: Thursday, October 25, 2007 10:00 PM
  Subject: Re: [PCN] RSVP and ECMP

  Hi Anna,

  Anna Charny (acharny) wrote:
  > 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? 

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

  > Anna
  >
  >   
  >> -----Original Message-----
  >> From: Hannes Tschofenig [mailto:[email-masked]] 
  >> Sent: Thursday, October 25, 2007 6:14 AM
  >> To: Georgios Karagiannis
  >> Cc: [email-masked]
  >> Subject: Re: [PCN] RSVP and ECMP
  >>
  >> 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.
  >>
  >> Georgios Karagiannis wrote:
  >>     
  >>> 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
  >>>
  >>>
  >>>
  >>> On 10/23/2007, "Bruce Davie" <[email-masked]> wrote:
  >>>
  >>>   
  >>>       
  >>>> 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: (+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
  >>>>>       
  >>>>>           
  >>>> _______________________________________________
  >>>> PCN mailing list
  >>>> [email-masked]
  >>>> https://www1.ietf.org/mailman/listinfo/pcn
  >>>>     
  >>>>         
  >>> _______________________________________________
  >>> PCN mailing list
  >>> [email-masked]
  >>> https://www1.ietf.org/mailman/listinfo/pcn
  >>>   
  >>>       
  >>
  >> _______________________________________________
  >> PCN mailing list
  >> [email-masked]
  >> https://www1.ietf.org/mailman/listinfo/pcn
  >>
  >>     

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