HIP Research Group Z. Cao
Internet-Draft H. Deng
Intended status: Informational F. Cao
Expires: September 7, 2011 China Mobile
March 6, 2011
HIP Extension for Flow Mobility Management
draft-cao-hiprg-flow-mobility-00
Abstract
This document defines flow mobility extension to the Host Identity
Protocol (HIP). A multi-homed HIP host makes the binding of a flow
and one or more locators, through the new parameter "E-LOCATOR",
which is the extension of "LOCATOR" defined in RFC5206, the host can
acknowledgement his peers with addresses available that fit for some
traffic flow. Peer hosts then selects the most appropriate address
to transfer the traffic flow.
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 September 7, 2011.
Copyright Notice
Copyright (c) 2011 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
Cao, et al. Expires September 7, 2011 [Page 1]
Internet-Draft HIP Flow Mobility March 2011
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. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 4
3.1. Flow binding . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Base Exchange . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Flow Mobility . . . . . . . . . . . . . . . . . . . . . . 6
3.3.1. Readdress without Rekey . . . . . . . . . . . . . . . 6
3.3.2. Readdress with Multi-homed-Initiated Rekey . . . . . . 7
3.3.3. Load balance . . . . . . . . . . . . . . . . . . . . . 7
4. E-Locator Definition . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Normative References . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Cao, et al. Expires September 7, 2011 [Page 2]
Internet-Draft HIP Flow Mobility March 2011
1. Introduction
The Host Identity Protocol (HIP) [RFC4423] uses a new identity, named
host identities, instead of IP addresses, as host identities.
Packets between two HIP hosts are forwarded by IP addresses but
identified by the host identities. Thereby when the IP address of a
host is changed, the connections between the host and its peers can
be sustained. [RFC5206] encompasses messaging and elements of
procedure for basic network-level mobility and simple multihoming. A
general "LOCATOR" parameter for HIP messages that allows for a HIP
host to notify peers about alternate addresses at which it is
reachable is defined. The LOCATORs may be merely IP addresses, or
they may have additional multiplexing and demultiplexing context to
aid the packet handling in the lower layers.
To enable the traffic control, HIP could be extended to support the
flow mobility. This document extends LOCATOR to support end-to-end
flow mobility of HIP. The extended LOCATOR, named as E-LOCATOR,
includes locators defined in RFC5206 and a flow identifier mobility
option, which defines the flow that is suitable transferred through
the corresponding locator. The detail format of E-LOCATOR is
described in Section 4.
The motivations to do HIP flow mobility include:
o Enable the flow mobility in HIP. That means flow can be
transferred through the most appropriate interface or redirected
to a better interface or address according to some factors, such
as address enable situations, user preference and operator policy,
etc.
o Enable the load sharing. The traffic to a certain interface of
host can be distributed among different interfaces. When the
resource of one connection is limited, other interfaces can be
used to help deliver the data together.
A flow is defined as a set of IP packets matching a traffic selector.
A traffic selector can identify the source and destination IP
addresses, transport protocol number, the source and destination port
numbers and other fields in IP and higher layer headers. For more
flow information, please refer to [RFC6089].
2. Scenarios
End-to-end flow mobility is important to HIP multihoming. The
traffic control, charging, QoS control and other operations can be
operated based on flow.
Cao, et al. Expires September 7, 2011 [Page 3]
Internet-Draft HIP Flow Mobility March 2011
A host that has one interface with multiple addresses, or a host that
has multiple interfaces, each interface has a separate address are
both multi-homed HIP hosts. It is envisioned that a multi-homed host
can use several addresses simultaneously to transfer flows.
When different addresses are used simultaneously to transfer flows,
first there must be policies in the multi-homed host about deciding a
flow to be transferred through a certain address; we call this as
flow binding. Then end-to-end address chosen and readdress are both
necessary. Before a communication, the multi-homed host should be
able to inform its peer about the reachable addresses, with the
corresponding flow binding; peers should be able to choose the most
suitable address for communication according to the flow going to be
transferred; during the conversation, caused by IP address changing
or in order to realize load balance, due to some mechanism, the
multi-homed host may redirect some exiting flows with its peer from a
previous interface or address to a new interface or address.
These situations are typical flow mobility scenarios. In these
scenarios, there is a need for some helper functionality in the
network, such as a HIP rendezvous server [RFC5204]. Such
functionality is out of the scope of this document.
3. Protocol Operations
This protocol is based on "End-Host Mobility and Multihoming with the
Host Identity Protocol" [RFC5206] .
This section introduces the solution of flow mobility. Using the
parameters "E-LOCATOR" introduced in this specification, a multi-
homed HIP host can notify peers about alternate addresses with
corresponding flow mobility option; a flow can be identified by a FID
in the mobility option. We can assume this as flow binding. Then
the peers can select the most suitable address as the communication
address. During the communication, when the using address is changed
or in order to make load balance, the multi-homed host can redirect
the existing flows to other addresses by using E-LOCATOR.
3.1. Flow binding
It is assumed that there should be some policies of flow binding. A
flow binding in the multi-homed host is about a flow to be
transferred through a certain address. In E-LOCATOR, a locator is
followed by a "Flow Identification Mobility Option", which means flow
with FID in the option is going to be transferred through the
locator. The details of these policies are outside the scope of this
document.
Cao, et al. Expires September 7, 2011 [Page 4]
Internet-Draft HIP Flow Mobility March 2011
In this document, a host with HIP protocol that initializes a
connection is Initiator; its peer host is Responder[RFC4423].
3.2. Base Exchange
Assuming that the Responder host has multiple addresses available at
begin of the communication with its peer. When Initiator initializes
the Base Exchange, a Responder host may include an E-LOCATOR
parameter in the R1 packet that it sends to the Initiator. This
parameter MUST be protected by the R1 signature.
The procedure of Base Exchange with RVS is followed:
1. First of all, Responder registers a RVS service with a RVS
server; its current available IP addresses are maintained by the
RVS.
2. An Initiator initializes the Base Exchange. First, it sends I1
packet with Initiator's and may be Responder's HIT, to the RVS,
with which the Responder registers. The source IP address of I1
is Initiator's IP address. The destination IP address of I1 is
RVS's IP address that can be got from a DNS server or other
servers.
3. Then the RVS found that I1 is aimed to the Responder, so it
updates the head of I1 packet and forwards it to the Responder.
The source IP address of I1 is RVS's IP address. The destination
address is currently available IP address of the Responder
[RFC5204].
4. After authentication, the Responder sends R1 packet to the
Initiator; an E-LOCATOR parameter is included in R1. This
parameter is protected by the R1 signature. Currently available
IP addresses of the Responder with corresponding flow are list in
E-LOCATOR.
5. When the Initiator gets the R1 packet, according to the flow that
to be transferred, it chooses the most suitable address among the
entire addresses list in the E-LOCATOR, that is to say, choose
the locator with the FID the same as the flow to be transferred.
If there is only one locator in the parameter, then the Initiator
chooses it as the communication address. If there is no locator
with the corresponding flow, then the Initiator may choose the
preferred locator to use. The Initiator should set the status as
ACTIVE once an address has been determined and send the I2 packet
to the new choose address. The I1 destination address and the
new choose address may be identical. All new other locators must
still undergo address verification once the Base Exchange
completes [RFC5206].
During the Base Exchange, as the Initiator knows what kind of flow is
to be transferred, it can make its most suitable address as the
Cao, et al. Expires September 7, 2011 [Page 5]
Internet-Draft HIP Flow Mobility March 2011
source address. The Initiator may include one or more E-LOCATOR
parameters in the I2 packet, independent of whether or not there was
a E-LOCATOR parameter in the R1. These parameters must be protected
by the I2 signature. Even if the I2 packet contains E-LOCATOR
parameters, the Responder must still send the R2 packet to the source
address of the I2. The new choosing address by the Responder should
be identical to the I2 source address. If the I2 packet contains
E-LOCATOR parameters, all new locators must undergo address
verification as usual, and the ESP traffic that subsequently follows
should use the addresses determined during the Base Exchange.
3.3. Flow Mobility
When a multi-homed host moves to a new place, the available address
may be changed or there may be a new address available and the new
address is more suitable for the existing flow, the multi-homed host
can send UPDATE message to its peer to inform the new available or
new more suitable address and then redirect the existing flow to the
new address.
3.3.1. Readdress without Rekey
Mobile Host Peer Host
UPDATE(ESP_INFO, E-LOCATOR, SEQ)
-----------------------------------v
UPDATE(ESP_INFO, SEQ, ACK, ECHO_REQUEST)
v-----------------------------------
UPDATE(ACK, ECHO_RESPONSE)
-----------------------------------v
Figure 1: Readdress without Rekey
According to RFC5206, during the procedure of readdressing, hosts can
use the old SAs or create new SAs. The first example considers the
case in which no rekeying occurs on the SAs and the new IP address
are within the same address family (Ipv4 or Ipv6) as the first
address. The scenario is depicted in Figure 1.
1. The multi-homed host is disconnected from the peer host for a
short period of time while it switches from one IP address to
another. Upon obtaining a new IP address, the multi-homed host
sends an E-LOCATOR parameter to the peer host in an UPDATE
message. The same FID as existing flow must be included with the
new locator. Set of ESP_INFO and SEQ parameters are the same as
RFC5206 3.2.1 depicts.
Cao, et al. Expires September 7, 2011 [Page 6]
Internet-Draft HIP Flow Mobility March 2011
2. When the peer host receives the UPDATE message, it performs as
RFC5206 3.2.1 depicts.
3. The multi-homed host completes the readdress by processing the
UPDATE ACK and echoing the nonce in an ECHO_RESPONSE. Once the
peer host receives this ECHO_RESPONSE, it considers the new
address to be verified and can put the address into full use.
4. The existing ESP traffic flow is transferred to the new address.
3.3.2. Readdress with Multi-homed-Initiated Rekey
If the Multi-homed host decide to rekey the SAs at the same time that
it notifies the peer of the new address. In this case, the above
procedure described in Figure 2 is slightly modified. The UPDATE
message sent from the Multi-homed host includes an ESP_INFO with the
OLD SPI set to the previous SPI, the NEW SPI set to the desired new
SPI value for the incoming SA, and the KEYMAT Index desired.
Optionally, the host may include a DIFFIE_HELLMAN parameter for a new
Diffie- Hellman key. The peer completes the request for a rekey as
is normally done for HIP rekeying, except that the new address is
kept as UNVERIFIED until the UPDATE nonce challenge is received as
described above. Figure 2 illustrates this scenario.
Mobile Host Peer Host
UPDATE(ESP_INFO, E-LOCATOR, SEQ, [DIFFIE_HELLMAN])
-----------------------------------v
UPDATE(ESP_INFO, SEQ, ACK, [DIFFIE_HELLMAN,] ECHO_REQUEST)
v-----------------------------------
UPDATE(ACK, ECHO_RESPONSE)
-----------------------------------v
Figure 2: Readdress with Multi-homed-Initiated Rekey
3.3.3. Load balance
/ peer1 / peer1
IP1 +- peer2 IP1 +
/(FIDx)\ peer3 /(FIDx)\ peer2
Multi- / ---> Multi-homed /
homed \ Host \
Host \ \
\ \
IP2 IP2 -- peer3
(FIDx) (FIDx)
Figure 3: Load Balance
Cao, et al. Expires September 7, 2011 [Page 7]
Internet-Draft HIP Flow Mobility March 2011
Mobile Host Peer 3
UPDATE(ESP_INFO, E-LOCATOR, SEQ, [DIFFIE_HELLMAN])
-----------------------------------v
UPDATE(ESP_INFO, SEQ, ACK, [DIFFIE_HELLMAN,] ECHO_REQUEST)
v-----------------------------------
UPDATE(ACK, ECHO_RESPONSE)
-----------------------------------v
Figure 4: Flow Redirection
Considering the scenario that the multi-homed host has two address
IP1, I23, which both are suitable for transferring flow X, identified
by FIDx. Peer1 host and Peer2 both have flow X with multi-homed host
through IP1. A new flow X is started between multi-homed host and
Peer3, also using IP1. Then in order to make load balance, multi-
homed host decides to redirect flow X with Peer3 to IP3. It then
sends an UPDATE message to Peer 3. E-LOCAOR is included in the
message, and there is only one locator, carries IP3 with FIDx option
in the parameter. Once receiving the UPDATE message, since there is
only one address available for FIDx, Peer3 redirects the flow X to
IP3. The scenario is depicted as Figure 3. There must be policies
for a multi-homed host to decide when to redirect the flow and which
address is redirected to, the policies are out scope of this
document.
Cao, et al. Expires September 7, 2011 [Page 8]
Internet-Draft HIP Flow Mobility March 2011
4. E-Locator Definition
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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Type | Locator Type | Locator Length | Reserved |F|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FLOW MOBILITY IDENTIFICATION OPTION |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Type | Locator Type | Locator Length | Reserved |P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FLOW MOBILITY IDENTIFICATION OPTION |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: E-Locator
F Flag
A new flag, when the locator carries a corresponding flow
identification mobility option, it is set to 1; otherwise it is set
to 0, that means the locator is suitble for all flow;
Flow Identification Mobility Option: as defined in [RFC6089]
Cao, et al. Expires September 7, 2011 [Page 9]
Internet-Draft HIP Flow Mobility March 2011
5. Security Considerations
TBD.
6. IANA Considerations
This document does not require any IANA actions.
7. Normative References
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
(HIP) Architecture", RFC 4423, May 2006.
[RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Rendezvous Extension", RFC 5204, April 2008.
[RFC5205] Nikander, P. and J. Laganier, "Host Identity Protocol
(HIP) Domain Name System (DNS) Extensions", RFC 5205,
April 2008.
[RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End-
Host Mobility and Multihoming with the Host Identity
Protocol", RFC 5206, April 2008.
[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.
Authors' Addresses
Zhen Cao
China Mobile
28 Xuanwumenxi Ave,Xuanwu District
Beijing 100053
China
Email: zehn.cao@gmail.com
Cao, et al. Expires September 7, 2011 [Page 10]
Internet-Draft HIP Flow Mobility March 2011
Hui Deng
China Mobile
28 Xuanwumenxi Ave,Xuanwu District
Beijing 100053
China
Email: denghui@chinamobile.com
Feng Cao
China Mobile
28 Xuanwumenxi Ave,Xuanwu District
Beijing 100053
China
Email: fengcao@chinamobile.com
Cao, et al. Expires September 7, 2011 [Page 11]