Internet DRAFT - draft-han-netext-nchi-flowmngt

draft-han-netext-nchi-flowmngt





NETEXT WG                                                         Y. Han
Internet-Draft                                                       KUT
Intended status: Informational                                    B. Ahn
Expires: July 1, 2010                                              Y. An
                                         Network Research Division, ETRI
                                                       December 28, 2009


    Network-controlled and Host-initiated Flow Management in PMIPv6
                   draft-han-netext-nchi-flowmngt-00

Abstract

   Multihomed mobile nodes are capable of simultaneous attachment to
   multiple access networks.  In this case, a PMIPv6-enabled local
   mobility anchor should distribute the application traffic to a proper
   access network which the mobile nodes wish to receive from.  This
   document specifies how mobile nodes send their desire to the attached
   mobile access gateway, which then relays it to a local mobility
   anchor.

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.

   This Internet-Draft will expire on July 1, 2010.

Copyright Notice

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



Han, et al.               Expires July 1, 2010                  [Page 1]

Internet-Draft       Host Flow Management in PMIPv6        December 2009


   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.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   3.  Protocol Operation  . . . . . . . . . . . . . . . . . . . . . . 4
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     5.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
     5.2.  Informative References  . . . . . . . . . . . . . . . . . . 6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 6






























Han, et al.               Expires July 1, 2010                  [Page 2]

Internet-Draft       Host Flow Management in PMIPv6        December 2009


1.  Introduction

   The PMIPv6 (Proxy Mobile IPv6) [RFC5213] protocol provides local
   mobility management to a mobile node (MN) without requiring any
   modification of the MN.  If an MN has multiple interfaces and does
   simultaneous attachment to multiple access networks, it is expected
   that a proper interface can be chosen by the MN to deliver the data.

   For the multihomed MN, the local mobility anchor (LMA) will assign
   different home network prefix(es) (HNPs) to multiple interfaces of
   the MN and manage the MN's binding state properly.  The problem is if
   the MN wishes to receive a flow traffic bound to HNP1 through
   interface1 (IF1), but LMA does not know such a MN's wish exactly in
   real-time manner.

   By multiple CoA [RFC5648] and flow identifier
   [I-D.draft-ietf-mext-flow-binding] supports, the Mobile IPv6
   [RFC3775] is extended to allow the binding of a particular flow to a
   care-of address without affecting other flows using the same home
   address.  In this schemes, an MN itself sends the binding identifier
   and the associated flow identifier to the home agent.  Therefore, the
   home agent becomes to know the exact MN's intention about flow
   distribution and each flow of the MN's multiple interfaces can be
   separately forwarded according to the binding identifier and the flow
   identifier managed in the binding cache.

   [I-D.draft-koodli-netext-flow-handover] specifies a protocol between
   the LMA and a mobile access gateway (MAG) to handover one or more
   service flows from an interface to another.  In this scheme, when a
   new service flow arrives at the LMA, the LMA verifies whether the
   flow is "best-mapped" to MN's interfaces that could serve them.  This
   verification serves as a flow handover trigger which is delivered to
   MAG.  While this scheme allows the LMA to have the flow handover
   control logic, [I-D.draft-hui-netext-service-flow-identifier] lets a
   MAG control the flow handover.  The latter document defines a new
   option, called Service Flow Identifier option, to carry the service
   flow identifier and service flow attributes in the Proxy Binding
   Update and Acknowledgement messages.  An MAG binds MN's each service
   flow to the proper HNP, and notifies the created flow binding
   information to LMA.

   Although the above proposals specify good network-controlled
   protocols to bind service flows to MN's interface, they do not
   describe how to receive the MN's intention about flow distribution.
   Actually, the pure network-controlled protocol excluding the MN's
   involvement completely cannot support such a function.  However,
   host-controlled MIPv6 does well support it and the home agent can
   distribute service flows according to MN's intention in a real-time



Han, et al.               Expires July 1, 2010                  [Page 3]

Internet-Draft       Host Flow Management in PMIPv6        December 2009


   manner.

   This document specifies how MNs send their intention about flow
   distribution to the attached MAG, which then relays it to a local
   mobility anchor.  The proposed scheme does not violate the PMIPv6's
   inherent policy.  That is, basic flow mobility management follows the
   network-controlled flow managment protocol which will be made as IETF
   standard based on [I-D.draft-koodli-netext-flow-handover] and
   [I-D.draft-hui-netext-service-flow-identifier], so that creation and
   management of flow binding are performed in network-side nodes (MAG
   or LMA).  There are no messages newly defined in this document.  MN
   just notifies its intention to MAG by exchanging the existing router
   solicitation and advertisement messages with MAG.


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

   The terminology in this document is based on the definitions in
   [RFC5213], [RFC5648], and [I-D.draft-ietf-mext-flow-binding].


3.  Protocol Operation

   In PMIPv6, an MN is not directly involved with mobility management
   and the binding information is created and managed by an MAG and the
   LMA.  Therefore, an MN cannot be also involved with flow binding
   creation and management.  The LMA or the MAG will perform the
   operations based on [I-D.draft-koodli-netext-flow-handover] or
   [I-D.draft-hui-netext-service-flow-identifier].

   When a flow binding is initially created in network-side, the MAG or
   the LMA determines which interface of the MN is "best-mapped" to the
   current service flow based usually on the MN policy, which is stored
   in somewhere in operator network.  When the flow binding information
   is exchanged by the MAG and the LMA by using a protocol defined by
   [I-D.draft-koodli-netext-flow-handover] or
   [I-D.draft-hui-netext-service-flow-identifier], the MAG sends a
   router advertisement message to the MN in unicast manner (in PMIPv6,
   router advertisement message should be sent in unicase manner).  This
   router advertisement message carries the created flow identifier and
   the corresponding flow information tuple (including the IPv6 HNP/IPv4
   HoA, transport protocol port numbers and QoS parameters for uplink
   and downlink).  When the MN receives such a router advertisement
   message, it stores the flow binding information internally.



Han, et al.               Expires July 1, 2010                  [Page 4]

Internet-Draft       Host Flow Management in PMIPv6        December 2009


   Sometimes, an MN wishes to move a service flow from the current
   interface to other interface.  This flow handover can be caused by
   the MN-internal decision or user's interim decision, etc.  At this
   time, the MN sends the router solicitation message to the MAG via the
   new interface from which the MN wishes to receive the flow traffic.
   In PMIPv6, the MAG acts as the default router on the point-to-point
   link shared with the MN.  So, the router solicitation message will be
   directly sent to the MAG.  This router solicitation message carries
   the flow identifier and the corresponding flow information tuple of
   the service flow which the MN intends to move from the current
   interface to the new interface.

   When receiving such a router solicitation including service flow
   information, MAG does perform the network-controlled flow handover
   operations based on [I-D.draft-koodli-netext-flow-handover] or
   [I-D.draft-hui-netext-service-flow-identifier].

   The following Figure 1 depicts the proposed procedure.

      MN-IF1       MN-IF2    Previous MAG   New MAG          LMA
        |            |            |            |              |
        |-----New Attachment----->|            |              |
        |            |            |-----------PBU------------>|
        |            |            |<----------PBA-------------|
        |            |            |            |              |
        |            |            |    Network-controlled     |
        |~~~~New Service Flow~~~~>|<=Flow Binidng Management=>|<~~ New
        |<--Router Advertisement--|            |              | Service
        |   (Flow Binding Info.)  |            |              | Flow
        |            |            |<~~~~~~Service Flow~~~~~~~>|
        |<~~~~~Service Flow~~~~~~>|            |              |
        |            |            |            |              |
        |            |            |            |              |
        |            |            |            |              |
        |            |---Router Solicitation-->|   Network-   |
        |            |   (Flow Binding Info.)  |  controlled  |
        |            |            |            |<=== Flow ===>|
        |            |            |            |    Binding   |
        |            |            |            |  Management  |
        |            |            |            |              |
        |            |            |            |<~~~Service~~>|
        |            |<~~~~~Service Flow~~~~~~>|     Flow     |
        |            |            |            |              |

                The proposed MN-initiated flow distribution

                                 Figure 1




Han, et al.               Expires July 1, 2010                  [Page 5]

Internet-Draft       Host Flow Management in PMIPv6        December 2009


4.  Security Considerations

   TBD


5.  References

5.1.  Normative References

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

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.

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

   [RFC5648]  Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T.,
              and K. Nagami, "Multiple Care-of Addresses Registration",
              RFC 5648, October 2009.

5.2.  Informative References

   [I-D.hui-netext-service-flow-identifier]
              Hui, M., Chen, G., and H. Deng, "Service Flow Identifier
              in Proxy Mobile IPv6",
              draft-hui-netext-service-flow-identifier-01 (work in
              progress), October 2009.

   [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-04 (work in
              progress), November 2009.

   [I-D.koodli-netext-flow-handover]
              Koodli, R. and K. Chowdhury, "Flow Handover for Proxy
              Mobile IPv6", draft-koodli-netext-flow-handover-01 (work
              in progress), October 2009.











Han, et al.               Expires July 1, 2010                  [Page 6]

Internet-Draft       Host Flow Management in PMIPv6        December 2009


Authors' Addresses

   Youn-Hee Han
   KUT
   Gajeon-Ri, 307, Byeongcheon-Myeon
   Cheonan, Chungnam
   Korea

   Phone: +82 41 560 1486
   Email: yhhan@kut.ac.kr


   Byung-Jun Ahn
   Network Research Division, ETRI
   Jeonmin-Dong, Yusung-Go
   Deajoen, Chungnam
   Korea

   Email: bjahn@etri.re.kr


   Yoon-Young An
   Network Research Division, ETRI
   Jeonmin-Dong, Yusung-Go
   Deajoen, Chungnam
   Korea

   Email: yyahn@etri.re.kr























Han, et al.               Expires July 1, 2010                  [Page 7]