draft-ietf-dmm-mag-multihoming-00.txt		draft-ietf-dmm-mag-multihoming-01.txt
	DMM WG P. Seite		DMM WG P. Seite
	Internet-Draft Orange		Internet-Draft Orange
	Intended status: Standards Track A. Yegin		Intended status: Standards Track A. Yegin
	Expires: June 18, 2016 Samsung		Expires: September 3, 2016 Samsung
	S. Gundavelli		S. Gundavelli
	Cisco		Cisco
	December 16, 2015		March 2, 2016
	MAG Multipath Binding Option		MAG Multipath Binding Option
	draft-ietf-dmm-mag-multihoming-00.txt		draft-ietf-dmm-mag-multihoming-01.txt
	Abstract		Abstract
	The document [RFC4908] proposes to rely on multiple Care-of Addresses		The document [RFC4908] proposes to rely on multiple Care-of Addresses
	(CoAs) capabilities of Mobile IP [RFC6275] an Network Mobility (NEMO;		(CoAs) capabilities of Mobile IP [RFC6275] an Network Mobility (NEMO;
	[RFC3963]) to enable Multihoming technology for Small-Scale Fixed		[RFC3963]) to enable Multihoming technology for Small-Scale Fixed
	Networks. In the continuation of [RFC4908], this document specifies		Networks. In the continuation of [RFC4908], this document specifies
	a multiple proxy Care-of Addresses (pCoAs) extension for Proxy Mobile		a multiple proxy Care-of Addresses (pCoAs) extension for Proxy Mobile
	IPv6 [RFC5213]. This extension allows a multihomed Mobile Access		IPv6 [RFC5213]. This extension allows a multihomed Mobile Access
	Gateway (MAG) to register more than one proxy care-of-address to the		Gateway (MAG) to register more than one proxy care-of-address to the
	skipping to change at page 1, line 40		skipping to change at page 1, line 40
	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 June 18, 2016.		This Internet-Draft will expire on September 3, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2016 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. Conventions and Terminology . . . . . . . . . . . . . . . . . 4		2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
	2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4		2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4
	2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4		2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.1. Example Call Flow . . . . . . . . . . . . . . . . . . . . 5		3.1. Example Call Flow . . . . . . . . . . . . . . . . . . . . 5
	3.2. Traffic distribution schemes . . . . . . . . . . . . . . . 6		3.2. Traffic distribution schemes . . . . . . . . . . . . . . . 6
	4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 7		4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 7
	4.1. MAG Multipath-Binding Option . . . . . . . . . . . . . . . 7		4.1. MAG Multipath-Binding Option . . . . . . . . . . . . . . . 7
	4.2. MAG Identifier Option . . . . . . . . . . . . . . . . . . 9		4.2. MAG Identifier Option . . . . . . . . . . . . . . . . . . 9
	4.3. New Status Code for Proxy Binding Acknowledgement . . . . 10		4.3. New Status Code for Proxy Binding Acknowledgement . . . . 10
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 10		6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
	skipping to change at page 3, line 39		skipping to change at page 3, line 39
	working group achievments, namely:		working group achievments, namely:
	o using GRE as mobile tuneling, possibly with its key extension		o using GRE as mobile tuneling, possibly with its key extension
	[RFC5845] (a possible reason to use GRE is given on Section 3.2).		[RFC5845] (a possible reason to use GRE is given on Section 3.2).
	o using UDP encapsulation [RFC5844] in order to support NAT		o using UDP encapsulation [RFC5844] in order to support NAT
	traversal in IPv4 networking environment.		traversal in IPv4 networking environment.
	o Prefix Delegation mechanism [RFC7148].		o Prefix Delegation mechanism [RFC7148].
			o Using the vendor specific mobility option [RFC5094], for example
			to allow the MAG and LMA to exchange information (e.g. WAN
			interface QoS metrics) allowing to make appropriate traffic
			steering decision.
	Proxy Mobile IPv6 (PMIPv6) relies on two mobility entities: the		Proxy Mobile IPv6 (PMIPv6) relies on two mobility entities: the
	mobile access gateway (MAG), which acts as the default gateway for		mobile access gateway (MAG), which acts as the default gateway for
	the end-node and the local mobility anchor (LMA), which acts as the		the end-node and the local mobility anchor (LMA), which acts as the
	topological anchor point. Point-to-point links are established,		topological anchor point. Point-to-point links are established,
	using IP-in-IP tunnels, between MAG and LMA. Then, the MAG and LMA		using IP-in-IP tunnels, between MAG and LMA. Then, the MAG and LMA
	are distributing traffic over these tunnels. All PMIPv6 operations		are distributing traffic over these tunnels. All PMIPv6 operations
	are performed on behalf of the end-node and its corespondent node, it		are performed on behalf of the end-node and its corespondent node, it
	thus makes PMIPv6 well adapted to multihomed architecture as		thus makes PMIPv6 well adapted to multihomed architecture as
	considered in [RFC4908]. Taking the LTE and WLAN networking		considered in [RFC4908]. Taking the LTE and WLAN networking
	environments as an example, the PMIPv6 based multihomed architecture		environments as an example, the PMIPv6 based multihomed architecture
	skipping to change at page 6, line 7		skipping to change at page 6, line 36
	| | |-===========*== TUNNEL ==============-|		| | |-===========*== TUNNEL ==============-|
	| (9) | |		| (9) | |
	| <------------------> | |		| <------------------> | |
	| | (10) | |		| | (10) | |
	| |<-----------> | |		| |<-----------> | |
	Figure 2: Functional Separation of the Control and User Plane		Figure 2: Functional Separation of the Control and User Plane
	3.2. Traffic distribution schemes		3.2. Traffic distribution schemes
	IP mobility protocols allow to establish the forwarding plane over		Once tunnels are established, traffic distribution can be managed
	the WAN interfaces of a multihomed MAG. Then, traffic distribution		either on a per-flow or on a per-packet basis:
	schemes define the way to distribute data packets over these paths
	(i.e. IP tunnels). Traffic distribution can be managed either on a
	per-flow or on a per-packet basis:
	o per-flow traffic management: each IP flow (both upstream and		o Per-flow traffic management: each IP flow (both upstream and
	downstream) is mapped to a given mobile IP tunnel, corresponding		downstream) is mapped to a given tunnel, corresponding to a given
	to a given WAN interface. This scenario is based on IP flow		WAN interface. Flow binding extension [RFC6089] is used to
	mobility mechanism using the Flow binding extension [RFC6089].		exchange, and synchronize, IP flow management policies (i.e. rules
	The mobility anchor provides IP session continuity when an IP flow		associating traffic selectors [RFC6088] to a tunnel).
	is moved from one WAN interfaces to another. The flow binding
	extension allows the IP mobility anchor and the MAG to exchange,
	and synchronize, IP flow management policies (i.e. policy routing
	rules associating traffic selectors [RFC6088] to mobility
	bindings).
	o Per-packet management: distribute the IP packets of a same IP		o Per-packet management: the LMA and the MAG distribute packets,
	flow, or of a group of IP flows, over more than one WAN interface.		belonging to a same IP flow, over more than one bindings (i.e.
	In this scenario, traffic management slightly differs from the		more than one WAN interface). When operating at the packet level,
	default mobile IP behaviour; the mobility entities (mobility		traffic distribution scheme introduces packet latency and out-of-
	anchor and client) distribute packets, belonging to a same IP		order delivery. Sequence number can be added, to tunneled
	flow, over more than one bindings simultaneously. The definition		packets, to allow LMA and MAG making reordering before packets
	of control algorithm of a Per-packet distribution scheme (how to		delivery. For that purpose, GRE with sequence number option
	distribute packets) is out the scope of this document. When
	operating at the packet level, traffic distribution scheme may
	introduce packet latency and out-of-order delivery. It may
	require the mobility entities (MAG and mobility anchor) to be able
	to reorder (ans thus, to buffer) received packets before
	delivering. A possible implementation is to use GRE as mobile
	tunnelling mechanism, together with the GRE KEY option [RFC5845]
	to add sequence number to GRE packets, and so, to allow the
	receiver to perform reordering. However, more detailed buffering
	and reordering considerations are out of the scope of this
	document.
	The traffic distribution scheme may require the MAG and the to		[RFC5845] can be used as tunneling mechanism. More detailed
	exchange interface metrics to make traffic steering decision.For		considerations (e.g. definition of control algorithm) on Per-
	example, the MAG may send it link bandwidth to the mobility anchor,		packet distribution scheme is out the scope of this document.
	so that the latter can make traffic forwarding decision accordingly.
	In this case, the vendor specific mobility option [RFC5094] can be
	used for that purpose.
	Per-flow and per-packet distribution schemes are not exclusive		Because latency introduced by per-packet can cause injury to some
	mechanisms; they can cohabit in the same multi-access system. For		application, per-flow and per-packet distribution schemes could be
	example, High throughput services (e.g. video streaming) may benefit		used in conjunction. For example, high throughput services (e.g.
	from per-packet distribution scheme, while some other may not.		video streaming) may benefit from per-packet distribution scheme,
	Typically VoIP application are sensitive to latency and thus should		while latency sensitive applications (e.g. VoIP) are not be spread
	not be split over different WAN paths. In this situation, the		over different WAN paths.
	mobility entities (MAG and mobility anchor) must exchange traffic
	management policies to associate distribution scheme, traffic and WAN
	interface (physical or virtual). [RFC6088] and [RFC6089] define
	traffic management on a flow basis but there is no such policy on a
	per packet basis.
	4. Protocol Extensions		4. Protocol Extensions
	4.1. MAG Multipath-Binding Option		4.1. MAG Multipath-Binding Option
	The MAG Multipath-Binding option is a new mobility header option		The MAG Multipath-Binding option is a new mobility header option
	defined for use with Proxy Binding Update and Proxy Binding		defined for use with Proxy Binding Update and Proxy Binding
	Acknowledgement messages exchanged between the local mobility anchor		Acknowledgement messages exchanged between the local mobility anchor
	and the mobile access gateway.		and the mobile access gateway.
End of changes. 12 change blocks.
	56 lines changed or deleted		34 lines changed or added
This html diff was produced by rfcdiff 1.43. The latest version is available from http://tools.ietf.org/tools/rfcdiff/