NetExt Working Group D. Premec Internet Draft Nokia Siemens Networks Intended status: Informational B. Patil Expires: September 2009 Nokia S. Krishnan Ericsson March 9, 2009 Bulk Re-registration for Proxy Mobile IPv6 draft-premec-netlmm-bulk-re-registration-02.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 9, 2009. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Premec Expires September 9, 2009 [Page 1] Internet-Draft PMIPv6 bulk re-registration March 2009 Abstract The Proxy Mobile IPv6 specification requires the Mobile Access Gateway (MAG) to send a separate Proxy Binding Update (PBU) message to the Local Mobility Agent (LMA) for each mobile node (MN) to renew the MN's mobility binding. This document defines a mechanism by which a MAG can update the mobility bindings of multiple MNs attached to it with a single PBU message to the serving LMA. This mechanism is also intended to be used by a MAG to re-establish bindings at a new LMA when its old LMA fails. Conventions used in this document 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]. Table of Contents 1. Introduction...................................................2 2. Terminology....................................................4 3. Bulk Re-registration Overview..................................4 4. Message formats................................................6 4.1. Proxy Binding Update message..............................6 4.2. Proxy Binding Acknowledgment message......................7 4.3. Bulk Set Identifier.......................................8 5. MAG Operation..................................................8 6. LMA operation.................................................10 7. Security Considerations.......................................11 8. IANA Considerations...........................................12 9. Acknowledgments...............................................12 10. References...................................................12 10.1. Normative References....................................12 Author's Addresses...............................................13 1. Introduction The Proxy Mobile IPv6 (PMIPv6) specification [RFC5213] defines a PMIPv6 domain as a network which provides a network based IP mobility Premec Expires September 9, 2009 [Page 2] Internet-Draft PMIPv6 bulk re-registration March 2009 service by deploying the PMIPv6 protocol. A MAG performs the mobility related signaling on behalf of a MN by sending the Proxy Binding Update (PBU) message to a LMA. When the binding lifetime of a particular MN is close to expiry, the MAG renews the registration of the MN by sending a PBU message, to the LMA, requesting the extension of the binding lifetime. A single LMA serves multiple MAGs and the capacity of the LMA in terms of the number of attached MNs can be quite large. It can be expected that LMA capacity in managed networks may easily exceed hundreds of thousands or more attached MNs. The following simple formula gives an estimate of the average number of re-registration transactions per second as a function of the number of registered MNs and the binding lifetime period: transactions/sec = (number of registered MNs) / (binding lifetime*4) For 50.000 MNs and the binding lifetime of half an hour this gives: 50000 MNs / 1800 sec = 27,7 transactions/sec Based on the above formula it is apparent that the default re- registration process where the MAG sends a separate message for each MN is inefficient or suboptimal. These re-registration messages consume significant network resources both in terms of processing power at the LMA and MAG and network bandwidth. In addition, since the registration messages are sent per MN, there is no efficient way for the MAG to recover from the failure of an LMA. It needs to resend registration messages for each MN attached to it, towards a new LMA. This increases the service disruption interval. This document proposes an optimization of the re-registration process by which the signaling load for re-registration can be reduced to a single transaction per MAG, irrespective of the number of attached MNs. A MAG adds a MN to a set of MNs re-registered in a bulk mode by setting the bulk re-registration bit (B) in the PBU message. A PBU message with the B bit set may include multiple MNs and the LMA creates new bindings for all the MNs listed in the bulk registration message. The PBU message sent in response may contain the Bulk Set ID mobility option (defined in section 4.3). The bulk set ID is an opaque identifier allocated by the LMA which uniquely identifies the bulk set to which the MN was added. Premec Expires September 9, 2009 [Page 3] Internet-Draft PMIPv6 bulk re-registration March 2009 A MAG requests a bulk re-registration for a set of MNs by sending a single PBU message which includes a Bulk Set ID mobility option and the LMA extends the binding lifetime of MNs that are members of the received bulk set ID. By using this method, the MAG and LMA accomplish the re-registration of MNs attached to a MAG in a single transaction. The number of re-registration transactions at the LMA becomes independent of the number of attached MNs; instead it is dependent only on the number of MAGs. In addition to minimizing the signaling overhead associated with the lifetime extension of the mobility bindings, the MAG and LMA may use a single timer per bulk re-registration set to monitor the binding lifetime of all the member MNs instead of an individual timer per MN. 2. Terminology General mobility related terminology is defined in [RFC3775]. Additional PMIPv6 specific terminology can be found in [RFC5213]. PMIPv6 domain Network providing the network based IP mobility service as defined in [RFC5213]. PMIPv6 Proxy Mobile IPv6 protocol specified in [RFC5213]. Bulk re-registration PBU/PBAck message exchange where the bulk re-registration flag (B) is set to 1. bulk re-registration set a set containing the MNs to which the request for bulk re-registration applies. 3. Bulk Re-registration Overview The bulk re-registration mechanism allows the MAG and the LMA to extend the binding lifetime for a number of MNs with a single transaction. The MAG and LMA maintain a set of MNs that can be re- registered in bulk mode. Such set is called a bulk re-registration set and is a subset of the MNs attached to a MAG. There can be multiple bulk re-registration sets for a given MAG-LMA pair. Initially the bulk re-registration set is empty. MAG requests to add individual MNs to the bulk set by sending a regular PBU message that Premec Expires September 9, 2009 [Page 4] Internet-Draft PMIPv6 bulk re-registration March 2009 identifies an individual MN and additionally the bulk registration flag in the message is set to 1. Based on the received bulk re- registration bit the LMA adds the MN to the bulk re-registration set and responds with the PBAck message with the bulk registration flag (B) set to 1. Once there is a non-empty bulk re-registration set, MAG can request to extend the binding lifetime for all MNs that are part of the bulk re-registration set by sending a PBU message and omitting any options that would identify an individual MN. In particular, the MAG omits both the MN ID (Mobile Node Identifier) option and the HNP (Home Network Prefix) options. If the bulk registration message is being sent to recover from an LMA failure the MAG MUST explicitly identify all the MNs that are included in the bulk registration set and provide all the mobility options that need to be included in an initial PBU. Due to the size of these options, the MAG may not be able to fit all the MNs attached to it into a single PBU. In this case the MAG will split the MNs across multiple PBUs. The receiving LMA can use the information included in these bulk PBUs to recreate the bulk registration set, so that the MAG can renew the MNs' lifetimes later with a single PBU. There may be different triggers that cause the MAG to request a bulk re-registration. Typically the trigger is the binding lifetime expiry of a MN that is a member of a bulk re-registration set. There could be other triggers as well, but they may be implementation or domain specific and outside the scope of this specification. When the MAG requests the MN to be added to the bulk re-registration set, the LMA may include the Bulk Set ID mobility option in the PBAck message. The bulk set ID is an opaque identifier allocated by the LMA that uniquely identifies the bulk set to which the MN was added. The MAG associates the MN with the bulk set ID received in the PBAck. The MAG includes the Bulk Set ID mobility option set to the value previously received from the LMA to request the bulk re-registration for the MNs that are part of this particular bulk re-registration set. The MAG may include multiple instances of the Bulk Set ID option in the PBU message to request lifetime refreshment for several bulk sets in a single message. The LMA extends the mobility binding of all MNs that are members of indicated bulk re-registration sets and responds with PBAck message echoing the received Bulk Set ID mobility options. Premec Expires September 9, 2009 [Page 5] Internet-Draft PMIPv6 bulk re-registration March 2009 A MAG may remove a MN from a bulk re-registration set by sending a regular PBU message identifying the MN to be removed and with the bulk re-registration flag set to 0. When requested to add a MN to the bulk re-registration set, the LMA may reject the request. In this case the LMA processes the PBU message as if the bulk re-registration flag was not set and responds with PBAck message where the bulk re-registration flag is set to 0. 4. Message formats This section introduces extensions to PBU and PBAck messages used in this specification. 4.1. 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|B| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 Proxy Binding Update message A Proxy Binding Update message is defined in the [RFC5213]. A new flag (B) is defined for the Binding Update message. Bulk Registration Flag (B) If the bulk registration flag (B) is set to 1, then the PBU message is a request to add the MN to the bulk re-registration set. If the bulk registration flag (B) is set to 0 and if the MN is found to be a member of the bulk re-registration set, then the MN is removed from the bulk re-registration set. Premec Expires September 9, 2009 [Page 6] Internet-Draft PMIPv6 bulk re-registration March 2009 Mobility Options For descriptions of the mobility options, refer to [RFC5213]. When the bulk registration flag is set to 1, the PBU message containing multiple MN ID and HNP options is valid and is processed as described in section 3. When set to refresh binding in a bulk mode, the PBU message contains at least one Bulk Set ID mobility option and does not contain the MN-ID and the HNP mobility options. 4.2. Proxy Binding Acknowledgment 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|B| Res. | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 Proxy Binding Acknowledgment message A Proxy Binding Acknowledgment message is defined in the [RFC5213]. A new flag (B) is defined for the Binding Acknowledgment message. Bulk Registration Flag (B) A new flag (B) is included in the Binding Acknowledgment message to indicate to the MAG that the MN was successfully added to the bulk re-registration set. The flag MUST NOT be set to the value of 1 if it was not set to 1 in the corresponding PBU message. Mobility Options For descriptions of these options, refer to [RFC5213]. When the bulk registration flag is set to 1 in the PBU message, then the PBAck message may also contain the Bulk Set ID mobility option. When the Premec Expires September 9, 2009 [Page 7] Internet-Draft PMIPv6 bulk re-registration March 2009 Bulk Set ID mobility were included in the PBU message, the PBAck message echoes back the Bulk Set ID options from the PBU message. 4.3. Bulk Set Identifier The format of the Bulk Set ID option is as shown below and its alignment requirement is 4n+2. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bulk Set ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Bulk Set ID Mobility Option Type: TBD, uniquely identifies the option as the Bulk Set ID mobility option. Length: 0 or 4 Bulk set ID: a 32-bit unsigned integer that identifies a bulk re-registration set. The Bulk Set ID option is valid in the Proxy Binding Update and Proxy Binding Acknowledgment messages. The semantics of the Bulk Set ID option is defined in section 3. 5. MAG Operation When a new MN attaches to a MAG, the MAG SHALL register the MN with the LMA by sending the PBU message formatted as described in [RFC5213]. Additionally, the MAG MAY set the bulk registration flag (B) in the PBU message to 1 to request the LMA to add the MN to the bulk registration set. The decision to request the bulk re- registration mode for a MN is a matter of local policy at the MAG and is outside the scope of this specification. The MAG SHALL add the MN to its bulk re-registration set when it receives a PBAck message with the bulk registration bit set to 1 and if the corresponding PBU message was requesting the LMA to add the MN to the bulk re-registration set. The MAG SHALL maintain a separate bulk re-registration set for each LMA. If the PBAck message contains Premec Expires September 9, 2009 [Page 8] Internet-Draft PMIPv6 bulk re-registration March 2009 the Bulk Set ID option, the MAG SHALL associate the MN being registered with the indicated bulk set identifier. When the binding lifetime of any MN contained in the bulk re- registration set is about to expire, the MAG SHALL request the bulk re-registration by sending the PBU message containing the Bulk Set ID mobility option. The length of the Bulk Set ID option may be 0 in which case the MAG is requesting a refreshment of the binding lifetime for all MN attached to that MAG that were registered with the B flag set. Alternatively, the MAG may include one or more Bulk Set ID options containing the values that were indicated by the LMA in the PBAck messages when the MN was added to the bulk set. In this case the MAG asks for refreshment of specific bulk sets indicated by the Bulk Set ID options. The MAG SHALL NOT include the MN ID and the HNP options in the PBU message requesting bulk refreshment. The MAG MAY also trigger a bulk re-registration at any time. The policy and exact conditions for these additional triggers are outside of scope of this specification. If the bulk registration message is being sent to recover from an LMA failure the MAG MUST explicitly identify all the MNs that are included in the bulk registration set and provide all the mobility options that need to be included in an initial PBU. Due to the size of these options, the MAG may not be able to fit all the MNs attached to it into a single BU. In this case the MAG MUST split the MNs across multiple BUs. When the MAG receives a PBAck message indicating success and which echoes the Bulk Set ID options that were included in the corresponding PBU message, the MAG SHALL update the binding lifetime of all affected MNs to the lifetime value contained in the PBAck message. If in the case of bulk re-registration the PBAck message repeatedly indicates an error, the MAG SHALL fall back to individual re-registration mode. Instead of maintaining one timer per MN, the MAG MAY start a single timer per bulk registration set to oversee the binding lifetime of all MNs that are members of that bulk registration set. If the MAG sets the bulk re-registration bit to 1 in a PBU message but the bulk registration bit (B) is set to 0 in a PBAck message, the MAG SHALL process the PBAck message as per [RFC5213]. In addition, the MAG SHALL infer that the LMA does not support bulk re- registration procedure. The MAG SHALL switch to regular, per-MN re- registration mode as described in [RFC5213]. The MAG MAY retry the Premec Expires September 9, 2009 [Page 9] Internet-Draft PMIPv6 bulk re-registration March 2009 bulk re-registration procedure after sufficient time has elapsed from the previous unsuccessful bulk re-registration. This amount of time SHOULD be configurable at the MAG. 6. LMA operation When the LMA receives a PBU message with a bulk registration bit (B) set to 1, the LMA SHALL first process the PBU message as per [RFC5213]. Upon successful processing of the message, the LMA SHALL perform additional processing of the PBU message as described further below for bulk mode re-registrations. If the PBU message contains multiple MNIDs and/or HNP options, and the LMA cannot find a matching binding cache entry, the LMA MUST consider this to be equivalent to receiving multiple PBUs with one MNID and/or HNP option each. If the bulk re-registration flag in the PBU message is set to 1, the LMA MAY add the MN(s) indicated in the PBU to the set of MNs re- registered in a bulk mode, subject to the local policy. The decision whether to enable bulk re-registration mode is a matter of local policy at the LMA and is outside the scope of this specification. If the LMA decides to accept the bulk re-registration mode for the MN, it SHALL add the MN to a bulk re-registration set. The LMA SHALL maintain distinct bulk re-registrations set per MAG and there could be several such sets per single MAG. Upon adding the MN to the bulk re-registration set, the LMA SHALL respond with the PBAck message containing the bulk registration bit set to 1. The LMA may include the Bulk Set ID option in the PBAck message. The bulk set ID is allocated by the LMA and identifies the particular bulk set to which the MN is assigned. The PBU message without the MN ID and HNP options but including the Bulk Set ID mobility option is a valid message and indicates a request for bulk mode re-registration of all MNs that are members of the indicated bulk re-registration set. There MAY be several Bulk Set ID options in the PBU message, in which case the MAG requests the bulk refreshment of all MNs that are members of the indicated bulk sets. If the length of the Bulk Set ID option is zero, the MAG is requesting a lifetime refreshment of all the MN attached to the MAG that are members of any bulk set. The LMA SHALL extend the binding lifetime of all affected MNs attached to the MAG that sent the bulk PBU. Premec Expires September 9, 2009 [Page 10] Internet-Draft PMIPv6 bulk re-registration March 2009 The LMA SHALL set the binding lifetime of all MNs re-registered in a bulk mode to expire at the same point in time. Upon successful processing of bulk mode re-registration request, the LMA MUST respond with a PBAck message indicating success and echoing the mobility options received from the PBU. The lifetime in the PBAck message indicates the time when binding cache entries of affected MNs will expire. The LMA MAY reject the request for bulk re-registration. In this case the LMA MUST NOT update binding cache entries of any MNs and SHALL respond with PBAck indicating the reason for the rejection in the status code. After successfully processing the bulk PBU message, the LMA SHOULD start a single timer to oversee the binding lifetime of all MNs affected by this bulk re-registration transaction. The LMA not supporting this specification ignores the bulk re- registration bit (B) and the Bulk Set ID option in a PBU message and processes the message as per the baseline specification [RFC5213]. In this case the PBAck message sent in response contains the bulk re- registration bit (B) is set to 0. If the LMA that does not support this specification receives a bulk PBU message that does not contain any options identifying a particular MN then the LMA responds with the PBAck message where the status field contains one of the following error codes: MISSING_HOME_NETWORK_PREFIX_OPTION MISSING_MN_IDENTIFIER_OPTION These error codes are defined in the baseline specification [RFC5213]. 7. Security Considerations The bulk re-registration mechanism does not introduce any new security threat or vulnerability to the PMIPv6 specification. Premec Expires September 9, 2009 [Page 11] Internet-Draft PMIPv6 bulk re-registration March 2009 8. IANA Considerations None. 9. Acknowledgments Thanks to Jouni Korhonen for his review and input. This document was prepared using 2-Word-v2.0.template.dot. 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. [RFC3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in IPv6", RFC 3775, June 2004. [RFC5213] Gundavelli, S., Ed., "Proxy Mobile IPv6", RFC 5213, August 2008 Premec Expires September 9, 2009 [Page 12] Internet-Draft PMIPv6 bulk re-registration March 2009 Author's Addresses Domagoj Premec Nokia Siemens Networks Heinzelova 70a 10000 Zagreb Croatia Email: domagoj.premec.ext@nsn.com Basavaraj Patil Nokia 6000 Connection Drive Irving, TX 75039 USA Email: basavaraj.patil@nokia.com Suresh Krishnan Ericsson 8400 Decarie Blvd. Town of Mount Royal, QC Canada Phone: +1 514 345 7900 x42871 Email: suresh.krishnan@ericsson.com Premec Expires September 9, 2009 [Page 13]