diff options
| author | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
|---|---|---|
| committer | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
| commit | 4bfd864f10b68b71482b35c818559068ef8d5797 (patch) | |
| tree | e3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc7161.txt | |
| parent | ea76e11061bda059ae9f9ad130a9895cc85607db (diff) | |
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc7161.txt')
| -rw-r--r-- | doc/rfc/rfc7161.txt | 2075 |
1 files changed, 2075 insertions, 0 deletions
diff --git a/doc/rfc/rfc7161.txt b/doc/rfc/rfc7161.txt new file mode 100644 index 0000000..323d1e3 --- /dev/null +++ b/doc/rfc/rfc7161.txt @@ -0,0 +1,2075 @@ + + + + + + +Internet Engineering Task Force (IETF) LM. Contreras +Request for Comments: 7161 Telefonica I+D +Category: Experimental CJ. Bernardos +ISSN: 2070-1721 I. Soto + UC3M + March 2014 + + + Proxy Mobile IPv6 (PMIPv6) Multicast Handover Optimization + by the Subscription Information Acquisition through the LMA (SIAL) + +Abstract + + This document specifies an experimental multicast handover + optimization mechanism for Proxy Mobile IPv6 (PMIPv6) to accelerate + the delivery of multicast traffic to mobile nodes after handovers. + The mechanism, called Subscription Information Acquisition through + the LMA (SIAL), is based on speeding up the acquisition of mobile + nodes' multicast context by the mobile access gateways. To do that, + extensions to the current PMIPv6 protocol are proposed. These + extensions are not only applicable to the base solution for multicast + support in Proxy Mobile IPv6, but they can also be applied to other + solutions developed to avoid the tunnel convergence problem. + Furthermore, these extensions are also independent of the role played + by the mobile access gateway within the multicast network (acting as + either multicast listener discovery proxy or multicast router). + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for examination, experimental implementation, and + evaluation. + + This document defines an Experimental Protocol for the Internet + community. This document is a product of the Internet Engineering + Task Force (IETF). It represents the consensus of the IETF + community. It has received public review and has been approved for + publication by the Internet Engineering Steering Group (IESG). Not + all documents approved by the IESG are a candidate for any level of + Internet Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7161. + + + + + + + +Contreras, et al. Experimental [Page 1] + +RFC 7161 PMIPv6 Multicast Handover Optimization March 2014 + + +Copyright Notice + + Copyright (c) 2014 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 + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Handover Optimization + Requirements . . . . . . . . . . . . . . . . . . . . . . 5 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 4. Proxy Mobile IPv6 Extensions . . . . . . . . . . . . . . . . 8 + 4.1. Active Multicast Subscription Mobility Option . . . . . . 8 + 4.1.1. Option Application Rules . . . . . . . . . . . . . . 8 + 4.1.2. Option Format . . . . . . . . . . . . . . . . . . . . 9 + 4.1.3. Backward Compatibility with MLDv1 . . . . . . . . . . 9 + 4.2. Multicast Signaling Flag on PBU/PBA Message Headers . . . 10 + 4.2.1. Flag Application Rules . . . . . . . . . . . . . . . 10 + 4.2.1.1. Registration Process . . . . . . . . . . . . . . 11 + 4.2.1.2. De-registration Process . . . . . . . . . . . . . 12 + 4.2.2. New Format of Conventional PBU/PBA Messages . . . . . 12 + 4.2.2.1. Proxy Binding Update Message . . . . . . . . . . 12 + 4.2.2.2. Proxy Binding Acknowledgement Message . . . . . . 13 + 4.3. Messages for Active Multicast Subscription Query . . . . 13 + 4.3.1. Subscription Query Message . . . . . . . . . . . . . 13 + 4.3.1.1. Message Application Rules . . . . . . . . . . . . 13 + 4.3.1.2. Message Format . . . . . . . . . . . . . . . . . 14 + 4.3.2. Subscription Response Message . . . . . . . . . . . . 15 + 4.3.2.1. Message Application Rules . . . . . . . . . . . . 15 + 4.3.2.2. Message Format . . . . . . . . . . . . . . . . . 15 + 4.4. New PBA Timer in the LMA . . . . . . . . . . . . . . . . 16 + 5. Handover Signaling Procedures . . . . . . . . . . . . . . . . 17 + 5.1. Handover of Proactive Type . . . . . . . . . . . . . . . 17 + 5.1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . 17 + 5.1.2. Message Flow Description . . . . . . . . . . . . . . 18 + 5.2. Handover of Reactive Type . . . . . . . . . . . . . . . . 20 + + + + +Contreras, et al. Experimental [Page 2] + +RFC 7161 PMIPv6 Multicast Handover Optimization March 2014 + + + 5.2.1. Rationale . . . . . . . . . . . . . . . . . . . . . . 20 + 5.2.2. Message Flow Description . . . . . . . . . . . . . . 21 + 5.2.3. Further Considerations for the Reactive Handover + Signaling . . . . . . . . . . . . . . . . . . . . . . 22 + 5.3. Prevention of Large Delays of the Binding + Acknowledgement for Unicast Traffic . . . . . . . . . . . 23 + 6. IPv4 Support . . . . . . . . . . . . . . . . . . . . . . . . 26 + 6.1. Active Multicast Subscription for IPv4 . . . . . . . . . 26 + 6.2. Signaling Procedures for IPv4 Support . . . . . . . . . . 27 + 6.3. Binding Cache Extensions for IPv4 Support . . . . . . . . 28 + 7. Coexistence with PMIPv6 Multicast Architectural + Evolutions . . . . . . . . . . . . . . . . . . . . . . . . . 28 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 28 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 + 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31 + 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 + 12.1. Normative References . . . . . . . . . . . . . . . . . . 32 + 12.2. Informative References . . . . . . . . . . . . . . . . . 32 + Appendix A. Performance Comparison with Base Solution . . . . . 34 + A.1. Delay Characterization of the Base Solution . . . . . . . 34 + A.2. Delay Characterization of SIAL . . . . . . . . . . . . . 35 + A.3. Performance Comparison . . . . . . . . . . . . . . . . . 35 + +1. Introduction + + The base solution for providing continuous multicast service delivery + in Proxy Mobile IPv6 (PMIPv6) domains is described in [RFC6224]. It + specifies the basic functionality needed in the Proxy Mobile IPv6 + [RFC5213] entities to provide a multicast service, so continuous + delivery of multicast traffic is supported by obtaining, after each + handover, the ongoing multicast subscription information directly + from the Mobile Node (MN). When a mobile node attaches to a new + Mobile Access Gateway (MAG), the mobile node is queried by the mobile + access gateway through a Multicast Listener Discovery (MLD) General + Query, which is sent just after any new link is set up, to learn of + any existing subscription, as specified in [RFC2710] and [RFC3810]. + + However, the base solution needs to be improved to meet some + performance requirements, especially those referring to the user- + perceived service quality, which is seriously affected by the + disruption of multicast content forwarding to the mobile node during + handovers. + + A mobile node with an active multicast subscription, moving from one + point of attachment to another within a Proxy Mobile IPv6 domain, + experiences a certain delay until it resumes receiving again the + multicast content that it was receiving at the previous location. + + + +Contreras, et al. Experimental [Page 3] + +RFC 7161 PMIPv6 Multicast Handover Optimization March 2014 + + + Such delay causes a gap in the content reception. Two different + actions can help mitigate such reception gap. One of them is to + buffer at the previous mobile access gateway a copy of the multicast + traffic destined to the mobile node and forward it to the new mobile + access gateway, in order to deliver that traffic to the mobile node. + The other possible (complementary) action is to reduce the time + needed by the new mobile access gateway to learn of the active + multicast subscription of the mobile node (i.e., the multicast + context), so the new mobile access gateway can subscribe to the + multicast group(s) on behalf of the mobile node as soon as possible. + + While the first mechanism could potentially be accomplished by using + some adaptation of [RFC5949] to multicast traffic (despite being only + applicable in the case the underlying radio access technology + supports Layer 2 (L2) triggers, thus requiring additional support on + the mobile node), there is no generic standard solution for the + accelerated acquisition of the ongoing multicast subscription of the + mobile node. + + The approach followed by the base solution [RFC6224] to learn of an + existing multicast subscription relies on the behavior of the IGMP/ + MLD protocols. Both protocols send multicast membership query + messages when a new link is up. The response to such a message + reports any existing multicast subscriptions by the mobile node. + While this is a straightforward approach, the mobile access gateway + can incur in a non-negligible delay in receiving the corresponding + MLD Report message. This delay is caused by the time needed for the + detection of the attachment in the new link and the re-establishment + of the data plane after the handover, the radio transfer delays + associated with the signaling to the mobile node, and the MLD query + response interval time required by this procedure (whose default + value is 10 seconds as defined in [RFC2710] and [RFC3810], or between + 5 and 10 seconds as considered in the best case wireless link + scenario in [RFC6636]). + + This document extends the Proxy Mobile IPv6 signaling protocol + defined in the base protocol [RFC5213] by including a new multicast + information option to update Proxy Mobile IPv6 entities during the + registration and de-registration processes, and new messages to + trigger the transfer of multicast information. No extension is + required in any of the multicast-related protocols in use (IGMP/MLD + or PIM protocols). Furthermore, this specification does not + substitute the standard procedures defined in [RFC6224] (e.g., the + mobile access gateway continues sending an MLD Query to the entering + mobile node as soon as the point-to-point link is set up), but + complements them for accelerating the acquisition of the multicast + content by the mobile access gateway associated to the new point-of- + attachment. + + + +Contreras, et al. Experimental [Page 4] + +RFC 7161 PMIPv6 Multicast Handover Optimization March 2014 + + + This document provides a signaling method internal to the network to + speed up the subscription information acquisition by the mobile + access gateway, in order to accelerate the multicast delivery to the + mobile node after having completed a handover. By doing so, the + knowledge by the mobile access gateway of the currently active + multicast subscription becomes independent of the underlying radio + technology dynamics and relaxes the requirement of a rapid response + from the mobile node in processing IGMP/MLD control messages. Issues + like radio framing, radio access contention, channel reliability, + MN's capabilities (i.e., L2 triggering support), IGMP/MLD timers + optimization for wireless environments, etc., will not impact the + observed multicast performance during handovers. + + The mechanisms described in this document can also be applied to the + solutions defined in [RFC7028]. Furthermore, it is also independent + of the role played by the mobile access gateway within the multicast + network (acting as either MLD proxy or multicast router). + +1.1. Handover Optimization Requirements + + A basic solution for providing support of multicast in a network- + based mobility management environment has been specified in [RFC6224] + without introducing changes on the original PMIPv6 specification + [RFC5213]. The focus of the present document is on improving the + efficiency of the base solution regarding handover performance. + + One of the critical aspects of the base solution is the expected + delay incurred by the mobile access gateway (where the mobile node is + being attached to) to be informed about the ongoing multicast + subscription of the entering MN, mainly due to the fact that the + mechanisms provided in the base solution relay on the original MLD + procedures, with long timing interactions not conceived for mobile + environments. Then, the requirements to be covered by a handover + optimization solution can be established in the following manner: + + o The solution MUST be applicable to any kind of MN (that is, not + requiring any particular functionality such as, for example, L2 + trigger capabilities), in such a way that any type of mobile node + in a PMIPv6 domain being served with multicast traffic can benefit + from the optimized solution. + + o The solution MUST NOT impact existing multicast protocols. + + o The solution MUST optimize the handover performance with respect + to the performance achieved with the base solution for any kind of + handover process (i.e., for proactive and reactive handovers). + + + + + +Contreras, et al. Experimental [Page 5] + +RFC 7161 PMIPv6 Multicast Handover Optimization March 2014 + + + o The solution SHOULD minimize the number and extent of additional + support (i.e., capabilities) required in the network, aiming at an + easier deployment. + + o The solution MUST NOT impact deployments of legacy implementations + of [RFC5213] and [RFC6224]. + + The present specification addresses all these requirements, as + described in the following sections. + +2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + This document uses the terminology referring to PMIPv6 components as + defined in [RFC5213]. + + Additionally, the following terms are defined and used in this + document. + + pMAG: The previous MAG or pMAG is the mobile access gateway where + the MN was initially registered before a handover event. + + nMAG: The new MAG or nMAG is the mobile access gateway where the MN + is registered at the end of the handover event. + + Reactive Handover: A reactive handover is a handover event in which + the Local Mobility Anchor (LMA) receives the mobile node + registration from the nMAG without having previously received the + MN de-registration from the pMAG. + + Proactive Handover: A proactive handover is a handover event where + the mobile node is firstly de-registered on the local mobility + anchor by the pMAG, and later on it is registered by the nMAG as a + consequence of changing the point of attachment. + + Multicast Membership Context: In this document, multicast membership + context makes reference to the information relative to the + currently active multicast subscription of an MN in a handover + event that is transferred between the PMIPv6 entities to support + the handover optimization. + + + + + + + + +Contreras, et al. Experimental [Page 6] + +RFC 7161 PMIPv6 Multicast Handover Optimization March 2014 + + +3. Overview + + The local mobility anchor is a key element within the PMIPv6 + infrastructure, which traces the mobile node reachability along the + PMIPv6 domain. Therefore, the LMA is the best element to keep the + MNs' multicast subscription information up-to-date and to forward it + to the rest of PMIPv6 entities (i.e., to the mobile access gateways) + as needed when MNs move within the domain. The LMA has timely + knowledge of the MNs' locations, especially during handover events, + and it is therefore able to quickly provide information to the new + point of attachment (e.g., by querying the previous one). Figure 1 + summarizes the main idea of the optimization. + + +------+ + | pMAG | | + +------+ | + / | + / | + / | + / | + -*-*-*-*- / (MN) + ( ) / | + ( ) +-----+ +------+ | + ( Internet )--| LMA |------| nMAG | v + ( ) +-----+ +------+ + ( ) + -*-*-*-*- Registration + <-------------- + + Registration Ack + & Multicast Context + --------------> + + Figure 1: High-Level Description of the Solution + + The local mobility anchor only obtains the detailed subscription + information or multicast context during a handover event. There is + no need for continuously informing the LMA about MNs' multicast state + while the mobile nodes remain attached to the same mobile access + gateway. Such a continuous updating procedure would significantly + increase the signaling load within the PMIPv6 domain without a clear + benefit. The multicast context is only critical during handovers: + neither after nor before. Indicating the active subscription while + the handover is ongoing guarantees that such information will be up + to date and ready to be transferred to the new MAG where the mobile + node has just attached. Therefore, this solution defines the + Subscription Information Acquisition through the LMA (SIAL) as the + + + + +Contreras, et al. Experimental [Page 7] + +RFC 7161 PMIPv6 Multicast Handover Optimization March 2014 + + + procedure to inform the new MAG about the multicast subscriptions + maintained by the entering MN. + + To be able to transfer the multicast subscription information between + PMIPv6 entities during a handover, this document extends the PMIPv6 + protocol in several ways. First of all, a new mobility option is + defined to carry the multicast context of the current subscription. + Furthermore, additional messages are defined to manage the + interchange of the multicast information among PMIPv6 entities. + Finally, some flags are defined to govern the process. + +4. Proxy Mobile IPv6 Extensions + + This section outlines the extensions proposed to the PMIPv6 protocol + specified in [RFC5213]. + +4.1. Active Multicast Subscription Mobility Option + +4.1.1. Option Application Rules + + A new TLV-encoded mobility option, Active Multicast Subscription + option is defined for use with the Proxy Binding Update (PBU) and + Proxy Binding Acknowledgement (PBA) messages exchanged between a + local mobility anchor and a mobility access gateway to transfer the + multicast subscription information. This option is used for + exchanging the multicast membership context. This information is + carried by directly using the format defined in the original MLD + specifications. There can be multiple Active Multicast Subscription + options present in the message, one for each active subscription + maintained by the mobile node when the handover is taking place + (i.e., one per multicast membership context). + + This new option is also used for the same purposes by the new + Subscription Response message defined later in this document. + + MLDv2 [RFC3810] is the primary objective for the definition of the + option format. MLDv1 [RFC2710] is also considered for backward + compatibility. + + + + + + + + + + + + + +Contreras, et al. Experimental [Page 8] + +RFC 7161 PMIPv6 Multicast Handover Optimization March 2014 + + +4.1.2. Option Format + + The format of this new option is as follows: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | MLD Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + Multicast Membership Context + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The alignment requirement of this option is 8n+1. + + Type: + + 57, which indicates the Active Multicast Subscription IPv6 option. + + Length: + + 8-bit unsigned integer indicating the length of the option in + octets, excluding the type and length fields. + + MLD type: + + Field used to identify the IPv6 multicast membership protocol in + use, and the corresponding format of the next Multicast Membership + Context information field. This field maps the type codification + used in the original MLD specifications for the Report message. + For MLDv2, the MLD Type value is 143, as specified in [RFC3810]. + + Multicast Membership Context: + + Multicast subscription information corresponding to a single + subscribed multicast address. For MLDv2, the format of this field + follows the Multicast Address Record format as defined in + [RFC3810]. + +4.1.3. Backward Compatibility with MLDv1 + + The following values are adopted when MLDv1 is used. + + MLD type: + + For MLDv1, the MLD Type value is 131, as specified in [RFC2710]. + + + + +Contreras, et al. Experimental [Page 9] + +RFC 7161 PMIPv6 Multicast Handover Optimization March 2014 + + + Multicast Membership Context: + + For MLDv1, the relevant information for multicast context is + simply given, according to [RFC2710], by the multicast address of + the subscribed content. + + In consequence, the Multicast Membership Context is defined as a + 4-octet reserved field and the Multicast Address of the subscribed + content as in [RFC2710], as shown next. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + * * + | | + * Multicast Address * + | | + * * + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +4.2. Multicast Signaling Flag on PBU/PBA Message Headers + +4.2.1. Flag Application Rules + + A new flag S has been added in both the PBU and PBA message headers + to advertise the mobile access gateway and the local mobility anchor + capabilities of processing multicast-related signaling for the MN + that caused the message. + + This flag governs the multicast-related signaling between the LMA and + the MAG. As a general rule, the value of the flag in the PBA message + is a copy of the value received in the PBU message. Specific rules + are described in next subsections. + + + + + + + + + + + + + + +Contreras, et al. Experimental [Page 10] + +RFC 7161 PMIPv6 Multicast Handover Optimization March 2014 + + +4.2.1.1. Registration Process + + During handover, the entities involved in this process are the nMAG + and the LMA. These rules also apply for the initial binding + registration process. + + o PBU message + + * S=0 indicates that the MAG sending the PBU message does not + accept multicast-related signaling for the MN being attached. + This can be used to discriminate PMIPv6 nodes that are not + multicast enabled, for backward compatibility reasons. + + * S=1 indicates that the MAG sending the PBU message accepts + multicast-related signaling for the MN being attached. + Depending on the type of handover (reactive or proactive) the + LMA takes some actions, described later in this document. + + o PBA message + + * If S=0 in the corresponding PBU message, the value of the flag + in the PBA message MUST be a copy of the value received in the + PBU message (thus S=0), without any further meaning. + + * If S=1 in the corresponding PBU message, two subcases are + possible: + + + S=1 and Active Multicast Subscription mobility option in the + PBA message. When the MN maintains an active multicast + session, if the LMA is able to provide the multicast + subscription information during registration, the PBA + message MUST include the Active Multicast Subscription + mobility option. If the LMA is not able to provide such + information during registration, the PBA message MUST NOT + include the Active Multicast Subscription mobility option. + This case is useful to decouple unicast and multicast + signaling for an MN being registered at nMAG. A way for + obtaining later active multicast-subscription information is + described later in this document. + + + S=0 in the PBA message if the MN does not maintain an active + multicast subscription (note that for backward compatibility + reasons, an LMA not supporting multicast related signaling + would always send S=0). + + + + + + + +Contreras, et al. Experimental [Page 11] + +RFC 7161 PMIPv6 Multicast Handover Optimization March 2014 + + +4.2.1.2. De-registration Process + + During handover, the entities involved in this process are the pMAG + and the LMA. These rules apply for the binding de-registration + process. + + o PBU message + + * S=0 indicates that the MN has no active multicast session (note + that for backward compatibility reasons, a pMAG not supporting + multicast related signaling would always send S=0). + + * S=1 indicates that the MN has an active multicast session, and + the multicast context MUST be transported in the Active + Multicast Subscription mobility option. + + o PBA message + + * The value of the flag in the PBA message SHOULD be 0, without + any further meaning (note that for backward compatibility + reasons, an LMA not supporting multicast related signaling + would always send S=0). + +4.2.2. New Format of Conventional PBU/PBA Messages + +4.2.2.1. Proxy Binding Update Message + + As result of the new defined flag, the PBU message format is updated + as follows: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sequence # | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |A|H|L|K|M|R|P|S| Reserved | Lifetime | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + . . + . Mobility Options . + . . + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + + +Contreras, et al. Experimental [Page 12] + +RFC 7161 PMIPv6 Multicast Handover Optimization March 2014 + + +4.2.2.2. Proxy Binding Acknowledgement Message + + As result of the new defined flag, the PBA message format is updated + as follows: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Status |K|R|P|S| Rsrvd | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sequence # | Lifetime | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + . . + . Mobility Options . + . . + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +4.3. Messages for Active Multicast Subscription Query + + A new pair of messages is defined for querying entities about the + active multicast subscription of the MN when the handover is of + reactive type. + + These messages are sent using the Mobility Header as defined in + [RFC6275]. + +4.3.1. Subscription Query Message + +4.3.1.1. Message Application Rules + + The Subscription Query message (value 22) is sent by the LMA towards + the pMAG to query it about any existing multicast subscriptions of + the MN that is being registered by the nMAG. This message is + generated in case the handover is of reactive type. + + Additionally, this message is sent by the nMAG towards the LMA to + query it about the existing multicast subscriptions of the MN when + the LMA acknowledges the PBU sent by the nMAG but the multicast + context is not provided (namely, when the PBU message has set the + flag S to 1, and the PBA message has set the flag S to 1 but the + multicast context is missing). + + + + + + + + +Contreras, et al. Experimental [Page 13] + +RFC 7161 PMIPv6 Multicast Handover Optimization March 2014 + + +4.3.1.2. Message Format + + The Subscription Query message has the following format. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sequence # | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + . . + . Mobility Options . + . . + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Sequence Number: + + The Sequence Number field establishes the order of the messages + sent in the Subscription Query / Subscription Response dialogue + between the LMA and the MAG for a certain MN. The initial + Sequence Number MUST be determined by the entity that creates the + message (either LMA or MAG, depending on the scenario), which is + responsible for managing this counter. + + This Sequence Number comparison MUST be performed modulo 2**8, + i.e., the number is a free-running counter represented modulo 256. + A Sequence Number in a received Subscription Query message is + considered less than or equal to the last received number if its + value lies in the range of the last received number and the + preceding 128 values, inclusive. For example, if the last + received sequence number was 15, then messages with sequence + numbers 0 through 15, as well as 143 through 255, would be + considered less than or equal. + + Reserved: + + This field is unused for now. The value MUST be initialized to 0. + + Mobility options: + + This message carries one or more TLV-encoded mobility options. + The valid mobility options for this message are the following: + + * Mobile Node Identifier option [RFC4283] (mandatory). + + * Home Network Prefix option [RFC5213] (optional). + + + + +Contreras, et al. Experimental [Page 14] + +RFC 7161 PMIPv6 Multicast Handover Optimization March 2014 + + + There can be one or more instances of the Home Network Prefix + option, but only one instance of the Mobile Node Identifier + option. + +4.3.2. Subscription Response Message + +4.3.2.1. Message Application Rules + + The Subscription Response message (value 23) is sent by the pMAG + towards the LMA, or by the LMA towards the nMAG, to answer a + previously received Subscription Query message, as described above. + +4.3.2.2. Message Format + + The Subscription Response message has the following format. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sequence # |I| Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + . . + . Mobility Options . + . . + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Sequence Number: + + The value of the Sequence Number field in the Subscriber Response + message MUST be a copy of the Sequence Number received in the + Subscription Query message. + + Multicast Information (I): + + The multicast Information flag I specifies whether or not there is + multicast subscription information available for the MN. The + meaning is the following: + + I=0: there is no multicast subscription information available + for the MN identified by the Mobile Node Identifier option in + this message. + + I=1: there is multicast subscription information available for + the MN identified by the Mobile Node Identifier option in this + message. The multicast subscription information MUST be + + + + +Contreras, et al. Experimental [Page 15] + +RFC 7161 PMIPv6 Multicast Handover Optimization March 2014 + + + carried on one or more instances of the Active Multicast + Subscription option in this message (one instance for each + active subscription). + + Reserved: + + This field is unused for now. The value MUST be initialized to 0. + + Mobility options: + + This message carries one or more TLV-encoded mobility options. + The valid mobility options for this message are the following: + + * Mobile Node Identifier option [RFC4283] (mandatory). + + * Active Multicast Subscription option (mandatory) only when flag + I=1; it MUST NOT be present in any other case. + + * Home Network Prefix option [RFC5213] (optional). + + There can be one or more instances of the Home Network Prefix + option (in all cases) and the Active Multicast Subscription option + (only when I=1), but only one instance of the Mobile Node + Identifier option. + +4.4. New PBA Timer in the LMA + + A new timer named "PBA timer" is used in the LMA to define the + maximum waiting time before the PBA message is sent to the nMAG in + case the multicast subscription information relative to the MN is not + yet available. The aim of this timer is to prevent potential large + delays in the forwarding of unicast traffic towards the MN being + registered at the nMAG. This timer allows decoupling the unicast + signaling from the multicast one in the SIAL solution. + + This timer SHOULD be upper bounded by the constant defined in + [RFC6275] INITIAL_BINDACK_TIMEOUT, whose default value is 1 s. This + constant sets the time when the nMAG will retry the MN registration + by sending again the PBU message. The "PBA timer" has to be set to a + value that ensures that the nMAG does not enter the retry mode. + Operational experience is needed on how to set up the PBA timer, and + therefore it is RECOMMENDED to set the "PBA timer" to zero, except + for experimental purposes. + + + + + + + + +Contreras, et al. Experimental [Page 16] + +RFC 7161 PMIPv6 Multicast Handover Optimization March 2014 + + +5. Handover Signaling Procedures + + As the MN moves from one access gateway to another, the mobility- + related signaling due to the handover event is carried out + independently by the pMAG and the nMAG. That signaling process is + not synchronized; thus, two scenarios need to be considered depending + on the order in which the LMA receives notification of the MN + registration and de-registration in the nMAG and the pMAG, + respectively. + +5.1. Handover of Proactive Type + +5.1.1. Rationale + + In the proactive case, the MN is firstly de-registered by the pMAG, + and later on it is registered by the nMAG as a consequence of + changing the point of attachment. + + Only for those MNs that maintain an active multicast subscription, + the pMAG includes the Active Multicast Subscription mobility option + carrying the multicast context of the MN at that moment as part of + the PBU message (with flag S set to 1). + + The local mobility anchor stores that information in the + corresponding binding cache. If later on the MN attaches to an nMAG, + this information is sent (using the same TLV option) to the nMAG as + part of the PBA confirmation of the registration process (if the PBU + message sent by the nMAG has the flag S set to 1). On the other + hand, if no further registration happens, the multicast information + is removed together with the rest of binding database for that MN. + + After receiving the multicast context, the nMAG can subscribe to the + multicast flow(s) on behalf of the MN in case there is no other MN + already receiving it at the nMAG. The multicast status can also be + set in advance for the point-to-point link towards the MN. + + Note that the SIAL solution described here does not prevent + benefiting from extended support in the mobile node / network that + facilitates the proactive mode operation of the solution, e.g., based + on L2 capabilities. + + + + + + + + + + + +Contreras, et al. Experimental [Page 17] + +RFC 7161 PMIPv6 Multicast Handover Optimization March 2014 + + +5.1.2. Message Flow Description + + Figure 2 summarizes this process. + + +-----+ +----+ +-----+ +----+ + | MN | |pMAG| | LMA | |nMAG| + +-----+ +----+ +-----+ +----+ + | | | | + | |==Bi-Dir Tunnel=| | + | Multicast Data | | | + |<---------------| | | + | | | | + 1) MN Detached | | | + | MN Detached Event | | + | | | | + | |Ext'd DeReg PBU | | + 2) | |--------------->| | + | | | | + 3) | | Accept PBU | + | |(Multicast Subscription info stored) + | | | | + | | PBA | | + 4) | |<---------------| | + | | | | + 5) MN Attached | | | + | | | MN Attached Event + | | | | + | | | PBU | + 6) | | |<---------------| + | | | | + | | | Ext'd PBA | + 7) | | |--------------->| + | | | | + 8) | | | Accept PBA, + | | | Multicast Group join + | | | and P-t-P status setup + | | | | + | | |==Bi-Dir Tunnel=| + | | | | + | | | Multicast Data | + |<-------------------------------------------------| + | | | | + | | | | + + Figure 2: Proactive Handover + + + + + + +Contreras, et al. Experimental [Page 18] + +RFC 7161 PMIPv6 Multicast Handover Optimization March 2014 + + + The message flow is as follows: + + 1. A registered MN is receiving a multicast content that has been + previously subscribed to by sending a standard MLD report from + the mobile node to the currently serving mobile access gateway, + pMAG. The pMAG keeps the multicast state of the point-to-point + link with the MN. + + 2. The MN initiates a handover process (e.g., because of better + radio conditions) over a radio access controlled by a new MAG. + As a consequence, pMAG determines a detachment event + corresponding to this mobile node, and updates the attachment + status of this MN to the local mobility anchor by sending an + extended Proxy Binding Update message, including the Active + Multicast Subscription, which contains the multicast context of + the active multicast subscriptions in the moment of handover. + + 3. The LMA processes the PBU message. Additionally, the LMA stores + in the binding cache the information regarding the ongoing + multicast subscription(s) when the detachment is initiated. This + information is kept until a new registration of the MN is + completed by another MAG, or until the binding cache expiration, + according to [RFC5213]. + + 4. The local mobility anchor acknowledges to the pMAG the previous + PBU message. + + 5. As a result of the handover process, the mobile node attaches to + another mobility access gateway, called nMAG. + + 6. The nMAG triggers a registration process by sending a PBU message + (with flag S set to 1) to the local mobility anchor. + + 7. After the analysis of the PBU message, the LMA sends an extended + PBA including the Active Multicast Subscription option, which + contains the multicast context of the active subscriptions in the + moment of handover. + + 8. The nMAG processes the PBA message following all the standard + procedures described in [RFC5213]. Additionally, with the new + information relative to multicast subscription, the nMAG sets up + the multicast status of the point-to-point link between the nMAG + and the MN, and joins the content identified by (S,G) on behalf + of the MN in case the nMAG is not receiving already such content + due to a previous subscription ordered by another MN attached to + it. From that instant, the multicast content is served to the + MN. + + + + +Contreras, et al. Experimental [Page 19] + +RFC 7161 PMIPv6 Multicast Handover Optimization March 2014 + + +5.2. Handover of Reactive Type + +5.2.1. Rationale + + In the reactive case, the LMA receives the mobile node registration + from the nMAG without having previously received the MN de- + registration from the pMAG. + + As the nMAG is not aware of any active multicast subscription of the + mobile node, the nMAG starts a conventional registration process, by + sending a normal PBU message (with flag S set to 1) towards the local + mobility anchor. + + In the reactive handover case, after MN registration at the nMAG, the + local mobility anchor SHOULD generically query the pMAG to retrieve + the multicast context of the ongoing multicast subscription of the + mobile node. However, the LMA may know in advance if the pMAG + supports multicast signaling based on the value of the flag S + received during the MN registration in pMAG. Specifically, in case + the pMAG does not support multicast signaling (e.g., the S flag value + received from pMAG at the time of registering the mobile node was 0), + the LMA MAY decide not to query pMAG even in the case of receiving an + nMAG indication of supporting multicast signaling. + + Once the multicast subscription information is retrieved from the + pMAG, the LMA encapsulates it in the PBA message by using the TLV + option Active Multicast Subscription and forwards the PBA message to + the nMAG. Then, the nMAG can subscribe the multicast flow on behalf + of the MN, if there is no other mobile node receiving it already at + the nMAG. The multicast status can be also set in advance for the + point-to-point link towards the mobile node. + + + + + + + + + + + + + + + + + + + + +Contreras, et al. Experimental [Page 20] + +RFC 7161 PMIPv6 Multicast Handover Optimization March 2014 + + +5.2.2. Message Flow Description + + Figure 3 summarizes this process. + + +-----+ +----+ +-----+ +----+ + | MN | |pMAG| | LMA | |nMAG| + +-----+ +----+ +-----+ +----+ + | | | | + | | | MN Attached Event + | | | | + | | | PBU | + 1) | | |<---------------| + | | | | + | | Subscr Query | | + 2) | |<---------------| | + | | | | + | | Subscr Resp | | + 3) | |--------------->| | + | | | | + | | (Multicast Subscription | + | | info forwarding) | + | | | | + | | | Ext'd PBA | + 4) | | |--------------->| + | | | | + 5) | | | Accept PBA, + | | | Multicast Group join + | | | and P-t-P status setup + | | | | + | | |==Bi-Dir Tunnel=| + | | | | + | | | (S,G) Data | + |<-------------------------------------------------| + | | | | + | | | | + + Figure 3: Reactive Handover + + We next take as starting point the situation where an MN is attached + to the pMAG, being multicast enabled and maintaining an active + multicast subscription at this moment. + + The sequence of messages for the handover of the mobile node is the + following (as depicted in Figure 3): + + 1. At a certain time, the MN initiates a handover process (e.g., + because of better radio conditions) over a radio access + controlled by a new MAG. Then, the nMAG triggers a registration + + + +Contreras, et al. Experimental [Page 21] + +RFC 7161 PMIPv6 Multicast Handover Optimization March 2014 + + + process by sending a PBU message (with flag S set to 1) to the + local mobility anchor. As it is a reactive case, the pMAG is not + aware of the detachment process. + + 2. Prior to acknowledging the received PBU message, the LMA queries + the pMAG about if there is any active multicast subscription for + the MN, by sending a Subscription Query message. + + 3. The pMAG answers the LMA with a Subscription Response message + including the multicast context of the existing subscriptions. + + 4. After processing the pMAG answer, the LMA acknowledges (with flag + S set to 1) the PBU message, including the multicast subscription + information within the Active Multicast Subscription option. The + nMAG then processes the extended PBA message. + + 5. The nMAG processes the PBA message, and it proceeds to set up the + multicast status of the point-to-point link between the nMAG and + the mobile node, and to join the content identified by (S,G) on + behalf of the MN in case the nMAG is not receiving already such + content. The bidirectional tunnel is also set up between the + nMAG and the local mobility anchor if it has not been established + before by another MN connection. At this moment, the multicast + content can be served to the MN. The unicast traffic for the + mobile node can be forwarded as well. + +5.2.3. Further Considerations for the Reactive Handover Signaling + + A handover event is managed independently by the pMAG and nMAG. It + is not a synchronized process. In a reactive handover, the LMA + receives a registration PBU from nMAG before a de-registration PBU is + received from pMAG. + + In the message flows detailed above, it could be the case that the + LMA receives a de-registration PBU from pMAG just after sending the + Subscription Query message, but before receiving the Subscription + Response message. That de-registration PBU message from pMAG carries + the multicast subscription information required to assist the MN in + the handover, so such valuable information SHOULD be kept by the LMA. + Furthermore, it is possible that once the Subscription Query message + arrives to pMAG, the pMAG could have already removed the multicast + related information for the MN. + + In order to avoid losing the multicast subscription information sent + in the de-registration PBU message, the local mobility anchor SHOULD + store it, and SHOULD include it in the PBA message towards the nMAG + in case the Subscription Response message from the pMAG does not + contain multicast subscription information for the mobile node. + + + +Contreras, et al. Experimental [Page 22] + +RFC 7161 PMIPv6 Multicast Handover Optimization March 2014 + + +5.3. Prevention of Large Delays of the Binding Acknowledgement for + Unicast Traffic + + According to the message sequences described for the reactive + handover case, in case the LMA has to request the multicast + subscription information from the pMAG, the binding request sent by + the nMAG is maintained on-hold until the local mobility anchor + receives, processes and includes the multicast subscription + information into the extended PBA message. As a consequence, the + unicast traffic may then suffer an extra delay motivated by the + multicast-related signaling. During that time, the unicast traffic + with destination the MN being registered by the nMAG MAY be buffered + by the local mobility anchor. + + In order to avoid any potential large delay in the forwarding of + unicast traffic arriving at the LMA towards the MN, a mechanism + SHOULD be implemented to decouple multicast from unicast traffic + reception by the MN. Figure 4 shows this mechanism. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Contreras, et al. Experimental [Page 23] + +RFC 7161 PMIPv6 Multicast Handover Optimization March 2014 + + + +-----+ +----+ +-----+ +----+ + | MN | |pMAG| | LMA | |nMAG| + +-----+ +----+ +-----+ +----+ + 1) | |==Bi-Dir Tunnel=| | + | unicast data | | | + |<-v-v-v-v-v-v-v-| | | + | | | | + | Multicast Data | | | + |<---------------| | | + | | | MN Attached Event + | | | PBU | + 2) | | |<---------------| + | | Subscr Query | | + 3) | |<---------------| | + | | | | + 4) | | <PBA timer starts> | + | | /// | + | | /// | + 5) | | <PBA timer expires> | + | | | | + | | | Ext'd PBA | + | | |--------------->| + | | | | + | | | Accept PBA + | | | | + | | |==Bi-Dir Tunnel=| + | | | | + | | | Unicast Data | + |<-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-| + | | | | + | | | Subscr Query | + 6) | | |<---------------| + | | Subscr Resp | | + 7) | |--------------->| | + | | | | + | | (Multicast Subscription | + | | info forwarding) | + | | | | + | | | Subscr Resp | + 8) | | |--------------->| + | | | | + | | | Multicast Group join + | | | and P-t-P status setup + | | Multicast Data | | + |<-------------------------------------------------| + | | | | + + Figure 4: Decoupling of Unicast and Multicast Signaling + + + +Contreras, et al. Experimental [Page 24] + +RFC 7161 PMIPv6 Multicast Handover Optimization March 2014 + + + The sequence of messages is the following: + + 1. An MN is attached to the pMAG. The MN is a multicast-enabled + node, and it is receiving both unicast and multicast traffic + simultaneously. + + 2. Some time later, The MN initiates a handover process (e.g., + because of better radio conditions) over a radio access + controlled by a new mobile access gateway. Then, the nMAG + triggers a registration process by sending a PBU message (with + flag S set to 1) to the local mobility anchor. As it is a + reactive case, the pMAG is not aware of the detachment process. + + 3. Prior to acknowledging the received PBU message, the LMA decides + to query the pMAG about if there is any active multicast + subscription for the mobile node, by sending a Subscription Query + message. + + 4. Immediately after sending the Subscription Query message, the LMA + starts the timer "PBA timer", which determines the maximum + waiting time before the PBA is sent to avoid any potential large + delay in the forwarding of unicast traffic towards the MN. + + 5. In case the "PBA timer" expires, the LMA acknowledges the PBU + message, by sending the PBA message with flag S=1, without the + multicast context information. The nMAG then processes the + extended PBA message. Such acknowledgement allows the mobile + node to receive the unicast traffic from that time on. The + bidirectional tunnel is also set up between the nMAG and the LMA + if it has not been established before. + + 6. In parallel, the nMAG sends a Subscription Query message to the + LMA requesting the multicast-subscription details yet unknown for + the mobile node. + + 7. The pMAG answers the Subscription Query message originally sent + by the local mobility anchor, including the multicast context. + + 8. After processing the pMAG answer, the LMA sends a Subscription + Response message to the nMAG, including the multicast + subscription information within the Active Multicast Subscription + option. The nMAG processes the PBA message, and it proceeds to + set up the multicast status of the point-to-point link between + the nMAG and the mobile node, and to join the content identified + by (S,G) on behalf of the MN in case the nMAG is not receiving + already such content. The bidirectional tunnel is also set up + + + + + +Contreras, et al. Experimental [Page 25] + +RFC 7161 PMIPv6 Multicast Handover Optimization March 2014 + + + between the nMAG and the LMA if it has not been established + before. At this moment, the multicast content can also be served + to the mobile node. + + The "PBA timer" in the LMA determines if the signaling flow follows + Figure 3 or Figure 4 in a reactive handover. A value of 0 for the + "PBA timer" guarantees that the unicast traffic does not suffer any + delay (according to the Figure 4 signaling flow), because the PBA is + sent immediately after the LMA receives the PBU from the nMAG. A + small non-zero "PBA timer" value MAY be used to reduce the signaling + load in the LMA and MAGs (as shown in the signaling flow of Figure 3 + if the Subscription Response message from the pMAG is received at the + LMA before the "PBA timer" expires), but this has to be carefully + balanced against added delay to the unicast traffic. + +6. IPv4 Support + + IPv4-based mobile nodes (being either IPv4/IPv6 dual-stack or + IPv4-only enabled) can be supported in a PMIPv6 domain according to + [RFC5844]. When referring to multicast membership protocols and + procedures, this means that IGMP functionality has to be also + supported between the PMIPv6 entities, as documented in [RFC6224], to + allow the mobile access gateway requesting multicast contents to the + mobility anchor on behalf of the mobile nodes attached to it. + +6.1. Active Multicast Subscription for IPv4 + + The Active Multicast Subscription option defined in Section 4.1, + which transports the multicast membership context of the mobile node + during handover, should be compatible with IGMP-based formats. + Specifically, the option format is defined for IPv4-based MNs as + follows: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | IGMP Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + Multicast Membership Context + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + IGMPv3 is the primary objective for the definition of the option + format. IGMPv1 and IGMPv2 are also considered for backward + compatibility. The alignment requirement of this option is 4n+1. + + + + + +Contreras, et al. Experimental [Page 26] + +RFC 7161 PMIPv6 Multicast Handover Optimization March 2014 + + + Type: + + 56, which indicates the Active Multicast Subscription IPv4 option. + + Length: + + 8-bit unsigned integer indicating the length of the option in + octets, excluding the type and length fields. + + IGMP type: + + Field used to identify the IPv4 multicast membership protocol in + use, and the corresponding format of the next Multicast Membership + Context information field. This field maps the type codification + used in the original IGMP specifications for the Report message. + + 0x12: Use of IGMPv1 multicast membership protocol. + + 0x16: Use of IGMPv2 multicast membership protocol. + + 0x22: Use of IGMPv3 multicast membership protocol. + + Multicast Membership Context: + + Multicast subscription information corresponding to a single + subscribed multicast address. Depending on the IGMP version being + used by the mobile node, the format of the Multicast Membership + Context could follow the following formats: + + * For IGMPv1, the Group Address format as defined in [RFC1112]. + + * For IGMPv2, the Group Address format as defined in [RFC2236]. + + * For IGMPv3, the Group Record format as defined in [RFC3376]. + +6.2. Signaling Procedures for IPv4 Support + + Generic signaling procedures for the support of IPv4 in PMIPv6 + domains have been already specified in [RFC5844]. In order to + prevent errors while signaling the ongoing multicast subscription for + a mobile node during the handover process, the following extensions + have to be considered in SIAL. + + o If the registration/de-registration process in a handover is for + an IPv6-only MN, and the type of the received Active Multicast + Subscription option indicates IPv4, then the multicast membership + context received MUST be silently discarded. + + + + +Contreras, et al. Experimental [Page 27] + +RFC 7161 PMIPv6 Multicast Handover Optimization March 2014 + + + o If the registration/de-registration process in a handover is for + an IPv4-only MN, and the type of the received Active Multicast + Subscription option indicates IPv6, then the multicast membership + context received MUST be silently discarded. + + o If the registration/de-registration process in a handover is for a + dual stack MN, the received Active Multicast Subscription option + (or options) MUST be accepted independently of the type + indication. + +6.3. Binding Cache Extensions for IPv4 Support + + Additionally, since the multicast membership information is + temporally stored in the mobility anchor under some circumstances + (e.g., proactive handover), the binding cache entry for an IPv4-based + multicast-enabled MN should be extended for storing the IGMP-based + context formats mentioned above, including the IGMP version + indicator. + +7. Coexistence with PMIPv6 Multicast Architectural Evolutions + + Throughout this document, the base solution for multicast support in + Proxy Mobile IPv6, described in [RFC6224], has been implicitly + considered, i.e., both unicast and multicast traffic addressing a + mobile node is delivered via the standard PMIPv6 bidirectional tunnel + between LMA and MAG. While here all multicast traffic is assumed to + be delivered via the local mobility anchor, the SIAL approach + described in this document can be also applied to other solutions in + which the multicast content is served from other entities in the + PMIPv6 domain, as described in [RFC7028] to solve the tunnel + convergence problem. + + In this case, the transfer of the multicast context would also pass + through the local mobility anchor, as described here. However, the + nMAG subscribes to the multicast content through the node in charge + of distributing multicast according to the adopted solution for + multicast distribution in the PMIPv6 domain. + +8. Security Considerations + + This proposal does not pose any additional security threats to those + already identified in [RFC5213]. All the security considerations in + [RFC5213] are directly applicable to this protocol. The signaling + messages, Proxy Binding Update, and Proxy Binding Acknowledgement + (extended with the new options defined in this document), the + Subscription Query Message, and the Subscription Response Message + + + + + +Contreras, et al. Experimental [Page 28] + +RFC 7161 PMIPv6 Multicast Handover Optimization March 2014 + + + exchanged between the mobile access gateway and the local mobility + anchor, MUST be protected using end-to-end security association(s) + offering integrity and data origin authentication. + + The mobile access gateway and the local mobility anchor MUST + implement the IPsec security mechanism mandated by Proxy Mobile IPv6 + [RFC5213] to secure the signaling described in this document. In the + following, we describe the Security Policy Database (SPD) and + Security Association Database (SAD) entries necessary to protect the + new signaling introduced by this specification (Subscription Query + Message and Subscription Response Message). We use the same format + used by [RFC4877]. The SPD and SAD entries are only example + configurations. A particular mobile access gateway implementation + and a local mobility anchor home agent implementation could configure + different SPD and SAD entries as long as they provide the required + security of the signaling messages. + + For the examples described in this document, a mobile access gateway + with address "mag_address_1", and a local mobility anchor with + address "lma_address_1" are assumed. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Contreras, et al. Experimental [Page 29] + +RFC 7161 PMIPv6 Multicast Handover Optimization March 2014 + + + mobile access gateway SPD-S: + - IF local_address = mag_address_1 & + remote_address = lma_address_1 & + proto = MH & (remote_mh_type = Subscription Query | + local_mh_type = Subscription Response | + remote_mh_type = Multicast Activity Indication Ack.| + local_mh_type = Multicast Activity Indication) + Then use SA1 (OUT) and SA2 (IN) + + mobile access gateway SAD: + - SA1(OUT, spi_a, lma_address_1, ESP, TRANSPORT): + local_address = mag_address_1 & + remote_address = lma_address_1 & + proto = MH + - SA2(IN, spi_b, mag_address_1, ESP, TRANSPORT): + local_address = lma_address_1 & + remote_address = mag_address_1 & + proto = MH + + local mobility anchor SPD-S: + - IF local_address = lma_address_1 & + remote_address =mag_address_1 & + proto = MH & (remote_mh_type = Subscription Response | + local_mh_type = Subscription Query | + remote_mh_type = Multicast Activity Indication | + local_mh_type = Multicast Activity Indication Ack.) + Then use SA2 (OUT) and SA1 (IN) + + local mobility anchor SAD: + - SA2(OUT, spi_b, mag_address_1, ESP, TRANSPORT): + local_address = lma_address_1 & + remote_address = mag_address_1 & + proto = MH + - SA1(IN, spi_a, lma_address_1, ESP, TRANSPORT): + local_address = mag_address_1 & + remote_address = lma_address_1 & + proto = MH + + While in the base solution the LMA has learned of the subscribed + multicast groups per MAG, in this specification the LMA is aware + (during a handover process) of the multicast groups to which an MN + visiting the PMIP domain is subscribed. + + + + + + + + + +Contreras, et al. Experimental [Page 30] + +RFC 7161 PMIPv6 Multicast Handover Optimization March 2014 + + +9. IANA Considerations + + This document establishes new assignments to the IANA mobility + parameters registry. + + o Mobility Header types: the Subscription Query (22) and + Subscription Response (23) mobility header types. The Type value + for these Headers has been assigned from the "Mobility Header + Types - for the MH Type field in the Mobility Header" registry + defined in <http://www.iana.org/assignments/mobility-parameters>. + + o Mobility options: the Active Multicast Subscription mobility + option for both IPv4 (56) and IPv6 (57) modes of operation. The + Type value for these Mobility options has been assigned from the + "Mobility Options" registry defined in <http://www.iana.org/ + assignments/mobility-parameters>. + + o Flags: this document reserves a new multicast Signaling flag (S). + This flag has been reserved as value 0x0020 in the "Binding Update + Flags" registry and value 0x04 in the "Binding Acknowledgment + Flags" registry. These registries appear on <http://www.iana.org/ + assignments/mobility-parameters>. + +10. Contributors + + Dirk Von Hugo (Telekom Innovation Laboratories, + Dirk.von-Hugo@telekom.de) extensively contributed to this document. + +11. Acknowledgments + + The authors would like to thank (in alphabetical order) Hitoshi + Asaeda, Sergio Figueiredo, Georgios Karagiannis, Marco Liebsch, + Behcet Sarikaya, Thomas C. Schmidt, and Stig Venaas for their + valuable comments and discussions on the MULTIMOB mailing list. The + authors are also grateful with Hitoshi Asaeda, Akbar Rahman, Behcet + Sarikaya, and Stig Venaas for their reviews of this document. + + The research of Carlos J. Bernardos leading to these results has + received funding from the European Community's Seventh Framework + Programme (FP7-ICT-2009-5) under grant agreement n. 258053 (MEDIEVAL + project), being also partially supported by the Ministry of Science + and Innovation (MICINN) of Spain under the QUARTET project (TIN2009- + 13992-C02-01). + + The research of Ignacio Soto has also received funding from the + Spanish MICINN through the I-MOVING project (TEC2010-18907). + + + + + +Contreras, et al. Experimental [Page 31] + +RFC 7161 PMIPv6 Multicast Handover Optimization March 2014 + + +12. References + +12.1. Normative References + + [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, + RFC 1112, August 1989. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2236] Fenner, W., "Internet Group Management Protocol, Version + 2", RFC 2236, November 1997. + + [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast + Listener Discovery (MLD) for IPv6", RFC 2710, October + 1999. + + [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. + Thyagarajan, "Internet Group Management Protocol, Version + 3", RFC 3376, October 2002. + + [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery + Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. + + [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. + Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 + (MIPv6)", RFC 4283, November 2005. + + [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with + IKEv2 and the Revised IPsec Architecture", RFC 4877, April + 2007. + + [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., + and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. + + [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy + Mobile IPv6", RFC 5844, May 2010. + + [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support + in IPv6", RFC 6275, July 2011. + +12.2. Informative References + + [Papagiannaki] + Papagiannaki, K., Moon, S., Fraliegh, C., Thiran, P., and + C. Diot, "Measurement and Analysis of Single-Hop Delay on + an IP Backbone Network", IEEE Journal on Selected Areas in + Communications, vol. 21, no. 6, August 2003. + + + +Contreras, et al. Experimental [Page 32] + +RFC 7161 PMIPv6 Multicast Handover Optimization March 2014 + + + [RFC5949] Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F. + Xia, "Fast Handovers for Proxy Mobile IPv6", RFC 5949, + September 2010. + + [RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base + Deployment for Multicast Listener Support in Proxy Mobile + IPv6 (PMIPv6) Domains", RFC 6224, April 2011. + + [RFC6636] Asaeda, H., Liu, H., and Q. Wu, "Tuning the Behavior of + the Internet Group Management Protocol (IGMP) and + Multicast Listener Discovery (MLD) for Routers in Mobile + and Wireless Networks", RFC 6636, May 2012. + + [RFC7028] Zuniga, JC., Contreras, LM., Bernardos, CJ., Jeon, S., and + Y. Kim, "Multicast Mobility Routing Optimizations for + Proxy Mobile IPv6", RFC 7028, September 2013. + + [Verizon] Verizon, "LTE: The Future of Mobile Broadband Technology", + Verizon White Paper, 2010, + <http://opennetwork.verizonwireless.com/pdfs/ + VZW_LTE_White_Paper_12-10.pdf>. + + [Y.1541] ITU-T, "Network performance objectives for IP-based + services", ITU-T Recommendation Y.1541, December 2011. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Contreras, et al. Experimental [Page 33] + +RFC 7161 PMIPv6 Multicast Handover Optimization March 2014 + + +Appendix A. Performance Comparison with Base Solution + + This informative annex briefly analyzes and compares the performance + improvement provided by the fast handover extensions specified in + this document with the base multicast solution defined in [RFC6224]. + The main aim is to determine the potential delay reduction in the + acquisition of the multicast subscription information by the nMAG + during the MN handover. To do that, the analysis focuses on the + delay additional to the unicast handover due to the multicast + operation in both cases. + + Different delay components have to be taken into account for this + comparison. Since the interaction between the actors during the + handover process (MN, pMAG, nMAG, LMA) is different for each of the + solutions, different sources of delay can be expected for each of + them. + +A.1. Delay Characterization of the Base Solution + + The base solution relies on the standard MLD procedures to obtain the + multicast subscription information directly from the MN. Once the + nMAG completes the configuration of point-to-point link to the + attaching MN (the configuration of this link as downstream interface + of an MLD proxy instance can run in parallel), it immediately sends + an MLD General Query towards the MN for learning of any active + multicast subscription by the MN. When the MN receives the MLD + Query, the MN provides information about the active memberships it + maintains in the form of an MLD Report message. After successful + transmission of this information via the wireless point of attachment + to nMAG, the corresponding MLD proxy instance at the nMAG sets up the + multicast status of the downstream interface. According to this + process, the delay is originated on the MAG-MN communication. + + The delay components to be considered for the base solution are the + following: + + o D_bh, which is the unidirectional (one-way) delay encountered in + the transmission path between the nMAG and the wireless point of + attachment. + + o D_radio, which is the unidirectional delay due to the transfer of + MLD control messages over the radio channel (user plane) between + the wireless point of attachment and the MN, for the MLD Query and + Report messages. + + o D_mld, which is the delay incurred by the MN to answer the MLD + Query. + + + + +Contreras, et al. Experimental [Page 34] + +RFC 7161 PMIPv6 Multicast Handover Optimization March 2014 + + + The total observed delay can be then formulated as: + + D_base = 2 x (D_bh + D_radio) + D_mld + +A.2. Delay Characterization of SIAL + + As described in this document, it is possible to distinguish two + scenarios depending on the order in which the LMA receives the + notifications of the MN registration and de-registration in the nMAG + and the pMAG, respectively. + + In the proactive case, the MN is firstly de-registered by the pMAG, + and later on it is registered by the nMAG. As specified in this + document, the LMA stores the multicast subscription information, + which is provided to the nMAG during the MN registration process. + Since the registration process necessarily happens before the MLD + Query and Report process described in the base solution, the + proactive case is inherently faster than the base solution. In fact, + since the multicast subscription information is acquired properly + during the registration process, the delay incurred is null. + + In the reactive case, the LMA receives the MN registration from the + nMAG without having previously received the MN de-registration from + the pMAG. In case the MN maintains an active subscription, the LMA + queries the pMAG to retrieve the multicast subscription information, + which is forwarded to the nMAG. According to this process, the delay + is originated on the MAG-LMA communication. + + The delay components to be considered for the base solution are the + following: + + o D_net, which is the unidirectional delay found in the network path + between the LMA and the MAG. + + The total observed delay can be then formulated as: + + D_sial = 2 x D_net + +A.3. Performance Comparison + + The performance of the base solution is highly dependent on the radio + technology used by the MN to attach to the PMIPv6 domain. Different + radio technologies have distinct properties in terms of radio + framing, radio access contention or collision avoidance, channel + reliability, etc. + + + + + + +Contreras, et al. Experimental [Page 35] + +RFC 7161 PMIPv6 Multicast Handover Optimization March 2014 + + + New radio access technologies, such as the one specified in new Long + Term Evolution (LTE) standards intend to reduce the latency in order + to provide high-speed communications. Even though, typical one-way + latencies in the LTE radio access will stay around 15 ms [Verizon]. + + The backhaul delay characterization becomes problematic. In a real + network, there are several solutions for the backhaul connection in + terms of network topology (ring, star, point-to-point, etc.) and + technology (optical fiber, microwave transmission, xDSL-based + accesses, etc.), all of them having distinct properties in terms of + performance, reliability, and delay. These solutions commonly + coexist in a real mobile network, in such a way that an MN changing + the point of attachment can pass smoothly from one solution to + another. A value of D_bh = 5 ms can be established as the typical + value for the backhaul latency in modern networks. + + Finally, the MLD induced delay is intrinsic to the MLD protocol + specification. A host receiving an MLD Query message waits a random + time in the range (0, Maximum Response Delay) to send the MLD Report + message. The default value of the Maximum Response Delay + (configurable through the Query Response Interval in MLD) is 10 s in + [RFC2710] and [RFC3810]. In [RFC6636] the effect of tuning the value + of the Query Response Interval is analyzed and 5 s is the smallest + value recommended (best case). Then, on average, a potential delay + of 5 s or 2.5 s, default and best case respectively, can be expected. + + As we have seen, D_base is, on average, greater than 2.5 s with the + best case of the values of Query Response Interval in MLD that are + recommended in [RFC6636]. That means that the handover delay of the + base solution is on the order of seconds, while in the solution + presented in this specification it is on the order of milliseconds + (as shown below). To improve the performance of the base solution, + we could further reduce the value of Query Response Interval, but the + implications of doing so would need to be carefully analyzed. Even + if we assume that Query Response Interval is 0 s, D_base would be + around 2 x (5 ms + 15 ms) = 40 ms for last-generation systems. Note + that this calculation does not take into account the necessary time + to re-establish the data plane after the handover to make possible + the MLD Query reception. The expected delay will get much worse for + older generation systems (e.g., 3G-based radio systems can suffer + radio delays in the order of hundreds of ms). + + For the SIAL case, the delay in the MAG-LMA communication will be + derived from the network diameter (i.e., the number of hops found + between the MAG and the LMA in the PMIPv6 domain). This is largely + influenced by the internal network planning. An administrative + domain can typically have in the order of five hops from access to + the interconnection gateway providing connectivity to other networks. + + + +Contreras, et al. Experimental [Page 36] + +RFC 7161 PMIPv6 Multicast Handover Optimization March 2014 + + + Even if the LMA plays a central role topologically in the PMIPv6 + domain, such number of hops seems reasonable in a common nation-wide + network. Each hop in the path between MAG and LMA will add a certain + delay, which can be estimated to be around 1 ms in the best case + [Papagiannaki] and 3 ms in the worst case [Y.1541]. With this in + mind, a total delay D_sial of around 2 x 5 x 3 ms = 30 ms can be + expected in the worst case. + + Then, in conclusion, in a typical deployment, it can be stated that + the SIAL proposal, even for the worst-case consideration, will + perform better than the best-case situation for the base solution, + which consists of the last-generation radio technology, LTE. For any + other radio technology, the base solution will show even larger + deviations from the delay achievable with the SIAL solution. + +Authors' Addresses + + Luis M. Contreras + Telefonica I+D + Ronda de la Comunicacion, s/n + Sur-3 building, 3rd floor + Madrid 28050 + Spain + + EMail: lmcm@tid.es + + + Carlos J. Bernardos + Universidad Carlos III de Madrid + Av. Universidad, 30 + Leganes, Madrid 28911 + Spain + + Phone: +34 91624 6236 + EMail: cjbc@it.uc3m.es + URI: http://www.it.uc3m.es/cjbc/ + + + Ignacio Soto + Universidad Carlos III de Madrid + Av. Universidad, 30 + Leganes, Madrid 28911 + Spain + + EMail: isoto@it.uc3m.es + + + + + + +Contreras, et al. Experimental [Page 37] + |