[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01                                                         
Network Working Group                                        G. Tsirtsis
Internet-Draft                                                  Qualcomm
Intended status: Standards Track                             S. Krishnan
Expires: September 26, 2008                                     Ericsson
                                                        October 20, 2008


                     Behavior of Collocated HA/LMA
             draft-tsirtsis-logically-separate-lmaha-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.

   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 23, 2009.

Abstract

   In discussions about PMIPv6-MIPv6 interactions in NETLMM WG, scenario
   C describes the case of collocation of LMA and HA function.  In this
   case a PMIP network emulates the "home link" for MNs using MIPv6.
   This document argues that even when LMA and HA functions are
   Collocated they MUST be treated as logically separate entities.  In
   particular this draft argues that PMIP BCEs MUST NOT overwrite MIPv6
   BCEs and vice versa.







Tsirtsis & Krishnan    Expires April 23, 2009               [Page 1]


Internet-Draft        Behavior of Collocated HA/LMA           March 2008


Table of Contents

   1.  Requirements notation . . . . . . . . . . . . . . . . . . . . . 3
   2.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   4.  The Case for Logically Separate LMA and HA  . . . . . . . . . . 3
     4.1.  Logical Relationship Between Colocated LMA/HA . . . . . . . 3
       4.1.1.  BCE Overwritting is Wrong . . . . . . . . . . . . . . . 4
       4.1.2.  Shared State between LMA and HA . . . . . . . . . . . . 5
   5.  Detailed Bootstrapping and Handoff Considerations . . . . . . . 5
     5.1.  Bootstrapping on Emulated Home Link . . . . . . . . . . . . 5
     5.2.  Connecting to Foreign Link  . . . . . . . . . . . . . . . . 6
     5.3.  Connecting Back to Emulated Home Link . . . . . . . . . . . 7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   8.  Informative References  . . . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8
   Intellectual Property and Copyright Statements  . . . . . . . . . . 9

































Tsirtsis & Krishnan    Expires April 23, 2009               [Page 2]


Internet-Draft        Behavior of Collocated HA/LMA           March 2008


1.  Requirements notation

   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].


2.  Acknowledgments

   We would like to thank the authors of PMIPv6-MIPv6 interactions draft
   [I-D.giaretta-netlmm-mip-interactions] for providing the basis for
   this discussion.


3.  Introduction

   In PMIPv6-MIPv6 interactions draft
   [I-D.giaretta-netlmm-mip-interactions], scenario C describes the case
   of collocation of LMA and HA function.  In this case a PMIP network
   emulates the "home link" for MNs using MIPv6.  This document argues
   that even when LMA and HA functions are Collocated they MUST be
   treated as logically separate entities.  In particular this draft
   argues that PMIP BCEs MUST NOT overwrite MIPv6 BCEs and vice versa.


4.  The Case for Logically Separate LMA and HA

   When a PMIPv6 [I-D.ietf-netlmm-proxymip6] local mobility agent is
   collocated with a MIPv6 [RFC3775] home agent, the PMIPv6 network can
   be configured to emulate the MIPv6 "home link" for a mobile node
   using MIPv6.  This configuration and its implications are discussed
   below.

4.1.  Logical Relationship Between Colocated LMA/HA

   A PMIPv6 network comprising an LMA and multiple MAGs emulates a
   single link.  When a PMIPv6 LMA and a MIPv6 HA are Collocated, PMIPv6
   is used to handle mobility between MAGs in the same PMIPv6 network
   emulating the link, and MIPv6 is used to handle mobility between
   different links (emulated or physical).

   In that sense, logically, the PMIPv6 LMA operates at a lower layer
   than the MIPv6 HA.  This means that when a packet is received by the
   LMA/HA, the destination address of the packet is first matched
   against Binding Cache Entries (BCE) created by MIPv6 BUs.  If there
   are no MIPv6 BCEs for this destination address (i.e., the MN is
   deregistered at MIPv6 level) then LMA BCEs are searched.




Tsirtsis & Krishnan    Expires April 23, 2009               [Page 3]


Internet-Draft        Behavior of Collocated HA/LMA           March 2008


   This simple way of thinking about logically separating the two
   functions, ensures that MNs can move between PMIPv6 emulated links
   and other links the same way the do between physical links and
   without require any specific implementation of the combined LMA/HA.

   Indeed, the two logical functions can be implemented as two different
   but communicating processes or as a single integrated process.  The
   BCE tables of the LMA and the HA can also be combined in a single
   table or they can be maintained as separate tables.  This draft does
   not impose, propose, or in any other way imply any specific
   implementation.  Instead, this draft describes the required external
   behavior of such a combined LMA/HA implementation and argues against
   PMIPv6 BCEs overwriting MIPv6 BCEs.

4.1.1.  BCE Overwritting is Wrong

   There is currently a school of thought in the NETLMM WG that wants
   PMIPv6 PBUs to overwrite state created by PMIPv6 BUs and vice versa.
   This school of thought comes from a fundamental assumptions that as
   MNs move from one link to another, they only maintain ONE link at a
   time.  In other words the assumption is that during a handoff an MN
   will disconnect from one link and connect to another.  In that sense,
   when a combined HA/LMA receives a MIPv6 BU over a foreign link, it
   can overwrite any state created in the LMA for the same mobile (since
   presumably the MN is no longer connected to the MAG).  Based on the
   same logic when an combined HA/LMA receives a PMIPv6 BU over a MAG on
   the home link, it can overwrite any state created in the HA for the
   same mobile (since presumably the MN is no longer connected to a
   foreign link).

   This logic breaks down if one considers MNs that are capable of
   maintaining more than one link at the same time.  Such capability is
   common and can be utilised in many different way, while specifically
   MIPv6 allows for the following behavior:

      Directing traffic between foreign links: If an MN can maintain two
      links at the same time, it can direct traffic to one or the other
      link by simply sending a BU to its HA, registering the CoA
      corresponding to one or the other link.

      Directing traffic between home and foreign link: If one of the
      links maintained is the home link, the MN can direct traffic to it
      by sending a deregistration MIPv6 BU to the HA over the home link,
      while it can also direct traffic to the foreign link by sending a
      MIPv6 BU to the HA directing traffic to the CoA of the foreign
      link.





Tsirtsis & Krishnan    Expires April 23, 2009               [Page 4]


Internet-Draft        Behavior of Collocated HA/LMA           March 2008


      Directing traffic between Multiple links: MEXT WG is also working
      on [I-D.ietf-monami6-multiplecoa] and
      [I-D.soliman-monami6-flow-binding] specifications allowing an MN
      to register multiple links (multiple CoAs and the home link) to
      its HA at the same time and even direct different flows to
      different links.

   It should be clear that none of this can be possible if every time
   the MN connects to its home link, the corresponding PMIPv6 BCE
   overwrites the HA BCEs for the same mobile or every time the MN sends
   a BU to its HA over a foreign link, the MIPv6 BCE overwrites the LMA
   BCE entry for the same MN.

4.1.2.  Shared State between LMA and HA

   If the HA is configured as a virtual home link HA (i.e., there is no
   direct link between MN and HA), there are no need to share any
   parameters between HA and LMA functions.  The LMA and HA function,
   however, need to share certain parameters in a Collocated
   implementation if the PMIPv6 network is used as a home link, i.e., if
   the PMIPv6 network emulates a direct connection between the MN and
   the HA.  The parameters that need to be shared in this case have to
   do with the addresses assigned to the MN by the two entities.
   Specifically:

      When an LMA receives a PBU for a new MN, it MUST first check if
      the MN is associated with the Collocated HA e.g. based on the
      MN-ID.  If the HA already has a home address associated with this
      MN, then the LMA MUST allocate the same address over the PMIPv6
      home link.

      When an HA receives an IKEv2 bootstrapping request for a new MN,
      it MUST first check if the MN is associated with the Collocated
      LMA e.g. based on the MN-ID.  If the LMA already has a prefix
      associated with this MN, then the HA provide the MN with the same
      HNP over the IKEv2 session.


5.  Detailed Bootstrapping and Handoff Considerations

5.1.  Bootstrapping on Emulated Home Link

   When an MN connects to a MAG in a PMIPv6 network, it receives an RA
   indicating a prefix that is topologically correct at the LMA and
   unique to the MN.  This prefix can be used by the MN to autoconfigure
   one (or more) IPv6 address.  This address continues to be valid as
   the MN moves between MAGs in the same PMIPv6 network.  This is so
   since every time the MN moves to a new MAG, the MAG sends a PBU to



Tsirtsis & Krishnan    Expires April 23, 2009               [Page 5]


Internet-Draft        Behavior of Collocated HA/LMA           March 2008


   the LMA creating a PMIPv6 Binding Cache Entry (BCE), binding the MN's
   prefix with a MAG's address.  Any packet with a destination address
   matching the MN's prefix, is directed to the LMA, which based on the
   BCE table it tunnels the packet to the appropriate MAG which then
   delivers it to the MN.

   Assume now that the MN, equipped with an IPv6 address derived from a
   prefix provided to it over the link emulated by the PMIPv6 network,
   wants to bootstrap MIPv6.  Also assume that the HA used by the MN is
   the one Collocated with the LMA of the PMIPv6 network the MN is
   connected to.  This address is maybe discovered by Dynamic HA Address
   Detection (DHAAD) as defined in [RFC3775] or by any of the
   bootstrapping mechanisms [RFC5026]
   [I-D.ietf-mip6-bootstrapping-integrated-dhc].

   The MN proceeds to establish a security association with it using
   IKEv2.  According to [RFC5026], as part of this procedure the HA can
   provide the home network prefix (HNP) to the MN.  The MN immediately
   understands that it is attached to its MIPv6 home link since the
   prefix advertised to it directly over the link (in an RA) matches the
   HNP provided to it by the HA.  In this case the MN does not need to
   send a MIPv6 BU to the HA and the logical HA function does not get
   initiated.

   In other words, any packet sent to the MN's prefix is still
   intercepted by the LMA and redirected to the appropriate MAG
   (according to PMIPv6 BCE table) for delivery to the MN over the
   emulated home link.

5.2.  Connecting to Foreign Link

   If the MN connects to an access router that is not part of the same
   PMIPv6 network as before i.e., on a foreign link, it will receive an
   RA with a different prefix (say a foreign prefix) and generates an IP
   address on the foreign link.

   Note that up to now nothing has changed at the Collocated LMA/HA.
   All traffic is still redirected by the LMA to the registered MAG
   according to the state in the PMIPv6 BCE table.  For this to change
   the MN needs to send a MIPv6 BU to the HA.  The BU introduces an
   entry to the MIPv6 BCE, binding the MN's prefix to the CoA.  Any
   packets now reaching the LMA/HA will now match the MIPv6 BCE and be
   redirected to the CoA.

   Note that the MIPv6 BCE created by the BU sent over the foreign link
   MUST NOT overwrite the PMIPv6 BCE for the same MN.  The PMIPv6 BCE
   for this MN is removed only if and when the MN disconnects from the
   MAG in the PMIPv6 domain and has nothing to do with the HA state.



Tsirtsis & Krishnan    Expires April 23, 2009               [Page 6]


Internet-Draft        Behavior of Collocated HA/LMA           March 2008


   Indeed, according to when a MAG an MN disconnects from a MAG, the MAG
   is supposed to send a deregistration BU to the LMA removing the
   corresponding BCE for that MN.

5.3.  Connecting Back to Emulated Home Link

   Now say that after the MN has disconnected to from the PMIPv6 MAG and
   registered to the HA via a foreign link, the MN connects again to its
   emulated home link via one of the MAGs in the PMIPv6 network.

   The MAG the MN connects to, is supposed to send a PBU to the LMA.
   Since the MN maintains a relationship with the HA, the LMA should
   provide the same prefix as before i.e., the HNP.  This means that
   when the MN receives the RA from the MAG, which includes the a prefix
   matching its HNP, it will detect that this emulated link is its home
   link.

   Note that the PBU sent by the MAG MUST NOT overwrite the MIPv6 BCE
   pointing to the foreign link for this MN.  This is because the MAG
   can not possibly know whether the MN still maintains the foreign link
   or not.  Indeed, if the MN wants to receive its traffic over the home
   link it will sent a deregistration MIPv6 BU to the HA and remove the
   MIPv6 BCE.  When that happens packets will again reach the LMA and be
   redirected according to the PMIPv6 BCE to the appropriate MAG.


6.  Security Considerations

   This document does not introduce security issues


7.  IANA Considerations

   This document requires no action from IANA.


8.  Informative References

   [I-D.giaretta-netlmm-mip-interactions]
              Giaretta, G., "Interactions between PMIPv6 and MIPv6:
              scenarios and related issues",
              draft-giaretta-netlmm-mip-interactions-02 (work in
              progress), November 2007.

   [I-D.ietf-mip6-bootstrapping-integrated-dhc]
              Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the
              Integrated Scenario",
              draft-ietf-mip6-bootstrapping-integrated-dhc-05 (work in



Tsirtsis & Krishnan    Expires April 23, 2009               [Page 7]


Internet-Draft        Behavior of Collocated HA/LMA           March 2008


              progress), July 2007.

   [I-D.ietf-monami6-multiplecoa]
              Ernst, T., Nagami, K., and V. Devarapalli, "Multiple
              Care-of Addresses Registration",
              draft-ietf-monami6-multiplecoa-06 (work in progress),
              February 2008.

   [I-D.ietf-netlmm-proxymip6]
              Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
              and B. Patil, "Proxy Mobile IPv6",
              draft-ietf-netlmm-proxymip6-11 (work in progress),
              February 2008.

   [I-D.soliman-monami6-flow-binding]
              Soliman, H., Montavont, N., Fikouras, N., and K.
              Kuladinithi, "Flow Bindings in Mobile IPv6 and Nemo Basic
              Support", draft-soliman-monami6-flow-binding-05 (work in
              progress), November 2007.

   [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.

   [RFC5026]  Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6
              Bootstrapping in Split Scenario", RFC 5026, October 2007.


Authors' Addresses

   George Tsirtsis
   Qualcomm

   Email: tsirtsis@googlemail.com


   Suresh Krishnan
   Ericsson

   Email: suresh.krishnan@ericsson.com









Tsirtsis & Krishnan    Expires April 23, 2009               [Page 8]


Internet-Draft        Behavior of Collocated HA/LMA           March 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.











Tsirtsis & Krishnan    Expires April 23, 2009               [Page 9]