draft-ietf-dmm-mag-multihoming-02.txt   draft-ietf-dmm-mag-multihoming-03.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: January 26, 2017 Samsung Expires: December 2, 2017 Actility
S. Gundavelli S. Gundavelli
Cisco Cisco
July 25, 2016 May 31, 2017
MAG Multipath Binding Option MAG Multipath Binding Option
draft-ietf-dmm-mag-multihoming-02.txt draft-ietf-dmm-mag-multihoming-03.txt
Abstract Abstract
The document [RFC4908] proposes to rely on multiple Care-of Addresses This specification defines extensions to the Proxy Mobile IPv6
(CoAs) capabilities of Mobile IP [RFC6275] an Network Mobility (NEMO; protocol for allowing a mobile access gateway to register more than
[RFC3963]) to enable Multihoming technology for Small-Scale Fixed one proxy care-of-address with the local mobility anchor and to
Networks. In the continuation of [RFC4908], this document specifies simultaneously establish multiple IP tunnels with the local mobility
a multiple proxy Care-of Addresses (pCoAs) extension for Proxy Mobile anchor. This capability allows the mobile access gateway to utilize
IPv6 [RFC5213]. This extension allows a multihomed Mobile Access all the available access networks for routing mobile node's IP
Gateway (MAG) to register more than one proxy care-of-address to the traffic.
Local Mobility Anchor (LMA).
Status of This Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 January 26, 2017. This Internet-Draft will expire on December 2, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
Using several links, the multihoming technology can improve Using several links, the multihoming technology can improve
connectivity availability and quality of communications; the goals connectivity availability and quality of communications; the goals
and benefits of multihoming are as follows: and benefits of multihoming are as follows:
o Redundancy/Fault-Recovery o Redundancy/Fault-Recovery
o Load balancing o Load balancing
skipping to change at page 3, line 5 skipping to change at page 3, line 26
o Preferences settings o Preferences settings
According to [RFC4908], users of Small-Scale Networks can take According to [RFC4908], users of Small-Scale Networks can take
benefit of multihoming using mobile IP [RFC6275] and Network Mobility benefit of multihoming using mobile IP [RFC6275] and Network Mobility
(NEMO) [RFC3963] architecture in a mobile and fixed networking (NEMO) [RFC3963] architecture in a mobile and fixed networking
environment. This document is introducing the concept of multiple environment. This document is introducing the concept of multiple
Care-of Addresses (CoAs) [RFC5648] that have been specified since Care-of Addresses (CoAs) [RFC5648] that have been specified since
then. then.
In the continuation of [RFC4908], a Proxy Mobile IPv6 [RFC5213] based In the continuation of c, a Proxy Mobile IPv6 [RFC5213] based
multihomed achitecture could be defined. The motivation to update multihomed achitecture could be defined to enable Multi-WAN support
[RFC4908] with proxy Mobile IPv6 is to leverage on latest mobility for Small-Scale Fixed Networks. The motivation to update [RFC4908]
working group achievments, namely: with proxy Mobile IPv6 is to leverage on latest mobility 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 o Using the vendor specific mobility option [RFC5094], for example
skipping to change at page 4, line 31 skipping to change at page 4, line 36
| | (_ _) Flow-3 | | (_ _) Flow-3
| | '----' Flow-4 | | '----' Flow-4
|Flow-3 |Flow-3
| |
Flow0-4 Flow0-4
Figure 1: Multihomed MAG using Proxy Mobile IPv6 Figure 1: Multihomed MAG using Proxy Mobile IPv6
The current version of Proxy Mobile IPv6 does not allow a MAG to The current version of Proxy Mobile IPv6 does not allow a MAG to
register more than one proxy Care-of-Adresse to the LMA. In other register more than one proxy Care-of-Adresse to the LMA. In other
words, only one MAG/LMA link, i.e. IP-in-IP tunnel, can be used at words, only one MAG/LMA link, i.e. IP-in-IP tunnel, can be used at
the same time. This document overcomes this limitation by defining the same time. This document overcomes this limitation by defining
the multiple proxy Care-of Addresses (pCoAs) extension for Proxy the multiple proxy Care-of Addresses (pCoAs) extension for Proxy
Mobile IPv6. Mobile IPv6.
2. Conventions and Terminology 2. Conventions and Terminology
2.1. Conventions 2.1. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2.2. Terminology 2.2. Terminology
All mobility related terms used in this document are to be All mobility related terms used in this document are to be
interpreted as defined in [RFC5213], [RFC5844] and [RFC7148]. interpreted as defined in [RFC5213], [RFC5844] and [RFC7148].
skipping to change at page 7, line 7 skipping to change at page 7, line 13
managed either on a per-flow or on a per-packet basis: 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 tunnel, corresponding to a given downstream) is mapped to a given tunnel, corresponding to a given
WAN interface. Flow binding extension [RFC6089] is used to WAN interface. Flow binding extension [RFC6089] is used to
exchange, and synchronize, IP flow management policies (i.e. rules exchange, and synchronize, IP flow management policies (i.e. rules
associating traffic selectors [RFC6088] to a tunnel). associating traffic selectors [RFC6088] to a tunnel).
o Per-packet management: the LMA and the MAG distribute packets, o Per-packet management: the LMA and the MAG distribute packets,
belonging to a same IP flow, over more than one bindings (i.e. belonging to a same IP flow, over more than one bindings (i.e.
more than one WAN interface). When operating at the IP packet more than one WAN interface). Packet distribution can be done
level, different packets distribution algorithms are possible. either at the transport level, e.g. using MPTCP or at When
For example, the algorithm may give precedence to one given operating at the IP packet level, different packets distribution
access: the MAG overflows traffic from the primary access, e.g. algorithms are possible. For example, the algorithm may give
WLAN, to the second one, only when load on primary access reaches precedence to one given access: the MAG overflows traffic from the
a given threshold. The distribution algorithm is left to primary access, e.g. WLAN, to the second one, only when load on
implementer but whatever the algorithm is, packets distribution primary access reaches a given threshold. The distribution
likely introduces packet latency and out-of-order delivery. LMA algorithm is left to implementer but whatever the algorithm is,
and MAG shall thus be able to make reordering before packets packets distribution likely introduces packet latency and out-of-
delivery. Sequence number can be can be used for that purpose, order delivery. LMA and MAG shall thus be able to make reordering
for example using GRE with sequence number option [RFC5845]. before packets delivery. Sequence number can be can be used for
However, more detailed considerations on reordering and IP packet that purpose, for example using GRE with sequence number option
distribution scheme (e.g. definition of packets distribution [RFC5845]. However, more detailed considerations on reordering
algorithm) are out the scope of this document. and IP packet distribution scheme (e.g. definition of packets
distribution algorithm) are out the scope of this document.
Because latency introduced by per-packet can cause injury to some Because latency introduced by per-packet can cause injury to some
application, per-flow and per-packet distribution schemes could be application, per-flow and per-packet distribution schemes could be
used in conjunction. For example, high throughput services (e.g. used in conjunction. For example, high throughput services (e.g.
video streaming) may benefit from per-packet distribution scheme, video streaming) may benefit from per-packet distribution scheme,
while latency sensitive applications (e.g. VoIP) are not be spread while latency sensitive applications (e.g. VoIP) are not be spread
over different WAN paths. IP flow mobility extensions, [RFC6089] and over different WAN paths. IP flow mobility extensions, [RFC6089] and
[RFC6088], can be used to provision the MAG with such flow policies. [RFC6088], can be used to provision the MAG with such flow policies.
4. Protocol Extensions 4. Protocol Extensions
skipping to change at page 11, line 39 skipping to change at page 11, line 50
and the MAG Identifier option. These options are carried like any and the MAG Identifier option. These options are carried like any
other mobility header option as specified in [RFC5213]. Therefore, other mobility header option as specified in [RFC5213]. Therefore,
it inherits security guidelines from [RFC5213]. Thus, this it inherits security guidelines from [RFC5213]. Thus, this
specification does not weaken the security of Proxy Mobile IPv6 specification does not weaken the security of Proxy Mobile IPv6
Protocol, and does not introduce any new security vulnerabilities. Protocol, and does not introduce any new security vulnerabilities.
7. Acknowledgements 7. Acknowledgements
The authors of this draft would like to acknowledge the discussions The authors of this draft would like to acknowledge the discussions
and feedback on this topic from the members of the DMM working group. and feedback on this topic from the members of the DMM working group.
The authors would also like to thank Jouni Korhonen, Jong Hyouk Lee,
Dirk Von-Hugo, Seil Jeon and Carlos Bernardos for their review
feedback.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
DOI 10.17487/RFC2119, March 1997, RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol", Thubert, "Network Mobility (NEMO) Basic Support Protocol",
RFC 3963, DOI 10.17487/RFC3963, January 2005, RFC 3963, DOI 10.17487/RFC3963, January 2005,
<http://www.rfc-editor.org/info/rfc3963>. <http://www.rfc-editor.org/info/rfc3963>.
[RFC5094] Devarapalli, V., Patel, A., and K. Leung, "Mobile IPv6 [RFC5094] Devarapalli, V., Patel, A., and K. Leung, "Mobile IPv6
Vendor Specific Option", RFC 5094, DOI 10.17487/RFC5094, Vendor Specific Option", RFC 5094, DOI 10.17487/RFC5094,
December 2007, <http://www.rfc-editor.org/info/rfc5094>. December 2007, <http://www.rfc-editor.org/info/rfc5094>.
[RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V.,
Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", Chowdhury, K., and B. Patil, "Proxy Mobile IPv6",
RFC 5213, DOI 10.17487/RFC5213, August 2008, RFC 5213, DOI 10.17487/RFC5213, August 2008,
<http://www.rfc-editor.org/info/rfc5213>. <http://www.rfc-editor.org/info/rfc5213>.
[RFC5648] Wakikawa, R., Ed., Devarapalli, V., Tsirtsis, G., Ernst, [RFC5648] Wakikawa, R., Ed., Devarapalli, V., Tsirtsis, G., Ernst,
T., and K. Nagami, "Multiple Care-of Addresses T., and K. Nagami, "Multiple Care-of Addresses
Registration", RFC 5648, DOI 10.17487/RFC5648, October Registration", RFC 5648, DOI 10.17487/RFC5648,
2009, <http://www.rfc-editor.org/info/rfc5648>. October 2009, <http://www.rfc-editor.org/info/rfc5648>.
[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
Mobile IPv6", RFC 5844, DOI 10.17487/RFC5844, May 2010, Mobile IPv6", RFC 5844, DOI 10.17487/RFC5844, May 2010,
<http://www.rfc-editor.org/info/rfc5844>. <http://www.rfc-editor.org/info/rfc5844>.
[RFC5845] Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung, [RFC5845] Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung,
"Generic Routing Encapsulation (GRE) Key Option for Proxy "Generic Routing Encapsulation (GRE) Key Option for Proxy
Mobile IPv6", RFC 5845, DOI 10.17487/RFC5845, June 2010, Mobile IPv6", RFC 5845, DOI 10.17487/RFC5845, June 2010,
<http://www.rfc-editor.org/info/rfc5845>. <http://www.rfc-editor.org/info/rfc5845>.
skipping to change at page 12, line 45 skipping to change at page 13, line 9
DOI 10.17487/RFC6088, January 2011, DOI 10.17487/RFC6088, January 2011,
<http://www.rfc-editor.org/info/rfc6088>. <http://www.rfc-editor.org/info/rfc6088>.
[RFC6089] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G., [RFC6089] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G.,
and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and
Network Mobility (NEMO) Basic Support", RFC 6089, Network Mobility (NEMO) Basic Support", RFC 6089,
DOI 10.17487/RFC6089, January 2011, DOI 10.17487/RFC6089, January 2011,
<http://www.rfc-editor.org/info/rfc6089>. <http://www.rfc-editor.org/info/rfc6089>.
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July Support in IPv6", RFC 6275, DOI 10.17487/RFC6275,
2011, <http://www.rfc-editor.org/info/rfc6275>. July 2011, <http://www.rfc-editor.org/info/rfc6275>.
[RFC7148] Zhou, X., Korhonen, J., Williams, C., Gundavelli, S., and [RFC7148] Zhou, X., Korhonen, J., Williams, C., Gundavelli, S., and
CJ. Bernardos, "Prefix Delegation Support for Proxy Mobile CJ. Bernardos, "Prefix Delegation Support for Proxy Mobile
IPv6", RFC 7148, DOI 10.17487/RFC7148, March 2014, IPv6", RFC 7148, DOI 10.17487/RFC7148, March 2014,
<http://www.rfc-editor.org/info/rfc7148>. <http://www.rfc-editor.org/info/rfc7148>.
8.2. Informative References 8.2. Informative References
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
December 1998, <http://www.rfc-editor.org/info/rfc2473>. December 1998, <http://www.rfc-editor.org/info/rfc2473>.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, for IPv6 Hosts and Routers", RFC 4213, DOI 10.17487/
DOI 10.17487/RFC4213, October 2005, RFC4213, October 2005,
<http://www.rfc-editor.org/info/rfc4213>. <http://www.rfc-editor.org/info/rfc4213>.
[RFC4908] Nagami, K., Uda, S., Ogashiwa, N., Esaki, H., Wakikawa, [RFC4908] Nagami, K., Uda, S., Ogashiwa, N., Esaki, H., Wakikawa,
R., and H. Ohnishi, "Multi-homing for small scale fixed R., and H. Ohnishi, "Multi-homing for small scale fixed
network Using Mobile IP and NEMO", RFC 4908, network Using Mobile IP and NEMO", RFC 4908, DOI 10.17487/
DOI 10.17487/RFC4908, June 2007, RFC4908, June 2007,
<http://www.rfc-editor.org/info/rfc4908>. <http://www.rfc-editor.org/info/rfc4908>.
Authors' Addresses Authors' Addresses
Pierrick Seite Pierrick Seite
Orange Orange
4, rue du Clos Courtel, BP 91226 4, rue du Clos Courtel, BP 91226
Cesson-Sevigne 35512 Cesson-Sevigne 35512
France France
Email: pierrick.seite@orange.com Email: pierrick.seite@orange.com
Alper Yegin Alper Yegin
Samsung Actility
Istanbul
Turkey Turkey
Email: alper.yegin@partner.samsung.com Email: alper.yegin@actility.com
Sri Gundavelli Sri Gundavelli
Cisco Cisco
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: sgundave@cisco.com Email: sgundave@cisco.com
 End of changes. 20 change blocks. 
66 lines changed or deleted 67 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/