NETLMM Working Group K. Weniger Internet-Draft G. Velev Intended status: Informational Panasonic Expires: April 30, 2009 V. Devarapalli Wichorus October 27, 2008 Data forwarding behaviour of co-located HA/LMA in PMIP6-MIP6 interactions scenario C draft-weniger-netlmm-mip-pmip-forwarding-00 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. 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 April 30, 2009. Weniger, et al. Expires April 30, 2009 [Page 1] Internet-Draft HA/LMA data forwarding behaviour October 2008 Abstract In PMIP6-MIP6 interactions scenario C, the HA and LMA are co-located and a transition between MIP6 and PMIP6 is supported without breaking the session. This draft discusses possible data forwarding behaviours of the co-located HA/LMA in such scenario. The two recently discussed options are: 1) data forwarding always according to the mobile node's MIP6 BCE, if exists, which means that MIP6 BCE has higher priority than PMIP6 BCE, or 2) data forwarding according to type of the last received mobility management registration message, i.e., PMIP6 and MIP6 BCE have equal priority. It is argued that option 1) increases handover delay by 1 MN-HA RTT and implementation complexity of the HA/LMA may be higher. Hence, it is proposed that HA/LMA should behave according to option 2, i.e., MIP6 BCE and PMIP6 BCE have same priority and HA/LMA forwards data according to the type of the last received mobility management registration message. Weniger, et al. Expires April 30, 2009 [Page 2] Internet-Draft HA/LMA data forwarding behaviour October 2008 Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Higher priority for MIP6 BCE vs. equal priority for PMIP6 BCE and MIP6 BCE . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Handover performance considerations . . . . . . . . . . . 6 3.2. Implementation complexity considerations . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.1. Normative References . . . . . . . . . . . . . . . . . . . 11 6.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 13 Weniger, et al. Expires April 30, 2009 [Page 3] Internet-Draft HA/LMA data forwarding behaviour October 2008 1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Furthermore, the terminology defined in [RFC3775] and [RFC5213] is used. Weniger, et al. Expires April 30, 2009 [Page 4] Internet-Draft HA/LMA data forwarding behaviour October 2008 2. Introduction The NETLMM WG has standardized Proxy Mobile IPv6 [RFC5213], a Mobile IPv6-based protocol for localized mobility management. This protocol allows the network to manage the mobility of mobile nodes. There are various scenarios, in which Mobile IPv6 (MIP6) [RFC3775] and Proxy Mobile IPv6 (PMIP6) can be used together. Three interactions scenarios, the corresponding interworking issues and some solutions are presented in [ID-MIP-PMIP]. Recently, alternative solutions for the PMIP6-MIP6 interactions scenario C were discussed on the NETLMM mailing list. In this scenario, the HA and LMA are co-located and a transition between MIP6 and PMIP6 is supported without breaking the session. This draft discusses different options of the external behaviour of the HA/LMA in this scenario, more specifically two data forwarding behaviours are analyzed. Weniger, et al. Expires April 30, 2009 [Page 5] Internet-Draft HA/LMA data forwarding behaviour October 2008 3. Higher priority for MIP6 BCE vs. equal priority for PMIP6 BCE and MIP6 BCE Two possible data forwarding behaviours of the co-located HA/LMA are possible in scenario C: 1. Data forwarding always according to mobile node's MIP6 BCE, if exists (i.e., MIP6 BCE has higher priority than PMIP6 BCE), or 2. Data forwarding according to type of the last received mobility management registration message (i.e., PMIP6 and MIP6 BCE have equal priority). With option 1, the HA/LMA forwards data according to mobile node's MIP6 BCE and ignores the mobile node's PMIP6 BCE with respect to data forwarding, if a MIP6 BCE exists for the mobile node. Only if no MIP6 BCE exists for the mobile node, forwarding is done according to the mobile node's PMIP6 BCE. This implies that MIP6 BCE has higher priority than PMIP6 BCE. The option is proposed in [I-D.tsirtsis-logically-separate-lmaha] and is only possible if the HA/LMA is implemented in a way that results in separate BCEs for PMIP6 and MIP6. With option 2, the HA/LMA forwards data according to the type of the last received mobility management registration message: If the HA/LMA receives a valid PBU, data forwarding is done according to the updated mobile node's PMIP6 BCE. If the HA/LMA receives a valid BU, data forwarding is done according to the updated mobile node's MIP6 BCE. This implies that PMIP6 and MIP6 have equal priority. This option is possible no matter how HA/LMA is implemented, i.e., separate or shared BCEs for PMIP6 and MIP6. 3.1. Handover performance considerations Figure Figure 1 shows both data forwarding behaviours in case of a foreign-to-home handover. It can be observed that with option 2 data forwarding starts once the PBU is received by the HA/LMA, whereas with option 1, data forwarding only starts after the BU de- registration is received. This results in a 1 RTT higher handover delay with option 1. Note that this additional handover delay is actually unnecessary, since the HA/LMA already has all the information about the mobile node's location needed for correct data forwarding at the time of receiving the PBU. Weniger, et al. Expires April 30, 2009 [Page 6] Internet-Draft HA/LMA data forwarding behaviour October 2008 +--+ +-------+ +-------+ |MN| | MAG | |HA/LMA | +--+ +-------+ +-------+ | attach | | |<------->| PBU | | |-------------------------------->| | data forwarding starts with option 2) | |<==========================================| | | PBA (accept) | | |<--------------------------------| | RA | | |<--------| | | BU de-registration | |------------------------------------------>| | data forwarding starts with option 1) | |<==========================================| | | | Figure 1: Data forwarding options in foreign-to-home handover in PMIP6-MIP6 interactions scenario C In summay, better handover performance is expected with data forwarding option 2. 3.2. Implementation complexity considerations In general, the next hop destination for data forwarding and hence the routing table at the HA/LMA can change whenever a PBU or BU is received containing a new CoA (or MAG address). With option 1), the data forwarding behaviour depends on whether a MIP6 BCE exists for the mobile node or not. This means that when the HA/LMA receives a PBU it always needs to check whether a MIP6 BCE exists for this mobile node or not in order to be able to make a decision about the routing table change. This translates into a dependency between MIP6 and PMIP6 processes in the HA/LMA. In contrast, when HA/LMA behaves according to option 2) and receives a BU or PBU, there is no need for the PMIP6 process to search for a MIP6 BCE of the mobile node or for the MIP6 process to search for a PMIP6 BCE of the mobile node, since the forwarding behaviour is decided solely based on the type of the received mobility management message (PBU or BU). Thus, option 2) results in no dependency between MIP6 and PMIP6 processes with respect to data forwarding. Typically, higher dependencies between processes typically result in higher implementation complexity. Hence, it is assumed that option 2 Weniger, et al. Expires April 30, 2009 [Page 7] Internet-Draft HA/LMA data forwarding behaviour October 2008 has lower implementation complexity. Weniger, et al. Expires April 30, 2009 [Page 8] Internet-Draft HA/LMA data forwarding behaviour October 2008 4. Security Considerations This draft analyzes two data forwarding behaviours of a co-located HA/LMA, which should have no impact on security considerations other than described in [ID-MIP-PMIP]. Weniger, et al. Expires April 30, 2009 [Page 9] Internet-Draft HA/LMA data forwarding behaviour October 2008 5. Acknowledgements TBD Weniger, et al. Expires April 30, 2009 [Page 10] Internet-Draft HA/LMA data forwarding behaviour October 2008 6. References 6.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., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 6.2. Informative References [I-D.tsirtsis-logically-separate-lmaha] Tsirtsis, G. and S. Krishnan, "Behavior of Collocated HA/ LMA", draft-tsirtsis-logically-separate-lmaha-01 (work in progress), October 2008. [ID-MIP-PMIP] Giaretta, G., Ed., "Interactions between PMIPv6 and MIPv6: scenarios and related issues", October 2008, . Weniger, et al. Expires April 30, 2009 [Page 11] Internet-Draft HA/LMA data forwarding behaviour October 2008 Authors' Addresses Kilian A. Weniger Panasonic R&D Center Germany Monzastr. 4c Langen 63225 Germany Email: kilian.weniger@eu.panasonic.com Genadi Velev Panasonic R&D Center Germany Monzastr. 4c Langen 63225 Gemany Email: genadi.velev@eu.panasonic.com Vijay Devarapalli Email: vijay@wichorus.com Weniger, et al. Expires April 30, 2009 [Page 12] Internet-Draft HA/LMA data forwarding behaviour October 2008 Full 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. 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. Intellectual Property 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 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. Weniger, et al. Expires April 30, 2009 [Page 13]