Subject: [netext] review of draft-ietf-netext-pmipv6-flowmob-03

From: Marco Liebsch <[email-masked]>
Date: Fri, 6 Jul 2012 15:49:41 +0000

Please find below some comments to the current version of
draft-ietf-netext-pmipv6-flowmob-03.

General comments:
>From a specification to extend RFC5213 to support flow mobility I see the following
components as key items to specify and describe associated operation:

(1) Prefix handling at LMA and MAG
(2) Handling and enforcement of flow policies at the LMA

IMO, the current draft focuses too much on thing which are not to be placed in
this specification, e.g. how the MN can accomplish multiple address handling.

My general recommendation is to thoroughly describe the delta to RFC5213
and which additional or extended functions are needed to accomplish base
flow mobility scenario and how these function operate with PMIPv6. My view
is that the specification also has lots of should and may. The draft should be clear
about what's really needed to enable flow mobility according to a well understood
problem statement. If there are options to enable additional features, they should
be clearly separated from the core specification. One example is the need
to propagate flow templates to MAGs. Only on the last pages (p.17) the reader
learns that maintaining flow level information on MAGs is not mandatory.
Is there text at all that explains why flow templates are needed on the MAG at all?

Please find specific comments below in a copy of the draft, labeled with [marco].

----------------

NETEXT Working Group                                  CJ. Bernardos, Ed.
Internet-Draft                                                      UC3M
Intended status: Standards Track                          March 12, 2012
Expires: September 13, 2012

         Proxy Mobile IPv6 Extensions to Support Flow Mobility
                  draft-ietf-netext-pmipv6-flowmob-03

Abstract

   Proxy Mobile IPv6 allows a mobile node to connect to the same Proxy
   Mobile IPv6 domain through different interfaces.  However, the
   ability of movement of selected flows from one access technology to
   another is missing in the basic Proxy Mobile IPv6 protocol.  This
   document describes extensions to the Proxy Mobile IPv6 protocol that
   are required to support network based flow mobility over multiple
   physical interfaces.

   This document assumes that the mobile node implements the logical
   interface model,

[marco] .. it should not. It's good that NetExt has an informational documentation
about how logical interfaces can support multi-homing and flow mobility, but this
specification should not assume it or even mandate its use. The spec should
solely assume that the MN is able to handle multiple addresses@ multiple interfaces
as well as to enforce uplink policies to select the right interface. 
The Abstract should focus on which features can be supported compared to
RFC5213 when the specified components are implemented.

   therefore allowing the support of traffic flows on
   different physical interfaces regardless of the assigned prefixes on
   these physical interfaces.

Requirements Language

   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 RFC 2119 [RFC2119].

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on September 13, 2012.

Copyright Notice

Bernardos              Expires September 13, 2012               [Page 1]

Internet-Draft            PMIPv6 flow mobility                March 2012

   Copyright (c) 2012 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 Simplified BSD License.

Table of Contents

/..snip

Bernardos              Expires September 13, 2012               [Page 2]

Internet-Draft            PMIPv6 flow mobility                March 2012

1.  Introduction

   Proxy Mobile IPv6 (PMIPv6), specified in [RFC5213], provides network
   based mobility management to hosts connecting to a PMIPv6 domain.
   PMIPv6 introduces two new functional entities, the Local Mobility
   Anchor (LMA) and the Mobile Access Gateway (MAG).  The MAG is the
   entity detecting Mobile Node's (MN) attachment and providing IP
   connectivity.  The LMA is the entity assigning one or more Home
   Network Prefixes (HNPs) to the MN and is the topological anchor for
   all traffic belonging to the MN.

   PMIPv6 allows an MN to connect to the same PMIPv6 domain through
   different interfaces.  The "logical interface" at the IP layer may
   enable packet transmission and reception over different physical
   media.  This technique can be used to achieve flow mobility, i.e.,
   the movement of selected flows from one access technology to another.

[marco] why does the document introduce the logical interface even before
what should be the core of the specification? I'd propose to just mention the assumption
of such support on the MN and refer to the availability of appropriate technology
on the MN. 

   It is assumed that an IP layer interface can simultaneously and/or
   sequentially attach to multiple MAGs (possibly over multiple media).
   This document specifies protocol extensions to Proxy Mobile IPv6
   between the LMA and MAGs to enable distributing specific traffic
   flows on different physical interfaces.  This document assumes that a
   "logical interface" at the mobile node is capable of supporting

[marco] ..again?

   traffic flows on different physical interfaces regardless of the
   assigned prefixes on those physical interfaces.

   In particular, this document specifies how to enable "flow mobility"
   in the PMIPv6 network (i.e.  LMAs and MAGs).  Flow mobility is
   enabled by assigning the required prefixes on the different accesses.

[marco] three lines about the actual scope of the draft. I don't want to
be nasty, but it really does not help the reader to understand or even
implement what's needed for PMIP if you focus on which technology to
use on the MN. 

2.  Terminology

   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 [RFC2119].

   The following terms used in this document are defined in the Proxy
   Mobile IPv6 [RFC5213]:

      Local Mobility Agent (LMA).

      Mobile Access Gateway (MAG).

      Proxy Mobile IPv6 Domain (PMIPv6-Domain).

      LMA Address (LMAA).

Bernardos              Expires September 13, 2012               [Page 3]

Internet-Draft            PMIPv6 flow mobility                March 2012

      Proxy Care-of Address (Proxy-CoA).

      Home Network Prefix (HNP).

   The following terms used in this document are defined in the Multiple
   Care-of Addresses Registration [RFC5648] and Flow Bindings in Mobile
   IPv6 and Network Mobility (NEMO) Basic Support [RFC6089]:

      Binding Identification Number (BID).

      Flow Identifier (FID).

      Traffic Selector (TS).

   The following terms are defined and used in this document:

   FMI (Flow Mobility Initiate).  Message sent by the LMA to the MAG
      conveying the information required to enable flow mobility in a
      PMIPv6-Domain.  This message is only needed when the prefixes
      initially assigned by the different MAGs to the mobile node are
      different.

   FMA (Flow Mobility Acknowledge).  Message sent by the MAG in reply to
      an FMI message.

[marco] I don't think protocol message definitions are needed in the terms section.

   FMC (Flow Mobility Cache).  Conceptual data structure maintained by
      the LMA and the MAG to support the flow mobility management
      operations described in this document.

3.  Overview of the PMIPv6 flow mobility extensions

3.1.  Use case scenarios

   Flow mobility assumes simultaneous access to more than one network,
   in contrast to a typical handover where connectivity to a physical
   medium is relinquished, and is re-established with another.  In order
   to support flow mobility in a PMIPv6 network, it is required to be
   able to to tie the different PMIPv6 mobility sessions (one per

[marco] typo: able to to --> able to

   interface) to a logical interface which is hiding one or more
   physical interfaces [I-D.ietf-netext-logical-interface-support].  In
   this specification, it is assumed that the LMA knows that the MN
   supports the logical interface and it can handle the same prefix(es)
   or different prefix(es) on both access networks.  How this is done is
   out of the scope of this specification.

[marco] this sounds like the spec mandates the logical interface.
In I-D.ietf-netext-logical-interface-support I see one approach
of solving the MN part being documented. Other possibilities beyond
I-D.ietf-netext-logical-interface-support using also virtual interfaces
exist. I'd propose to just place assumptions about functional support
as written above. If really needed, an Appendix section can be added
where a reader gets informed about an exemplary configuration
on MNs , e.g. using a logical interface.

   There are different flow mobility scenarios.  In some of them the
   mobile node might share a common set of prefixes among all its

Bernardos              Expires September 13, 2012               [Page 4]

Internet-Draft            PMIPv6 flow mobility                March 2012

   physical interfaces, whereas in others the mobile node might have a
   different subset of prefixes configured on each of the phyisical
   interfaces.  The different possibilities are the following:

[marco] 'possibilities' = 'scenarios', correct?

   1.  At the time of a new network attachment, the MN obtains the same
       prefix or the same set of prefixes as already assigned to an
       existing session.  This is not the default behavior with basic
       PMIPv6 [RFC5213], and the LMA needs to be able to provide the
       same assignment even for the simultaneous attachment (as opposed
       to the handover scenario only).

   2.  At the time of a new network attachment, the MN obtains a new
       prefix or a new set of prefixes for the new session.  This is the
       default behavior with basic PMIPv6 [RFC5213].

   3.  At the time of a new network attachment, the MN obtains a
       combination of prefix(es) in use and new prefix(es).  This is a
       hybrid of the two above-mentioned scenarios.  The local policy
       determines whether the new prefix is exclusive to the new
       attachment or it can be assigned to an existing attachment as
       well.

   Among these, scenario 1 needs extensions to basic PMIPv6 [RFC5213]
   signaling at the time of a new attachment, to ensure that the same
   prefix (or set of prefixes) is assigned to all the interfaces of the
   same mobile node that are simultaneously attached.  Subsequently, no
   further signaling is necessary.

[marco] maybe clearer: '..No further signaling is necessary between the LMA
and the MAG and flows are forwarded according to policy rules on the LMA and the MN'

   Scenario 2 requires flow mobility signaling to enable relocating
   flows between the different attachments, so the MAGs are aware of the
   prefixes for which the MN is going to receive traffic, and local
   routing entries are configured accordingly.

[marco] scenario 2 per se does not need any extension. As you write above,
it's covered by RFC5213. You only need extra signaling if scenario 2 turns into
scenario 3. Hence, you should probably mention this in the next paragraph.

   Scenario 3 requires flow mobility signaling to enable relocating
   flows for the new prefix(es) which are not shared across attachments.

   In all the scenarios, the MAGs should be aware of the prefixes for
   which is going to receive uplink (UL) or downlink (DL) traffic.
   These prefixes might not be limited to those delegated by the MAG
   upon attachment of the connected interface, and therefore in these
   cases, signaling is required.

   Once the network is configured with the right set of prefixes, the
   actual flow mobility can take place at any time thereafter (e.g., by
   redirecting DL or UL packets from one access to another).

   The extensions described in this document support any of these
   aforementioned scenarios.

Bernardos              Expires September 13, 2012               [Page 5]

Internet-Draft            PMIPv6 flow mobility                March 2012

3.2.  Basic Operation

   This section describes how the PMIPv6 extensions described in this
   document enable flow mobility support.

3.2.1.  MN sharing a common set of prefixes on all MAGs

   This scenario corresponds to the use case scenario number 1 described
   in Section 3.1.  When a multi-interfaced mobile node connects to a
   PMIPv6-domain, it performs regular attachment and as a result is able
   to configure an IP address (or a set of IP addresses) on the logical
   interface hiding the different physical interfaces.

[marco] again, the spec should not assume how flow mobility is implemented
in the MN. Hence, no assumption should be taken about the existence of a
logical interface in the core specification part of the document.

   If the LMA
   assigns a common prefix (or set of prefixes) to the different
   physical interfaces attached to the domain, then all the MAGs already
   have all the routing knowledge required to forward UL or DL packets,
   and the LMA does not need to perform any kind of signaling in order
   to move flows across the different physical interfaces.

   The LMA needs to know when to assigne the same set of prefixes to all

[marco]: assigne --> assign

   the different physical interfaces of the mobile node.  This can be
   achieved by different means, such as policy configuration or default
   policies, etc.  In this document a new Handoff Indicator (HI) value
   ("Attachment over a new interface sharing prefixes") is defined, to
   allow the mobile access gateway indicate to the local mobility anchor
   that the same set of prefixes should be assigned to the mobile node.
   The considerations of Section 5.4.1 of [RFC5213] are updated by this
   specification as follows:

   o  If there is at least one Home Network Prefix option present in the
      request with a NON_ZERO prefix value, there exists a Binding Cache
      entry (with one all home network prefixes in the Binding Cache
      entry matching the prefix values of all Home Network Prefix
      options of the received Proxy Binding Update message), and the
      entry matches the mobile node identifier in the Mobile Node
      Identifier option of the received Proxy Binding Update message,
      and the value of the Handoff Indicator of the received Proxy
      Binding Update is equal to "Attachment over a new interface
      sharing prefixes".

      1.  If there is a Mobile Node Link-layer Identifier Option present
          in the request and the Binding Cache entry matches the Access
          Technology Type (ATT), and MN-LL-Identifier, the request MUST
          be considered as a request for updating that Binding Cache
          entry.

[marco] does that conflict with the above mentioned presence of
the new HI value? Above it's said that the message comprises a HI which
indicates "Attachment over a new interface sharing prefixes", whereas
procedure 1.is about a handover (BCE update). Or is the new
HI value used also in case of handover, not only at initial attachment?

      2.  If there is a Mobile Node Link-layer Identifier Option present
          in the request and the Binding Cache entry does not match the
          Access Technology Type (ATT), and MN-LL-Identifier, the

Bernardos              Expires September 13, 2012               [Page 6]

Internet-Draft            PMIPv6 flow mobility                March 2012

          request MUST be considered as a request for creating a new
          mobility session sharing the same set of Home Network Prefixes
          assigned to the existing Binding Cache entry found.

      3.  If there is not a Mobile Node Link-layer Identifier Option
          present in the request, the request MUST be considered as a
          request for creating a new mobility session sharing the same
          set of Home Network Prefixes assigned to the existing Binding
          Cache entry found.

   As described in [I-D.ietf-netext-logical-interface-support], there

[marco] where is 'there' ? The assumption about MN support should have been
clarified earlier in this document. I do not see need for the complete paragraph.

   should be a local policy in place that ensures that packets are
   forwarded coherently.  This SHOULD be enforced by the logical
   interface engine [I-D.ietf-netext-logical-interface-support].  For
   unidirectional outbound communications, there SHOULD also be a policy
   at the mobile node defining which physical interface is used to send
   the traffic.  For bidirectional outbound communications, there SHOULD
   be also such a policy, but its content must be consistent with the
   policy at the network-side (the details about how this consistency is
   ensured are out of the scope of this document).

   In case the MAGs needs to be configured to support flow mobility,
   because of packet policing, packet enforcement, charging or similar
   reasons, the LMA SHOULD re-use the signaling defined later in this
   document to convey this information.

Bernardos              Expires September 13, 2012               [Page 7]

Internet-Draft            PMIPv6 flow mobility                March 2012

                                     LMA Binding Cache
                       +---+       =======================
                       |LMA|        MN1, if1, pref1, MAG1
                       +---+        MN1, if2, pref1, MAG2
                        //\\
             +---------//--\\-------------+
            (         //    \\             ) PMIPv6 domain
            (        //      \\            )
             +------//--------\\----------+
                   //          \\
                  //            \\
               +----+           +----+
               |MAG1|           |MAG2|
               +----+           +----+
                 |                |
                 |   +-------+    |
                 |   |  I P  |    |
                 |   +-------+    |
                 |   |  lif  |    |
                 |   +---+---+    |
                 |---|if1|if2|----|
                     +---+---+
                        MN1

        Figure 1: Shared prefix across physical interfaces scenario

[marco] I propose to just draw the IP box and the two IF boxes.
same for the description below. Much clearer for the reader, as focus
is on the infrastructure, not on understanding how the LIF works.

   Next, an example of how flow mobility works in this case is shown.
   In Figure 1, a mobile node (MN1) has two different physical
   interfaces (if1 and if2), grouped in a unique logical interface
   (lif).  Each physical interface is attached to a different MAG, both
   of them anchored and controlled by the same LMA.  Since both physical
   interfaces are assigned the same prefix (pref1) upon attachment to
   the MAGs, the mobile node has one single IPv6 addresses configured on
   the logical interface: pref1::lif.  Initially, flow X goes through
   MAG1 and flow Y through MAG2.  At certain point, flow Y can be moved
   to also go through MAG1.  As shown in Figure 2, no signaling between
   the LMA and the MAGs is needed.

Bernardos              Expires September 13, 2012               [Page 8]

Internet-Draft            PMIPv6 flow mobility                March 2012

                 +-----+           +------+        +------+      +-----+
   Internet      | LMA |           | MAG1 |        | MAG2 |      | MN1 |
                 +-----+           +------+        +------+      +-----+
      |             |                 |               |             |
      |  flow X to  |    flow X to    |           flow X to         |
      |  pref1::lif |    pref1::lif   |           pref1::lif        |
      |<----------->|<--------------->|<-------------------------->if1
      |  flow Y to  |             flow Y to           |  flow Y to  |
      |  pref1::lif |             pref1::lif          |  pref1::lif |
      |<----------->|<------------------------------->|<---------->if2
      |             |                 |               |             |
      |   =============================================================
      |  ||                 decision to move flow Y                   ||
      |   =============================================================
      |             |                 |               |             |
      |  flow Y to  |    flow Y to    |          flow Y to          |
      |  pref1::lif |    pref1::lif   |          pref1::lif         |
      |<----------->|<--------------->|<-------------------------->if1
      |             |                 |               |             |

   Figure 2: Flow mobility message sequence with common set of prefixes

[marco] The big decision box confuses, IMHO. I'd propose to
draw two small boxes, one on the LMA's and another on the MN's
line which say 'flow policy update'. That should be clear enough.

   Figure 3 shows the state of the different network entities after
   moving flow Y in the previous example.  This documents re-uses some
   of the terminology and mechanisms of the flow bindings and multiple
   care-of address registration specifications.  Note, that in this case
   the BIDs shown in the figure are assigned locally by the LMA, since
   there is no signaling required in this scenario.  In any case,
   alternative implementations of flow routing at the LMA could be used,
   as it does not impact on the operation of the solution in this case.

Bernardos              Expires September 13, 2012               [Page 9]

Internet-Draft            PMIPv6 flow mobility                March 2012

                           LMA Binding Cache        LMA flowmob state
                      (BID, MN-ID, ATT, HNP, PCoA)      (BID, TS)
                 +---+ ==========================  ===================
                 |LMA|  1, MN1, att1, pref1, MAG1       1, flow X
                 +---+  2, MN1, att2, pref1, MAG2       1, flow Y
                  //\\
       +---------//--\\-------------+
      (         //    \\             ) PMIPv6 domain
      (        //      \\            )
       +------//--------\\----------+
             //          \\
            //            \\       MAG1 routing state
         +----+           +----+  ================================
         |MAG1|           |MAG2|     (dest)         (next hop)
         +----+           +----+   pref1::/64   p2p-iface-with-MN1
           |                |         ::/0             LMA
           |   +-------+    |
           |   |  I P  |    |      MAG2 routing state
           |   +-------+    |     ================================
           |   |  lif  |    |        (dest)         (next hop)
           |   +---+---+    |      pref1::/64   p2p-iface-with-MN1
           |---|if1|if2|----|         ::/0             LMA
               +---+---+
                  MN1

           Figure 3: Data structures with common set of prefixes

[marco] Maybe it's good to be consistent and the LMA Binding Cache in the above figure
should also refer to entries IF1, IF1 as depicted in Fig. 1, instead of ATT. Or vice versa. 

3.2.2.  MN with different sets of prefixes on each MAG

   A different flow mobility scenario happens when the LMA assigns
   different sets of prefixes to physical interfaces of the same mobile
   node.  This covers the second and third use case scenarios described
   in Section 3.1.  In this case, specific signaling is required between
   the LMA and the MAG to support this scenario.  Two different
   possibilities are considered next.

   The first possibility corresponds to the use case scenario number 2
   described in Section 3.1, in which a multi-interfaced MN obtains a
   different set of prefixes on each attachment.  Signaling is required
   when a flow is to be moved from its original interface to a new one.
   Since the LMA cannot send a PBA message which has not been triggered
   in response to a received PBU message, new signaling messages are
   defined to cover this case.  The trigger for the flow movement can be
   on the mobile node (e.g., by using layer-2 signaling, by explicitly
   start sending flow packets via a new interface, etc.) or on the
   network (e.g., based on congestion and measurements performed at the
   network).

Bernardos              Expires September 13, 2012              [Page 10]

Internet-Draft            PMIPv6 flow mobility                March 2012

   If the flow is being moved from its default path (which is determined
   by the destination prefix) to a different one, the LMA constructs a
   Flow Mobility Initiate (FMI) message.  This message is sent to the
   new target MAG, i.e. the one selected to be the used in the
   forwarding of the flow.  The FMI message contains (as explained in
   further detail in Section 4.1), the MN-Identifier, the Flow
   Identification Mobility option (specified in [RFC6089]) which can
   convey prefix or full flow information, and the type of flow mobility
   operation (add flow).  Optionally, the LMA may send another FMI
   message, this time to remove the flow Y state at MAG2.  Otherwise the
   flow state at MAG2 will be removed upon timer expiration.  The
   message sequence is shown in Figure 4.

[marco] I don't get the point why the flow information is needed on the MAG.
is that mandatory for the key scenarios? I would propose not covering that
in the core specification part, maybe in the back of the specification if it's
really needed.

[marco] One technical proposal: The FMI/FMA imply pretty much overhead,
IMO. Why can't all prefixed be communicated to a MAG during a PBU/PBA
exchange? Having them in the BUL from the beginning allows
driving this like scenario 1by having all keys/identifiers at the MAG.
LMA and MN just enforce the flow policy.
Nothing else needed, or? Well, prefixes might be flagged at the MAG to indicate
whether or not the prefix is configured on the attached interface, just to know
which ones are to be communicated during ND. But important is the availability
of the HNPs, which serve as key to identify the UE, at the MAG. And these could
be established early. No intention to change your spec, but just a proposal
to make protocol operation for flow mobility more lightweight.

                 +-----+           +------+        +------+      +-----+
   Internet      | LMA |           | MAG1 |        | MAG2 |      | MN1 |
                 +-----+           +------+        +------+      +-----+
      |             |                 |               |             |
      |  flow X to  |    flow X to    |           flow X to         |
      |  pref1::lif |    pref1::lif   |           pref1::lif        |
      |<----------->|<--------------->|<-------------------------->if1
      |  flow Y to  |             flow Y to           |  flow Y to  |
      |  pref2::lif |             pref2::lif          |  pref2::lif |
      |<----------->|<------------------------------->|<---------->if2
      |             |                 |               |             |
      |   =============================================================
      |  ||                 decision to move flow Y                   ||
      |   =============================================================
      |             |                 |               |             |
      |             | FMI[MN1-ID,flow_info(Y),add]    |             |
      |             |---------------->|               |             |
      |             |            FMA  |               |             |
      |             |<----------------|               |             |
      |             |             (optional)          |             |
      |             | FMI[MN1-ID,flow_info(Y),lft=0]  |             |
      |             |-------------------------------->|             |
      |             |                 |         FMA   |             |
      |             |<--------------------------------|             |
      |  flow Y to  |    flow Y to    |          flow Y to          |
      |  pref2::lif |    pref2::lif   |          pref2::lif         |
      |<----------->|<--------------->|<-------------------------->if1
      |             |                 |               |             |

       Figure 4: Flow mobility message sequence when the LMA assigns
     different sets of prefixes per physical interface (FMI signaling)

   The state in the network after moving a flow, for the case the LMA
   assigns a different set of prefixes is shown in Figure 5.

Bernardos              Expires September 13, 2012              [Page 11]

Internet-Draft            PMIPv6 flow mobility                March 2012

                           LMA Binding Cache          LMA flowmob state
                      (BID, MN-ID, ATT, HNP, PCoA)       (BID, TS)
                 +---+ ============================  ===================
                 |LMA|  1, MN1, att1, pref1,              1, flow X
                 +---+                pref2, MAG1         1, flow Y
                  //\\  2, MN1, att2, pref2, MAG2
       +---------//--\\-------------+
      (         //    \\             ) PMIPv6 domain
      (        //      \\            )
       +------//--------\\----------+
             //          \\
            //            \\       MAG1 routing state
         +----+           +----+  ================================
         |MAG1|           |MAG2|     (dest)         (next hop)
         +----+           +----+   pref1::/64   p2p-iface-with-MN1
           |                |      pref2::/64   p2p-iface-with-MN1
           |   +-------+    |         ::/0             LMA
           |   |  I P  |    |
           |   +-------+    |      MAG2 routing state
           |   |  lif  |    |     ================================
           |   +---+---+    |        (dest)         (next hop)
           |---|if1|if2|----|      pref2::/64   p2p-iface-with-MN1
               +---+---+              ::/0             LMA
                  MN1

    Figure 5: Data structures when the LMA assigns a  different set of
                                 prefixes

   The second possibility corresponds to the use case scenario number 3
   described in Section 3.1, in which upon new physical interface
   attachment, the MN obtains a combination of prefix(es) in use and new
   prefix(es).  Here, the mobile node is already attached to the PMIPv6-
   Domain via MAG1.  At a certain moment, the mobile node attaches a new
   interface (if2) to MAG2.  MAG2 sends a PBU which is then used by the
   LMA to enable flow mobility.  In this case, we consider that flows
   are moved with a prefix granularity, meaning that flows are moved by
   moving prefixes among the different MAGs the mobile node is attached
   to.  In this example, flow Y is bound to pref2::/64 and therefore the
   flow can be moved by just binding pref2::/64 to MAG2.  This is done
   by including the prefix in the PBA message.  The scenario is shown in
   Figure 6.

   Optionally, a message can be sent to MAG1 to remove the transferred
   prefix(es).  This message can be a Binding Revocation Indication
   message [RFC5846] with the P bit set to indicate that this is
   revocation of PMIP prefix(es).  After processing BRI, the source MAG
   will send a Binding Revocation Acknowledgement (BRA) message back to
   the LMA.

Bernardos              Expires September 13, 2012              [Page 12]

Internet-Draft            PMIPv6 flow mobility                March 2012

   In case flow mobility is needed with a finer granularity than full
   prefix (e.g., flow level), this is done by including in the PBA a
   Flow Identification Mobility option (specified in [RFC6089]) which
   can convey full flow information.  The MAG can also include the Flow
   Identification Mobility option in the PBU message that it sends to
   the LMA.  This serves as a request for the LMA to consider the flow
   policy rules specified in the option.  In this case no prefix is
   removed from any MAG because the movement is performed at flow level.

                 +-----+           +------+        +------+      +-----+
   Internet      | LMA |           | MAG1 |        | MAG2 |      | MN  |
                 +-----+           +------+        +------+      +-----+
      |             |                 |               |             |
      |  flow X to  |    flow X to    |           flow X to         |
      |  pref1::lif |    pref1::lif   |           pref1::lif        |
      |<----------->|<--------------->|<-------------------------->if1
      |  flow Y to  |    flow Y to    |           flow Y to         |
      |  pref2::lif |    pref2::lif   |           pref2::lif        |
      |<----------->|<--------------->|<-------------------------->if1
      |             |                 |               |             |
      |             |                 |               |             |
      |             |                 |            MN powers on if2 and
      |             |                 |           performs L2 attachment
      |             |                 |               |<-----------if2
      |             |                 |          PBU  |             |
      |             |<--------------------------------|             |
      |             |   PBA (pref2)   |               |             |
      |             |-------------------------------->|             |
      |     LMA moves pref2 to new    |               |             |
      |  binding cache entry for if2  |               |             |
      |             |                 |               |             |
      |             |                 |               |             |
      |             |   (optional)    |               |             |
      |             |   BRI[pref2]    |               |             |
      |             |---------------->|               |             |
      |             |       BRA       |               |             |
      |             |<----------------|               |             |
      |  flow y to  |             flow y to           |  flow y to  |
      |  pref2::lif |             pref2::lif          |  pref2::lif |
      |<----------->|<------------------------------->|<---------->if2
      |             |                 |               |             |

      Figure 6: Flow mobility message sequence with different set of
              prefixes per physical interface (PBU signaling)

Bernardos              Expires September 13, 2012              [Page 13]

Internet-Draft            PMIPv6 flow mobility                March 2012

4.  Message formats

4.1.  Flow Mobility Initiate (FMI)

   The LMA sends an FMI message to a MAG to enable flow mobility.  It is
   a Mobility Header message.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                     |           Sequence #          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |I|        Reserved             |           Lifetime            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                                                               .
     .                        Mobility options                       .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Sequence Number:

      A monotonically increasing integer.  Set by the LMA sending then
      initiate message, and used to match a reply in the acknowledge.

   'I' (initiate) flag:

      Set to 1, indicates it is an FMI message.

   Reserved:

      This field is unused.  MUST be set to zero by the sender.

   Lifetime:

      The requested time in seconds for which the LMA asks the MAG keep
      flow-specific state.  A value of all one bits (0xffff) represents
      infinity.  If set to 0, it indicates a request to remove state
      about the flow (cancel flow mobility)

   Mobility Options:

      MUST contain the MN-ID, followed by one or more Flow
      Identification Mobility options [RFC6089].

Bernardos              Expires September 13, 2012              [Page 14]

Internet-Draft            PMIPv6 flow mobility                March 2012

4.2.  Flow Mobility Acknowledge (FMA)

   The MAG sends an FMI message to the LMA as a response to the FMI
   message.  It is a Mobility Header message.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                     |           Sequence #          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |I|  Reserved   |    Status     |           Lifetime            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                                                               .
     .                        Mobility options                       .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Sequence Number:

      A monotonically increasing integer.  Copied from the value set by
      the sending LMA in the FMI message being acknowledged by this FMA
      message.

   'I' flag:

      Set to 0, indicates it is an FMA message.

   Reserved:

      This field is unused.  MUST be set to zero by the sender.

   Status (values to be assigned by IANA):

      ??: Success.

      ??: Reason unspecified.

      ??: MN not attached.

      ??: Sequence number out of window.

      ??: Traffic Selector format unsupported.

      ??: No existing Flow Mobility Cache entry.

   Lifetime:

Bernardos              Expires September 13, 2012              [Page 15]

Internet-Draft            PMIPv6 flow mobility                March 2012

      The requested time in seconds for which the MAG keeps flow-
      specific state.  A value of all one bits (0xffff) represents
      infinity.

   Mobility Options:

      When Status code is 0, MUST contain the MN-ID, followed by one or
      more Flow Identification Mobility options [RFC6089].

5.  Conceptual Data Structures

5.1.  Multiple Care-of Address Registration

   The LMA is extended to allow a mobile node to register multiple proxy
   care of address (Proxy-CoA).

[marco] That's actually supported by RFC5213, isn't it? Maybe you could
write ' ..to register multiple proxy care of address (Proxy-CoA) while using the
same address (prefix) beyond a single interfaces and MAG'

  The LMA maintains multiple binding
   cache entries for an MN.  The number of binding cache entries for an
   MN is equal to the number of the MN's interfaces attaching to any
   MAGs.

            +---------+-----+-------+------+-----------+------------+
            | BID-PRI | BID | MN-ID |  ATT |   HNP(s)  |  Proxy-CoA |
            +---------+-----+-------+------+-----------+------------+
            |    20   |  1  |  MN1  | WiFi | HNP1,HNP2 | IP1 (MAG1) |
            |    30   |  2  |  MN1  | 3GPP | HNP1,HNP3 | IP2 (MAG2) |
            +---------+-----+-------+------+-----------+------------+

                     Figure 7: Extended Binding Cache

   Figure 7 shows two Binding Cache Entries of the MN1 when it is
   attached to the network using two different access technologies.
   Both of the two attachments share HNP1 and are bounded to two
   different Proxy-CoAs.

5.2.  Flow Mobility Cache

   Each LMA MUST maintain a flow mobility cache (FMC) as shown in
   Figure 8.  This table MUST contain an entry for each flow sent from
   the MN.  A flow binding entry includes the following fields:

   o  Flow Identifier Priority (FID-PRI).

   o  Flow Identifier (FID).

   o  Traffic Selector (TS).

   o  Binding Identifier (BID).

Bernardos              Expires September 13, 2012              [Page 16]

Internet-Draft            PMIPv6 flow mobility                March 2012

   o  Action.

   o  Active/Inactive.

               +---------+-----+-----+------+---------+----------+
               | FID-PRI | FID |  TS | BIDs |  Action |   A/I    |
               +---------+-----+-----+------+---------+----------+
               |    10   |  2  | TCP |   1  | Forward |  Active  |
               |    20   |  4  | UDP |  1,2 | Forward | Inactive |
               +---------+-----+-----+------+---------+----------+

                       Figure 8: Flow Mobility Cache

   The BID field contains the identifier of the binding cache entry
   which packets matching the flow information described in the TS field
   will be forwarded to.  When a flow is decided to be moved, the
   affected BID(s) of the table are updated.

   Similar to flow binding described in [RFC6089], each flow binding
   entry points to a specific binding cache entry identifier (BID).
   When a flow is moved, the LMA simply updates the pointer of the flow
   binding entry with the BID of the interface to which the flow will be
   moved.  The traffic selector (TS) in flow binding table is defined as
   in [RFC6088].  TS is used to classify the packets of flows basing on
   specific parameters such as service type, source and destination
   address, etc.  The packets matching with the same TS will be applied
   the same forwarding policy.  FID-PRI is the order of precedence to
   take action on the traffic.  Action may be forward or drop. 

[marco] is flow filtering a new feature of the specification?
I did not see its description in the operations sections.

   If a
   binding entry becomes 'Inactive' it does not affect data traffic.  An
   entry becomes 'Inactive' only if all of the BIDs are deregistered.

   The Mobile Access Gateway MAY also maintain a similar data structure.
   In case no full flow mobility state is required at the MAG, the
   Binding Update List (BUL) data structure is enough and no extra
   conceptual data entries are needed.  In case full per-flow state is
   required at the MAG, it SHOULD also maintain a Flow Mobility Cache
   structure.

[marco] I think this should be one of the most important sections of the
specification. The protocol operation before should refer to the BCE and
the table, where the flow rules are available, and describe the procedure
from packet arrival to the release of the encapsulated packet on the wire.
What's being looked up first, the Flow Mobility Cache or the BCE?

6.  Mobile Node considerations

   This specification assumes the MN implements the logical interface
   model.

[marco] it should not, in my opinion.

  The "logical interface" at the IP layer hides the use of
   different physical media from the IP stack, enabling the MN to send
   and receive packets over different interfaces.  This document assumes
   the MN behaves as stated in the applicability statement document
   [I-D.ietf-netext-logical-interface-support].  In particular, it is

Bernardos              Expires September 13, 2012              [Page 17]

Internet-Draft            PMIPv6 flow mobility                March 2012

   assumed that -- for the case of bidirectional traffic -- the logical
   interface at the MN "replicates" the behavior observed for downlink
   packets on a per-flow basis.  This means that the MN sends UL Flow X
   on the same interface which received the DL Flow X. It also means
   that if the LMA moves flow X during its lifetime, the MN will follow
   that change, upon the reception of packets of flow X via a different
   interface.

   This specification only supports flow mobility between different
   physical interfaces belonging to the same logical interface.  If an
   MN has several logical interfaces, flow mobility across different
   logical interfaces is not supported.

../snip

Hope it helps.

marco

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Fri, 06 Jul 2012 18:23:20 +0200

Hi Marco,

Thanks a lot for your review. I'll take a look at it next week and post
my comments on how to revise the draft.

Thanks,

Carlos

On Fri, 2012-07-06 at 15:49 +0000, Marco Liebsch wrote:
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext

-- 
Carlos Jesús Bernardos Cano     http://www.netcoms.net
   GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
                IEEE Network Special Issue on
                  Video over Mobile Networks
 http://dl.comsoc.org/livepubs/ni/info/cfp/cfpnetwork0313.htm 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Mon, 16 Jul 2012 21:16:24 +0200

Hi Marco, all,

Please find below some comments inline. Since Juan Carlos also made some
comments regarding the draft, and some are related, I've tried to update
the document taking into account both reviews.

> this specification, e.g. how the MN can accomplish multiple address handling.

Taking into account your comments and Juan Carlos's ones, I've tried to
make the draft focus less on the MN and more on the delta from RFC 5213
(the core was already there, so I've tried to make it more clear).

> be clearly separated from the core specification. One example is the need

OK, I've tried to do that in -04.

> Is there text at all that explains why flow templates are needed on the MAG at all?

OK, same than above.

> Please find specific comments below in a copy of the draft, labeled with [marco].

[Carlos] I've modified the abstract.

> of such support on the MN and refer to the availability of appropriate technology

[Carlos] I've modified it following your suggestion, and re-using part
of Juan Carlos's proposed text.

>    "logical interface" at the mobile node is capable of supporting

[Carlos] Addressed above.

> implement what's needed for PMIP if you focus on which technology to

[Carlos] I've modified this part a bit. I preferred not to describe in
detail the extensions, because they are different depending on the
considered use case. Therefore, I preferred to introduce the reader that
different use case scenarios are analyzed in the draft, each one
involving different prefix management requirements and protocol
extensions.

> [marco] I don't think protocol message definitions are needed in the terms section.

[Carlos] Well, many documents do so. RFC5213 for example follows the
same approach. Unless more people think they should be remove, I'd
prefer to keep them.

> [marco] typo: able to to --> able to

[Carlos] fixed.

> on MNs , e.g. using a logical interface.

[Carlos] I've modified it, taking also into account Juan Carlos's
comments to avoid mandating a concrete approach.

> [marco] 'possibilities' = 'scenarios', correct?

[Carlos] Right.

> and the MAG and flows are forwarded according to policy rules on the LMA and the MN'

[Carlos] right.

> scenario 3. Hence, you should probably mention this in the next paragraph.

[Carlos] Not really. Scenario 2 needs extensions. Juan Carlos pointed
out in his review that the way this section is written may lead to
confusion and suggested to merge the description of the scenarios with
the parts where the full scenario is tackled. I've tried to do so in
-04. Please check if now it is clearer.

> logical interface in the core specification part of the document.

[Carlos] Fixed.

> [marco]: assigne --> assign

[Carlos] Fixed.

> HI value used also in case of handover, not only at initial attachment?

[Carlos] The HI value is also used in case of handover.

> clarified earlier in this document. I do not see need for the complete paragraph.

[Carlos] This is related to a comment made by Juan Carlos. I've modified
the text according to his suggestion and promoted before in the
document.

> Internet-Draft            PMIPv6 flow mobility                March 2012

[Carlos] Done.

> Internet-Draft            PMIPv6 flow mobility                March 2012

[Carlos] Done.

>                       (BID, MN-ID, ATT, HNP, PCoA)      (BID, TS)

[Carlos] Done.

> in the core specification part, maybe in the back of the specification if it's

[Carlos] If different prefixes are assigned to the different interfaces
of the MN, in order to perform flow mobility, the MAGs need to know the
prefixes assigned to the other MN's interfaces (not only to the one
attached to the MAG itself), that are involved in the flow mobility. No
information at flow-granularity itself is required, but at least on the
prefix level. Providing information at flow-level is optional. I've
modified the text a bit to make clearer that flow-level granularity info
is not mandatory.

> to make protocol operation for flow mobility more lightweight.

[Carlos] Well, there is a tradeoff here. Signaling the prefixes during
PBU/PBA in this scenario is only possible once the prefixes are known,
as the PBA can only be sent as a response to a received PBU. It might be
the case that only one interface is attached, then the MN attaches a new
one and a flow mobility operation is desired to be performed without
waiting for the first MAG to send a periodic PBU (so a PBA with all the
prefixes can be included in the response to it). I think FMI/FMA was
discussed previously and the consensus on the WG was to keep it.

[Carlos] Yes, thanks for the suggested text.

>    MN is equal to the number of the MN's interfaces attaching to any

[Carlos] This is the way the LMA performs flow routing, which is needed
to perform flow mobility, and mentioned in the document. Do you think we
should explicitly mention that we re-use RFC6089 procedures when
describing the flow mobility operations in sections 3.2.X?

> What's being looked up first, the Flow Mobility Cache or the BCE?

[Carlos] The approach followed here is the same than in RFC 6089, so the
FMC is first looked up first. I think this an important aspect to be
discussed in the WG. Do we want to extend this section, probably
re-using text from RFC6089 to explain in detail how this works? Do we
want also to include more details in the Sections 3.2.X about how flow
routing is performed and how the signaling defined updates the FMC and
extended BCE?

> [marco] it should not, in my opinion.

[Carlos] I've updated this section.

>    logical interfaces is not supported.

It does indeed. Thanks again for the comments!

Carlos

 http://www.comsoc.org/netmag/call-papers (EXTENDED: July, 31)