[multimob] PMIP Unicast Routing
"Thomas C. Schmidt" <schmidt@informatik.haw-hamburg.de> Thu, 09 January 2014 19:39 UTC
Return-Path: <prvs=07912bb8b=schmidt@informatik.haw-hamburg.de>
X-Original-To: multimob@ietfa.amsl.com
Delivered-To: multimob@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1FB1AE52F for <multimob@ietfa.amsl.com>; Thu, 9 Jan 2014 11:39:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Level:
X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.538] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n40PT_55oLMx for <multimob@ietfa.amsl.com>; Thu, 9 Jan 2014 11:39:53 -0800 (PST)
Received: from mx3.haw-public.haw-hamburg.de (mx3.haw-public.haw-hamburg.de [141.22.6.2]) by ietfa.amsl.com (Postfix) with ESMTP id 8739C1AE3A0 for <multimob@ietf.org>; Thu, 9 Jan 2014 11:39:52 -0800 (PST)
Received: from mailgate.informatik.haw-hamburg.de ([141.22.30.74]) by mail3.is.haw-hamburg.de with ESMTP/TLS/ADH-AES256-SHA; 09 Jan 2014 20:39:41 +0100
Received: from localhost (localhost [127.0.0.1]) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTP id BAD7910679D7; Thu, 9 Jan 2014 20:39:41 +0100 (CET)
Received: from mailgate.informatik.haw-hamburg.de ([127.0.0.1]) by localhost (mailgate.informatik.haw-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 06756-01; Thu, 9 Jan 2014 20:39:41 +0100 (CET)
Received: from [10.171.40.58] (tmo-096-203.customers.d1-online.com [80.187.96.203]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgate.informatik.haw-hamburg.de (Postfix) with ESMTPSA id 8BC5710679CF; Thu, 9 Jan 2014 20:39:39 +0100 (CET)
Message-ID: <52CEFAD6.40300@informatik.haw-hamburg.de>
Date: Thu, 09 Jan 2014 20:39:02 +0100
From: "Thomas C. Schmidt" <schmidt@informatik.haw-hamburg.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Behcet Sarikaya <sarikaya@ieee.org>
Content-Type: text/plain; charset="ISO-8859-15"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: by amavisd-new at informatik.haw-hamburg.de
Cc: "multimob@ietf.org" <multimob@ietf.org>
Subject: [multimob] PMIP Unicast Routing
X-BeenThere: multimob@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multicast Mobility <multimob.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multimob>, <mailto:multimob-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/multimob/>
List-Post: <mailto:multimob@ietf.org>
List-Help: <mailto:multimob-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multimob>, <mailto:multimob-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jan 2014 19:39:56 -0000
Hi Behcet, On 09.01.2014 19:20, Behcet Sarikaya wrote: > My question was not related to this document specifically. As far as I'm aware of, this subject is not related to any WG item of Multimob ... that's why I put it in a new thread. > So my conclusion from your reply is that there is no written document on > so-called policy routing in PMIP. Certainly RFC 5213 does not mention it. > PMIP describes unicast routing, only, not multicast. Forwarding from the MN is described in Section 6.10.5. There it says: " o On receiving a packet from a mobile node connected to its access link, the mobile access gateway MUST ensure that there is an established binding for that mobile node with its local mobility anchor before forwarding the packet directly to the destination or before tunneling the packet to the mobile node's local mobility anchor. ... o On receiving a packet from a mobile node connected to its access link, to a destination that is not directly connected, the packet MUST be forwarded to the local mobility anchor through the bi- directional tunnel established between itself and the mobile node's local mobility anchor. " Aside from a typo (not "to" but "by the local mobility anchor"), this describes a routing procedure, which is not regular IP routing (according to the destination address), but according to a 'policy' (the "established binding for that mobile node with its local mobility anchor"). Often, such forwarding decisions are referred to as 'policy-based' routing - RFC 5213 does not name this procedure, but describes it only verbally. When I used the term 'policy-based routing', I was referring to this quoted paragraphs on PMIP forwarding from the MN. The term is not important. What matters is that the forwarding decision is based on the source, not on the destination address. However, if you are interested in the nitty gritty details of PMIP, you should probably discuss with the real PMIP experts. I've neither designed, nor implemented PMIP. Best regards, Thomas -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidt Fax: +49-40-42875-8409 °
- [multimob] PMIP Unicast Routing Thomas C. Schmidt