Network Working Group H. Yokota Internet-Draft D. Kim Intended status: Standards Track KDDI Lab Expires: January 15, 2013 B. Sarikaya F. Xia Huawei USA July 14, 2012 Home Agent Initiated Flow Binding for Mobile IPv6 draft-yokota-mext-ha-init-flow-binding-02 Abstract There are scenarios in which the home agent needs to trigger flow binding operations towards the mobile node such as moving a flow from one access network to another based on the network resource availability. In order for the home agent to be able to initiate interactions for flow bindings with the mobile node, this document defines new signaling messages and sub-options for Mobile IPv6. Home agent initiated flow bindings are supported for both IPv4 and IPv6 enabled mobile nodes. 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 January 15, 2013. Copyright Notice 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 Yokota, et al. Expires January 15, 2013 [Page 1] Internet-Draft HA Initiated Flow Binding for Mobile IPv6 July 2012 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 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Over-the-air Flow Binding Provisioning . . . . . . . . . . 3 3.2. Traffic Offload . . . . . . . . . . . . . . . . . . . . . 4 3.3. Flow Binding Revocation . . . . . . . . . . . . . . . . . 4 3.4. Exceeding traffic quota . . . . . . . . . . . . . . . . . 4 4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Adding flow bindings . . . . . . . . . . . . . . . . . . . 5 4.2. Deleting flow bindings . . . . . . . . . . . . . . . . . . 5 4.3. Modifying flow bindings . . . . . . . . . . . . . . . . . 5 4.4. Refreshing flow bindings . . . . . . . . . . . . . . . . . 6 4.5. Moving flow bindings . . . . . . . . . . . . . . . . . . . 6 4.6. Revoking flow bindings . . . . . . . . . . . . . . . . . . 6 5. Handling of the Flow Bindings List . . . . . . . . . . . . . . 6 6. Flow Binding Messages and Options . . . . . . . . . . . . . . 7 6.1. Mobility Header . . . . . . . . . . . . . . . . . . . . . 7 6.1.1. Flow Binding Indication . . . . . . . . . . . . . . . 8 6.1.2. Flow Binding Acknowledgement . . . . . . . . . . . . . 9 6.1.3. Flow Binding Revocation Extensions . . . . . . . . . . 10 6.2. New Options . . . . . . . . . . . . . . . . . . . . . . . 10 6.2.1. Flow binding action sub-option . . . . . . . . . . . . 10 6.2.2. Target Care-of-Address sub-option . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. Protocol constants . . . . . . . . . . . . . . . . . . . . . . 12 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 10.2. Informative references . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Yokota, et al. Expires January 15, 2013 [Page 2] Internet-Draft HA Initiated Flow Binding for Mobile IPv6 July 2012 1. Introduction [RFC6089] allows a mobile node to bind a particular flow to a care-of address without affecting other flows using the same home address. Binding Update (BU)/Binding Acknowledgement(BA) messages are extended for the mobile node to add, modify, remove and refresh flow binding in a home agent. The operations are always initiated by the mobile node. In some cases, the home agent would like to initiate flow binding operations. e.g, the home agent revokes a flow binding for reasons such as accounting insufficiency of the mobile node; for the mobile node equipped with multiple interfaces, the home agent moves a flow binding from one interface to another based on network resource availability; the home agent provisions default flow binding rules to the mobile node based on the mobile node's default profile. This document defines one new Mobility Header and two new messages for the home agent to control flow bindings in the mobile node. Flow mobility for the mobile nodes with IPv4 home address and IPv4 address of the home agent as described in [RFC5555] is also supported. 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 [RFC3775] and [RFC6089]. 3. Use Cases 3.1. Over-the-air Flow Binding Provisioning When a new subscriber purchases a dual mode phone equipped with both 3GPP and WiFi interfaces, depending on the services that the subscriber can use, the operator provisions the mobile phone over the air with the following information: o 3GPP access takes priority over WiFi access when providing Voice- over-IP (VoIP) service. That is, when making a call, the 3GPP network is always used as far as the network is accessible. o WiFi access is primarily selected to serve IPTV service. Yokota, et al. Expires January 15, 2013 [Page 3] Internet-Draft HA Initiated Flow Binding for Mobile IPv6 July 2012 o Peer-to-peer (p2p) download is only allowed through WiFi access. The above profile can be downloaded through the home agent to the mobile node when registering. 3.2. Traffic Offload The 3G operator may want to move traffic flows from the 3G access to another due to ever-increasing traffic load in the 3G access network. Fine-grained traffic offload is desirable. For example, IMS-based VoIP flows must stay in the mobile core network while video streaming flows provided by servers on the Internet could bypass the mobile core network via WiFi access. Since the network knows more about its conditions and has access to the policy server, more timely and well- controlled traffic offloading is possible. To this end, already established sessions are moved by the home agent by sending down an updated flow descriptor to the mobile node. 3.3. Flow Binding Revocation For administrative reasons, such as the utilization of CPU of a home agent reaches a threshold or the home agent needs to reboot some of it line cards, sometimes it becomes necessary to inform the mobile node that its flow binding has been revoked and the mobile node is no longer able to receive IP mobility service for a given flow. Apart from revocation, the home agent may decide to delete a flow binding with a delete operation. 3.4. Exceeding traffic quota The 3G operator offers a mobile broadband service with a flat rate subscription limited to 5G Byte per month. Once the quota is reached the service is downgraded to 64 K bit per second. This limitation does not prevent the user from using the 3G access for mobile broadband services and there is no reason for the operator to change the policy since the service is still available. However, since the operator has more information available than the user, the operator can indicate this to the user by sending modified flow descriptors to the user as a proposal to change access for an ongoing session. 4. Protocol Operation [RFC6089] makes use of Binding Update (BU) /Binding Acknowledgement(BA) signalling to forward, i.e. register or discard a flow binding in a home agent. That is, flow binding operations are always initiated from the mobile node. The mechanism specified in this document is complimentary to the method described in [RFC6089]. Yokota, et al. Expires January 15, 2013 [Page 4] Internet-Draft HA Initiated Flow Binding for Mobile IPv6 July 2012 It is assumed that the home agent has already created Binding Cache entries for the mobile node before launching flow binding operations. In this document, one new Mobility Header and two new messages are defined, that is, Flow Binding Indication (FBI) Section 6.1.1 and Flow Binding Acknowledgement (FBA)Section 6.1.2. FBI is used by the home agent to initiate flow binding operations, while FBA is used for acknowledging FBI. Due to access network change on the mobile node side, some interface that used to be active may not be valid at the time of flow binding operation by the home agent, in which case, even if the HA sends the FBI to the MN, the FBA will not return. After retransmitting the FBIs for MAX_FBI_RETRIES times and not receiving the FBA, the HA determines that the target interface is not available. 4.1. Adding flow bindings Adding the flow binding implies associating a flow with a particular care-of address for the mobile node. The care-of address concerned with the flow binding is present in the destination address of the packet or the alternate care-of address option. Alternatively, the care-of address may be indicated by the Target Care-of Address sub- option defined in Section 6.2.2. Binding Identification number (BID) described in [RFC5648] is not used in the flows initiated by the home agent. When adding a new flow binding, the home agent sends a FBI with a Flow Identification Mobility option to the mobile node. The Flow Identification Mobility option defined in [RFC6089] includes a unique Flow Identifier (FID). The Flow binding action sub-option MUST indicate Add operation defined in Section 6.2.1. The FID needs only be unique for the receiver of the message that adds a flow, i.e. the same FID can be used across different receivers of the message. 4.2. Deleting flow bindings When removing a flow binding, the home agent sends a FBI with a Flow Identification Mobility option in which the Flow binding action sub- option indicates Delete operation. The Flow Identification Mobility option includes a unique FID for the mobile node to locate the flow binding and remove it. 4.3. Modifying flow bindings When modifying a flow binding (either the care-of address or other attributes of the flow), the home agent sends the mobile node a FBI message with Flow Identification Mobility option. The option Yokota, et al. Expires January 15, 2013 [Page 5] Internet-Draft HA Initiated Flow Binding for Mobile IPv6 July 2012 includes the FID for the binding being modified. A Traffic Selector sub-option may come with the Flow Identification Mobility Option and contain the new attributes needed to classify the flow such as DS (Differential Services) values in [RFC6088]. Hence, flow modification is essentially a process where an existing flow definition is removed and a new flow (included in the option) is added with the same FID as the flow that was removed. 4.4. Refreshing flow bindings A flow binding is refreshed by simply including the Flow Identification Mobility option with Refresh Action field in the FBI message. The message should be sent before the expiration of the flow binding. The message updates existing bindings with new information. Hence, all information previously sent in the last refreshing message need to be resent, otherwise such information will be lost. 4.5. Moving flow bindings The home agent can move a flow associated to one interface of the multi-interfaced mobile node to another by sending a FBI message to the mobile node. A Flow Identification Mobility option whose Action field is set to Move is included. The address of the target interface is also included in the Flow Identification Mobility option in Target Care-of Address sub-option. 4.6. Revoking flow bindings When the home agent or the network attached to it is overloaded, the home agent can revoke a flow binding registered by the mobile node. The home agent sends the mobile node a FBI message with a Flow Identification Mobility option in which the Flow binding action sub- option indicates Revoke operation. When the MN receives the FBI message with Revoke operation, it returns the FBA and decides whether the flow should be removed (de-registration) or moved to another interface. The mobile node SHOULD take an action by sending a new BU to, for example, deregister the flow. 5. Handling of the Flow Bindings List Flow bindings list defined in [RFC6089] needs to be modified after each protocol operation defined above as follows: If FBI contains a flow binding add operation and if the corresponding FBA has a status code equal to zero, home agent MUST add a new entry to the flow bindings list. FID, Flow Descriptor, FID-PRI and Action Yokota, et al. Expires January 15, 2013 [Page 6] Internet-Draft HA Initiated Flow Binding for Mobile IPv6 July 2012 fields are taken from the Flow Identification Mobility Option. BID is copied from the Binding Reference sub-option. Active/Inactive Flag is set to Active. Note that if BID is not available it may be replaced by Care-of-Address. If FBI contains a flow binding delete operation and if the corresponding FBA has a status code equal to zero, home agent MUST locate the list entry corresponding to this flow and then delete the entry. If the home agent sends a Binding Revocation Indication message with Flow Mobility Option where the action field is set to Revoke and if the corresponding Binding Revocation Acknowledgement message indicates acceptance, home agent MUST locate the list entry corresponding to this flow and then delete the entry. If FBI contains a flow binding modify operation and if the corresponding FBA has a status code equal to zero, home agent MUST delete the list entry corresponding to this flow and then add a new entry setting the values as defined in the Flow Identification Mobility Option. If FBI contains a flow binding refresh operation and if the corresponding FBA has a status code equal to zero, home agent MUST locate the list entry corresponding to this flow and then set Active/ Inactive Flag to Active. If FBI contains a flow binding move operation and if the corresponding FBA has a status code equal to zero, home agent MUST locate the list entry corresponding to this flow and then change the BID value to the Care-of-Address in the Flow Identification Mobility Option. If FBI contains a flow binding switch operation and if the corresponding FBA has a status code equal to zero, home agent MUST locate the list entry corresponding to this flow and then delete the entry. Flow binding operations apply equally to IPv6 packets as well as IPv4 packets as in Dual-Stack Mobile IPv6 [RFC5555]. 6. Flow Binding Messages and Options 6.1. Mobility Header The messages described below follow the Mobility Header format specified in Section 6.1 of [RFC3775]. Yokota, et al. Expires January 15, 2013 [Page 7] Internet-Draft HA Initiated Flow Binding for Mobile IPv6 July 2012 6.1.1. Flow Binding Indication The Flow Binding Indication messages are used by the home agent to initiate flow binding operations to the mobile node. The Flow Binding Indication messages use the MH Type value (IANA-TBD1) for Flow Binding message and a Flow Binding Type value of 1, and the format of the Message Data field in the Mobility Header is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flow Binding Type = 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | Trigger |A| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Flow Binding Indication Message Type Sequence # A 16-bit unsigned integer used by the home agent to match a returned Flow Binding Acknowledgement with this Flow Binding Indication. It could be a random number. Trigger 8-bit unsigned integer indicating the event which triggered the home agent to send the Flow Binding Indication message. The following Trigger values are currently defined: 0 Reserved 1 Unspecified 2 Administrative Reason 3 Possible Out-of Sync BCE State 250-255 Reserved For Testing Purposes only All the other values are reserved Acknowledge (A) The Acknowledge (A) bit is set by the home agent to request a Flow Binding Acknowledgement be returned upon receipt of the Flow Binding Indication. Yokota, et al. Expires January 15, 2013 [Page 8] Internet-Draft HA Initiated Flow Binding for Mobile IPv6 July 2012 Reserved These fields are unused. They MUST be initialized to zero by the sender and MUST be ignored by the receiver. Mobility Options Variable-length field of such length that the complete Mobility Header is an integer multiple of 8 octets long. Flow Identification Mobility Options are included in this field. 6.1.2. Flow Binding Acknowledgement The Flow Binding Acknowledgement is used to acknowledge receipt of a Flow Binding Indication. The mobile node sends FBA message to acknowledge the reception of FBI to Add, Delete, Modify, Refresh, Move, or Switch a flow binding. On receiving messages with Flow Identification Mobility Option(s), the mobile node should copy each Flow Identification Mobility Option to the Acknowledgement messages. The Flow Binding Acknowledgement has the MH Type value (IANA-TBD1) for Flow Binding message and a Flow Binding Type value of 2. When this value is indicated in the MH Type field, the format of the Message Data field in the Mobility Header is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flow Binding Type = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | Status | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Flow Binding Acknowledgement Message Type Sequence # The sequence number in the Flow Binding Acknowledgement is copied from the Sequence Number field in the Flow Binding Indication. Status 8-bit unsigned integer indicating the result of processing the Flow Binding Indication message by the receiving mobile node. Values of the Status field less than 128 indicate that the Flow Binding Indication was processed successfully by the receiving node. Values greater than or equal to 128 indicate that the Flow Binding Indication was rejected by the receiving node. The Yokota, et al. Expires January 15, 2013 [Page 9] Internet-Draft HA Initiated Flow Binding for Mobile IPv6 July 2012 following status values are currently defined: 0 success 128 Binding Does NOT Exist All the other values are reserved Mobility Options Variable-length field of such length that the complete Mobility Header is an integer multiple of 8 octets long. This field contains zero or more TLV-encoded mobility options. Flow Identification Mobility Options are included in this field. 6.1.3. Flow Binding Revocation Extensions This specification enables Binding Revocation Indication and Binding Revocation Acknowledgement messages to carry Flow Identification Mobility Options as defined in [RFC6089] with extensions defined in this document. 6.2. New Options This specification defines two Flow Indication sub-options that is included in Flow Identification Mobility Option specified in [RFC6089]. 6.2.1. Flow binding action sub-option This section defines a new sub-option for flow binding actions, which must be included in the Flow Identification Mobility Option as shown in Figure 3. 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 | Action | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Flow binding action Sub-option Sub-opt Type To be assigned by IANA (IANA-TBD2) Sub-opt Len Length of the sub-option in 8-octet units Yokota, et al. Expires January 15, 2013 [Page 10] Internet-Draft HA Initiated Flow Binding for Mobile IPv6 July 2012 Action This is a 8-bit field that describes the required processing for the option. It can be assigned one of the following new values: 11 Add a flow binding 12 Delete a flow binding 13 Modify a flow binding 14 Refresh a flow binding 15 Move a flow binding 16 Revoke a flow binding All the other values are reserved for future use 6.2.2. Target Care-of-Address sub-option This section introduces the Target Care-of-Address sub-option, which may be included in the Flow Identification Mobility Option. This sub-option is used to indicate the mobile node to move a flow binding from one interface to another. 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 4: Target Care-of-Address Sub-option Sub-opt Type To be assigned by IANA (IANA-TBD3) 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 The address of an interface that the flow is moved to. This address could be IPv4 or IPv6 address. This sub-option MUST be included when the action taken is "15 Move a flow binding". Yokota, et al. Expires January 15, 2013 [Page 11] Internet-Draft HA Initiated Flow Binding for Mobile IPv6 July 2012 7. Security Considerations Security issues for this document follow those of [RFC6088],[RFC6089] and [RFC5846]. This specification allows the home agent to manipulate only the binding of a flow(s) that is currently registered with it, which is the same principle described in [RFC5846]. No additional security issue specific to this document is identified. 8. Protocol constants Maximum FBI retries (MAX_FBI_RETRIES) This variable specifies the maximum number of times the HA MAY retransmit a Flow Binding Indication message when FBA is not returned within the time period specified by MAX_FBA_TIMEOUT. The default value for this parameter is 3. Maximum FBA timeout (MAX_FBA_TIMEOUT) This variable specifies the maximum time in seconds the HA MUST wait before retransmitting another FBI message. The default for this parameter is 3 seconds. 9. IANA considerations This document defines one new Mobility Header and two new mobility options to be used in Flow Binding Initiate and Flow Binding Acknowledge messages. A new Mobility Header Type and two new sub-opt type values (IANA-TBD1, IANA-TBD2 and IANA-TBD3) need to be assigned by IANA. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, June 2009. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC5846] Muhanna, A., Khalil, M., Gundavelli, S., Chowdhury, K., and P. Yegani, "Binding Revocation for IPv6 Mobility", RFC 5846, June 2010. Yokota, et al. Expires January 15, 2013 [Page 12] Internet-Draft HA Initiated Flow Binding for Mobile IPv6 July 2012 [RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont, "Traffic Selectors for Flow Bindings", RFC 6088, January 2011. [RFC6089] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G., and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support", RFC 6089, January 2011. 10.2. Informative references [RFC5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, "Multiple Care-of Addresses Registration", RFC 5648, October 2009. Yokota, et al. Expires January 15, 2013 [Page 13] Internet-Draft HA Initiated Flow Binding for Mobile IPv6 July 2012 Authors' Addresses Hidetoshi Yokota KDDI Lab 2-1-15 Ohara Fujimino Saitama, Japan 356-8502 Phone: Email: yokota@kddilabs.jp Dae-Sun Kim KDDI Lab 2-1-15 Ohara Fujimino Saitama, Japan 356-8502 Phone: Email: da-kim@kddilabs.jp Behcet Sarikaya Huawei USA 5340 Legacy Drive Building 3 Plano, TX 75024 Phone: +1 469-277-5839 Email: sarikaya@ieee.org Frank Xia Huawei USA 5430 Legacy Dr. Building 3 Plano, TX 75024 Phone: Email: xiayangsong@huawei.com Yokota, et al. Expires January 15, 2013 [Page 14]