Network Working Group M. Liu Internet Draft Y. Wang Intended status: Informational ICT, CAS Expires: March 27, 2014 September 27, 2013 Distributed Mobility Management: Service Flows Distribution and Handoff Technique based on MIPv6 draft-liu-dmm-flows-distribution-and-handoff-01 Abstract This document has a normative description of the service flow management technology based on mobile IPv6 (MIPv6). It makes the upgrade of management model in MIPv6 from the entire node granularity to the single service flow granularity. It proposes a distributed mobility management solution, DMIPv6, which is compatible with MIPv6 and takes different mobility management strategies according to the Correspondent Node's position, network conditions and service requirements of different service flows so as to achieve the service flow handoff and transmission path control. The standard also provides route optimization mechanism between the Mobile Node and the ordinary Correspondent Node that doesn't support mobile IPv6. 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), 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 March 27, 2014. Liu, et al. Expires March 27, 2014 [Page 1] Internet-Draft flows-distribution-and-handoff September 2013 Copyright Notice Copyright (c) 2013 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 1. Introduction ................................................... 2 2. Conventions used in this document .............................. 3 2.1. Conventions used in this document ......................... 3 2.2. Terminology ............................................... 3 3. Basic Framework ................................................ 4 4. Message Types .................................................. 5 4.1. Messages Between MN and HA ................................ 6 4.2. Messages Between MN and CN ................................ 6 4.3. DHP Query Message ......................................... 6 4.4. DHoA Request/Response Message .............................13 4.5. DHP Binding Update/Confirmation Message ...................15 5. DMIPv6 Workflow ................................................17 5.1. The Processing Workflow of New Service Connection .........17 5.2. The Processing Workflow when MN Moves .....................20 6. Security Considerations ........................................21 7. IANA Considerations ............................................21 8. References .....................................................22 8.1. Normative References ......................................22 8.2. Informative References ....................................22 Authors' Addresses ................................................23 1. Introduction This standard proposes a distributed mobility management protocol, DMIPv6, which is compatible with the standard mobile IPv6 protocol. DMIPv6 introduces Distributed Home-Proxy (DHP) and Distributed Home Liu, et al. Expires March 27, 2014 [Page 2] Internet-Draft flows-distribution-and-handoff September 2013 Address (DHoA) for a Mobile Node (MN) while there are Home Agent (HA) and Home-Of-Address (HoA) already. MN will use DMIPv6 proposed in this document if the DHP and DHoA are available, otherwise the standard mobile IPv6 is used. The deployment of the DMIPv6 could be implemented step by step, with the compatibility to the existing mobile IPv6. What's more, compared to the standard mobile IPv6 in management model,DMIPv6 could select different DHP for a MN's different service flows.MN takes different management strategy for different service flows according to network conditions and the actual requirements during the move. The introduction of DHP not only reduces the home network congestion and HA load, but also greatly reduces the possible failures in home network and HA, and the bad impacts to the MN. Besides, the MN could achieve optimized transmission path and transmission delay even choosing bidirectional tunnel, because the DHP is located close to the Correspondent Node (CN). For CN that is a server, the introduction of DHP makes it possible for it to enhance its mobility support for its clients without any updates of itself. 2. Conventions and Terminology 2.1. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. 2.2. Terminology All general mobility-related terms and their acronyms used in this document are to be interpreted as defined in the Mobility Support in IPv6 specification [RFC6275] and in the Proxy mobile IPv6 specification [RFC5213]. These terms include mobile node (MN), correspondent node (CN), home agent (HA), Care-of-Address (CoA), Home-of-Address (HoA), Binding Update (BU), and Binding Acknowledgement (BA). In addition, this document uses the following terms: Distributed Home-Proxy (DHP) is a router near CN, with the function for an extension of the HA, which assigns distributed home address for the MN, receives and forwards the packet between the MN and CN. It plays a role in router optimization and handoff management on service flow granularity. Liu, et al. Expires March 27, 2014 [Page 3] Internet-Draft flows-distribution-and-handoff September 2013 Distributed Mobile IPv6 (DMIPv6) is a distributed network layer mobility solution compatible with mobile IPv6, which would take different mobility management strategies according to the CN's position, network conditions and service requirements of different service flows so as to achieve the service flow handoff and transmission path control. And the standard will also provide route optimization mechanism between the MN and the ordinary CN that doesn't support mobile IPv6. Distributed Home Address (DHoA) is a home address that MN gets from the corresponding DHP for establishing a connection with CN so as to achieve the service flow handoff and transmission path control. 3. Basic Framework Distributed Mobile IPv6(DMIPv6), which is a distributed mobility management architecture compatible with Mobile IPv6, introduces Distributed Home-Proxy(DHP) to the existing Mobile IPv6 architecture. In DMIPv6, DHP can be deployed in subdomain of each network. DHP is implemented based on HA, and multiple DHPs independent of each other can be deployed in the same domain. The DHP is deployed the same style as the HA and general router. Under such condition, MN can select one or more DHPs according to the state of DHP and service demand. In general, one DHP is enough, but multiple DHPs can be selected to backup or improve concurrent performance. Figure 1 shows the basic architecture of DMIPv6: Liu, et al. Expires March 27, 2014 [Page 4] Internet-Draft flows-distribution-and-handoff September 2013 +------------+ +---------------------+ | +------+ | | +------+ +------+ | | | HA | |/---+ | | DHP1 | | CN1 | | | +------+ |\--+| | +------+ +------+ | |Home Domain | || | Domain 1 | +------------+ || +---------------------+ || /\ || || || || \/ \/ +---------------------+ | | | IPv6 Network | | | +---------------------+ /\ /\ || || || \/ +--------------+ || +---------------------+ | +------+ | || | +------+ +------+ | | | MN | |/--+| | | DHP2 | | CN2 | | | +------+ |\---+ | +------+ +------+ | |Foreign Domain| | Domain 2 | +--------------+ +---------------------+ Figure 1 Architecture of Service Flow Distribution and Handoff Management As Figure 1, there exists multiple independent DHPs in the CN network, and MN can selecte one of them as the proxy server. The introduction of DHP greatly decreases the MN's dependence on HA, and can also optimize the transmission path and transmission delay. When MN moves to a new link, the DHP can act as a proxy and forward the data for it. According to the deployment style and the available equipment's support to DMIPv6, MN will perform DMPv6 if the DHP and DHoA are available, otherwise the standard mobile IPv6 is used. 4. Message Types In this standard, majority of equipments need to complete a series of interactions to transmit information. The following messages are extended from the standard ICMPv6 messages. All extension types of the extended ICMP messages are different from those of standards defined by international organizations like IETF. If collisions occur in the future, values of corresponding message types should be adjusted according to the actual situation. Liu, et al. Expires March 27, 2014 [Page 5] Internet-Draft flows-distribution-and-handoff September 2013 4.1. Messages Between MN and HA Messages between MN and HA include binding update message (BU) sent when MN moves and binding acknowledgment messages (BA). This standard is compatible with standard mobile IPv6 protocol. For detailed information about the above messages, refer to the IETF RFC 6275. 4.2. Messages Between MN and CN Messages between MN and CN include binding update message (BU) sent when MN updates its CoA-address and binding acknowledgment messages (BA). This standard is compatible with standard mobile IPv6 protocol. For detailed information about the above messages, refer to the IETF RFC 6275. 4.3. DHP Query Message DHP query message is used by MN to perform the DHP query and selection operations. This standard proposes 3 kinds of DHP query method. Corresponding query methods are depicted as follow: 4.3.1. Dynamic DHP Discovery Query/Acknowledgement Message In this method, DHP query messages are sent to corresponding network to request response directly. This procedure is similar to "dynamic home agent address discovery mechanism" in MIPv6. When adopt this method, all DHPs in a common CN domain should maintain the status information of other DHPs, i.e. every DHP maintains a list of information about all DHPs in current domain. When comes to specific operation, MN query the DNS to get the DHP anycast address in the CN domain, and then send dynamic DHP discovery query message to that anycast address. According to the routing protocols, the topologically nearest DHP from the mobile node may receive the request message and then respond to it. Status information of all DHPs in the CN domain should be included in the reply message. MN can perform the HP selection based on this state information. This approach is the active query mode of MN. Liu, et al. Expires March 27, 2014 [Page 6] Internet-Draft flows-distribution-and-handoff September 2013 4.3.1.1. DHP Query 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 Dynamic DHP Discovery Query Message o Source address: IPv6 address of the interface sending this message o Destination address: anycast address of DHP in the CN domain o Hop limit: 255 o Authentication Header: sender should contain this header field when security association of IP authentication header present between sender and receiver. o ICMP fields: Type 160 Code 0 Checksum ICMP checksum Reserved Reserved for future use. The value must be initialized to zero by the sender, and must be ignored by the receiver. Liu, et al. Expires March 27, 2014 [Page 7] Internet-Draft flows-distribution-and-handoff September 2013 4.3.1.2. DHP Acknowledgement 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DHP Address 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Load | Process | CN-dist | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DHP Address 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DHP Status Info (same as above) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 Dynamic DHP Discovery Acknowledgement Message o Source address: IPv6 address of the interface sending this message o Destination address: IPv6 address of MN o Hop limit: 255 o Authentication Header: sender should contain this header field when security association of IP authentication header present between sender and receiver. Source address: IPv6 address of the interface sending this message o ICMP fields: Type 161 Code 0 Checksum ICMP checksum Reserved Reserved for future use. The value must be initialized to zero by the sender, and must be ignored by the receiver. Liu, et al. Expires March 27, 2014 [Page 8] Internet-Draft flows-distribution-and-handoff September 2013 o Options: Sender must contain following options in the request message: DHP proxy server address: local IPv6 address of the sender. This address should be a DHP network interface address. If there exists more than one DHP in current network domain, information of all DHPs should be sequentially contained in the options part. DHP status information: the current DHP state information should include load conditions, process capability, distance from CN and so on. 4.3.2. Multicast Request DHP Query/Acknowledgement Message Through this method, IP address and status information of DHP in the CN domain can be obtained by sending multicast request message. This method requires all DHPs from one CN domain form a multicast group, then share a multicast address. Firstly MN query the DNS to get the DHP multicast address in the CN domain, and then send query message to that multicast address. Since then, all DHPs in the multicast group will reply acknowledgement message to the MN which also contains DHP address and other status information. This also is a MN active query method. 4.3.2.1. DHP Query 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 Multicast Request DHP Query Message o Source address: IPv6 address of the interface sending this message o Destination address: DHP multicast address in the CN domain o Hop limit: 255 Liu, et al. Expires March 27, 2014 [Page 9] Internet-Draft flows-distribution-and-handoff September 2013 o Authentication Header: sender should contain this header field when security association of IP authentication header present between sender and receiver. o ICMP fields: Type 162 Code 0 Checksum ICMP checksum Reserved Reserved for future use. The value must be initialized to zero by the sender, and must be ignored by the receiver. 4.3.2.2. DHP Acknowledgement 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DHP Address 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Load | Process | CN-dist | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DHP Address 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DHP Status Info (same as above) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5 Multicast Request DHP Acknowledgement Message o Source address: IPv6 address of the interface sending this message o Destination address: IPv6 address of MN o Hop limit: 255 Liu, et al. Expires March 27, 2014 [Page 10] Internet-Draft flows-distribution-and-handoff September 2013 o Authentication Header: sender should contain this header field when security association of IP authentication header present between sender and receiver. o ICMP fields: Type 163 Code 0 Checksum ICMP checksum Reserved Reserved for future use. The value must be initialized to zero by the sender, and must be ignored by the receiver. o Options: Sender must contain following options in the request message: DHP proxy server address: local IPv6 address of the sender. DHP status information: state information of this machine, contains load conditions, process capability, distance from CN and so on. The distance here is as same as defined above. Depending on the routing protocols, it may be the number of hops or delay in the actual network topology. 4.3.3. Specific Server DHP Query/Response Message The DHP selection can also use special DHP management server to complete. In actual circumstances, we can set global DHP management server to maintain all the DHP status information in the real-time network. MN can use DNS to query the DHP management server's address, and then send the corresponding DHP query messages to the server, the server sends the request a timely response. In accordance with different handling ways of MN, these methods can be divided into two categories: active and passive queries. 4.3.3.1. Active Query In this way, the MN sends a request message to DHP management server, the server will send all of the information to the MN terminal, for MN itself to make a choice. It is called MN active query. Liu, et al. Expires March 27, 2014 [Page 11] Internet-Draft flows-distribution-and-handoff September 2013 4.3.3.1.1. DHP query message The DHP query message in this way is the same with the corresponding query message in 4.3.1, the difference is that the message type code is 164 and the destination address is DHP management server address. 4.3.3.1.2. DHP Query Response Message DHP query response message in this way is the same with the corresponding query response message in 4.3.1, the difference is that the message type code is 165 and the destination address is DHP management server address. 4.3.3.2. Passive Query Different from the above mentioned active query, in the passive way, the MN sends a request message to the DHP information management server, the request message further includes business type that MN initiate currently and other relevant requirements of DHP ( including the ability to handle, the size of the load, the routing hops requests and so on. According to the requirements of MN, DHP information management server complete DHP preferred choice for MN in predetermined rules , then the selected DHP information response to MN. The Message format is as below: 4.3.3.2.1. DHP Query 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Symbol | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Business Types | processing capability | load | routing | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | other requirements (for extended use) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6 Specific Server DHP Query Message o source address:IPv6 address of MN interface which send this message Liu, et al. Expires March 27, 2014 [Page 12] Internet-Draft flows-distribution-and-handoff September 2013 o destination address: DHP information management server address in CN domain o hop limit: 255 o authentication header: if exists Security Association of IP authentication header between sending and receiving peer , the sending peer should include this header field o ICMP field: type 164 code 0 checksum ICMP checksum. retained this field is not used. The sender must initialize it to 0, the recipient must ignore it. o Options: the sending node must contain the following options in the request message sent: MN business requirement description: include business type to be initiated, processing capability, load requirements and the routing request and so on, users can also make further needs customization expansion according to the actual situation. 4.3.3.2.2. DHP Query Response Message DHP query response message in this way is the same with the corresponding query response message in 4.3.2, the difference is that the message type code is 165 and the destination address is DHP management server address. In particular, the CN can act as a DHP management server if it makes some upgrades and extensions. For example, the CN needs to be able to receive the DHP routing announcements of its domain and record the relevant information, while the normal CN doesn't have this feature. 4.4. DHoA Request/Response Message After choosing DHP, MN needs to apply a specific DHoA from the selected DHP, which is completed by sending a message of DHoA application. Based on the domain prefix information and address generation algorithm, DHP generate the corresponding DHoA address, Liu, et al. Expires March 27, 2014 [Page 13] Internet-Draft flows-distribution-and-handoff September 2013 and then back the address information to the MN, message format is shown in Figure 7 and figure 8. 4.4.1. DHoA Application Message 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7 DHoA Request Message o source address:IPv6 address of MN interface which send this message o destination address: DHP information management server address in CN domain o hop limit: 255 o authentication header: if exists Security Association of IP authentication header between sending and receiving peer , the sending peer should include this header field o ICMP field: type 166 code 0 checksum ICMP checksum. retained this field is not used. The sender must initialize it to 0, the recipient must ignore it Liu, et al. Expires March 27, 2014 [Page 14] Internet-Draft flows-distribution-and-handoff September 2013 4.4.2. DHoA Request Response 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DHoA | +-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+ Figure 8 DHoA Request Response Message o source address:IPv6 address of MN interface which send this message o destination address: DHP information management server address in CN domain o hop limit: 255 o authentication header: if exists Security Association of IP authentication header between sending and receiving peer , the sending peer should include this header field o ICMP field: type 167 code 0 checksum ICMP checksum. retained this field is not used. The sender must initialize it to 0,the recipient must ignore it The transmitting node must contain the following options in the request message DHoA address: distributed by DHP for MN 4.5. DHP Binding Update/Confirmation Message In this standard, if the DHP service is enabled, then when MN moves, we need to judge whether to continue the current business, then make a DHP binding update for current CoA address. This binding update Liu, et al. Expires March 27, 2014 [Page 15] Internet-Draft flows-distribution-and-handoff September 2013 message format is similar with the binding update message of BU in MIPv6, but needs extend a byte to store the corresponding business flow port number in its message extension headerto distinguish different traffic flows. The message format is shown in Figure 9. Binding update confirm message between DHP and MN is the same with BA in MIPv6. The message format can be seen in IETF RFC6275. 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 Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|L|K| Retain | valid time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | mobile option | +-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Business flow attribute | | +-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+ Figure 9 DHP Binding Update Message o sequence number: same with the BU message regulations of standard MIPv6 o standard of related bits: same with the BU message regulations of standard MIPv6 o valid time: same with the BU message regulations of standard MIPv6 o retention o mobile options: same with the BU message regulations of standard MIPv6 o extension field o The sending nodes contains the following options in the request message: Business flow attribute, business port number when initiating business locally, used to identify a service flow between the host and the corresponding DHP. Liu, et al. Expires March 27, 2014 [Page 16] Internet-Draft flows-distribution-and-handoff September 2013 5. DMIPv6 Workflow This standard provides a distributed MIPv6 compatible solution named DMIPv6 which enables service flow distribution and handoff management. We assume that MN has already moved to foreign network from home network here, thus MN should has DHoA address and CoA address, or HoA address and CoA address if the DMIPv6 is unavailable. We introduce the main processing workflow of the technical proposal in this standard, with 2 steps: the processing procedure of the new service flows and the MN handoffs, which corresponds to the service flow distribution and mobility handoff management. 5.1. The Processing Workflow of New Service Connection It is the processing workflow in the DMIPv6 when there is a new service connection between MN and CN. The detailed procedure is introduced as follows, and the related message interaction diagram is introduced in Figure 10. The detailed message format is showed in Chapter 4. 5.1.1. The Decision of the Mobility Requirement of Service Flow MN decides whether the service flow needs mobility support according to the service type of the new connection request. The standard of this decision can refer to the requirement of the MN itself and set the decision rule in advance: If MN decides that the service flow needs mobility support, then it goes to section 5.1.2; or MN will use the old CoA address to establish the connection with CN. 5.1.2. The Requirement Decision Started by the New Connection Mobile nodes decides whether the new connection request is started by the local MN, if it is then MN goes to section 5.1.3; or MN uses HoA address to establish the connection with CN. 5.1.3. DHP Query MN queries the DHP address and status of CN's network for its service flow, and there are 4 ways to realize the DHP query, which can be found in section 4.3. Figure 10 provides the message interaction diagram for different ways of query. Figure 10(a) is for the query of dynamic discovery and multicast request in section 4.3.1 and 4.3.2. Figure 10(b) is for the query which introduces DHP management server or uses CN in section 4.3.3 and 4.3.4. Liu, et al. Expires March 27, 2014 [Page 17] Internet-Draft flows-distribution-and-handoff September 2013 5.1.4. DHP Selection After the DHP query, MN needs to make the DHP selection. For the active query introduced in section 4.3, MN will decide which DHP serves itself according to different targets. The actual decision can be made in MN in advance, such as the distance to CN, processing ability, related workload information, etc. As for the passive query, MN can directly achieve the DHP address and the corresponding information. Besides, during the process procedure of this standard, DHP always knows MN's location information and must ensure to avoid MN's information disclosure. As a result, the DHP selection introduces the selection of DHP's security mechanism. Each DHP will make its security warranty as one of the most important status information and can provide hierarchical classification on occasion. As for the active query in section 4.3, MN can decide to select which security level of DHP to serve it; as for the passive query, MN needs the related management server to make selection policy and directly achieve the related information. It is preferred that these security requirements are considered as an integral part of the DMM design. 5.1.5. DHoA Address Application MN will send the corresponding address application message to the DHP after deciding which DHP serves it. DHP can create the required DHoA message according to the address creation algorithm and local prefix information, and then inform the MN of this DHoA. At the same time, it will bind the allocated DHoA with MN's current address. 5.1.6. Establishing the Communication Connection MN uses the queried DHoA to establish the connection with CN, and at the same time, DHP will save the information of DHoA and MN's address. It maintains a mapping table of the DHoA, MN and a service connection, and this mapping table is used for the management of mobility handoff. A notice is that, MN will use HoA to establish the connection with CN if the DHP query is failed in DHP, which means no DHP is found to serve the current MN. Later workflow is the same as that defined in MIPv6. 5.1.7. Confirming the Communication Mode MN needs to decide whether to use routing optimization mode or bi- direction tunneling mode according to the situation how CN supports the routing optimization. MN will use routing optimization mode for Liu, et al. Expires March 27, 2014 [Page 18] Internet-Draft flows-distribution-and-handoff September 2013 the CN which supports routing optimization; or it will use the bi- direction tunneling mode. After confirming the communication mode, MN will start data transmission with CN. +--+ +----+ +----+ +--+ |MN| |DHP1| |DHP2| |CN| +--+ +----+ +----+ +--+ | | | | [DHP Discovery] | | | |DHP query/response message | | | |<--------------------------->| | | | | | | | DHP query/response message | | |<--------------------------------------------->| | | | | | [DHP select] | | | |DHoA request/response message| | | |<--------------------------->| | | | | | | [connection established] | | | |DMIPv6 tunnel | data packets | |=============================|<-------------------------------->| (a) +--+ +------------------------+ +----+ +--+ |MN| |DHP management server/CN| |DHP | |CN| +--+ +------------------------+ +----+ +--+ | | | | [DHP Discovery] | | | |DHP query/response message | | | |<--------------------------->| | | | | | | [DHP select] | | | |DHoA request/response message| | | |<--------------------------->| | | | | | | | DHP query/response message | | |<--------------------------------------------->| | | | | [connection established] | | |DMIPv6 tunnel | data packets | |===============================================|<-------------->| (b) Liu, et al. Expires March 27, 2014 [Page 19] Internet-Draft flows-distribution-and-handoff September 2013 Figure 10 New Service Connect Message interaction 5.2. The Processing Workflow when MN Moves In the communication between MN and CN, when MN moves, first need to judge whether the DHP has been enabled. For the enabled DHP, to carry on the following steps, otherwise according to the standard MIPv6 protocol to execute. 5.2.1. The Qos Conditions Identification of A New Access Network MN According to the Qos condition of a new access network, business priorities and the Qos requirement to judge whether the Qos requirement has been satisfied and whether the business should be continue. Specific we can achieve the condition of network interface, topology-aware, business flow parameter estimation of available bandwidth measurement, network packet loss rate and throughput to implement the requirement. 5.2.2. Handoff Management For the service streams need to continue communication, will perform the following operations: 1. MN bind the CoA address and the port of the flow with the selected DHP. 2. DHP Replies binding update confirmation. 3. DHP performs proxy functions, intercepts the packets of CN sent to the MN existing home network, through the establishment of the tunnel DHP sent the packets to the new access network of MN. 4. For the CN of supporting the route optimization function, MN binds the new CoA address with CN, begin to communicate with CN until the CN's reply has been accepted. For the CN of not supporting the route optimization function, MN will carry on communication and transmission by bidirectional tunnel. For the service streams that don't need to continue communication and Qos has no requirement. MN will stop the flow and will not bind the new CoA address with DHP. For different businesses, MN can take different interrupt. Specifically, according to different transport layer protocols, and Liu, et al. Expires March 27, 2014 [Page 20] Internet-Draft flows-distribution-and-handoff September 2013 its own characteristics MN will take different message exchange or notification. 6. Security Considerations This standard is compatible with MIPv6, in the meantime, DHP equipments are added to it. Its basic procedures and messages exchanging schemes are similar to MIPv6, which lead to similar security issues like MIPv6's, including the security of dynamic DHP discovery, addresses binding and tunnels setting up between MN, HA, and CN. Detailed information in IETF RFC 6275. This standard is compliant with standard MIPv6, which means MN still has HoA in home domain. When MN is initiating a new connection with DMIPv6, it will first apply for DHoA. According to MIPv6, MN's HoA is permanent during in its travelling, so CN always knows its HoA. So CN will see MN travel from home domain to network with same prefix like DHoA. In addition, DHP is commonly in CN's domain and is close to CN, so CN will identify that MN has already moved to place near itself. In the whole process, CoA is hidden from CN, which avoid some security risks to some extensions. In the standard, DMIPv6 will be chosen when MN initates connection first. So, if there are random or periodic pseudo-connections, the process of DHP lookup and DHoA application will be triggered, which will impose heavy burden on MN and DHP. In fact, it's likely that from trojans and hackers' attacks. Under such circumstance, MN should use secured authentication to limit the number of pseudo-connections, and set bidirectional security mechanisms in DHP. When DMIPv6 is turned on, DHP will always know MN's location, and can send the information to third parties, while those requests for location may be ill-intended. So, DHP needs to build enough security mechanisms to guard MN's information. Whether DHP has security mechanisms will be an important condition in MN's inqury to DHP. Detailed information see 5.1.4. 7. IANA Considerations This document proposes 4 DHP query methods, and 8 message types totally for them: o The Dynamic DHP Discovery Query Message, and the Dynamic DHP Discovery Acknowledgement Message, described in Section 4.3.1 o The Multicast Request DHP Query Message, and the Multicast Request DHP Acknowledgement Message, described in Section 4.3.2 Liu, et al. Expires March 27, 2014 [Page 21] Internet-Draft flows-distribution-and-handoff September 2013 o The Specific Server DHP Query Message, in Section 4.3.3.1.2 o The DHoA Request Message, in Section 4.4.1 o The DHoA Request Response Message, in Section 4.4.2 o The DHP Binding Update Message, in Section 4.5 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S., "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, November 1997. [RFC4862] Thomson, S., Narten, T. and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. [RFC5944] Perkins, Ed., C., "IP Mobility Support for IPv4, Revised", RFC 5944, November 2010. [RFC6275] Perkins, Ed., C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011. [RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility Management", RFC 5380, October 2008. 8.2. Informative References [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [RFC5026] Giaretta, G. Kempf, J. and V. Devarapalli, "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026, Oct 2007. [NTMS2008]Bertin, P., "A Distributed Dynamic Mobility Management Scheme designed for Flat IP Architectures.", NTMS'2008, November 2008. [I-D. yokota-dmm-scenario] Liu, et al. Expires March 27, 2014 [Page 22] Internet-Draft flows-distribution-and-handoff September 2013 Yokota, H., Seite, P., Demaria, E., and Z. Cao, "Use case scenarios for Distributed Mobility Management", draft- yokota-dmm-scenario-00 (work in progress), October 2010. Authors' Addresses Min Liu Institute of Computing Technology, Chinese Academy of Sciences, No.6 Kexueyuan South Avenue, Zhongguancun, Beijing 100190, China Email: liumin@ict.ac.cn Yuwei Wang Institute of Computing Technology, Chinese Academy of Sciences, No.6 Kexueyuan South Avenue, Zhongguancun, Beijing 100190, China Email: wangyuwei@ict.ac.cn Liu, et al. Expires March 27, 2014 [Page 23]