draft-ietf-dmm-mag-multihoming-03.txt   draft-ietf-dmm-mag-multihoming-04.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: December 2, 2017 Actility Expires: January 1, 2018 Actility
S. Gundavelli S. Gundavelli
Cisco Cisco
May 31, 2017 June 30, 2017
MAG Multipath Binding Option MAG Multipath Binding Option
draft-ietf-dmm-mag-multihoming-03.txt draft-ietf-dmm-mag-multihoming-04.txt
Abstract Abstract
This specification defines extensions to the Proxy Mobile IPv6 This specification defines extensions to the Proxy Mobile IPv6
protocol for allowing a mobile access gateway to register more than protocol for allowing a mobile access gateway to register more than
one proxy care-of-address with the local mobility anchor and to one proxy care-of-address with the local mobility anchor and to
simultaneously establish multiple IP tunnels with the local mobility simultaneously establish multiple IP tunnels with the local mobility
anchor. This capability allows the mobile access gateway to utilize anchor. This capability allows the mobile access gateway to utilize
all the available access networks for routing mobile node's IP all the available access networks for routing mobile node's IP
traffic. traffic.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 December 2, 2017. This Internet-Draft will expire on January 1, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 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
skipping to change at page 2, line 23 skipping to change at page 2, line 23
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 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 Multihoming support on IP hosts can greatly improve the user
connectivity availability and quality of communications; the goals experience. With the simultaneoous use of multiple access networks,
and benefits of multihoming are as follows: multihoming brings better network connectivity, reliability and
improved quality of communication. Following are some of the goals
and benefits of multihoming support:
o Redundancy/Fault-Recovery o Redundancy/Fault-Recovery
o Load balancing o Load balancing
o Load sharing o Load sharing
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 c, a Proxy Mobile IPv6 [RFC5213] based The motivation for this work is to extend Proxy Mobile IPv6 protocol
multihomed achitecture could be defined to enable Multi-WAN support with multihoming extensions [RFC4908] for realizing the following
for Small-Scale Fixed Networks. The motivation to update [RFC4908] capabilities:
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 8, line 40 skipping to change at page 8, line 40
This 8-bit field identifies the Access-Technology type of the This 8-bit field identifies the Access-Technology type of the
interface through which the mobile node is connected. The interface through which the mobile node is connected. The
permitted values for this are from the Access Technology Type permitted values for this are from the Access Technology Type
registry defined in [RFC5213]. registry defined in [RFC5213].
Interface Label (If-Label) Interface Label (If-Label)
This 8-bit field represents the interface label represented as an This 8-bit field represents the interface label represented as an
unsigned integer. The MAG identifies the label for each of the unsigned integer. The MAG identifies the label for each of the
interfaces through which it registers a pCoA with the LMA. When interfaces through which it registers a pCoA with the LMA. When
using static traffic flow policies on the mobile node and the home using static traffic flow policies on the mobile node and the LMA,
agent, the label can be used for generating forwarding policies. the label can be used for generating forwarding rules. For
For example, the operator may have policy which binds traffic for example, the operator may have policy which binds traffic for
Application "X" needs to interface with Label "Y". When a Application "X" to an interface with Label "Y". When a
registration through an interface matching Label "Y" gets registration through an interface matching Label "Y" gets
activated, the home agent and the mobile node can dynamically activated, the LMA and the mobile node can dynamically generate a
generate a forwarding policy for forwarding traffic for forwarding policy for forwarding traffic for Application "X"
Application "X" through mobile IP tunnel matching Label "Y". Both through the tunnel matching Label "Y". Both the LMA and the
the home agent and the mobile node can route the Application-X mobile node can route the Application-X traffic through that
traffic through that interface. The permitted values for If-Label interface. The permitted values for If-Label are 1 through 255.
are 1 through 255.
Binding-Identifier (BID) Binding-Identifier (BID)
This 8-bit field is used for carrying the binding identifier. It This 8-bit field is used for carrying the binding identifier. It
uniquely identifies a specific binding of the mobile node, to uniquely identifies a specific binding of the mobile node, to
which this request can be associated. Each binding identifier is which this request can be associated. Each binding identifier is
represented as an unsigned integer. The permitted values are 1 represented as an unsigned integer. The permitted values are 1
through 254. The BID value of 0 and 255 are reserved. The mobile through 254. The BID value of 0 and 255 are reserved. The mobile
access gateway assigns a unique value for each of its interfaces access gateway assigns a unique value for each of its interfaces
and includes them in the message. and includes them in the message.
Bulk Re-registration Flag (B) Bulk Re-registration Flag (B)
skipping to change at page 10, line 46 skipping to change at page 10, line 46
Identifier Identifier
A variable length identifier of type indicated in the Subtype A variable length identifier of type indicated in the Subtype
field. field.
4.3. New Status Code for Proxy Binding Acknowledgement 4.3. New Status Code for Proxy Binding Acknowledgement
This document defines the following new Status Code value for use in This document defines the following new Status Code value for use in
Proxy Binding Acknowledgement message. Proxy Binding Acknowledgement message.
The LMA SHOULD use this error code when rejecting a Proxy Binding
Update message from a MAG requesting a multipath binding. Following
is the potential reason for rejecting the request:
o The LMA does not support multipath binding.
CANNOT_SUPPORT_MULTIPATH_BINDING (Cannot Support Multipath Binding): CANNOT_SUPPORT_MULTIPATH_BINDING (Cannot Support Multipath Binding):
<IANA-4> <IANA-4>
5. IANA Considerations 5. IANA Considerations
This document requires the following IANA actions. This document requires the following IANA actions.
o Action-1: This specification defines a new mobility option, the o Action-1: This specification defines a new mobility option, the
MAG Multipath-Binding option. The format of this option is MAG Multipath-Binding option. The format of this option is
described in Section 4.1. The type value <IANA-1> for this described in Section 4.1. The type value <IANA-1> for this
mobility option needs to be allocated from the Mobility Options mobility option needs to be allocated from the Mobility Options
skipping to change at page 11, line 36 skipping to change at page 11, line 42
allocated value has to be greater than 127. RFC Editor: Please allocated value has to be greater than 127. RFC Editor: Please
replace <IANA-4> in Section 4.3 with the assigned value and update replace <IANA-4> in Section 4.3 with the assigned value and update
this section accordingly. this section accordingly.
6. Security Considerations 6. Security Considerations
This specification allows a mobile access gateway to establish This specification allows a mobile access gateway to establish
multiple Proxy Mobile IPv6 tunnels with a local mobility anchor, by multiple Proxy Mobile IPv6 tunnels with a local mobility anchor, by
registering a care-of address for each of its connected access registering a care-of address for each of its connected access
networks. This essentially allows the mobile node's IP traffic to be networks. This essentially allows the mobile node's IP traffic to be
routed through any of the tunnel paths and either based on a static routed through any of the tunnel paths based on the negotiated flow
or a dynamically negotiated flow policy. This new capability has no policy. This new capability has no impact on the protocol security.
impact on the protocol security. Furthermore, this specification Furthermore, this specification defines two new mobility header
defines two new mobility header options, MAG Multipath-Binding option options, MAG Multipath-Binding option and the MAG Identifier option.
and the MAG Identifier option. These options are carried like any These options are carried like any other mobility header option as
other mobility header option as specified in [RFC5213]. Therefore, specified in [RFC5213]. Therefore, it inherits security guidelines
it inherits security guidelines from [RFC5213]. Thus, this from [RFC5213]. Thus, this specification does not weaken the
specification does not weaken the security of Proxy Mobile IPv6 security of Proxy Mobile IPv6 Protocol, and does not introduce any
Protocol, and does not introduce any new security vulnerabilities. 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, The authors would also like to thank Jouni Korhonen, Jong Hyouk Lee,
Dirk Von-Hugo, Seil Jeon and Carlos Bernardos for their review Dirk Von-Hugo, Seil Jeon, Carlos Bernardos and Robert Sparks for
feedback. 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, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997, RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
 End of changes. 15 change blocks. 
36 lines changed or deleted 41 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/