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