NETLMM Working Group D. Premec Internet Draft Nokia Siemens Networks Intended status: Informational B. Patil Expires: January 2009 Nokia S. Krishnan Ericsson July 14, 2008 Bulk Re-registration for Proxy Mobile IPv6 draft-premec-netlmm-bulk-re-registration-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. 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 January 14, 2009. Premec & Patil Expires January 14, 2009 [Page 1] Internet-Draft PMIP6 bulk re-registration July 2008 Copyright Notice Copyright (C) The IETF Trust (2008). 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...................................................3 2. Terminology....................................................4 3. Bulk Re-registration Overview..................................4 4. Message formats................................................6 4.1. Proxy Binding Update message..............................7 4.2. Proxy Binding Acknowledgment message......................8 5. MAG Operation..................................................8 6. LMA operation.................................................10 7. Security Considerations.......................................12 8. IANA Considerations...........................................12 9. Acknowledgments...............................................12 10. References...................................................13 10.1. Normative References....................................13 10.2. Informative References..................................13 Author's Addresses...............................................14 Intellectual Property Statement..................................14 Premec Expires January 14, 2009 [Page 2] Internet-Draft PMIP6 bulk re-registration July 2008 Disclaimer of Validity...........................................15 1. Introduction According to the Proxy Mobile IPv6 (PMIP6) specification [Gun2008], a netlmm domain is defined as a network which provides a network based IP mobility service by deploying the PMIP6 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 requests a bulk re-registration for a set of MNs by sending a single PBU message with a new bulk re-registration flag (B) set to 1. Premec Expires January 14, 2009 [Page 3] Internet-Draft PMIP6 bulk re-registration July 2008 The LMA extends the binding lifetime of MNs that are currently attached to that MAG and meet the criteria contained in the renewals request. If no current binding cache entry exists, the LMA creates new bindings for the MNs listed in the bulk registration message. The LMA indicates success of a bulk re-registration by responding with a PBAck message with the bulk re-registration flag (B) set to 1. 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. 2. Terminology General mobility related terminology is defined in [RFC3775]. Additional PMIP6 specific terminology can be found in [Gun2008]. netlmm domain Network providing the network based IP mobility service as defined in [Gun2008]. PMIP6 Proxy Mobile IPv6 protocol specified in [Gun2008]. 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 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. This set is called a bulk re-registration set and is a subset of the MNs attached to a MAG. Initially the bulk re- registration set is empty. MAG requests to add individual MNs to this set by sending a regular PBU message that identifies an individual MN and additionally the bulk re-registration flag in the message is set Premec Expires January 14, 2009 [Page 4] Internet-Draft PMIP6 bulk re-registration July 2008 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 re-registration flag (B) set to 1. Once there is a non-empty bulk re-registration set, MAG can request to extend the binding lifetime of some or all MNs that are part of the bulk re-registration set by sending a PBU message with bulk re- registration flag set to 1 and omitting any options that would identify an individual MN. In particular, the MAG may omit both the MN ID (Mobile Node Identifier) option and the HNP (Home Network Prefix) option in which case the MAG requests bulk re-registration of all MNs in the bulk re-registration set. 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 will split the MNs across multiple PBUs. The receiving LMA can use the information included in these bulk PBUs to recreate the bul 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. The MAG may restrict the set of MNs to which the request for bulk re- registration applies by including additional mobility options in the PBU message that act as a filter. In this case only those MNs from the bulk re-registration set which match the imposed restrictions will be re-registered in a bulk mode. This filtering restriction is valid only for the duration of the current re-registration transaction. The binding cache entries of MNs that are members of bulk re-registration set but not matching the filter will be left unaffected. Following options may be used as a filter in a bulk re- registration request: 1. Mobile Node Identifier (MN ID) option This option can be used to select only MNs belonging to particular domain, for example, by setting it to "@example.com". 2. Home Network Prefix (HNP) option This option can be used to select MNs whose HNP matches the indicated prefix for the first Prefix Length bits. Premec Expires January 14, 2009 [Page 5] Internet-Draft PMIP6 bulk re-registration July 2008 3. Service Selection option [RFC5149] This option can be used to select MNs whose Service Selection option in the binding cache entry exactly matches the requested Service Selection option in the PBU. 4. Vendor-Specific Mobility option [RFC5094] This option can be used to select MNs whose Vendor-Specific option in the binding cache entry matches the requested Vendor-Specific option in the PBU. If MN's binding cache entry does not match all of the filtering options from the bulk re-registration request, then it is not affected by this bulk re-registration operation. The LMA extends the mobility binding of all MNs from the bulk re- registration set that meet the filtering criteria and responds with PBAck message with the bulk re-registration flag set to 1. The LMA includes in its response the same mobility options that were included in the request. 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. Premec Expires January 14, 2009 [Page 6] Internet-Draft PMIP6 bulk re-registration July 2008 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 Binding Update message that is sent by a MAG to a LMA is referred to as the "Proxy Binding Update" message; it is defined in the [Gun2008]. A new flag (B) is included in the Binding Update message. Bulk Re-registration Flag (B) If the mobility options included in the message identify a single MN and if the bulk re-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 re-registration flag (B) is set to 0, then the PBU message is sent to remove the MN from the bulk re-registration set. If bulk re-registration flag (B) is set to 1 and the included mobility options do not identify a single MN, then the PBU message is a request to extend the lifetime of the MNs contained in the bulk re- registration set and whose binding cache entries match the mobility options from the message. Mobility Options For descriptions of these options, refer to [Gun2008]. When the bulk re-registration flag is set to 1, the PBU message without Mobile Node Identifier option and/or without HNP option is valid and is processed as described in section 3. Premec Expires January 14, 2009 [Page 7] Internet-Draft PMIP6 bulk re-registration July 2008 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 Binding Acknowledgment message that is sent by a LMA to a MAG is referred to as the "Proxy Binding Acknowledgment" message; it is defined in the [Gun2008]. A new flag (B) is included in the Binding Acknowledgment message. Bulk Re-registration Flag (B) A new flag (B) is included in the Binding Acknowledgment message to indicate to the MAG that the requested bulk re-registration operation was successful. 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 [Gun2008]. When the bulk re-registration flag was set to 1 in the PBU message and Mobile Node Identifier option and/or HNP option were not included, then the PBAck message is also sent without those mobility options as described 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 [Gun2008]. Additionally, the MAG MAY set the bulk re-registration Premec Expires January 14, 2009 [Page 8] Internet-Draft PMIP6 bulk re-registration July 2008 flag (B) in the PBU message to 1 to request the LMA to add the MN to the set of MNs re-registered in a bulk mode. The decision to request 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 re-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. 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 with a bulk re- registration flag set to 1. Mobility options in such PBU message SHALL NOT identify an individual MN. In addition, the MAG MAY trigger a bulk re-registration at any time. The policy and exact conditions for these additional triggers are outside of scope of this specification. A MAG MAY omit HNP and MN ID options from a PBU message requesting bulk re-registration. A MAG MAY include mobility options in a PBU requesting a bulk re- registration to restrict the set of MNs updated by this transaction. In this case the set of MNs affected by this bulk re-registration operation is the subset of MNs contained in a bulk re-registration set whose binding cache entries match the mobility options included in the PBU message, as described in section 3. 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 with the bulk re-registration bit set to 1 in response to a PBU message requesting the bulk re-registration, 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. Premec Expires January 14, 2009 [Page 9] Internet-Draft PMIP6 bulk re-registration July 2008 After successfully processing the PBAck message indicating successful re-registration in bulk mode, the MAG MAY start a single timer to oversee the binding lifetime of all attached MNs served by the LMA to which it sent the bulk PBU message. If the MAG sets the bulk re-registration bit to 1 in a PBU message but the bulk re-registration bit (B) is set to 0 in a PBAck message, the MAG SHALL process the PBAck message as per [Gun2008]. 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 [Gun2008]. The MAG MAY retry the 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. If the PBAck message indicates success and it contains the MN ID and HNP options, the MAG SHALL update the binding of the MN indicated by the MN ID and HNP options, regardless of the value of the bulk re- registration bit (B) in the PBAck message. 6. LMA operation When the LMA receives a PBU message with a bulk re-registration bit (B) set to 1 and if the message contains MN ID and/or HNP options identifying a single MN, the LMA SHALL first process the PBU message as per [Gun2008]. Upon successful processing of the message, if the bulk re-registration flag is set in the message, the LMA SHALL continue 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 and if included mobility options identify a single MN, the LMA MAY add the MN 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 for a MN is a matter of local policy at the LMA and is outside the scope of this specification. Premec Expires January 14, 2009 [Page 10] Internet-Draft PMIP6 bulk re-registration July 2008 If the LMA decides to accept the bulk re-registration mode for the MN, it SHALL add the MN to the bulk re-registration set. The LMA SHALL maintain the bulk re-registration set per MAG. Upon adding the MN to the bulk re-registration set, the LMA SHALL respond with the PBAck message containing the bulk registration bit to 1. The PBU message with the bulk re-registration bit (B) set to 1 but without the MN ID and HNP options is a valid message and indicates a request for bulk mode re-registration of all MNs that are members of the bulk re-registration set. If the bulk re-registration flag (B) is set in the PBU message and included mobility options do not identify an individual MN, the LMA SHALL extend the binding lifetime of all affected MNs attached to the MAG that sent the bulk PBU. The affected MNs are those MNs that are members of a bulk re-registration set and whose binding cache entries match the mobility options included in the bulk PBU message. The valid mobility options and their semantics are described in section 3. The LMA SHOULD set the binding lifetime of all MNs re-registered in a bulk mode to expire at the same point in time. The LMA SHOULD copy the mobility options from the bulk re- registration request into the PBAck message sent in response. Upon successful processing of bulk mode re-registration request, the LMA MUST respond with a PBAck message indicating success and it SHOULD set the bulk re-registration bit (B) to 1. 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 where the bulk re-registration bit is set to 1 and the status code indicates the reason for rejection. After successfully processing the bulk PBU message, the LMA MAY start a single timer to oversee the binding lifetime of all MNs affected by this bulk re-registration transaction. When the LMA receives a PBU message requesting a (re-)registration of a single MN from a MAG that successfully executed a bulk re- registration procedure before and the lifetime of that bulk re- Premec Expires January 14, 2009 [Page 11] Internet-Draft PMIP6 bulk re-registration July 2008 registration is not expired yet, the LMA MAY set the lifetime in the PBAck message to match the remaining lifetime of the MNs contained in the bulk re-registration set. As a result the LMA is not required to start a separate timer to oversee the binding lifetime of this MN. The LMA not supporting this specification ignores the bulk re- registration bit (B) in a PBU message and processes the message as per the baseline specification [Gun2008]. 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 [Gun2008]. 7. Security Considerations The bulk re-registration mechanism does not introduce any new security threat or vulnerability to the PMIP6 specification. 8. IANA Considerations None. 9. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. Premec Expires January 14, 2009 [Page 12] Internet-Draft PMIP6 bulk re-registration July 2008 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. [Gun2008] Gundavelli, S., Ed., "Proxy Mobile IPv6", May 2008, draft- ietf-netlmm-proxymip6-18.txt 10.2. Informative References [RFC5149] J. Korhonen, U. Nilsson, V. Devarapalli, "Service Selection for Mobile IPv6", RFC 5149, February 2008 [RFC5094] V. Devarapalli, A. Patel, K. Leung, "Mobile IPv6 Vendor Specific Option", RFC 5094, December 2007 Premec Expires January 14, 2009 [Page 13] Internet-Draft PMIP6 bulk re-registration July 2008 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 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this Premec Expires January 14, 2009 [Page 14] Internet-Draft PMIP6 bulk re-registration July 2008 specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Premec Expires January 14, 2009 [Page 15]