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/