Internet DRAFT - draft-weniger-netlmm-mip-pmip-forwarding

draft-weniger-netlmm-mip-pmip-forwarding






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,
              <draft-ietf-netlmm-mip-interactions-00.txt>.



























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]