Proxy MIPv6 Support of Transient Registration
draft-muhanna-netlmm-pmipv6-support-transient-coa-01

Versions: 00 01                                                         
NETLMM Working Group                                          A. Muhanna
Internet-Draft                                                    Nortel
Intended status: Standards Track                             S. Krishnan
Expires: August 28, 2008                                        Ericsson
                                                                K. Leung
                                                                   Cisco
                                                                B. Patil
                                                  Nokia Siemens Networks
                                                       February 25, 2008


             Proxy MIPv6 Support of Transient Registration
        draft-muhanna-netlmm-pmipv6-support-transient-coa-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 August 28, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

   In order for the local mobility anchor to receive and forward uplink
   traffic for a mobile node, Proxy Mobile IPv6 base protocol mandates
   the LMA to have an active BCE with a registered proxy CoA that is the



Muhanna, et al.          Expires August 28, 2008                [Page 1]


Internet-Draft    PMIPv6 Support Transient Registration    February 2008


   other end of the tunnel between the LMA and MAG.  In some systems and
   during active inter-MAG handoff with traffic that is sensitive to
   delay and packet loss, the LMA is required to forward uplink traffic
   for the mobile node from the target MAG without completely switching
   the tunnel from the source MAG.  This document specifies a mechanism
   which allows the target MAG to perform transient registration for a
   new proxy CoA and the LMA to create a transient BCE for the same
   mobile node for a specified period of time while maintaining the
   original mobile node's BCE which reference the old pCoA at the source
   MAG.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions used in this document  . . . . . . . . . . . . . .  4
   3.  PMIPv6 Transient Registration Overview . . . . . . . . . . . .  5
   4.  Transient Registration Option  . . . . . . . . . . . . . . . .  6
   5.  Mobile Access Gateway Operation  . . . . . . . . . . . . . . .  8
   6.  Local Mobility Anchor Operation  . . . . . . . . . . . . . . . 10
   7.  Transient Binding Cache Entries Update . . . . . . . . . . . . 10
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     11.1.  Normative References  . . . . . . . . . . . . . . . . . . 14
     11.2.  Informative References  . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
   Intellectual Property and Copyright Statements . . . . . . . . . . 16






















Muhanna, et al.          Expires August 28, 2008                [Page 2]


Internet-Draft    PMIPv6 Support Transient Registration    February 2008


1.  Introduction

   Proxy Mobile IPv6 is a network-based mobility protocol which provides
   IP mobility for a mobile node without the involvement of the IPv6
   host.  Whenever a mobile node is attached to a PMIPv6 domain via a
   mobility access gateway, it appears to the mobile node as if it is
   attached to the same home link and thus the mobile node may think
   that it is not roaming away from home.  In the case of mobile node
   active inter-MAG handoff from the source to the target MAG, the
   target MAG usually sends a proxy BU message to the mobile node local
   mobility anchor to update the mobile node BCE with a new pCoA.  As
   soon as the LMA receives and successfully processes the proxy BU from
   the target MAG, LMA updates the mobile node BCE with the new care of
   address and switch the tunnel to the target MAG.


   However, during active inter-MAG handoff scenario, some of the mobile
   node uplink traffic may still be in transit through the previous MAG.
   In addition, in some active handoff scenarios, it is necessary to
   prepare the target MAG prior to completion of link layer handoff
   procedures.  In some systems, the target MAG will be the recipient of
   uplink traffic prior to the completion of the procedure that would
   result in the PBU/PBA.  Currently and as per PMIPv6 base protocol
   [1], LMA routes the mobile node's uplink traffic received from a
   tunnel as long as the source IP address of the mobile node's uplink
   traffic matches the IP address of the mobile node's registered pCoA
   in an active BCE.


   This document specifies an enhancement to Proxy MIPv6 base protocol
   to support transient registration.  This process allows the target
   mobile access gateway to request the local mobility anchor to create
   a transient binding cache entry with uplink traffic forwarding
   capabilities for a specified period of time while still maintaining
   the active state for the existing BCE, i.e., sending and receiving
   traffic on both directions.  Eventually and after a short lived
   lifetime, the mobile node transient BCE is updated to regular BCE and
   the original regular BCE is removed as described in Section 6

   This mechanism is critical for reducing handoff latency and will be
   an important parameter for real-time applications such as VoIP.  It
   is assumed that inter-MAG handoff is carried out with a central
   entity that is responsible for the mobile node context transfer
   across the source and target MAGs.







Muhanna, et al.          Expires August 28, 2008                [Page 3]


Internet-Draft    PMIPv6 Support Transient Registration    February 2008


2.  Conventions used in this document

   The keywords "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].

   General mobility terminology can be found in [5], [3], and [1].  The
   following additional or clarified terms are used in this document:

   Proxy BCE (pBCE):

      The mobile node BCE that has the same characteristics as the MN
      BCE in PMIPv6 base protocol [1].

   Transient BCE (tBCE):

      The mobile node BCE that is created by the process described in
      this document.  The tBCE is short lived with a lifetime that is no
      more than the transient registration lifetime.  When LMA creates
      such transient BCE, it allows uplink traffic from the mobile node
      while the mobile node is in the process of moving from sMAG to the
      tMAG.

   Transient Registration (tReg.)

      The mechanism which allows the LMA to create a transient BCE for a
      specific mobile node with uplink traffic forward capability from a
      care-of address different than the current proxy care-of address
      that is registered in the mobile node current regular BCE.  During
      the lifetime of the tBCE, the LMA may forward the mobile node
      uplink traffic from both care-of addresses to the internet while
      sending the downlink traffic to the source care-of address.

   Source MAG (sMAG):

      The mobile access gateway that the mobile node is currently
      attached to and moving from its area coverage to another MAG.

   Target MAG (tMAG):

      The mobile access gateway that the mobile node is moving to its
      area of coverage and attaches to during an inter-MAG handoff
      scenario.








Muhanna, et al.          Expires August 28, 2008                [Page 4]


Internet-Draft    PMIPv6 Support Transient Registration    February 2008


   Source proxy Care-of Address (s-pCoA):

      The mobile node proxy care-of address that is hosted at the sMAG
      and currently referenced in the mobile node regular BCE before the
      transient registration starts.

   Transient proxy Care-of Address (t-pCoA):

      The mobile node's proxy care-of address that is hosted at tMAG and
      has been registered by the tMAG during a mobile node transient
      registration procedure.  It is the pCoA in an active tBCE.


3.  PMIPv6 Transient Registration Overview

   Several scenarios have been identified relevant to PMIPv6 support for
   mobile nodes multihoming where a mobile node is multihomed through
   different interfaces simultaneously accessing the same PMIPv6 domain.
   Transient multihoming scenario has been described in [4] where a
   mobile node is transitionally multihomed using different proxy
   care-of addresses for a short period of time.  This transient
   multihoming scenario is enabled through PMIPv6 support of transient
   registration.

   During active inter-MAG handoff scenario, a transitional period of
   time requires the LMA in the PMIPv6 domain to accept uplink traffic
   for the same mobile node but through different MAGs.  Context
   transfer is assumed to provide the needed mobile node information and
   parameters to enable the target MAG to send a proxy BU message with
   the same HNP and interface ID, however, with an indication that the
   current registration is a transient registration with a short
   lifetime.  As soon as the LMA receives a P-BU with transient
   registration mobility option, the LMA identifies the mobile nodes
   current pBCE which reflects the s-pCoA and creates a new tBCE with a
   lifetime as specified in the TRO lifetime field.  Additionally, the
   LMA tags the tBCE as uplink traffic forwarding as per the traffic
   direction in the TRO.  Figure 1 shows a mobile node binding cache
   entry state during inter-MAG active handoff using a single interface
   to access the PMIPv6 domain.












Muhanna, et al.          Expires August 28, 2008                [Page 5]


Internet-Draft    PMIPv6 Support Transient Registration    February 2008


                         Mobile node's BCE States @ LMA
                         ==============================
                         Before tReg.
                                MN-if1 [prefix1 @ sMAG]  [pBCE]

                         During tReg.
                                MN-if1 [prefix1 @ tMAG]  [tBCE]
                                MN-if1 [prefix1 @ sMAG]  [pBCE]

                         After tReg.
                               MN-if1 [prefix1 @ tMAG]  [pBCE]
                               MN-if1 [prefix1 @ sMAG]  [removed]

+=====+   if1     +------+                                      +------+
| MN  |---------->|      |                                      |      |
+=====+           | tMAG |\          +=================+        |      |
   |              |      | \       /                     \      |      |
   ^              +------+  \     /  IPv6/IPv4 Transport  \     |  L   |
   MN                        +---+          ......         +----|  M   |
Handover          +------+  /     \  IPv6/IPv4 Transport  /     |  A   |
   ^              |      | /       \                     /      |      |
...^...   if1     | sMAG |/          +=================+        |      |
| MN  |...........|      |                                      |      |
.......           +------+                                      +------+


                  |<------------------ PMIPv6 Domain ---------------->|


   Figure 1: PMIPv6 Transient Multihoming during Inter-MAG handoff Over
                              one Interface.



   It is assumed that during the active inter-MAG handoff and when the
   tMAG sends a P-BU for a new transient BCE, the mobile node is homed
   at the target MAG.  However, in order to guarantee safe and on time
   delivery of the uplink and downlink traffics, a transient BCE with
   uplink traffic forwarding capability is necessary.  During the tBCE
   lifetime, the LMA continue to send all of the mobile node downlink
   traffic to the sMAG.  It is also assumed that the source MAG is aware
   of the mobile node's current point of attachment and forward all of
   the downlink traffic to the mobile node accordingly.


4.  Transient Registration Option

   Transient Registration Option, TRO, is included in the P-BU message



Muhanna, et al.          Expires August 28, 2008                [Page 6]


Internet-Draft    PMIPv6 Support Transient Registration    February 2008


   by the tMAG to indicate to the LMA that it is requesting the
   registration and creation of a transient BCE with the criterias as
   defined in the TRO.  The source IP address of the P-BU is considered
   the transient CoA while the lifetime field specifies the transient
   BCE lifetime in one-tenth of seconds.  The transient traffic field
   specifies the traffic forwarding capability throughout the tBCE
   lifetime, which in this case is limited to uplink only.  The
   Transient Registration option has an alignment requirement of 4n+2.
   Its format is as shown in Figure 2 below.


       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     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Reserved (R) | Trans. Traffic|    Transient BCE Lifetime     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


              Figure 2: Transient Registration Option Format


  Type
      <IANA>

  Length
      8-bit unsigned integer indicating the length in octets of this
      option, excluding the type and length fields. The value of this
      field must be set to 4.

  Reserved (R)
      This 8-bit field is unused for now. The value MUST be initialized
      to 0 by the sender and MUST be ignored by the receiver.

  Transient Traffic Direction
      This 8-bit field is used as a bit-wise field to specify the
      transient traffic direction. The following values are specified.

      00000001   Uplink Traffic Forward Capability
      All remaining Values are reserved.

  Transient BCE Lifetime
      This 16-bit field specify the requested lifetime for the transient
      BCE in the number one-tenth of a second.






Muhanna, et al.          Expires August 28, 2008                [Page 7]


Internet-Draft    PMIPv6 Support Transient Registration    February 2008


5.  Mobile Access Gateway Operation

   During the mobile node inter-MAG handoff process, the target MAG gets
   the current mobile node BCE information through an out of scope
   context transfer mechanism.  It is assumed that the target MAG have
   access to the mobile node ID, HNP, Interface ID.  When the target MAG
   receives the indication that the mobile node is moving from the
   source MAG access network area to the target MAG area, the target MAG
   sends a PBU on behalf of the mobile node.  In this PBU, the target
   MAG specifies the MN-ID, HNP, and the interface ID as per PMIPv6 base
   protocol.


   On the other hand, the target MAG sets the HI to 3 and includes the
   transient registration option to indicate to the LMA that this
   registration is a transient registration P-BU and the LMA needs to
   create a tBCE.  The tMAG sets the value of the transient lifetime to
   a value that is dependent on the deployment and operator specific.
   Additionally, the tMAG indicates that transient traffic forwarding
   capability is uplink only by setting the transient traffic field to a
   value 1.


   After the target MAG receives an indication that the mobile node has
   completed the inter-MAG handoff process and the data path is ready to
   move the tunnel completely from the source MAG to the target MAG, the
   target MAG SHOULD send a PBU to allow the local mobility anchor to
   update the tBCE to a regular BCE and to switch the data bath
   completely to be delivered through the target care-of address.  In
   this case, the tMAG sends a PBU with the MN-ID, Interface ID, MN-HNP
   and at the same time sets the HI to 3.  The tMAG does not include the
   transient registration option as shown in Figure 3.



















Muhanna, et al.          Expires August 28, 2008                [Page 8]


Internet-Draft    PMIPv6 Support Transient Registration    February 2008


    +-----+      +-----+      +-----+                     +-----+
    | MN  |      |s-MAG|      |t-MAG|                     | LMA |
    +-----+      +-----+      +-----+                     +-----+
       |            |            |  bi-directional           |
       |            |<<<<<<<<========================>>>>>>>>|
       |            |            |                         pBCE
       |            |            |                  [HNP1, s-pCOA, IF1]
   Handoff Event    |            |                           |
       |        MN HO Event      |                           |
       |            |      HO Event Acquire                  |
       |            |   MN pBCE[MN-ID, HNP1, IF1]            |
 LL Attach to       |            |                           |
    tMAG AN         |            |-------P-BU (tReg.)------->|
       |            |            |                     Create tBCE
       |            |            |                  [HNP1, t-pCOA, IF1]
       |            |            |                   pBCE HO Progress
       |            |            |<------P-BA (tReg.)--------|
       |            |            |                           |
       |            |          bi-directional                |
       |            |<<<<<<<<========================>>>>>>>>|
       |            |            |                           |
       |            |            |      uplink only          |
       |            |            |>>>>>>=============>>>>>>>>|
       |            |            |                           |
       |            |        HO Complete                     |
       |            |            |----- P-BU (NO tReg.) ---->|
       |            |            |                           |
       |            |            |                   Update tBCE to pBCE
       |            |            |              pBCE=[HNP1, t-pCOA, IF1]
       |            |            |<--------- P-BA -----------|
       |            |`           |                           |
       |            |            |<<<<<<<<===========>>>>>>>>|
       |            |            |                           |
       |            |            |                   remove Source pBCE
       |            |            |                           |


       Figure 3: Target MAG Update MN tBCE during Inter-MAG Handover



   In the event that the target MAG receives downlink traffic destined
   to the mobile node from the LMA over the MAG-LMA tunnel, the tMAG
   MUST deliver the downlink traffic to the mobile node.  In this case,
   the tMAG choose not to send a PBU to update the mobile node tBCE.
   The tMAG may assume that the LMA has updated the mobile node tBCE to
   regular BCE possibly after the LMA received a de-registration message
   from the source MAG for the pBCE with care-of address s-pCoA.



Muhanna, et al.          Expires August 28, 2008                [Page 9]


Internet-Draft    PMIPv6 Support Transient Registration    February 2008


6.  Local Mobility Anchor Operation

   When an uplink packet is received from the MN through the target MAG,
   the LMA MUST verify if the source address of the packet matches the
   transient pCoA.  If the address matches, the LMA MUST consider the
   packet to be valid and MUST forward the packet appropriately based on
   the contents of the decapsulated packet.  If the mobile node's tBCE
   indicates uplink traffic forwarding capability, the LMA MUST NOT use
   the tBCE for sending out downlink traffic to the MN through the
   target MAG.


   When the LMA receives a PBU with the transient registration option
   included and the MN-ID, HNP, and the IF-ID, the LMA allocates all the
   binding cache entries for the same MN-ID.  The LMA then identifies
   the BCE that have the same HNP and Interface ID.  The LMA set an
   indication flag to "handoff in progress".  The LMA creates a tBCE
   after allocating the same HNP and sets the transient lifetime field
   to the value received in the TRO.  LMA sends a PBA with HI equals to
   the value received in PBU and as per the processes in PMIPv6 base
   protocol.


   After the LMA creates the mobile node transient BCE, the LMA add
   another routing entry to the MN for the new t-pCOA.  As long as the
   tBCE is active, the LMA MUST forward all of the mobile node
   intercepted downlink traffic to the source pCOA.



7.  Transient Binding Cache Entries Update

   The transient binding cache entry, which was created by the procedure
   described in this document, needs to be short lived. i.e. for the
   duration of the inter-MAG handover.  After the handover completes,
   this entry needs to be updated to a pBCE state.  At the same time,
   the LMA deletes the mobile node pBCE which is tagged as "handoff in
   progress" and points to the source pCOA which is hosted at the sMAG.
   There are three ways by which this process can happen:

   1.  The target MAG sends a new PBU with HI value 3 (Handoff between
       mobile access gateways for the same interface): The transient
       binding cache entry is converted into a full blown binding cache
       entry and the BCE for the source MAG is removed.  Figure 3 shows
       the call flow for this procedure.






Muhanna, et al.          Expires August 28, 2008               [Page 10]


Internet-Draft    PMIPv6 Support Transient Registration    February 2008


   2.  The source MAG sends a deregistration PBU: The transient binding
       cache entry is converted into a pBCE and the pBCE for the source
       MAG is removed.  Figure 4 shows the call flow for this procedure.


   3.  Transient BCE lifetime expires: If the tBCE lifetime expires
       before the tBCE has been updated based on one of the above cases
       Paragraph 1 or Paragraph 2, the LMA MUST update the tBCE to pBCE
       and remove the pBCE for the source MAG as shown in Figure 5 .
       Additionally, the LMA MAY send a revocation indication message to
       indicate to the source MAG that the mobile node's pBCE has been
       removed and it needs to clean associated resources.







































Muhanna, et al.          Expires August 28, 2008               [Page 11]


Internet-Draft    PMIPv6 Support Transient Registration    February 2008


    +-----+      +-----+      +-----+                     +-----+
    | MN  |      |s-MAG|      |t-MAG|                     | LMA |
    +-----+      +-----+      +-----+                     +-----+
       |            |            |  bi-directional           |
       |            |<<<<<<<<========================>>>>>>>>|
       |            |            |                         pBCE
       |            |            |                  [HNP1, s-pCOA, IF1]
   Handoff Event    |            |                           |
       |        MN HO Event      |                           |
       |            |      HO Event Acquire                  |
       |            |   MN pBCE[MN-ID, HNP1, IF1]            |
 LL Attach to       |            |                           |
    tMAG AN         |            |                           |
       |            |            |-------P-BU (tReg.)------->|
       |            |            |                           |
       |            |            |                     Create tBCE
       |            |            |                  [HNP1, t-pCOA, IF1]
       |            |            |                   pBCE HO Progress
       |            |            |<------P-BA (tReg.)--------|
       |            |            |                           |
       |            |          bi-directional                |
       |            |<<<<<<<<========================>>>>>>>>|
       |            |            |                           |
       |            |            |      uplink only          |
       |            |            |>>>>>>=============>>>>>>>>|
       |           HO            |                           |
       |         Complete        |                           |
       |            |------------- P-BU (de-Reg.) ---------->|
       |            |            |                           |
       |            |            |                   Remove Source pBCE
       |            |<------------------ P-BA ---------------|
       |            |            |                           |
       |            |            |                   Update tBCE to pBCE
       |            |            |              pBCE=[HNP1, t-pCOA, IF1]
       |            |`           |                           |
       |            |            |<<<<<<<<===========>>>>>>>>|
       |            |            |                           |



   Figure 4: Source MAG Deregister MN Old pBCE during Inter-MAG Handover










Muhanna, et al.          Expires August 28, 2008               [Page 12]


Internet-Draft    PMIPv6 Support Transient Registration    February 2008


    +-----+      +-----+      +-----+                     +-----+
    | MN  |      |s-MAG|      |t-MAG|                     | LMA |
    +-----+      +-----+      +-----+                     +-----+
       |            |            |                           |
       |            |            |                     tBCE Active
       |            |            |                  tReg. Lifetime Start
       |            |              bi-directional            |
       |            |<<<<<<<<========================>>>>>>>>|
       |            |            |                           |
       |            |            |       uplink only         |
       |            |            |>>>>>>=============>>>>>>>>|
       |           HO            |                           |
       |         Complete        |                           |
       |            |            |                tReg. Lifetime Expires
       |            |            |                  No PBU from tMAG
       |            |            |                No De-reg. from sMAG
       |            |            |                           |
       |            |            |                           |
       |            |            |                   Update tBCE to pBCE
       |            |            |      bi-directional       |
       |            |            |<<<<<<<<===========>>>>>>>>|
       |            |            |                           |
       |            |            |                   remove source pBCE
       |            |            |                           |
       |            |            |                           |


      Figure 5: LMA Updates Transient BCE upon Transient Registration
                              Lifetime Expiry



8.  IANA Considerations

   This document defines one new Mobility Header option, the Transient
   Registration option, which is described in Figure 2.  The Type value
   for this option needs to be assigned from the same numbering space as
   allocated for the other mobility options, as defined in [3].



9.  Security Considerations

   This document does not present any new security requirement on the
   top of the security requirements listed in PMIPv6 base protocol [1].
   It only presents a mechanism which allows a mobile node to be
   transitionally multihomed at two care of addresses during an inter-
   MAG active handoff using the existing trust relationship and security



Muhanna, et al.          Expires August 28, 2008               [Page 13]


Internet-Draft    PMIPv6 Support Transient Registration    February 2008


   association between the LMA and the source and target MAGs.




10.  Acknowledgements

   The idea to capture transient registration as presented in this
   document came out of a discussion during IETF70 at Vancouver in
   December 2007.  The following people were involved in the discussion
   (listed by last name) Kuntal Chowdhury, Vijay Devarapalli, Sri
   Gundavelli, Lalit Kotecha, Suresh Krishnan, Kent Leung and Ahmad
   Muhanna.




11.  References

11.1.  Normative References

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

   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [3]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
        IPv6", RFC 3775, June 2004.

   [4]  Muhanna, A. and M. Khalil, "Proxy MIPv6 support for Mobile Nodes
        with Multihoming", draft-muhanna-netlmm-multihoming-support-01
        (work in progress), February 2008.

11.2.  Informative References

   [5]  Manner, J. and M. Kojo, "Mobility Related Terminology",
        RFC 3753, June 2004.

   [6]  Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile
        IPv6", draft-ietf-netlmm-pmip6-ipv4-support-02 (work in
        progress), November 2007.








Muhanna, et al.          Expires August 28, 2008               [Page 14]


Internet-Draft    PMIPv6 Support Transient Registration    February 2008


Authors' Addresses

   Ahmad Muhanna
   Nortel Networks
   2221 Lakeside Blvd.
   Richardson, TX  75082
   USA

   Phone: +1 (972) 685-1416
   Email: amuhanna@nortel.com


   Suresh Krishnan
   Ericsson
   8400 Decarie Blvd.
   Town of Mount Royal, QC
   Canada

   Phone: +1 (514) 345-7900 x42871
   Email: suresh.krishnan@ericsson.com


   Kent Leung
   Cisco
   170 West Tasman Drive
   San Jose, CA  95134
   USA

   Email: kleung@cisco.com


   Basavaraj Patil
   Nokia Siemens Networks
   6000 Connection Drive
   Irving, TX  75039
   USA

   Email: basavaraj.patil@nsn.com













Muhanna, et al.          Expires August 28, 2008               [Page 15]


Internet-Draft    PMIPv6 Support Transient Registration    February 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.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Muhanna, et al.          Expires August 28, 2008               [Page 16]