Internet DRAFT - draft-xia-netext-flow-binding

draft-xia-netext-flow-binding






Network Working Group                                             F. Xia
Internet-Draft                                               B. Sarikaya
Expires: December 27, 2010                                    Huawei USA
                                                           June 25, 2010


                   Flow Binding in Proxy Mobile IPv6
                    draft-xia-netext-flow-binding-02

Abstract

   This document introduces extensions to Proxy Mobile IPv6 that allows
   networks dynamically binding IP flows to different interfaces of a
   mobile node.  Mobile Access Gateways can move flows to other mobile
   access gateways by establishing flow bindings at the local mobility
   anchor.  Local mobility anchor sends packets from the offloaded flow
   seamlessly to the new mobile access gateway.

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 December 27, 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



Xia & Sarikaya          Expires December 27, 2010               [Page 1]

Internet-Draft           Flow Binding in PMIPv6                June 2010


   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Use Cases  . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Design Assumptions and Principles  . . . . . . . . . . . . . .  4
   5.  Protocol Operation . . . . . . . . . . . . . . . . . . . . . .  5
     5.1.  Other Enhancements . . . . . . . . . . . . . . . . . . . .  7
   6.  MAG Operation  . . . . . . . . . . . . . . . . . . . . . . . .  7
   7.  LMA Operation  . . . . . . . . . . . . . . . . . . . . . . . .  8
   8.  MN Operation . . . . . . . . . . . . . . . . . . . . . . . . .  9
   9.  Message formats  . . . . . . . . . . . . . . . . . . . . . . .  9
     9.1.  Target Care-of-Address sub-option  . . . . . . . . . . . .  9
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   11. IANA considerations  . . . . . . . . . . . . . . . . . . . . . 10
   12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 10
     13.2. Informative references . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12




























Xia & Sarikaya          Expires December 27, 2010               [Page 2]

Internet-Draft           Flow Binding in PMIPv6                June 2010


1.  Introduction

   Assume a mobile node equipped with two interfaces namely IF1 (e.g.
   3GPP) and IF2 (e.g WiFi), and IF1 is active while IF2 is not
   activated.  There are two flows running on IF1, that is, VoIP and
   file downloading.  At some time, e.g., the mobile node moves into a
   WiFi hotspot, IF2 becomes active, and the file downloading flow is
   then offloaded to IF2 while VoIP flow remains on IF1.  When the
   mobile node moves out of the hotspot, the file downloading flow is
   moved back to IF1 again.

   In this document, a flow is defined as one or more connections that
   are identified by a flow identifier.  A single connection is
   typically identified by the source and destination IP addresses,
   transport protocol number and the source and destination port
   numbers.

   [I-D.ietf-mext-flow-binding] allows a mobile node to bind a
   particular flow to a care-of address without affecting other flows
   using the same home address.  Flow Identification option is defined
   and included in Binding Update (BU) / Binding Acknowledgement(BA)
   messages.  However, the mechanism specified in the document can't be
   directly applied to Proxy Mobile IPv6 in which the mobile node is not
   involved in mobility management.  A Mobile Access Gateway (MAG) is
   then introduced to take on mobility management on behalf of the
   mobile node.

   This document introduces extensions to Proxy Mobile IPv6 that allows
   networks dynamically bind IP flows to different interfaces of a
   mobile node.  In the aforementioned scenario, the IF1 attaches to a
   mobile access gateway forwarding VoIP and file downloading flows at
   the beginning.  When the mobile node moves into a WiFi hotspot, IF2
   becomes active and connects to another mobile access gateway which
   then takes over file downloading flow.  Based on operator policy or
   the mobile node profile, the mobile access gateways may signal a
   Local Mobility Anchor (LMA) to redirect flows from one to another.


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

   The terminology in this document is based on the definitions in
   [RFC5213], in addition to the ones specified in this section.





Xia & Sarikaya          Expires December 27, 2010               [Page 3]

Internet-Draft           Flow Binding in PMIPv6                June 2010


   Serving Interface:  a mobile node's interface on which some
      application flows are running.  Based on the MN's profile,
      operator's policy, or other reasons, some of the flows are
      supposed to be offloaded to the other interfaces of the mobile
      node when they become available.

   Target Interface:  a mobile node's interface which is taking over
      some application flows from a serving interface of the mobile
      node.

   Serving IP Address (SIP):  an IPv4 or IPv6 address configured on a
      serving interface.

   Target IP Address (TIP):  an IPv4 or IPv6 address configured on a
      target interface.

   Serving Mobile Access Gateway(SMAG):  A mobile access gateway which a
      serving interface attaches to.

   Target Mobile Access Gateway(TMAG):  A mobile access gateway which a
      target interface attaches to.


3.  Use Cases

   Michael is using 3GPP access to different services with different
   characteristics in terms of QoS requirements and bandwidth:
   o  a VoIP call.
   o  a non-conversational video streaming, e.g.IPTV.
   o  a p2p download.

   When Michael gets into his home where WiFi access is available,
   Michael prefers running the p2p download and IPTV through the WiFi
   network, and leaving the VoIP call still on 3GPP networks.

   At some time, Michael's device starts ftp file synchronization with a
   backup server.  Due to the synchronization, the WiFi access becomes
   congested and the IPTV flow is then moved back to 3GPP access.

   After a while, Michael moves out of his home and loses the WiFi
   connectivity.  Triggered by this event, all the IP flows through the
   WiFi access need to be moved to the 3GPP access which is the only
   access available.


4.  Design Assumptions and Principles

   The following are assumptions and principles when this solution is



Xia & Sarikaya          Expires December 27, 2010               [Page 4]

Internet-Draft           Flow Binding in PMIPv6                June 2010


   proposed.
   o  This document only deals with scenarios that multiple interfaces
      of a mobile node are registered at the same local mobility anchor.
   o  This document also tries to avoid any new layer 2 or layer 3
      protocols introduced between a mobile node and a mobile access
      gateway.
   o  Mobile access gateways can detect attachments or detachments of
      mobile nodes through existing layer 2 mechanism (e.g. 3GPP, WiMAX,
      or WiFi).  The attachment or detachment events can serve as
      triggers for mobile access gateways to initiate flow mobility
      procedure.
   o  There are no direct communications among mobile access gateways to
      which multiple interfaces of a mobile node attach.  One mobile
      access gateway may be able to learn the presence of another mobile
      access gateway through message exchanges with the common local
      mobility anchor.
   o  When a local mobility anchor receives a flow binding request from
      a mobile access gateway, it can make a decision by itself or
      consult a mobile access gateway to which the flow will move.


5.  Protocol Operation



        +--------+      +------+      +------+      +------+
        |  MN    |      | SMAG |      | TMAG |      | LMA  |
        +--------+      +------+      +------+      +------+
         IF1 IF2           |              |             |
          |    |           |              |             |
          |   1 Attachment |              |             |
          |<-------------->|      2 PBU&PBA             |
          |   3 Addr Cfg   |<-------------------------->|
          |<-------------->|              |             |
       Running |           |              |             |
     Applications          |              |             |
          |    |    4  Attachment/PBU&PBA/Addr Cfg      |
          |    |<------------------------>|<----------->|
          |    |           |              |             |
          |    |           |     5 PBU(Flow Binding)    |
          |    |           |--------------------------->|
          |    |           |                            |
          |    |           |     6 PBA(Flow Binding)    |
          |    |           |<---------------------------|
          |    |           |              |   7 Packets |
          |    |         8 Packets        |<============|
          |    |<=========================|             |
          |    |           |              |             |



Xia & Sarikaya          Expires December 27, 2010               [Page 5]

Internet-Draft           Flow Binding in PMIPv6                June 2010


                       Figure 1: Protocol Operation

   1.  A mobile node has two interfaces, IF1 and IF2.  At the beginning,
       only IF1 is activated and attachment procedure is triggered.
   2.  On receiving attachment signaling from the mobile node, a mobile
       access gateway, acting as a SMAG, sends a PBU to a LMA.  Access
       Technology Type Option defined in [RFC5213] is carried in the
       PBU.  The LMA assigns a unique prefix for the mobile node through
       a PBA message to the SMAG.
   3.  The SMAG extracts the prefix, and advertises it to the mobile
       node through Router Advertisement message.  The mobile node then
       configures its address, acting as a SIP, through stateless
       address configuration procedure specified in [RFC4862].  Then,
       the mobile node runs applications using this address, such as,
       VoIP,IPTV, and p2p downloading.
   4.  When the mobile node moves into some other places where IF2 is
       activated, the mobile node follows similar steps to 1,2,3 to
       configure IP address for IF2, acting as TIP.  According to Proxy
       Mobile IPv6 specification [RFC5213], this is an attachment over a
       new interface with the Handoff Indicator field set to a value of
       1 and the SIP is different from TIP.  Here the binding cache
       entry is modified as described in
       [I-D.sarikaya-netext-fb-support-extensions].
   5.  Based on the mobile node's profile, operator's policy, or network
       status the SMAG decides to offload some traffic flows from IF1 to
       IF2.  The SMAG then sends a PBU with Flow Identification option
       defined in [I-D.ietf-mext-flow-binding].  This message indicates
       the LMA to change the direction of the requested flows from the
       SMAG to the TMAG.  SMAG first assigns a Flow Identifier (FID)
       value to this flow and then sets Action field to Forward.  SMAG
       adds the flow description using the Traffic Selector sub-option.
       SMAG indicates TMAG address in Target Care-of-Address Sub-option
       defined in Section 9.1.
   6.  It is the LMA that makes a decision if offloading request is
       granted or not.  The LMA may decide based on local information,
       such as, access technology types, bandwidth, service types, and
       so on.  The LMA inquires the TMAG of acceptability of the
       offloading request and establishes this new flow at the TMAG.
       Section 5.1 explains message exchanges between the LMA and the
       SMAG.  TMAG adds a new entry for this flow in its Flow Binding
       Entries Table.  The LMA sends a PBA to indicate the operation
       result of the flow binding request.
   7.  All the offloaded packets with SIP as destination address (if it
       belongs to the home interface as described in
       [I-D.sarikaya-netext-fb-support-extensions]) received by LMA are
       encapsulated and sent to the TMAG.





Xia & Sarikaya          Expires December 27, 2010               [Page 6]

Internet-Draft           Flow Binding in PMIPv6                June 2010


   8.  The TMAG strips the encapsulation, and checks that an entry for
       this flow exists in the flow binding entries table and then
       forwards the packets to the mobile node's IF2.  The mobile node
       then processes the packets with SIP as the destination address.

5.1.  Other Enhancements

   It is helpful for a SMAG when initiating flow movement if the SMAG is
   aware of the presence of the potential TMAGs.  This awareness can be
   achieved through notification from a local mobility anchor because
   all MAGs of mobile node are associated to the same local mobility
   anchor.

   The LMA notifies SMAG about IF2's presence through Generic Signaling
   Request / Generic Signaling Acknowledgement message exchanges
   specified in [I-D.ietf-mext-generic-signaling-message].  Flow
   Identification Mobility Option with Target Care-of Address sub-option
   defined in Section 9.1 is included in the message from the LMA to the
   SMAG.  Through this message exchange, the SMAG has an idea of
   availability of other interfaces of the mobile node, and the address
   of the TMAG.

   To make a better decision, the LMA may send a Generic Signaling
   Request message to the TMAG for inquiring if the offloading is
   allowed.  Flow Identification option is included in the message.  The
   TMAG responds with a Generic Signaling Acknowledgment message.  If
   the TMAG accepts the flows, the Status field of the message SHOULD be
   set to 0, otherwise, the field is set to a value of 128 or higher.

   Flow binding extensions described in
   [I-D.sarikaya-netext-fb-support-extensions] are assumed.  These
   extensions are needed to avoid LMA sending packets with double
   encapsulation to MN over LMA-MAG tunnel after a particular flow is
   moved from one interface to another interface.  The extensions
   require LMA to distinguish the home interface, e.g. 3G interface from
   the secondary interfaces, e.g.  WiFi and the mobile node always uses
   the home interface address as the source address in the packets it
   sends over a virtual interface.


6.  MAG Operation

   Flow binding is always initiated by a SMAG, that is, the SMAG wants
   to offload its traffic flow to other MAGs.  There are several reasons
   for triggering flow binding.
   o  The SMAG is notified by a LMA the availability of other MAGs which
      the same mobile node currently attaches to.




Xia & Sarikaya          Expires December 27, 2010               [Page 7]

Internet-Draft           Flow Binding in PMIPv6                June 2010


   o  Congestion occurs in the SMAG which knows there are other MAGs
      connecting to the same mobile node.
   o  The SMAG detects the serving interface of the mobile node is out
      of service.
   o  ... ...

   As to Flow Identification option used in this document, there are two
   fields needing special consideration, that is, Flow ID (FID) and
   Binding Identification number (BID).  BID is mainly defined for
   multiple-interfaced mobile nodes with Mobile IPv6 functionalities.
   The BID is an identification number used to distinguish multiple
   bindings registered by the mobile node.  Each BID is generated and
   managed by a mobile node in Mobile IPv6.  In Proxy Mobile IPv6,
   mobility management of mobile nodes with multiple interfaces is run
   in different independent MAGs, and BID loses its meaning.  All BID
   fields in Flow Identification option SHOULD be set to 0.  In this
   document flows are identified using FID.  FID is set by the
   initiator, e.g.  SMAG.  Thereafter it is used by all other entities
   like LMA and any other MAGs to which this flow is forwarded to.


7.  LMA Operation

   The LMA is the center of the flow binding processing.  It has
   following functionalities:
   o  Advertising the availability of a new interface of a mobile node.
      When an interface of the mobile node becomes active, a
      corresponding MAG SHOULD sends a PBU to the LMA.  Triggered by the
      PBU, the LMA then notifies all the other MAGs which the mobile
      node is attaching to.  Generic Signalling Request with Flow
      Identification Mobility Option is used for this notification.  The
      new MAG's address is sent in Target Care-of Address Sub-option.
   o  Deciding if an offloading request is acceptable.  On receiving PBU
      from a SMAG with a flow binding request, the LMA makes a decision
      based on operator's local policy, mobile node's preference,
      bandwidth of the flow, and so on.
   o  Inquiring a TMAG for acceptability of the offloaded flows.  If the
      LMA can't decide on accepting offloading request, the LMA SHOULD
      inquire other MAGs using Generic Signaling Request message with
      Flow Identification Mobility Option copying the fields from the
      PBU sent by the originating SMAG.  TMAG sends a Generic Signaling
      Acknowledgement message and sets Status field to 0 indicating
      acceptance.  TMAG also inserts the new flow in its flow binding
      entries table.
   o  Redirecting upstream packets.  In Mobile IPv6, the home agent
      tunnels the upstream packets to the Care-of Address indicated in
      the flow binding entry table for this flow.  In Proxy Mobile IPv6,
      LMA keeps a flow binding entry table as in



Xia & Sarikaya          Expires December 27, 2010               [Page 8]

Internet-Draft           Flow Binding in PMIPv6                June 2010


      [I-D.ietf-mext-flow-binding] and links binding cache entries for
      each mobile node to this table.  The table contains an entry for
      each active flow that the mobile node has indicating to which MAG,
      i.e.  Proxy-CoA1 to forward the flow to.  LMA first matches the
      traffic selectors given in the table entry and then tunnels the
      packet to the corresponding MAG.  Together with provisions in
      [I-D.sarikaya-netext-fb-support-extensions], the destination MAG
      can simply decapsulate the packet and forward to the mobile node's
      interface connected to this MAG.


8.  MN Operation

   In this document, it is assumed that different interfaces are
   assigned different prefixes, and the same interface is configured
   with the same IP address even after resetting of the interface.  Once
   one interface becomes inactive, the software SHOULD map the address
   to another interface, or to a virtual interface,so that ongoing
   sessions with the address can survive.  When the interface becomes
   active again, and receive the same prefix from a LMA, the address
   SHOULD be moved back to the interface.


9.  Message formats

9.1.  Target Care-of-Address sub-option

   This section introduces the Target Care-of-Address, which may be
   included in the Flow Identification Mobility Option.  This sub-option
   is used by the TMAG to indicate the Local Mobility Anchor to move a
   flow binding from SMAG to the Target Care-of Address, i.e.  TMAG.


       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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Sub-opt Type  | Sub-opt Len   |          Reserved             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 Target Care-of-Address                        |
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                Figure 2: Target Care-of-Address Sub-option







Xia & Sarikaya          Expires December 27, 2010               [Page 9]

Internet-Draft           Flow Binding in PMIPv6                June 2010


   Sub-opt Type

      To be assigned by IANA
   Sub-opt Len

      Length of the sub-option in 8-octet units
   Reserved

      This field is unused.  It MUST be initialized to zero by the
      sender and MUST be ignored by the receiver.
   Target Care-of-Address

      An IP address of a MAG to which a new interface is attaching.
      This address could be IPv4 or IPv6 address.


10.  Security Considerations

   This specification allows a mobile access gateway to offload traffic
   to other mobile access gateway.  This mechanism facilitate a serving
   mobile access gateway to launch DoS attacks to a target mobile access
   gateway.  However, a local mobility anchor finally decides
   acceptability of an offloading request, as mitigates DoS attacks
   threat.


11.  IANA considerations

   A new mobile option, Alternative Interface Indicator, is defined.
   Option type SHOULD be assigned by IANA.


12.  Acknowledgements

   TBD.


13.  References

13.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5213]  Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
              and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support



Xia & Sarikaya          Expires December 27, 2010              [Page 10]

Internet-Draft           Flow Binding in PMIPv6                June 2010


              in IPv6", RFC 3775, June 2004.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862, September 2007.

   [RFC0792]  Postel, J., "Internet Control Message Protocol", STD 5,
              RFC 792, September 1981.

   [RFC4443]  Conta, A., Deering, S., and M. Gupta, "Internet Control
              Message Protocol (ICMPv6) for the Internet Protocol
              Version 6 (IPv6) Specification", RFC 4443, March 2006.

13.2.  Informative references

   [I-D.ietf-mext-flow-binding]
              Soliman, H., Tsirtsis, G., Montavont, N., Giaretta, G.,
              and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and NEMO
              Basic Support", draft-ietf-mext-flow-binding-06 (work in
              progress), March 2010.

   [I-D.ietf-mext-generic-signaling-message]
              Haley, B. and S. Gundavelli, "Mobile IPv6 Generic
              Signaling Message",
              draft-ietf-mext-generic-signaling-message-00 (work in
              progress), August 2008.

   [I-D.sarikaya-netext-fb-support-extensions]
              Sarikaya, B. and F. Xia, "PMIPv6 Multihoming Support for
              Flow Mobility",
              draft-sarikaya-netext-fb-support-extensions-00 (work in
              progress), February 2010.




















Xia & Sarikaya          Expires December 27, 2010              [Page 11]

Internet-Draft           Flow Binding in PMIPv6                June 2010


Authors' Addresses

   Frank Xia
   Huawei USA
   1700 Alma Dr. Suite 500
   Plano, TX  75075

   Phone: +1 972-509-5599
   Email: xiayangsong@huawei.com


   Behcet Sarikaya
   Huawei USA
   1700 Alma Dr. Suite 500
   Plano, TX  75075

   Phone: +1 972-509-5599
   Email: sarikaya@ieee.org

































Xia & Sarikaya          Expires December 27, 2010              [Page 12]