Internet DRAFT - draft-liu-dmm-flows-distribution-and-handoff
draft-liu-dmm-flows-distribution-and-handoff
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]
