doc: Add RFC documents

1 files changed, 1291 insertions, 0 deletions

diff --git a/doc/rfc/rfc6602.txt b/doc/rfc/rfc6602.txt
new file mode 100644
index 0000000..facedd3
--- /dev/null
+++ b/doc/rfc/rfc6602.txt
@@ -0,0 +1,1291 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                  F. Abinader, Ed.
+Request for Comments: 6602                 Instituto Nokia de Tecnologia
+Category: Standards Track                             S. Gundavelli, Ed.
+ISSN: 2070-1721                                                 K. Leung
+                                                                   Cisco
+                                                             S. Krishnan
+                                                                Ericsson
+                                                               D. Premec
+                                                            Unaffiliated
+                                                                May 2012
+
+
+           Bulk Binding Update Support for Proxy Mobile IPv6
+
+Abstract
+
+   For extending the lifetime of a mobility session, the Proxy Mobile
+   IPv6 specification requires the mobile access gateway to send a Proxy
+   Binding Update message to the local mobility anchor on a per-session
+   basis.  In the absence of signaling semantics for performing
+   operations with group-specific scope, this results in a significant
+   amount of signaling traffic on a periodic basis between a given
+   mobile access gateway and a local mobility anchor.  This document
+   defines optimizations to the binding update and revocation operations
+   in Proxy Mobile IPv6 for performing operations with group-specific
+   scope with the use of a group identifier.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   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).  Further information on
+   Internet Standards is available in 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/rfc6602.
+
+Copyright Notice
+
+   Copyright (c) 2012 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+
+
+
+
+
+Abinader, et al.             Standards Track                    [Page 1]
+
+RFC 6602               Bulk Binding Update Support              May 2012
+
+
+   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
+   2. Conventions and Terminology .....................................4
+      2.1. Conventions ................................................4
+      2.2. Terminology ................................................4
+   3. Bulk Binding Update Overview ....................................4
+      3.1. Motivation .................................................4
+      3.2. General Operation ..........................................5
+   4. Message Formats .................................................8
+      4.1. Extensions to Proxy Binding Update Message .................9
+      4.2. Extensions to Proxy Binding Acknowledgement Message .......10
+      4.3. Mobile Node Group Identifier Option .......................10
+      4.4. Status Codes ..............................................11
+   5. Protocol Considerations ........................................12
+      5.1. MAG Considerations ........................................12
+           5.1.1. Extensions to Binding Update List Entry
+                  Data Structure .....................................12
+           5.1.2. Requesting Bulk Binding Update Support for
+                  a Mobility Session .................................12
+           5.1.3. Supporting Bulk Binding Updates ....................14
+      5.2. LMA Considerations ........................................15
+           5.2.1. Extensions to Binding Cache Entry Data Structure ...15
+           5.2.2. Enabling Bulk Binding Update Support for a
+                  Mobility Session ...................................16
+           5.2.3. Supporting Bulk Binding Updates ....................18
+   6. Protocol Configuration Variables ...............................20
+      6.1. Local Mobility Anchor - Configuration Variables ...........20
+      6.2. Mobile Access Gateway - Configuration Variables ...........20
+   7. IANA Considerations ............................................20
+   8. Security Considerations ........................................21
+   9. Acknowledgements ...............................................21
+   10. References ....................................................22
+      10.1. Normative References .....................................22
+      10.2. Informative References ...................................22
+
+
+
+
+
+
+Abinader, et al.             Standards Track                    [Page 2]
+
+RFC 6602               Bulk Binding Update Support              May 2012
+
+
+1.  Introduction
+
+   The Proxy Mobile IPv6 base specification [RFC5213] requires the
+   Mobile Node Identifier option to be present in the mobility signaling
+   messages, such as in the Proxy Binding Update (PBU) and Proxy Binding
+   Acknowledgement (PBA) messages.  It essentially limits the
+   operational scope of the binding update operation to a single
+   mobility session.  These signaling messages lack the capability to
+   identify a group of mobility sessions, so the operations related to
+   binding update and revocation can be performed on all the mobility
+   sessions that are part of that group.
+
+   There is a need to have semantics for associating a group identity to
+   a mobility session, so the scope of the operations related to binding
+   update and revocation can be extended to all the mobility sessions
+   identified by the group identifier.  The group identifier therefore
+   provides a considerably improved mechanism for protocol operations
+   that would otherwise require multiple atomic transactions on a per-
+   mobility-session basis.  Following are some of the use cases where
+   the group identifier can be used.
+
+   o  For extending the lifetime of a mobility session, the mobile
+      access gateway (MAG) periodically sends a Proxy Binding Update
+      message to the local mobility anchor (LMA) on a per-session basis.
+      This process can be optimized by allowing the mobile access
+      gateway to send a single Proxy Binding Update [RFC5213] message
+      for a group of mobility sessions identified by a group identifier.
+      Upon accepting the request, the local mobility anchor can update
+      the lifetime of all the mobility sessions that are part of that
+      group.
+
+   o  On detecting the failure of a specific service card, a local
+      mobility anchor, or a mobile access gateway service hosted on
+      blade architecture system, can potentially request the peer to
+      revoke all the sessions identified by a common group identifier
+      that are hosted on that service card.  Potentially, a single
+      Binding Revocation Indication [RFC5846] message carrying the group
+      identifier can be used to revoke all the sessions hosted on that
+      service card, which otherwise needs to be handled on a per-session
+      basis.
+
+   This document defines a new mobility option, the Mobile Node Group
+   Identifier option, and the extensions to procedures related to
+   binding update and binding revocation for performing binding
+   operations with group-specific scope.
+
+
+
+
+
+
+Abinader, et al.             Standards Track                    [Page 3]
+
+RFC 6602               Bulk Binding Update Support              May 2012
+
+
+2.  Conventions and Terminology
+
+2.1.  Conventions
+
+   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 RFC 2119 [RFC2119].
+
+2.2.  Terminology
+
+   All the mobility-related terms used in this document are to be
+   interpreted as defined in the base Proxy Mobile IPv6 specifications
+   [RFC5213] and [RFC5844].  Additionally, this document uses the
+   following terms:
+
+   Bulk Binding Update
+
+      A binding update operation that has group-specific scope.  A
+      binding operation is associated with a specific mobility session.
+      However, a bulk binding update operation is associated with
+      multiple mobility sessions.  This operation is not relevant for
+      new mobility session creation.
+
+   Bulk Binding Update Group
+
+      A group of mobility sessions that are part of the same logical
+      group and therefore share a common group identifier.  This group
+      is the bulk binding update group.  This bulk binding update group
+      is maintained by both the mobile access gateway and the local
+      mobility anchor, and the grouping logic is local to that node.  A
+      mobility session can therefore be identified by two bulk binding
+      update group identifiers, one specific group created by the mobile
+      access gateway and the other specific group created by the local
+      mobility anchor.  The bulk binding update group identifiers are
+      exchanged as part of the initial mobility session creation.  The
+      mobility entities thereafter can perform operations related to
+      binding update such as lifetime extension and revocation
+      operations on an entire bulk binding update group identified by
+      the group identifier.
+
+3.  Bulk Binding Update Overview
+
+3.1.  Motivation
+
+   In a typical Proxy Mobile IPv6 domain, a local mobility anchor serves
+   multiple mobile access gateways, and the capacity of that node with
+   respect to the number of mobility sessions that it can host is quite
+   high, typically in the order of a few millions.  As the number of
+
+
+
+Abinader, et al.             Standards Track                    [Page 4]
+
+RFC 6602               Bulk Binding Update Support              May 2012
+
+
+   mobility sessions hosted by a local mobility anchor goes up, so does
+   the amount of signaling traffic related to periodic binding update
+   traffic.
+
+   The currently specified approach of the binding update procedure for
+   extending the lifetimes of multiple mobility sessions (where the
+   mobile access gateway is required to send a unique binding update
+   message for each mobility session even when there is no change to the
+   session state) is inefficient or sub-optimal.  These periodic binding
+   update messages consume a significant amount of network resources at
+   both the peers, in terms of processing power and network bandwidth.
+   There is an opportunity to optimize the signaling procedures by
+   allowing the local mobility anchor and the mobile access gateway to
+   perform bulk binding update operations.  This document specifies
+   extensions to Proxy Mobile IPv6 signaling for performing binding
+   update and revocation operations on a group of mobility sessions.
+   These extensions do not take away the existing functionality of
+   performing binding operations on a single mobility session.
+
+3.2.  General Operation
+
+   The bulk binding update mechanism specified in this document allows
+   the mobile access gateway and the local mobility anchor to perform
+   binding update and revocation operations on a group of mobility
+   sessions.  As part of the initial signaling during mobility session
+   establishment, the local mobility anchor and the mobile access
+   gateway exchange the respective bulk binding update group identifiers
+   for that mobility session.  Subsequently, both the peers can perform
+   bulk operations on those groups by presenting the bulk binding update
+   group identifier in the signaling messages.
+
+   When sending a Proxy Binding Update message after detecting a new
+   mobile node on its access link, a mobile access gateway can request
+   the local mobility anchor to assign a bulk binding update group
+   identifier for the mobile node's mobility session.  This is indicated
+   by setting the (B) flag in the Proxy Binding Update to a value of
+   (1).  The mobile access gateway will also assign a bulk binding
+   update group identifier (or it may assign a default bulk binding
+   update group - ALL-SESSIONS) and include that in the Mobile Node
+   Group Identifier option.
+
+   Upon accepting the request, the local mobility anchor will group the
+   mobility session to a specific bulk binding update group (or it may
+   assign it to the default bulk binding update group - ALL-SESSIONS)
+   and return this bulk binding update group identifier in a Proxy
+   Binding Acknowledgement message.  It will also set the (B) flag in
+
+
+
+
+
+Abinader, et al.             Standards Track                    [Page 5]
+
+RFC 6602               Bulk Binding Update Support              May 2012
+
+
+   the Proxy Binding Acknowledgement message to a value of (1).  The
+   bulk binding update group identifier is carried in the Mobile Node
+   Group Identifier option, described in Section 4.3.
+
+   Once the bulk binding update group identifiers are exchanged, the
+   local mobility anchor and the mobile access gateway can perform
+   binding operations on those entire groups, by including the bulk
+   binding update group identifier in the signaling messages.  For
+   example, the mobile access gateway can extend the lifetime of all the
+   mobility sessions that are part of a group by sending a single Proxy
+   Binding Update message with that bulk binding update group
+   identifier.  Similarly, the local mobility anchor can revoke all the
+   mobility sessions that are part of a group by including that group
+   identifier in the Proxy Binding Revocation message.  When initiating
+   bulk binding update operations on a group of mobility sessions, the
+   group identifier that is carried in the Mobile Node Group Identifier
+   option is always the identifier of the local group, and not the
+   identifier of the group on the peer.
+
+   Figure 1 explains the operational sequence of the bulk binding update
+   and revocation operations on a group of mobile nodes (MN1, MN2, and
+   MN3).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Abinader, et al.             Standards Track                    [Page 6]
+
+RFC 6602               Bulk Binding Update Support              May 2012
+
+
+              MAG                         LMA
+         (1)  |                            |
+    MN1-------|           (2) PBU          |
+              |--------------------------->|
+              |                            * (3)
+              |           (4) PBA          |
+              |<---------------------------|
+              * (5)                        |
+         (6)  |                            |
+    MN2-------|                            |
+              * (7)........................|
+         (8)  |                            |
+    MN3-------|                            |
+              * (9)........................|
+              |                            |
+              |           (10) PBU         |
+              |--------------------------->|
+              |                            * (11)
+              |           (12) PBA         |
+              |<---------------------------|
+              * (13)
+              |                            |
+              |           (14) BRI         |
+              |<---------------------------|
+              |                            * (15)
+              |           (16) BRA         |
+              |--------------------------->|
+              * (17)                       |
+              |                            |
+
+          Figure 1: Exchange of Group Identifier
+
+   o  (1) to (2): The MAG detects the mobile node's (MN1) attachment to
+      the access link.  The MAG groups the mobile node to a specific
+      bulk binding update group, (M1).  The MAG notifies this group
+      identifier to the LMA by including it in the Mobile Node Group
+      Identifier option of the PBU message.
+
+   o  (3): Upon accepting the PBU, the LMA creates a mobility session
+      and groups the mobility session to a specific bulk binding update
+      group, (L1).  The LMA updates the mobile node's Binding Cache
+      entry to include the bulk binding update group identifier, (L1),
+      and the bulk binding update group identifier presented by the MAG,
+      (M1).  The LMA also notifies the MAG about the bulk binding update
+      group identifier (L1), by including it in the PBA.
+
+
+
+
+
+
+Abinader, et al.             Standards Track                    [Page 7]
+
+RFC 6602               Bulk Binding Update Support              May 2012
+
+
+   o  (4) to (5): Upon receiving the PBA, the MAG updates the Binding
+      Update List entry for that mobility session to include the bulk
+      binding update group identifiers (L1) and (M1).  At this point,
+      both the LMA and MAG are aware of the mobile node's bulk binding
+      update group identifiers assigned by the peers.
+
+   o  (6) to (9): The above steps (1 through 5) are repeated here for
+      MN2 and MN3; details are omitted.  At the end of step (9), the MAG
+      completes the signaling with the LMA.  The MAG assigns the mobile
+      nodes MN2 and MN3 to bulk binding update groups (M1) and (M2)
+      respectively, while the LMA assigns them both to the same bulk
+      binding update group, (L1).
+
+   o  At this point, LMA has assigned MN1, MN2, and MN3 to the bulk
+      binding update group (L1), while the MAG has assigned MN1 and MN2
+      to group (M1) and MN3 to group (M2).  Both peers can now perform
+      binding operations on a group of mobility sessions identified by
+      the respective bulk binding update group identifier.
+
+   o  (10) to (13): The MAG sends a Proxy Binding Update message for
+      extending the lifetime of all the mobility sessions that are part
+      of the bulk binding update group (M1).  It includes the bulk
+      binding update group identifier (M1) in the PBU.  Upon accepting
+      the PBU, the LMA extends the lifetime of both MN1 and MN2, which
+      are part of the group (M1).
+
+   o  (14) to (17): The LMA decides to revoke all the sessions that are
+      part of bulk binding update group (L1).  The LMA sends a Binding
+      Revocation Indication (BRI) message with the bulk binding update
+      group identifier (L1).  Upon accepting the BRI message, the MAG
+      revokes all the MN1, MN2, and MN3 mobility sessions, which are
+      part of that bulk binding update group (L1), and sends a Binding
+      Revocation Acknowledgement (BRA) [RFC5846] message.
+
+4.  Message Formats
+
+   This section identifies the extensions to Proxy Mobile IPv6 signaling
+   messages that are required for supporting this specification.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Abinader, et al.             Standards Track                    [Page 8]
+
+RFC 6602               Bulk Binding Update Support              May 2012
+
+
+4.1.  Extensions to Proxy Binding Update Message
+
+    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|F|T|B| Reserved  |            Lifetime           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   .                                                               .
+   .                        Mobility options                       .
+   .                                                               .
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+           Figure 2: Extensions to Proxy Binding Update Message
+
+   A new flag, the Bulk-Binding-Update flag (B), is defined in the Proxy
+   Binding Update message specified in [RFC5213].  The bit value of
+   Bulk-Binding-Update flag (B) in the flags field of the message will
+   be 0x0040.
+
+   If the Bulk-Binding-Update flag (B) is set to a value of (1), it
+   informs the local mobility anchor to enable bulk binding update
+   support for the mobility session associated with this message.  If
+   the (B) flag is set to a value of (0), the local mobility anchor MUST
+   exclude the mobility session associated with this message from any
+   bulk-binding-related operations and any binding update, or binding
+   revocation operations with bulk-specific scope will not be relevant
+   to that mobility session.
+
+   This flag is relevant only for Proxy Mobile IPv6 and therefore MUST
+   be set to the value of (0) when the (P) flag is set to a value of
+   (0).
+
+   All other fields in the Proxy Binding Update message and the mobility
+   options that can be carried in the message conform to the appropriate
+   specifications.
+
+
+
+
+
+
+
+
+
+
+
+
+Abinader, et al.             Standards Track                    [Page 9]
+
+RFC 6602               Bulk Binding Update Support              May 2012
+
+
+4.2.  Extensions to Proxy Binding Acknowledgement Message
+
+    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|T|B| Res.|
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |         Sequence #            |           Lifetime            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   .                                                               .
+   .                        Mobility options                       .
+   .                                                               .
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+       Figure 3: Extensions to Proxy Binding Acknowledgement Message
+
+   A new flag, the Bulk-Binding-Update flag (B), is defined in the Proxy
+   Binding Acknowledgement message specified in [RFC5213].  The bit
+   value of Bulk-Binding-Update flag (B) in the flags field of the
+   message is 0x08.
+
+   If the Bulk-Binding-Update flag (B) is set to a value of (1), it
+   serves as an indication to the mobile access gateway that the local
+   mobility anchor has enabled bulk binding update support for the
+   mobility session associated with this message.  The value of the flag
+   MUST be set to the value of (0) if the value of the (B) flag in the
+   Proxy Binding Update message that it received from the mobile access
+   gateway was set to a value of (0).
+
+   This flag is relevant only for Proxy Mobile IPv6 and therefore MUST
+   be set to a value of (0) when the (P) flag is set to a value of (0).
+
+   All other fields in the Proxy Binding Acknowledgement message and the
+   mobility options that can be carried in the message conform to the
+   appropriate specifications.
+
+4.3.  Mobile Node Group Identifier Option
+
+   A new option, the Mobile Node Group Identifier option, is defined for
+   use in Proxy Mobile IPv6 signaling messages exchanged between a local
+   mobility anchor and a mobile access gateway.  This option is used for
+   carrying the mobile node's group identifier.  There can be multiple
+   instances of this option in a given signaling message; however, each
+   of the instances SHOULD have a different sub-type value.  This option
+   is a generic option, and this specification uses only the sub-type
+   value of (1).
+
+
+
+Abinader, et al.             Standards Track                   [Page 10]
+
+RFC 6602               Bulk Binding Update Support              May 2012
+
+
+   The type value for this option is 50.
+
+   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      |  Sub-type   |    Reserved     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                  Mobile Node Group Identifier                 |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+               Figure 4: Mobile Node Group Identifier Option
+
+   Type
+      <50>
+
+   Length
+      This is an 8-bit unsigned integer indicating the length in octets
+      of this option, excluding the type and length fields.  The value
+      for this field MUST be set to a value of (6).
+
+   Sub-type
+      This 8-bit field identifies the specific mobile node's group type.
+      This number space will be managed by the IANA.  The sub-type value
+      of (1) is reserved for the Bulk Binding Update Group.
+
+   Reserved
+      This 8-bit field is unused for now.  The value MUST be initialized
+      to (0) by the sender and MUST be ignored by the receiver.
+
+   Mobile Node Group Identifier
+      This 32-bit field contains the mobile node's group identifier.
+      The value of (0) is reserved and SHOULD NOT be used.  The value of
+      (1) ALL-SESSIONS is the default group of all mobility sessions
+      established between a given local mobility anchor and a mobile
+      access gateway.
+
+4.4.  Status Codes
+
+   This document defines the following new status code values for use in
+   the Proxy Binding Acknowledgement message.  These values have been
+   allocated from the same number space as defined in Section 6.1.8 of
+   [RFC6275].
+
+   INVALID_MOBILE_NODE_GROUP_IDENTIFIER: 175
+
+      Invalid group identifier value in the request
+
+
+
+
+
+Abinader, et al.             Standards Track                   [Page 11]
+
+RFC 6602               Bulk Binding Update Support              May 2012
+
+
+5.  Protocol Considerations
+
+5.1.  MAG Considerations
+
+   The following are the considerations relevant to the mobile access
+   gateway when supporting this specification.
+
+5.1.1.  Extensions to Binding Update List Entry Data Structure
+
+   The conceptual Binding Update List entry data structure maintained by
+   the mobile access gateway, described in Section 6.1 of [RFC5213], is
+   extended to include the following REQUIRED additional fields:
+
+   o  MAG-Bulk-Binding-Update-Group-Id
+      This is the bulk binding update group identifier assigned by this
+      mobile access gateway for this mobility session.  It is a 32-bit
+      unsigned integer.  This identifier is not globally unique within a
+      Proxy Mobile IPv6 domain; the same group identifier value may be
+      used by other nodes.
+
+   o  LMA-Bulk-Binding-Update-Group-Id
+      This is the bulk binding update group identifier assigned by the
+      local mobility anchor for this mobility session.  It is a 32-bit
+      unsigned integer.  This identifier is received in the Mobile Node
+      Group Identifier option of the Proxy Binding Acknowledgement
+      message.  This identifier is not globally unique within a Proxy
+      Mobile IPv6 domain; the same group identifier value may be used by
+      other nodes.
+
+5.1.2.  Requesting Bulk Binding Update Support for a Mobility Session
+
+   The following are the considerations for the mobile access gateway
+   for requesting bulk binding update support for a mobility session.
+
+   o  When sending a Proxy Binding Update message to the local mobility
+      anchor, the mobile access gateway can choose to request that the
+      local mobility anchor enable bulk binding update support for the
+      mobility session associated with that Proxy Binding Update
+      request.  When making such request, the Bulk-Binding-Update flag
+      (B) in the request MUST be set to a value of (1) and the Mobile
+      Node Group Identifier option MUST be present.  The decision to
+      request bulk binding update support for a mobile node is a matter
+      of local policy at the mobile access gateway and is controlled by
+      the configuration variable
+      RequestBulkBindingUpdateSupportForMobilitySession.
+
+
+
+
+
+
+Abinader, et al.             Standards Track                   [Page 12]
+
+RFC 6602               Bulk Binding Update Support              May 2012
+
+
+   o  The mobile access gateway MUST assign a bulk binding update group
+      identifier for the mobility session.  Considerations on how the
+      mobile access gateway assigns a group identifier to a mobility
+      session is outside the scope of this document.  This group
+      identifier can be unique to the service card on which the mobility
+      session is hosted or based on other grouping considerations.  When
+      no such group assignment is done, the mobile access gateway SHOULD
+      assign the default group identifier value of (ALL-SESSIONS).  This
+      assigned group identifier value MUST be present in the Mobile Node
+      Group Identifier option, and the sub-type value in the option MUST
+      be set to the value of (1) (Bulk Binding Update Group).
+
+   o  If the received Proxy Binding Acknowledgement message has the
+      status code value set to (0) (Proxy Binding Update accepted) and
+      the Bulk-Binding-Update flag (B) set to a value of (0), in
+      response to a Proxy Binding Update request with the Bulk-Binding-
+      Update flag (B) set to a value of (1), it is an indication that
+      the local mobility anchor has denied the request for enabling bulk
+      binding update support for that mobility session and that the
+      mobility session is not associated with any bulk binding update
+      group.  The mobile access gateway SHOULD set the bulk binding
+      update group identifier values LMA-Bulk-Binding-Update-Group-Id
+      and MAG-Bulk-Binding-Update-Group-Id to (0) in the Binding Update
+      List entry for that mobility session.  Furthermore, the mobility
+      session should be excluded from any bulk binding update
+      operations.
+
+   o  If the received Proxy Binding Acknowledgement message has the
+      status code value set to (0) (Proxy Binding Update accepted) and
+      the Bulk-Binding-Update flag (B) in the reply is set to a value of
+      (1), it is an indication that the local mobility anchor has
+      accepted the request to allow bulk binding update support for that
+      mobility session.  Furthermore, the Mobile Node Group Identifier
+      option in the reply, with the sub-type value of (1) (Bulk Binding
+      Update Group), contains the bulk binding update group identifier
+      for that mobility session assigned by the local mobility anchor.
+      The mobile access gateway MUST update the LMA-Bulk-Binding-Update-
+      Group-Id and MAG-Bulk-Binding-Update-Group-Id parameters in the
+      Binding Update List entry for that mobility session.  However, if
+      the received Proxy Binding Acknowledgement message has the Bulk-
+      Binding-Update flag (B) set to a value of (1), but the Mobile Node
+      Group Identifier option is not present, the message MUST be
+      considered malformed and ignored.
+
+   o  If, at any point in time, the mobile access gateway chooses to
+      request the local mobility anchor to disable bulk binding update
+      support for a mobility session, it MUST send a Proxy Binding
+      Update message with the (B) flag set to a value of (0), and the
+
+
+
+Abinader, et al.             Standards Track                   [Page 13]
+
+RFC 6602               Bulk Binding Update Support              May 2012
+
+
+      Mobile Node Group Identifier option MUST NOT be present.  This
+      message is sent as a normal binding update request for lifetime
+      extension.  Requirements from Section 6.9.1 of [RFC5213] apply.
+      Furthermore, the mobile access gateway MUST update the Binding
+      Update List entry by setting the bulk binding update group
+      identifier values LMA-Bulk-Binding-Update-Group-Id and MAG-Bulk-
+      Binding-Update-Group-Id to (0), and the mobility session MUST be
+      excluded from any bulk binding update operations.
+
+5.1.3.  Supporting Bulk Binding Updates
+
+   The following section identifies the considerations for a mobile
+   access gateway performing binding update and revocation operations
+   with group-specific scope.
+
+   o  For extending the lifetime of all mobility sessions that share the
+      same bulk binding update group identifier, the mobile access
+      gateway can choose to send a bulk binding update request.  To make
+      such a request, it can send a Proxy Binding Update message to the
+      local mobility anchor, including the Mobile Node Group Identifier
+      option with the sub-type value of (1) (Bulk Binding Update Group)
+      and with the Bulk-Binding-Update flag (B) set to a value of (0).
+      The identifier value in the option MUST be set to the bulk binding
+      update group identifier of the group for which bulk binding update
+      operation is being requested.  The message MUST NOT include any
+      individual session identifiers such as the Mobile Node Identifier
+      option [RFC4283], the Home Network Prefix option [RFC5213], the
+      IPv4 Home Address Request option [RFC5844], or the GRE Key option
+      [RFC5845].  All the considerations from Section 5.3.3 of [RFC5213]
+      MUST be followed when sending the bulk binding update request,
+      with the exception related to the use of Mobile Node Group
+      Identifier option in place of the individual session identifiers
+      (Mobile Node Identifier option, Home Network Prefix option, GRE
+      Key option, and IPv4 Home Address Request option).
+
+   o  When requesting binding revocation for all the sessions that share
+      the same bulk binding update group identifier, the mobile access
+      gateway can choose to send a bulk revocation request.  To make
+      such a request, it can send a Binding Revocation Indication
+      message [RFC5846] to the local mobility anchor, including the
+      Mobile Node Group Identifier option with the sub-type value of (1)
+      (Bulk Binding Update Group).  The identifier value in the option
+      MUST be set to the bulk binding update group identifier of the
+      group for which bulk binding update operation is being requested.
+      The message MUST NOT include any individual session identifiers
+      such as the Mobile Node Identifier option [RFC4283], the Home
+      Network Prefix option [RFC5213], the IPv4 Home Address Request
+      option [RFC5844], or the GRE Key option [RFC5845].  All the
+
+
+
+Abinader, et al.             Standards Track                   [Page 14]
+
+RFC 6602               Bulk Binding Update Support              May 2012
+
+
+      considerations from Section 9.2 of [RFC5846] MUST be followed when
+      sending the bulk binding update request, with the exception
+      related to the use of Mobile Node Group Identifier option in place
+      of the individual session identifiers (Mobile Node Identifier
+      option, Home Network Prefix option, GRE Key option, IPv4 Home
+      Address Request option).
+
+   o  Any time the mobile access gateway receives a Binding Revocation
+      Indication message [RFC5846], with a Mobile Node Group Identifier
+      option present in the request and with the sub-type value of (1)
+      (Bulk Binding Update Group), this message serves as a bulk
+      revocation request, with the request scope for revoking of all the
+      mobility sessions that are part of that bulk binding update group
+      specific to that local mobility anchor and identified by the group
+      identifier in the Mobile Node Group Identifier option.
+
+   o  All the considerations from [RFC5846] apply when processing a
+      binding revocation request, except making the scope of the
+      operation apply to a set of mobility sessions identified by the
+      bulk binding update group identifier present in the request.
+
+   o  If the received Binding Revocation Indication message includes the
+      Mobile Node Identifier option [RFC4283], the Home Network Prefix
+      option [RFC5213], the IPv4 Home Address Request option [RFC5844],
+      or the GRE Key option [RFC5845], the mobile access gateway MUST
+      consider this as an invalid message; it MUST reject the Binding
+      Revocation Indication message and send a Binding Revocation
+      Acknowledgement message with the Status field set to a value of
+      128 (Binding Does NOT Exist).
+
+5.2.  LMA Considerations
+
+   The following are the considerations relevant to a local mobility
+   anchor when supporting this specification.
+
+5.2.1.  Extensions to Binding Cache Entry Data Structure
+
+   The conceptual Binding Cache entry data structure maintained by the
+   local mobility anchor, described in Section 5.1 of [RFC5213], is
+   extended to include the following REQUIRED additional fields.
+
+   o  MAG-Bulk-Binding-Update-Group-Id
+
+      This is the bulk binding update group identifier assigned by the
+      mobile access gateway for this mobility session.  It is a 32-bit
+      unsigned integer.  This identifier is received in the Mobile Node
+      Group Identifier option of the Proxy Binding Update message.  This
+
+
+
+
+Abinader, et al.             Standards Track                   [Page 15]
+
+RFC 6602               Bulk Binding Update Support              May 2012
+
+
+      identifier is not globally unique within a Proxy Mobile IPv6
+      domain; the same group identifier value may be used by other
+      nodes.
+
+   o  LMA-Bulk-Binding-Update-Group-Id
+
+      This is the bulk binding update group identifier assigned by this
+      local mobility anchor for this mobility session.  It is a 32-bit
+      unsigned integer.  This identifier is not globally unique within a
+      Proxy Mobile IPv6 domain; the same group identifier value may be
+      used by other nodes.
+
+5.2.2.  Enabling Bulk Binding Update Support for a Mobility Session
+
+   The local mobility anchor will process a received Proxy Binding
+   Update message as specified in [RFC5213].  However, if the (B) flag
+   in the received Proxy Binding Update message is set to a value of (1)
+   and if it includes a Mobile Node Group Identifier option with the
+   sub-type value of (1) (Bulk Binding Update Group), the following
+   processing takes place:
+
+   o  If the (B) flag in the received Proxy Binding Update message is
+      set to a value of (1) and if the Mobile Node Group Identifier
+      option is present in the request, the message serves as a request
+      to the local mobility anchor to enable bulk binding update support
+      for that mobility session.
+
+   o  Upon successful processing and acceptance of the Proxy Binding
+      Update, the local mobility anchor can choose to enable bulk
+      binding update support for this mobility session.  The decision
+      whether to enable bulk binding update support for that mobility
+      session is a matter of local policy and is controlled by the
+      configuration variable
+      AcceptBulkBindingUpdateReqForMobilitySession.
+
+   o  For enabling the bulk binding update support for the mobility
+      session, the local mobility anchor MUST associate the mobility
+      session to a specific bulk binding update group locally.  The
+      specific details on how the local mobility anchor associates the
+      given mobility session to a specific bulk binding update group is
+      outside the scope of this document.  The local mobility anchor can
+      choose to assign a default bulk binding update group identifier
+      value of (ALL-SESSIONS), indicating that all the mobility sessions
+      from that mobile access gateway are part of that group.  The local
+      mobility anchor SHOULD update the bulk binding update group
+      identifier values in the Binding Cache entry, LMA-Bulk-Binding-
+      Update-Group-Id and MAG-Bulk-Binding-Update-Group-Id, to the
+      respective values.
+
+
+
+Abinader, et al.             Standards Track                   [Page 16]
+
+RFC 6602               Bulk Binding Update Support              May 2012
+
+
+   o  If the bulk binding update support is enabled for the mobile
+      node's mobility session, the local mobility anchor MUST send the
+      assigned bulk binding update group identifier as part of the
+      Mobile Node Group Identifier option, with the sub-type value of
+      (1) (Bulk Binding Update Group) in the Proxy Binding
+      Acknowledgement message that it sends to the mobile access
+      gateway.  The (B) flag in the Proxy Binding Acknowledgement
+      message MUST be set to value of (1).
+
+   o  If the bulk binding update support is not enabled for the mobility
+      session, the local mobility anchor MUST NOT include the Mobile
+      Node Group Identifier option with the sub-type value of (1) (Bulk
+      Binding Update Group), in the Proxy Binding Acknowledgement
+      message that it sends to the mobile access gateway.  Furthermore,
+      the (B) flag in the Proxy Binding Acknowledgement message MUST be
+      set to value of (0).  It is to be noted that the Mobile Node Group
+      Identifier option is a generic option and new sub-types may be
+      defined by future specifications.
+
+   o  If the received Proxy Binding Update message is not a bulk binding
+      update request, (i.e., the (B) flag is set to a value of (0) and
+      the Mobile Node Group Identifier option with the sub-type value of
+      (1) (Bulk Binding Update Group) is not present), but is a request
+      for extending the lifetime of an existing mobility session, for
+      which the bulk binding update support is already enabled, then the
+      local mobility anchor MUST process the request as specified in
+      [RFC5213].  However, the value of (0) in the (B) flag in the
+      message serves as a request for the local mobility anchor to
+      disable bulk binding update support for that mobility session.
+      Upon accepting the request, the local mobility anchor SHOULD set
+      the parameters, LMA-Bulk-Binding-Update-Group-Id and MAG-Bulk-
+      Binding-Update-Group-Id in the Binding Cache entry to a value of
+      (0) and the mobility session MUST be excluded from any bulk
+      binding update operations.
+
+   o  Any time the local mobility anchor detects that the mobile node
+      has roamed and changed its point of attachment to a new mobile
+      access gateway, it SHOULD also update the bulk binding update
+      group identifier of the mobility session.  Additionally, it should
+      also update the existing group identifiers associated with that
+      session.  As part of sending the Proxy Binding Acknowledgement to
+      the new mobile access gateway, it MUST include the updated group
+      identifier in the Mobile Node Group Identifier option, with a sub-
+      type value of (1).  However, if the if the received Proxy Binding
+      Update from the new mobile access gateway did not have the (B)
+      flag set to a value of (1), then it MUST NOT include the mobility
+
+
+
+
+
+Abinader, et al.             Standards Track                   [Page 17]
+
+RFC 6602               Bulk Binding Update Support              May 2012
+
+
+      session in any of bulk binding update group and MUST NOT include
+      the Mobile Node Group Identifier option with the sub-type value of
+      (1).
+
+   o  Any time a mobile node's mobility session is de-registered by the
+      mobile access gateway, or the session is revoked for
+      administrative or any other reasons, the mobility session MUST
+      also be removed from the bulk binding update group.
+
+5.2.3.  Supporting Bulk Binding Updates
+
+   The following section identifies the considerations for a local
+   mobility anchor for performing bulk binding update and revocation
+   operations with group-specific scope.
+
+   o  Any time the local mobility anchor receives a Proxy Binding Update
+      message with the (B) flag in the request set to a value of (0) and
+      a Mobile Node Group Identifier option present in the request with
+      sub-type value of (1) (Bulk Binding Update Group), the local
+      mobility anchor MUST consider the request a bulk binding update
+      request, with the request scope including all the mobility
+      sessions that are part of that bulk binding update group, specific
+      to that mobile access gateway, and identified by the group
+      identifier in Mobile Node Group Identifier option.  However, if
+      the received request also includes any individual session
+      identifiers such as the Mobile Node Identifier option [RFC4283],
+      the Home Network Prefix option [RFC5213], the IPv4 Home Address
+      Request option [RFC5844], or the GRE Key option [RFC5845], the
+      local mobility anchor MUST consider this as an invalid message; it
+      MUST reject the Proxy Binding Update message and send a Proxy
+      Binding Acknowledgement message with the Status field set to
+      INVALID_MOBILE_NODE_GROUP_IDENTIFIER (Invalid group identifier
+      value in the request).
+
+   o  The local mobility anchor MUST consider the message as a request
+      for extending the lifetime of all the mobility sessions that are
+      associated with the group identifier in the Mobile Node Group
+      Identifier option.  However, if the Mobile Node Group Identifier
+      option with the sub-type value of (1) (Bulk Binding Update Group)
+      has an unknown group identifier, then the local mobility anchor
+      MUST reject the Proxy Binding Update message and send a Proxy
+      Binding Acknowledgement message with the Status field set to
+      INVALID_MOBILE_NODE_GROUP_IDENTIFIER (Invalid group identifier
+      value in the request).
+
+   o  Upon accepting the bulk binding update request, the local mobility
+      anchor SHOULD extend the lifetime for all the mobility sessions
+      that are part of the bulk binding update group identified by the
+
+
+
+Abinader, et al.             Standards Track                   [Page 18]
+
+RFC 6602               Bulk Binding Update Support              May 2012
+
+
+      group identifier in the Mobile Node Group Identifier in the
+      message.  Considerations from [RFC5213] MUST be applied for
+      extending the lifetime of a mobile node's session.  It MUST also
+      send a Proxy Binding Acknowledgement message with the Status field
+      value set to 0 (Proxy Binding Update accepted).  The lifetime
+      field in the message MUST be set to the allocated lifetime for all
+      the mobility sessions.  The message MUST also include the Mobile
+      Node Group Identifier option, with the sub-type value of (1) (Bulk
+      Binding Update Group) and with the identifier value copied from
+      the Mobile Node Group Identifier option present in the received
+      Proxy Binding Update message.
+
+   o  If the local mobility anchor rejects the bulk binding update
+      request for any administrative reason, then it MUST NOT update the
+      lifetime in the Binding Cache entries of any of the mobile nodes
+      identified by the group identifier.  The local mobility anchor
+      SHOULD send a Proxy Binding Acknowledgement indicating the reason
+      for the rejection in the status code.
+
+   o  Any time the local mobility anchor receives a Binding Revocation
+      Indication Message [RFC5846] with a Mobile Node Group Identifier
+      option present in the request and with the sub-type value of (1)
+      (Bulk Binding Update Group), the local mobility anchor MUST
+      consider the request as a bulk revocation request, with the
+      request scope including all the mobility sessions that are part of
+      the bulk binding update group specific to that mobile access
+      gateway and identified by the group identifier in Mobile Node
+      Group Identifier option.  However, if the received request also
+      includes the Mobile Node Identifier option [RFC4283], the Home
+      Network Prefix option [RFC5213], the IPv4 Home Address Request
+      option [RFC5844], or the GRE Key option [RFC5845], the local
+      mobility anchor MUST consider this as an invalid message; it MUST
+      reject the Binding Revocation Indication message and send a BRA
+      message with the Status field set to a value of 128 (Binding Does
+      NOT Exist).  All the considerations from [RFC5846] apply when
+      processing a binding revocation request, except making the scope
+      of the operation apply to a set of mobility sessions identified by
+      the group identifier present in the request.
+
+   o  Upon accepting the Binding Revocation Indication request and
+      completing the operation, the local mobility anchor MUST send a
+      Binding Revocation Acknowledgement message with the Status field
+      set to a value of 0 (success).  The message MUST include the
+      Mobile Node Group Identifier option, with the identifier value
+      copied from the Mobile Node Group Identifier option present in the
+      received Binding Revocation Indication message.
+
+
+
+
+
+Abinader, et al.             Standards Track                   [Page 19]
+
+RFC 6602               Bulk Binding Update Support              May 2012
+
+
+6.  Protocol Configuration Variables
+
+6.1.  Local Mobility Anchor - Configuration Variables
+
+   This specification adds a new configuration variable for the local
+   mobility anchor.  The configured value for this variable is expected
+   to survive server reboots and service restarts.
+
+   AcceptBulkBindingUpdateReqForMobilitySession
+
+      This flag indicates whether or not the local mobility anchor will
+      accept the request from the mobile access gateway to enable bulk
+      binding update support for the mobility session.  The default
+      value for this flag is set to (1), indicating that it will accept
+      the request from the mobile access gateway.  If the value of the
+      flag is set to (0), the local mobility anchor will deny the
+      request.
+
+6.2.  Mobile Access Gateway - Configuration Variables
+
+   This specification adds a new configuration variable for the mobile
+   access gateway.  The configured value for this variable is expected
+   to survive server reboots and service restarts.
+
+   RequestBulkBindingUpdateSupportForMobilitySession
+
+      This flag indicates whether or not the mobile access gateway will
+      request the local mobility anchor to enable bulk binding update
+      support for the mobility session.  The default value for this flag
+      is set to (1), indicating that the mobile access gateway will set
+      the bulk binding update flag (B) in the Proxy Binding Update
+      request to a value of (1).  If the flag is set to a value of (0),
+      the mobile access gateway will set the bulk binding update flag
+      (B) in the Proxy Binding Update to a value of (0).
+
+7.  IANA Considerations
+
+   Per this document, IANA has done the following:
+
+   o  Action-1: This specification defines a new flag (B) to the Proxy
+      Binding Update message, specified in [RFC5213].  This flag is
+      described in Section 4.1.  The value of the flag (B) has been
+      allocated from the "Binding Update Flags" registry.
+
+   o  Action-2: This specification defines a new flag (B) to the Proxy
+      Binding Acknowledgement message, specified in [RFC5213].  This
+      flag is described in Section 4.2.  The value of the flag (B) has
+      been allocated from the "Binding Acknowledgement Flags" registry.
+
+
+
+Abinader, et al.             Standards Track                   [Page 20]
+
+RFC 6602               Bulk Binding Update Support              May 2012
+
+
+   o  Action-3: This specification defines a new Mobility Header option,
+      the Mobile Node Group Identifier option.  This option is described
+      in Section 4.3.  The Type value for this option has been assigned
+      in the same number space as allocated for the other mobility
+      options [RFC6275].
+
+   o  Action-4: The Sub-type field of the Mobile Node Group Identifier
+      option introduces a new number space.  This number space is now
+      managed by IANA, under the Registry, "Mobile Node Group Identifier
+      Type Registry".  This specification reserves the sub-type value of
+      (1) (Bulk Binding Update Group).  Approval of new sub-type values
+      are to be made through IANA Expert Review.  The value range of
+      this field is 0 through 255, but the values 0 and 255 are marked
+      as reserved.  The remaining values 2-254 are available for
+      allocation.
+
+   o  Action-5: This document also defines a new status value
+      INVALID_MOBILE_NODE_GROUP_IDENTIFIER (Invalid group identifier
+      value in the request: 175) for use in the Proxy Binding
+      Acknowledgement message, as described in Section 4.4.  This value
+      has been assigned from the same number space as allocated for
+      other status codes [RFC6275].
+
+8.  Security Considerations
+
+   The Mobile Node Group Identifier option defined in this specification
+   is for use in Proxy Binding Update and Proxy Binding Acknowledgement
+   messages.  This option is carried like any other mobility header
+   option, and it does not require any other special security
+   considerations.
+
+   The bulk binding update and the bulk revocation operations specified
+   in this document perform operations on a group of mobility sessions.
+   If proper authorization checks are not in place, a malicious node may
+   be able to hijack a mobile node's mobility session or may carry out a
+   denial-of-service attack.  To prevent this attack, this specification
+   requires the local mobility anchor to allow only authorized mobile
+   access gateways to perform bulk operations.
+
+9.  Acknowledgements
+
+   The authors would like to specially thank Jouni Korhonen, Basavaraj
+   Patil, Carlos Jesus Bernardos Cano, Dirk Von-Hugo, Pete Resnick, and
+   Jari Arkko for reviewing this document and providing input.
+
+
+
+
+
+
+
+Abinader, et al.             Standards Track                   [Page 21]
+
+RFC 6602               Bulk Binding Update Support              May 2012
+
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [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.
+
+   [RFC5846]  Muhanna, A., Khalil, M., Gundavelli, S., Chowdhury, K.,
+              and P. Yegani, "Binding Revocation for IPv6 Mobility",
+              RFC 5846, June 2010.
+
+   [RFC6275]  Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
+              in IPv6", RFC 6275, July 2011.
+
+10.2.  Informative References
+
+   [RFC4283]  Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
+              Chowdhury, "Mobile Node Identifier Option for Mobile IPv6
+              (MIPv6)", RFC 4283, November 2005.
+
+   [RFC5845]  Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung,
+              "Generic Routing Encapsulation (GRE) Key Option for Proxy
+              Mobile IPv6", RFC 5845, June 2010.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Abinader, et al.             Standards Track                   [Page 22]
+
+RFC 6602               Bulk Binding Update Support              May 2012
+
+
+Authors' Addresses
+
+   Fuad Abinader (editor)
+   Instituto Nokia de Tecnologia
+   Av. Torquato Tapajos, 7200 - Km. 12 - Col Terra Nova
+   Manaus, AM  69048-660
+   Brazil
+
+   EMail: fabinader@gmail.com
+
+
+   Sri Gundavelli (editor)
+   Cisco
+   170 West Tasman Drive
+   San Jose, CA  95134
+   USA
+
+   EMail: sgundave@cisco.com
+
+
+   Kent Leung
+   Cisco
+   170 West Tasman Drive
+   San Jose, CA  95134
+   USA
+
+   EMail: kleung@cisco.com
+
+
+   Suresh Krishnan
+   Ericsson
+   8400 Decarie Blvd.
+   Town of Mount Royal, QC
+   Canada
+
+   Phone: +1 514 345 7900 x42871
+   EMail: suresh.krishnan@ericsson.com
+
+
+   Domagoj Premec
+   Unaffiliated
+
+   EMail: domagoj.premec@gmail.com
+
+
+
+
+
+
+
+
+Abinader, et al.             Standards Track                   [Page 23]
+