--- 1/draft-ietf-dmm-mag-multihoming-05.txt 2017-09-25 17:13:08.041630511 -0700 +++ 2/draft-ietf-dmm-mag-multihoming-06.txt 2017-09-25 17:13:08.073631282 -0700 @@ -1,21 +1,21 @@ DMM WG P. Seite Internet-Draft Orange Intended status: Standards Track A. Yegin -Expires: March 10, 2018 Actility +Expires: March 29, 2018 Actility S. Gundavelli Cisco - September 6, 2017 + September 25, 2017 MAG Multipath Binding Option - draft-ietf-dmm-mag-multihoming-05.txt + draft-ietf-dmm-mag-multihoming-06.txt Abstract This specification defines extensions to the Proxy Mobile IPv6 protocol for allowing a mobile access gateway to register more than one proxy care-of-address with the local mobility anchor and to simultaneously establish multiple IP tunnels with the local mobility anchor. This capability allows the mobile access gateway to utilize all the available access networks for routing mobile node's IP traffic. @@ -28,21 +28,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -60,26 +60,26 @@ 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Example Call Flow . . . . . . . . . . . . . . . . . . . . 5 3.2. Traffic distribution schemes . . . . . . . . . . . . . . . 7 4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 8 4.1. MAG Multipath-Binding Option . . . . . . . . . . . . . . . 8 4.2. MAG Identifier Option . . . . . . . . . . . . . . . . . . 10 4.3. New Status Code for Proxy Binding Acknowledgement . . . . 11 4.4. Signaling Considerations . . . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction Multihoming support on IP hosts can greatly improve the user experience. With the simultaneoous use of multiple access networks, 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 @@ -221,21 +221,21 @@ | | | (1) ATTACH | | | | | | <--------> | | | | | | (2) ATTACH | | | | | <---------------------->| | | | | (3) PBU (MAG-NAI, MMB, ...) | | | | ------------------------*-------------->| | | | | | | | Accept PBU | | | (allocate HNP, | | | create BCE) - | | | (4) PBA (MAG-NAI, MMB, ...) | + | | | (4) PBA (MMB, ...) | | | | <-----------------------*---------------| | | | (5) TUNNEL INTERFACE CREATION over WLAN | | | |-============== TUNNEL ==*==============-| | | | | | | | (6) PBU (MAG-NAI, MMB, ...) | | | | -----------*--------------------------->| | | | | | | | Accept PBU | | | (update BCE) | | | (7) PBA (MAG-NAI, MMB, ...) | @@ -461,20 +461,35 @@ 4.4. Signaling Considerations o The MAG when requesting multipath support MUST include the MAG Multipath Binding Option (Section 4.1) in each of the PBU messages that it sends through the different WAN interfaces. The inclusion of this option serves as a hint that the MAG is requesting Multipath support. Furthermore, the MAG Identifier option MUST 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 specification, the LMA will skip the MAG Multipath Binding option (and MAG NAI option) and process the rest of the message as specified in the base Proxy Mobile IPv6 specification ([RFC5213]). Furthermore, the LMA will not include the MAG Multipath Binding option (or the MAG NAI Option)in the PBA message. The MAG on receiving the PBA message without the MAG Multipath Binding option SHOULD disable Multipath support for the mobile node. o If the mobile node is not authorized for Multipath support, then @@ -534,21 +549,22 @@ security of Proxy Mobile IPv6 Protocol, and does not introduce any new security vulnerabilities. 7. Acknowledgements The authors of this draft would like to acknowledge the discussions 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, Carlos Bernardos, Robert Sparks, Adam 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.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ RFC2119, March 1997, .