draft-ietf-dmm-mag-multihoming-05.txt   draft-ietf-dmm-mag-multihoming-06.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: March 10, 2018 Actility Expires: March 29, 2018 Actility
S. Gundavelli S. Gundavelli
Cisco Cisco
September 6, 2017 September 25, 2017
MAG Multipath Binding Option MAG Multipath Binding Option
draft-ietf-dmm-mag-multihoming-05.txt draft-ietf-dmm-mag-multihoming-06.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 March 10, 2018. This Internet-Draft will expire on March 29, 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 25 skipping to change at page 2, line 25
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 . . . . . . . . . . . . . . . 7 3.2. Traffic distribution schemes . . . . . . . . . . . . . . . 7
4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 8 4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 8
4.1. MAG Multipath-Binding Option . . . . . . . . . . . . . . . 8 4.1. MAG Multipath-Binding Option . . . . . . . . . . . . . . . 8
4.2. MAG Identifier Option . . . . . . . . . . . . . . . . . . 10 4.2. MAG Identifier Option . . . . . . . . . . . . . . . . . . 10
4.3. New Status Code for Proxy Binding Acknowledgement . . . . 11 4.3. New Status Code for Proxy Binding Acknowledgement . . . . 11
4.4. Signaling Considerations . . . . . . . . . . . . . . . . . 11 4.4. Signaling Considerations . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
Multihoming support on IP hosts can greatly improve the user Multihoming support on IP hosts can greatly improve the user
experience. With the simultaneoous use of multiple access networks, experience. With the simultaneoous use of multiple access networks,
multihoming brings better network connectivity, reliability and multihoming brings better network connectivity, reliability and
improved quality of communication. Following are some of the goals improved quality of communication. Following are some of the goals
and benefits of multihoming support: and benefits of multihoming support:
o Redundancy/Fault-Recovery o Redundancy/Fault-Recovery
skipping to change at page 6, line 25 skipping to change at page 6, line 25
| | | (1) ATTACH | | | | | | (1) ATTACH | | |
| | | <--------> | | | | | | <--------> | | |
| | | (2) ATTACH | | | | | (2) ATTACH | |
| | | <---------------------->| | | | | <---------------------->| |
| | | (3) PBU (MAG-NAI, MMB, ...) | | | | (3) PBU (MAG-NAI, MMB, ...) |
| | | ------------------------*-------------->| | | | ------------------------*-------------->|
| | | | | | | |
| | | Accept PBU | | | Accept PBU
| | | (allocate HNP, | | | (allocate HNP,
| | | create BCE) | | | create BCE)
| | | (4) PBA (MAG-NAI, MMB, ...) | | | | (4) PBA (MMB, ...) |
| | | <-----------------------*---------------| | | | <-----------------------*---------------|
| | | (5) TUNNEL INTERFACE CREATION over WLAN | | | | (5) TUNNEL INTERFACE CREATION over WLAN |
| | |-============== TUNNEL ==*==============-| | | |-============== TUNNEL ==*==============-|
| | | | | | | |
| | | (6) PBU (MAG-NAI, MMB, ...) | | | | (6) PBU (MAG-NAI, MMB, ...) |
| | | -----------*--------------------------->| | | | -----------*--------------------------->|
| | | | | | | |
| | | Accept PBU | | | Accept PBU
| | | (update BCE) | | | (update BCE)
| | | (7) PBA (MAG-NAI, MMB, ...) | | | | (7) PBA (MAG-NAI, MMB, ...) |
skipping to change at page 11, line 35 skipping to change at page 11, line 35
4.4. Signaling Considerations 4.4. Signaling Considerations
o The MAG when requesting multipath support MUST include the MAG o The MAG when requesting multipath support MUST include the MAG
Multipath Binding Option (Section 4.1) in each of the PBU messages Multipath Binding Option (Section 4.1) in each of the PBU messages
that it sends through the different WAN interfaces. The inclusion that it sends through the different WAN interfaces. The inclusion
of this option serves as a hint that the MAG is requesting of this option serves as a hint that the MAG is requesting
Multipath support. Furthermore, the MAG Identifier option MUST Multipath support. Furthermore, the MAG Identifier option MUST
also be present in the PBU message. also be present in the PBU message.
o If the MAG is aware that the LMA supports the multipath feature
defined in this specification and if it chooses to enable multiple
path feature, then it can send the PBU packets for each of the
paths, either sequentially, or concurrently. However, if the MAG
is not aware of the LMA capability, then it should first discover
the LMA capability by sending PBU packets with multipath on only
one path first. This will ensure the LMA will not be over-writing
the binding of one path with the other path.
o If the LMA supports multipath capability as defined in this
specification and if it enables the same for a mobile node's'
session per the MAG's request, then the LMA MUST include the
Multipath Binding Option (Section 4.1), without the MAG NAI Option
Section 4.2 in the corresponding PBA reply.
o If the LMA is a legacy LMA that does not support this o If the LMA is a legacy LMA that does not support this
specification, the LMA will skip the MAG Multipath Binding option specification, the LMA will skip the MAG Multipath Binding option
(and MAG NAI option) and process the rest of the message as (and MAG NAI option) and process the rest of the message as
specified in the base Proxy Mobile IPv6 specification ([RFC5213]). specified in the base Proxy Mobile IPv6 specification ([RFC5213]).
Furthermore, the LMA will not include the MAG Multipath Binding Furthermore, the LMA will not include the MAG Multipath Binding
option (or the MAG NAI Option)in the PBA message. The MAG on option (or the MAG NAI Option)in the PBA message. The MAG on
receiving the PBA message without the MAG Multipath Binding option receiving the PBA message without the MAG Multipath Binding option
SHOULD disable Multipath support for the mobile node. SHOULD disable Multipath support for the mobile node.
o If the mobile node is not authorized for Multipath support, then o If the mobile node is not authorized for Multipath support, then
skipping to change at page 13, line 15 skipping to change at page 13, line 28
security of Proxy Mobile IPv6 Protocol, and does not introduce any security of Proxy Mobile IPv6 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, Carlos Bernardos, Robert Sparks, Adam Dirk Von-Hugo, Seil Jeon, Carlos Bernardos, Robert Sparks, Adam
Roach, Kathleen Moriarty, Hilarie Orman, Ben Campbell, Warren Kumari, Roach, Kathleen Moriarty, Hilarie Orman, Ben Campbell, Warren Kumari,
Mirja Kuehlewind, for their review feedback. for their review feedback. Special thanks to Mirja Kuehlewind for a
very thorugh review and suggesting many text improvements.
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,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
 End of changes. 9 change blocks. 
8 lines changed or deleted 24 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/