Re: [PCN] RSVP and ECMP

"Georgios Karagiannis" <karagian@cs.utwente.nl> Thu, 25 October 2007 09:20 UTC

Return-path: <pcn-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikysz-00071W-La; Thu, 25 Oct 2007 05:20:17 -0400
Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Ikysy-00071N-8Q for pcn-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 05:20:16 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ikysx-00071A-Rl for pcn@ietf.org; Thu, 25 Oct 2007 05:20:15 -0400
Received: from rotterdam.ewi.utwente.nl ([130.89.10.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ikysx-0000bL-88 for pcn@ietf.org; Thu, 25 Oct 2007 05:20:15 -0400
Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id l9P9KCuN006991; Thu, 25 Oct 2007 11:20:12 +0200 (MEST)
Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Thu, 25 Oct 2007 09:20:12 +0000
To: Bruce Davie <bdavie@cisco.com>, "menth@informatik.uni-wuerzburg.de" <menth@informatik.uni-wuerzburg.de>
Subject: Re: [PCN] RSVP and ECMP
Date: Thu, 25 Oct 2007 09:20:12 +0000
X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl)
Message-ID: <7i9binUY.1193304012.0627110.karagian@ewi.utwente.nl>
In-Reply-To: <6C20D78B-36AE-4D88-8F7A-20F4D4A512A4@cisco.com>
From: Georgios Karagiannis <karagian@cs.utwente.nl>
Bounce-To: "Georgios Karagiannis" <karagian@cs.utwente.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0 ()
X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Thu, 25 Oct 2007 11:20:13 +0200 (MEST)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248
Cc: "pcn@ietf.org" <pcn@ietf.org>
X-BeenThere: pcn@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: PCN WG list <pcn.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pcn>, <mailto:pcn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/pcn>
List-Post: <mailto:pcn@ietf.org>
List-Help: <mailto:pcn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pcn>, <mailto:pcn-request@ietf.org?subject=subscribe>
Errors-To: pcn-bounces@ietf.org

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" <bdavie@cisco.com> 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:menth@informatik.uni-wuerzburg.de
>> http://www3.informatik.uni-wuerzburg.de/research/ngn
>>
>>
>>
>> _______________________________________________
>> PCN mailing list
>> PCN@ietf.org
>> https://www1.ietf.org/mailman/listinfo/pcn
>
>
>_______________________________________________
>PCN mailing list
>PCN@ietf.org
>https://www1.ietf.org/mailman/listinfo/pcn


_______________________________________________
PCN mailing list
PCN@ietf.org
https://www1.ietf.org/mailman/listinfo/pcn