< draft-cao-hiprg-flow-mobility-00.txt		draft-cao-hiprg-flow-mobility-01.txt >
	HIP Research Group Z. Cao		HIP Working Group Z. Cao
	Internet-Draft H. Deng		Internet-Draft H. Deng
	Intended status: Informational F. Cao		Intended status: Informational F. Cao
	Expires: September 7, 2011 China Mobile		Expires: January 12, 2012 China Mobile
	March 6, 2011		July 11, 2011
	HIP Extension for Flow Mobility Management		HIP Extension for Flow Mobility Management
	draft-cao-hiprg-flow-mobility-00		draft-cao-hiprg-flow-mobility-01
	Abstract		Abstract
	This document defines flow mobility extension to the Host Identity		This document defines flow mobility extension to the Host Identity
	Protocol (HIP). A multi-homed HIP host makes the binding of a flow		Protocol (HIP). A multi-homed HIP host makes the binding of a flow
	and one or more locators, through the new parameter "E-LOCATOR",		and one or more locators, through the new parameter "E-LOCATOR",
	which is the extension of "LOCATOR" defined in RFC5206, the host can		which is the extension of "LOCATOR" defined in RFC5206, the host can
	acknowledgement his peers with addresses available that fit for some		acknowledgement his peers with addresses available that fit for some
	traffic flow. Peer hosts then selects the most appropriate address		traffic flow. Peer hosts then selects the most appropriate address
	to transfer the traffic flow.		to transfer the traffic flow.
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 37 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on September 7, 2011.		This Internet-Draft will expire on January 12, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 4		2.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3.1. Flow binding . . . . . . . . . . . . . . . . . . . . . . . 4		3. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 5
	3.2. Base Exchange . . . . . . . . . . . . . . . . . . . . . . 5		3.1. Flow binding . . . . . . . . . . . . . . . . . . . . . . . 5
	3.3. Flow Mobility . . . . . . . . . . . . . . . . . . . . . . 6		3.2. Base Exchange . . . . . . . . . . . . . . . . . . . . . . 6
	3.3.1. Readdress without Rekey . . . . . . . . . . . . . . . 6		3.3. Flow Mobility . . . . . . . . . . . . . . . . . . . . . . 7
	3.3.2. Readdress with Multi-homed-Initiated Rekey . . . . . . 7		3.3.1. Readdress without Rekey . . . . . . . . . . . . . . . 7
	3.3.3. Load balance . . . . . . . . . . . . . . . . . . . . . 7		3.3.2. Readdress with Multi-homed-Initiated Rekey . . . . . . 8
	4. E-Locator Definition . . . . . . . . . . . . . . . . . . . . . 9		3.3.3. Load balance . . . . . . . . . . . . . . . . . . . . . 8
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 10		4. E-Locator Definition . . . . . . . . . . . . . . . . . . . . . 10
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	7. Normative References . . . . . . . . . . . . . . . . . . . . . 10		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10		7. Normative References . . . . . . . . . . . . . . . . . . . . . 11
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
	1. Introduction		1. Introduction
	The Host Identity Protocol (HIP) [RFC4423] uses a new identity, named		The Host Identity Protocol (HIP) [RFC4423] uses a new identity, named
	host identities, instead of IP addresses, as host identities.		host identities, instead of IP addresses, as host identities.
	Packets between two HIP hosts are forwarded by IP addresses but		Packets between two HIP hosts are forwarded by IP addresses but
	identified by the host identities. Thereby when the IP address of a		identified by the host identities. Thereby when the IP address of a
	host is changed, the connections between the host and its peers can		host is changed, the connections between the host and its peers can
	be sustained. [RFC5206] encompasses messaging and elements of		be sustained. [RFC5206] encompasses messaging and elements of
	procedure for basic network-level mobility and simple multihoming. A		procedure for basic network-level mobility and simple multihoming. A
	skipping to change at page 4, line 28 ¶		skipping to change at page 4, line 28 ¶
	transferred; during the conversation, caused by IP address changing		transferred; during the conversation, caused by IP address changing
	or in order to realize load balance, due to some mechanism, the		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		multi-homed host may redirect some exiting flows with its peer from a
	previous interface or address to a new interface or address.		previous interface or address to a new interface or address.
	These situations are typical flow mobility scenarios. In these		These situations are typical flow mobility scenarios. In these
	scenarios, there is a need for some helper functionality in the		scenarios, there is a need for some helper functionality in the
	network, such as a HIP rendezvous server [RFC5204]. Such		network, such as a HIP rendezvous server [RFC5204]. Such
	functionality is out of the scope of this document.		functionality is out of the scope of this document.
			2.1. Example
			Figure 1 is an example. Suppose the MN has two interfaces, one is
			the cellular interface, and the other is the WLAN interface. In the
			beginning, there are two connections between the MN and CN, one is
			the VOIP connection, and the other is FTP connection, both running on
			the cellular interface. When WLAN becomes available, the MN only
			wants moves the data intensive flows to the new locator, for cost
			efficient and load balancing. So it is desirable that the MN can
			notify the CN about the flow granularity information in the mobility
			signaling.
			+-------+
			/| Base |\VOIP
			/ |Station| \
			+----------+/ /+-------+\ \
			| +---+/ / FTP\ \ ___________
			| |IF0||/ \ \ / \
			| +---+| \ \---/ \-----------+-------+
			|MN +---+| \===( Internet )==========| CN |
			| |IF1|| ___( )__________| |
			| +---+\ / \ / +-------+
			| |\ / \___________/
			+----------+ \ /
			\+-------+ /
			| AP |/
			+-------+
			Figure 1: An Example
	3. Protocol Operations		3. Protocol Operations
	This protocol is based on "End-Host Mobility and Multihoming with the		This protocol is based on "End-Host Mobility and Multihoming with the
	Host Identity Protocol" [RFC5206] .		Host Identity Protocol" [RFC5206] .
	This section introduces the solution of flow mobility. Using the		This section introduces the solution of flow mobility. Using the
	parameters "E-LOCATOR" introduced in this specification, a multi-		parameters "E-LOCATOR" introduced in this specification, a multi-
	homed HIP host can notify peers about alternate addresses with		homed HIP host can notify peers about alternate addresses with
	corresponding flow mobility option; a flow can be identified by a FID		corresponding flow mobility option; a flow can be identified by a FID
	in the mobility option. We can assume this as flow binding. Then		in the mobility option. We can assume this as flow binding. Then
	skipping to change at page 6, line 35 ¶		skipping to change at page 7, line 32 ¶
	Mobile Host Peer Host		Mobile Host Peer Host
	UPDATE(ESP_INFO, E-LOCATOR, SEQ)		UPDATE(ESP_INFO, E-LOCATOR, SEQ)
	-----------------------------------v		-----------------------------------v
	UPDATE(ESP_INFO, SEQ, ACK, ECHO_REQUEST)		UPDATE(ESP_INFO, SEQ, ACK, ECHO_REQUEST)
	v-----------------------------------		v-----------------------------------
	UPDATE(ACK, ECHO_RESPONSE)		UPDATE(ACK, ECHO_RESPONSE)
	-----------------------------------v		-----------------------------------v
	Figure 1: Readdress without Rekey		Figure 2: Readdress without Rekey
	According to RFC5206, during the procedure of readdressing, hosts can		According to RFC5206, during the procedure of readdressing, hosts can
	use the old SAs or create new SAs. The first example considers the		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		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		are within the same address family (Ipv4 or Ipv6) as the first
	address. The scenario is depicted in Figure 1.		address. The scenario is depicted in Figure 2.
	1. The multi-homed host is disconnected from the peer host for a		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		short period of time while it switches from one IP address to
	another. Upon obtaining a new IP address, the multi-homed host		another. Upon obtaining a new IP address, the multi-homed host
	sends an E-LOCATOR parameter to the peer host in an UPDATE		sends an E-LOCATOR parameter to the peer host in an UPDATE
	message. The same FID as existing flow must be included with the		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		new locator. Set of ESP_INFO and SEQ parameters are the same as
	RFC5206 3.2.1 depicts.		RFC5206 3.2.1 depicts.
	2. When the peer host receives the UPDATE message, it performs as		2. When the peer host receives the UPDATE message, it performs as
	RFC5206 3.2.1 depicts.		RFC5206 3.2.1 depicts.
	3. The multi-homed host completes the readdress by processing the		3. The multi-homed host completes the readdress by processing the
	UPDATE ACK and echoing the nonce in an ECHO_RESPONSE. Once the		UPDATE ACK and echoing the nonce in an ECHO_RESPONSE. Once the
	peer host receives this ECHO_RESPONSE, it considers the new		peer host receives this ECHO_RESPONSE, it considers the new
	address to be verified and can put the address into full use.		address to be verified and can put the address into full use.
	4. The existing ESP traffic flow is transferred to the new address.		4. The existing ESP traffic flow is transferred to the new address.
	3.3.2. Readdress with Multi-homed-Initiated Rekey		3.3.2. Readdress with Multi-homed-Initiated Rekey
	If the Multi-homed host decide to rekey the SAs at the same time that		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		it notifies the peer of the new address. In this case, the above
	procedure described in Figure 2 is slightly modified. The UPDATE		procedure described in Figure 3 is slightly modified. The UPDATE
	message sent from the Multi-homed host includes an ESP_INFO with the		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		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.		SPI value for the incoming SA, and the KEYMAT Index desired.
	Optionally, the host may include a DIFFIE_HELLMAN parameter for a new		Optionally, the host may include a DIFFIE_HELLMAN parameter for a new
	Diffie- Hellman key. The peer completes the request for a rekey as		Diffie- Hellman key. The peer completes the request for a rekey as
	is normally done for HIP rekeying, except that the new address is		is normally done for HIP rekeying, except that the new address is
	kept as UNVERIFIED until the UPDATE nonce challenge is received as		kept as UNVERIFIED until the UPDATE nonce challenge is received as
	described above. Figure 2 illustrates this scenario.		described above. Figure 3 illustrates this scenario.
	Mobile Host Peer Host		Mobile Host Peer Host
	UPDATE(ESP_INFO, E-LOCATOR, SEQ, [DIFFIE_HELLMAN])		UPDATE(ESP_INFO, E-LOCATOR, SEQ, [DIFFIE_HELLMAN])
	-----------------------------------v		-----------------------------------v
	UPDATE(ESP_INFO, SEQ, ACK, [DIFFIE_HELLMAN,] ECHO_REQUEST)		UPDATE(ESP_INFO, SEQ, ACK, [DIFFIE_HELLMAN,] ECHO_REQUEST)
	v-----------------------------------		v-----------------------------------
	UPDATE(ACK, ECHO_RESPONSE)		UPDATE(ACK, ECHO_RESPONSE)
	-----------------------------------v		-----------------------------------v
	Figure 2: Readdress with Multi-homed-Initiated Rekey		Figure 3: Readdress with Multi-homed-Initiated Rekey
	3.3.3. Load balance		3.3.3. Load balance
	/ peer1 / peer1		/ peer1 / peer1
	IP1 +- peer2 IP1 +		IP1 +- peer2 IP1 +
	/(FIDx)\ peer3 /(FIDx)\ peer2		/(FIDx)\ peer3 /(FIDx)\ peer2
	Multi- / ---> Multi-homed /		Multi- / ---> Multi-homed /
	homed \ Host \		homed \ Host \
	Host \ \		Host \ \
	\ \		\ \
	IP2 IP2 -- peer3		IP2 IP2 -- peer3
	(FIDx) (FIDx)		(FIDx) (FIDx)
	Figure 3: Load Balance		Figure 4: Load Balance
	Mobile Host Peer 3		Mobile Host Peer 3
	UPDATE(ESP_INFO, E-LOCATOR, SEQ, [DIFFIE_HELLMAN])		UPDATE(ESP_INFO, E-LOCATOR, SEQ, [DIFFIE_HELLMAN])
	-----------------------------------v		-----------------------------------v
	UPDATE(ESP_INFO, SEQ, ACK, [DIFFIE_HELLMAN,] ECHO_REQUEST)		UPDATE(ESP_INFO, SEQ, ACK, [DIFFIE_HELLMAN,] ECHO_REQUEST)
	v-----------------------------------		v-----------------------------------
	UPDATE(ACK, ECHO_RESPONSE)		UPDATE(ACK, ECHO_RESPONSE)
	-----------------------------------v		-----------------------------------v
	Figure 4: Flow Redirection		Figure 5: Flow Redirection
	Considering the scenario that the multi-homed host has two address		Considering the scenario that the multi-homed host has two address
	IP1, I23, which both are suitable for transferring flow X, identified		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		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		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-		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		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		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		message, and there is only one locator, carries IP3 with FIDx option
	in the parameter. Once receiving the UPDATE message, since there is		in the parameter. Once receiving the UPDATE message, since there is
	only one address available for FIDx, Peer3 redirects the flow X to		only one address available for FIDx, Peer3 redirects the flow X to
	IP3. The scenario is depicted as Figure 3. There must be policies		IP3. The scenario is depicted as Figure 4. There must be policies
	for a multi-homed host to decide when to redirect the flow and which		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		address is redirected to, the policies are out scope of this
	document.		document.
	4. E-Locator Definition		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		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 |		| Type | Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 9, line 43 ¶		skipping to change at page 10, line 43 ¶
	| |		| |
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| FLOW MOBILITY IDENTIFICATION OPTION |		| FLOW MOBILITY IDENTIFICATION OPTION |
	| |		| |
	| |		| |
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 5: E-Locator		Figure 6: E-Locator
	F Flag		F Flag
	A new flag, when the locator carries a corresponding flow		A new flag, when the locator carries a corresponding flow
	identification mobility option, it is set to 1; otherwise it is set		identification mobility option, it is set to 1; otherwise it is set
	to 0, that means the locator is suitble for all flow;		to 0, that means the locator is suitble for all flow;
	Flow Identification Mobility Option: as defined in [RFC6089]		Flow Identification Mobility Option: as defined in [RFC6089]
	5. Security Considerations		5. Security Considerations
End of changes. 16 change blocks.
	27 lines changed or deleted		57 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/