Subject: [netext] comments to draft-krishnan-netext-pmip-lr-00

From: Marco Liebsch <[email-masked]>
Date: Fri, 05 Mar 2010 16:40:35 +0100

Please find some comments to draft-krishnan-netext-pmip-lr-00 attached.
We edited our comments into the draft up to section 5.

marco

Netext WG                                                    S. Krishnan
Internet-Draft                                                  Ericsson
Intended status: Informational                                 R. Koodli
Expires: September 2, 2010                                 Cisco Systems
                                                             P. Loureiro
                                                                     NEC
                                                                D. Oulai
                                                               Videotron
                                                                   Q. Wu
                                                                  Huawei
                                                           March 1, 2010

                  Local Routing for Proxy Mobile IPv6
                    draft-krishnan-netext-pmip-lr-00

Abstract

   Proxy Mobile IPv6 (PMIPv6) is a network based mobility management
   protocol that enables IP mobility for a host without requiring its
   participation in any mobility-related signaling.  PMIPv6 requires all
   communications to go through the local mobility anchor.  As this can
   be suboptimal, local routing allows mobile nodes attached to the same
   or different mobile access gateways to exchange traffic by using
   localized forwarding or a direct tunnel between the gateways.  This
   document proposes an initiation mechanism for local routing.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Krishnan, et al.        Expires September 2, 2010               [Page 1]

Internet-Draft            PMIPv6 Local Routing                March 2010

   This Internet-Draft will expire on September 2, 2010.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.

Krishnan, et al.        Expires September 2, 2010               [Page 2]

Internet-Draft            PMIPv6 Local Routing                March 2010

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Conventions used in this document  . . . . . . . . . . . .  3
   2.  Scenario A11: Two MNs attached to the same MAG and LMA . . . .  4
   3.  Scenario A21: Two MNs attached to different MAGs but same
       LMA  . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   4.  Scenario A12: Two MNs attached to the same MAG with
       different LMAs . . . . . . . . . . . . . . . . . . . . . . . .  8
   5.  Message Formats  . . . . . . . . . . . . . . . . . . . . . . . 10
     5.1.  Local Routing Initiation (LRI) . . . . . . . . . . . . . . 10
     5.2.  Local Routing Acknowledgment (LRA) . . . . . . . . . . . . 11
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   8.  Normative References . . . . . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16

Krishnan, et al.        Expires September 2, 2010               [Page 3]

Internet-Draft            PMIPv6 Local Routing                March 2010

1.  Introduction

   Proxy Mobile IPv6 [RFC5213] describes the protocol operations to
   maintain reachability and session persistence for a Mobile Node (MN)
   without the explicit participation from the MN in signaling
   operations at the Internet Protocol (IP) layer.  In order to
   facilitate such network-based mobility, the PMIPv6 protocol defines a
   Mobile Access Gateway (MAG), which acts as a proxy for the Mobile
   IPv6 [RFC3775] signaling, and the Local Mobility Anchor (LMA) which
   acts similar to a Home Agent.  The LMA and the MAG estalish a
   bidirectional tunnel for forwarding all data traffic belonging to the
   Mobile Nodes.  In the case where both endpoints are located in the
   same PMIPv6 domain, this can be suboptimal and results in higher
   delay and congestion in the network.  Moreover, it increases
   transport costs and traffic load at the LMA.

   To overcome these issues, local routing can be used to allow nodes
   attached to the same or different MAGs to directly exchange traffic
   by using localized forwarding or a direct tunnel between the
   gateways.  [LR-PS] defines the problem statement for PMIPv6 local
   routing.  This document describes a solution for PMIPv6 localized
   routing.  The protocol specified here assumes that both the LMA and
   the MAG have established bindings for the communicating Mobile Nodes
   using the PBU and PBA messages specified in [RFC5213].

[marco] This is true for MN1, its MAG (MAG1) and LMA (LMA1), as well as
for MN2, its MAG (MAG2) and LMA (LMA2). It cannot be assumed that
MN1's MAG can perform a binding with LMA2.
We propose to make the text more unambiguous:
  "...The protocol specified here assumes that each MN is attached
to a MAG and that each MN's MAG has established a binding for the
attached MN at its selected LMA according to [RFC5213]."

1.1.  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

Krishnan, et al.        Expires September 2, 2010               [Page 4]

Internet-Draft            PMIPv6 Local Routing                March 2010

2.  Scenario A11: Two MNs attached to the same MAG and LMA

   In this scenario, the two Mobile Nodes involved in communication are
   attached to a single MAG and both are anchored at the same LMA.

                        Internet
                           :
                           |
                           |
                        +-----+
                        | LMA |
                        +-----+
                           |
                           |
                           |
                        +-----+
                        | MAG |
                        +-----+
                         :   :
                      +---+ +---+
                      |MN1| |MN2|
                      +---+ +---+

   The LMA initiates a local routing session by detecting a flow between
   two MNs attached to the same MAG.  The exact flow identification
   mechanism is not specified in this document, and is left open for
   implementations and specific deployments.  An example trigger could
   be that an application-layer signaling entity (such as a SIP Proxy)
   notifies the LMA about two VoIP flow end-points, and the latter
   determines that the two end-points are attached to the same MAG.
   Such a trigger mechanism offers local routing at the granularity of
   an individual application session, providing flexibility in usage.
   This and other possible examples serve to illustrate the trigger
   mechanism for initiating local routing.

[marco] Since this is the only scenario considered in RFC5213, how does
this operation match section 6.10.3 of RFC5213 and the associated
use of the EnableMAGLocalRouting? And what happens if LMA enforces
localized routing with an LRI command, but the MAG has the 
EnableMAGLocalRouting flag set to 0? Probably it sends back
an LRA with status code "not allowed"...

[marco] general about terms: For the PS at least there were comments
to consistently refer to an MN and a CN as communication peers.
This draft refers to two MNs (MN1 and MN2). Using MN/CN would also
ease identification of a traffic initiator (MN) and the callee (CN).

Krishnan, et al.        Expires September 2, 2010               [Page 5]

Internet-Draft            PMIPv6 Local Routing                March 2010

   +----+      +----+      +----+          +----+
   |MN1 |      |MN2 |      |MAG |          |LMA |
   +----+      +----+      +----+          +----+
     |           |           |               |
     |        data           |     data      |
     |<--------------------->|<------------->|
     |           |           |               |
     |           |    data   |     data      |
     |           |<--------->|<------------->|
     |           |           |          LR decision
     |           |           |  LRI(Opts)    |
     |           |           |<--------------|
     |           |           |               |
     |           |           |  LRA(Opts)    |
     |           |           |-------------->|
     |           |           |               |
     |        data           |               |
     |<--------------------->|               |
     |           |           |               |
     |           |   data    |               |
     |           |<--------->|               |
     |           |           |               |
     |           |           |               |

   After detecting a possibility for local routing, the LMA constructs a
   Local Routing Initiation (LRI) message that is used to signal the
   intent to initiate local routing and to convey parameters for the
   same.  This is a Mobility Header message and it contains the MN-
   Identifier and the Home Network Prefix (as Mobility Header options)
   for each of the MNs involved.  The LMA sends the LRI message to the
   MAG where the two MNs are attached.

   The MAG starts by verifying that the two MNs are indeed attached to
   it.  It then creates Local Routing Entries(LREs) for each direction
   of the communication between the two MNs.  The exact form of the
   forwarding entries is left for the implementations to decide;
   however, they should contain the HNP corresponding to the destination
   IP address and a next-hop identifier (e.g. the layer 2 address of the
   next- hop).  These LREs MUST override the BUL entries for the
   specific HNPs identified in the LRI message.  Hence all traffic
   matching the HNPs is forwarded locally.

   If a MAG is unable to make deliver packets using the LREs, it is
   possible that the MN is no longer attached to the MAG.  Hence, the
   MAG SHOULD fall back to using the BUL entry, and the LMA MUST forward
   the received packets using its BCE.  The MAG MAY use other

Krishnan, et al.        Expires September 2, 2010               [Page 6]

Internet-Draft            PMIPv6 Local Routing                March 2010

   mechanisms, such as Proxy MIP6 Fast Handovers [PFMIP6] to forward
   packets when a handover has taken place.

[marco] Why talking about handover optmization here? This protocol
is about path setup and maintenance for traffic between two
MNs, not between previuos and new location of a particular MN.
Would omit the last sentence.

[marco] Rather, an important aspect of handover is missing in this
draft entirely, which is the maintenance of localized routing
states at new MAGs in case of one or both MNs hand over.

   The local forwarding is not permanent.  For instance, the LMA may
   send a LRI message with a request to cancel an existing local
   forwarding service.  The local forwarding also has a default
   lifetime, upon the expiry of which, the forwarding reverts to
   bidirectional tunneling.  When local forwarding service ceases, the
   corresponding LFE entries MUST be removed.

   The MAG completes the processing of the LRI message and responds with
   a Local Routing Acknowledgment (LRA) message.  This Mobility Header
   message also includes the MN-ID and the HNP for each of the
   communicating MNs as well as an appropriate Status code indicating
   the outcome of LRI processing.  Status code 0 indicates local routing
   was successfully offered by the MAG.  Any other value for Status code
   indicates the reason for the failure to offer local routing service.
   When Status code is 0, the LMA sets a flag in the BCE corresponding
   to the HNPs to record that local routing is in progress for that HNP.

   The MAG may refresh the lifetime of an existing local forwarding
   service.  For this, it sends an unsolicited LRA (U-LRA) message that
   contains the new lifetime value.  The MAG MUST wait for the following
   LRI message from the LMA before it can conclude that the refresh
   request is granted.

Krishnan, et al.        Expires September 2, 2010               [Page 7]

Internet-Draft            PMIPv6 Local Routing                March 2010

3.  Scenario A21: Two MNs attached to different MAGs but same LMA

   The LMA may choose to support local forwarding to mobile nodes
   attached to two different MAGs within a single PMIPv6 domain.

                        Internet
                           :
                           |
                           |
                        +-----+
                        | LMA |
                        +-----+
                           |
                           |
                      +----+-----+
                      |          |
                   +----+     +----+
                   |MAG1|     |MAG2|
                   +----+     +----+
                     :           :
                   +---+       +---+
                   |MN1|       |MN2|
                   +---+       +---+

   As earlier, the LMA initiates LRI as a response to some trigger
   mechanism.  In this case, however, it sends two separate LRI messages
   to the two MAGs.  In addition to the MN-ID and the HNP options, each
   LRI message contains the IP Address of the counterpart MAG.  When the
   MAG IP Address option is present, each MAG MUST create a local
   forwarding entry such that the packets for the MN attached to the
   remote MAG are sent over a tunnel associated with that remote MAG.
   The tunnel between the MAGs is assumed to be established by means
   outside the scope of this document.

   As before, each MAG responds to the LRI with an LRA message.  Barring
   the error cases, all subsequent packets are routed between the MAGs
   locally, without traversing the LMA.

   The protocol does not require any synchronization between the MAGs
   before local forwarding begins.  Each MAG begins its local forwarding
   independent of the other.

[marco] Having parallel signaling only from LMA to MAGs makes sense
in case there is reason to avoid inter-LMA signaling. As NetExt scope
considers solely a localized routing tunnel between two MAGs of the
same provider domain, there is no issue with signaling between these
two. This would allow a clear protocol sequence: LMA initaites and
notifies one dediacted MAG, which signals then to the other MAG.
An issue with no synchronization is that e.g MAG1 tunnels packets to
MAG2 which does not have an LR state yet. In case the MAG does not
have a rule to terminate ANY downlink tunnel and forward encapsulated
traffic, these packets will be dropped at the MAG2.

Krishnan, et al.        Expires September 2, 2010               [Page 8]

Internet-Draft            PMIPv6 Local Routing                March 2010

4.  Scenario A12: Two MNs attached to the same MAG with different LMAs

   In this scenario, both the MNs are attached to the same MAG, but are
   anchored at two different LMAs.

                        Internet
                  :                  :
                  +------------------+
                  |                  |
               +----+              +----+
               |LMA1|              |LMA2|
               +----+              +----+
                  |                  |
                  |                  |
                  +------------------+
                           |
                           |
                           |
                        +-----+
                        | MAG |
                        +-----+
                         :   :
                      +---+ +---+
                      |MN1| |MN2|
                      +---+ +---+

   Hence, neither LMA has a means to determine that the two Mobile Nodes
   are attached to the same MAG.  Only the MAG can possibly determine
   that the two Mobile Nodes involved in communication are attached to
   it.  Hence the local routing has to be initiated by the MAG.

[marco] Why now at the MAG? How should the MAG know that now it is
responsible to check Src/Dest and associated bindings to initiate
Localized Routing? We think it's good to consider detection on the LMA
and on the MAG in the protocol, but this should be either-or, hence
administratively set. In LMA detected and intiated case, you could
say that always the traffic initiator's LMA (LMA1 in case of MN1)
is responsible to do that.

   The MAG sends an LRI message containing the MN-ID, HNP and the
   counterpart LMA address to each LMA.  Each LMA makes decision to
   support local forwarding independently, based on, among others,
   policy configuration for the counterpart LMA.  Each LMA MUST respond
   to the LRI message with an LRA message.  Only after it receives both
   the LRA messages each with Status value set to zero (success) from
   the two different LMAs, the MAG MUST conclude that it can provide
   local forwarding support for the two Mobile Nodes.

[marco] The LRI is bi-directional from LMA->MAG and from MAG->LMA???
Don't think this is a good choice.
In handover cases the signaling and state machines look like being
screwed up. Who updates? The MAG or the LMA? May be better to
have a dedicated entity (i.e. the LMA) to take care of sending the
LRI.

Krishnan, et al.        Expires September 2, 2010               [Page 9]

Internet-Draft            PMIPv6 Local Routing                March 2010

   +----+      +----+      +----+      +----+        +----+
   |MN1 |      |MN2 |      |MAG |      |LMA1|        |LMA2|
   +----+      +----+      +----+      +----+        +----+
     |           |           |           |             |
     |        data           |   data    |    data     |
     |<--------------------->|<--------->|<----------->|
     |           |           |           |             |
     |           |   data    |          data           |
     |           |<--------->|<----------------------->|
     |           |           |           |             |
     |           |           |           |             |
     |           |           | LRI(Opts) |             |
     |           |           |---------->|             |
     |           |           |           |             |
     |           |           |        LRI(Opts)        |
     |           |           |------------------------>|
     |           |           |           |             |
     |           |           | LRA(Opts) |             |
     |           |           |<----------|             |
     |           |           |           |             |
     |           |           |        LRA(Opts)        |
     |           |           |<------------------------|
     |           |           |           |             |
     |           |           |           |             |
     |           |           |           |             |
     |        data           |    data   |             |
     |<--------------------->|<--------->|             |
     |           |           |           |             |
     |           |    data   |           |             |
     |           |<--------->|           |             |
     |           |           |           |             |
     |           |           |           |             |

[marco] The operation for scenario A22 is missing. 

5.  Message Formats

...