Skip to main content

Update Notifications for Proxy Mobile IPv6
draft-ietf-netext-update-notifications-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7077.
Authors Suresh Krishnan , Sri Gundavelli , Marco Liebsch , Hidetoshi Yokota , Jouni Korhonen
Last updated 2013-03-14
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state Became RFC 7077 (Proposed Standard)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-netext-update-notifications-01
Netext WG                                                    S. Krishnan
Internet-Draft                                                  Ericsson
Intended status: Standards Track                           S. Gundavelli
Expires: September 15, 2013                                        Cisco
                                                              M. Liebsch
                                                                     NEC
                                                               H. Yokota
                                                                    KDDI
                                                             J. Korhonen
                                                  Nokia Siemens Networks
                                                          March 14, 2013

               Update Notifications for Proxy Mobile IPv6
               draft-ietf-netext-update-notifications-01

Abstract

   Proxy Mobile IPv6 (PMIPv6) is a network based mobility management
   protocol that enables IP mobility for a host without requiring its
   participation in any mobility-related signaling.  This document
   proposes a mechanism for the Local Mobility Anchor to asynchronously
   notify the Mobile Access Gateway about changes related to the
   mobility session.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on September 15, 2013.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal

Krishnan, et al.       Expires September 15, 2013               [Page 1]
Internet-Draft         PMIPv6 Update Notifications            March 2013

   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Example use case: LMA-requested re-registration . . . . . . . . 3
   3.  LMA Behavior  . . . . . . . . . . . . . . . . . . . . . . . . . 4
   4.  MAG Behavior  . . . . . . . . . . . . . . . . . . . . . . . . . 4
   5.  Message Formats . . . . . . . . . . . . . . . . . . . . . . . . 5
     5.1.  Update Notification(UPN)  . . . . . . . . . . . . . . . . . 5
     5.2.  Update Notification Acknowledgement(UPA)  . . . . . . . . . 5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     9.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7

Krishnan, et al.       Expires September 15, 2013               [Page 2]
Internet-Draft         PMIPv6 Update Notifications            March 2013

1.  Introduction

   Proxy Mobile IPv6 [RFC5213] describes the protocol operations to
   maintain reachability and session persistence for a Mobile Node (MN)
   without the explicit participation from the MN in signaling
   operations at the Internet Protocol (IP) layer.  In order to
   facilitate such network-based mobility, the PMIPv6 protocol defines a
   Mobile Access Gateway (MAG), which acts as a proxy for the Mobile
   IPv6 [RFC6275] signaling, and the Local Mobility Anchor (LMA) which
   acts similar to a Home Agent.  The setup of the mobility session is
   initiated by the MAG by sending a PBU message and confirmed by the
   LMA in the PBA message.  Once the mobility session is set up for a
   given lifetime, the LMA has no mechanism to inform the MAG about
   changes to the mobility session or any parameters related to the
   mobility session.

   One such scenario where such a mechanism is needed is when the LMA
   wants to inform the MAG that it needs to re-register MNs being
   attached to the MAG.  It is possible to achieve a similar effect by
   using a much shorter lifetime for the mobility sessions but in
   several networks this results in an unacceptable, and mostly
   unnecessary, increase in the signaling load and overhead.  More
   suitable is to enable a demand-based trigger from an LMA by means of
   signaling from the LMA to one or more MAGs.

   This document defines a new mobility header message for performing
   notifications and a corresponding mobility header message for the MAG
   to acknowledge the notification.  While it is possible to use an
   existing mobility header type for this purpose, for instance the
   PMIPv6 Heartbeat message [RFC5847], the existing messages do not
   provide the required semantics. e.g.  The Heartbeat message does not
   provide a reason why it was sent.

2.  Example use case: LMA-requested re-registration

   Consider a use case where an LMA (rfLMA) wants to move over one or
   more mobility sessions from a given MAG to a different LMA (r2LMA)
   using [RFC6463], e.g. in order to allow planned maintenance.  The LMA
   could send an update notification to the MAG to force a re-
   registration for one or more MNs.  The MAG tries to register and gets
   a redirect from the rfLMA towards the r2LMA according to the
   mechanisms as per [RFC6463].  Such operation is exemplarily depicted
   in Figure 1.

Krishnan, et al.       Expires September 15, 2013               [Page 3]
Internet-Draft         PMIPv6 Update Notifications            March 2013

   +--+      +---+            +-----+           +-----+
   |MN|      |MAG|            |rfLMA|           |r2LMA|
   +--+      +---+            +-----+           +-----+
   |          |                 |                 |
   O----------O-----------------O                 |
   |          | UPN[FORCEREREG] |                 |
   |          |<----------------|                 |
   |          |       PBU       |                 |
   |          |---------------->|      [IWK]      |
   |          |  PBA(redirect)  |<--------------->|
   |          |<----------------|                 |
   |          |                 |                 |
   |          |                 |                 |
   |<====================data====================>|
   |          |                 |                 |
   .          .                 .                 .
   .          .                 .                 .
   .          .                 .                 .
   |          |       PBU       |                 | Lifetime
   |          |---------------------------------->| extension
   |          |                 |                 |
   |          |                 |                 |

         Figure 1: Using the UPN for LMA-requested re-registration

3.  LMA Behavior

   The LMA sends the Update Notification message in response to a
   condition that is specified in the Notification Reason field.  If the
   LMA requires an acknowledgement from the MAG concerning the UPN
   message, it MUST set the A bit to 1.  If not it MUST set the A bit to
   0.  The LMA MAY retransmit the UPN messages if reliability is
   required for the specific Notification reason.  If the UPN message is
   retransmitted, the LMA MUST reuse the same sequence number as the
   original message.  If the LMA receives an UPA message with a failure
   Status (Status value >127) it SHOULD log an error.

4.  MAG Behavior

   If a received Update Notification message has the A bit set to 1, the
   MAG MUST create and transmit an Update Notification Acknowledgement
   message in response to the UPN message.  The sequence number of the
   UPA message MUST be copied from the UPN message that is being
   responded to.  Depending on whether the message was processed
   successfully or not, the MAG MUST set the Status value in the UPA
   message to an appropriate value.  The actual processing required on

Krishnan, et al.       Expires September 15, 2013               [Page 4]
Internet-Draft         PMIPv6 Update Notifications            March 2013

   the MAG is out of the scope of this document and will be specified
   for each Notification reason.

5.  Message Formats

5.1.  Update Notification(UPN)

   The LMA sends an UPN message to a MAG to notify the MAG that some
   information regarding the mobility session or parameters related to
   the mobility session has changed.

       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 #          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Notification Reason        |A|         Reserved            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       .                                                               .
       .                        Mobility options                       .
       .                                                               .
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Sequence Number: A monotonically increasing integer.  Set by the
      LMA and retained for retransmissions.

      Acknowledgement Requested (A): If this bit is set, the MAG MUST
      send an UPA message in response to the received UPN message.

      Notification Reason: Contains the code corresponding to the reason
      that caused the LMA to send the Update Notification to the MAG.
      This field does not contain any structure and MUST be treated as
      an enumeration.

      Mobility Options: Contains a set of mobility options for the MAG
      to act upon. The set of mobility options that can be present in
      the message is related to the Notification Reason field in the
      message.

5.2.  Update Notification Acknowledgement(UPA)

   The MAG sends an UPA message to a LMA in order to acknowledge that it
   has received an UPN message with the A bit set.

Krishnan, et al.       Expires September 15, 2013               [Page 5]
Internet-Draft         PMIPv6 Update Notifications            March 2013

       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 #          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Status     |                                               |
       +-+-+-+-+-+-+-+-+                                               +
       |                                                               |
       .                        Mobility options                       .
       .                                                               .
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Sequence Number: Copied from the UPN message being acknowledged.

      Status: Specifies the result of the MAG's processing of the UPN
      message. The status codes between 0 and 127 signify successful
      processing of the UPN message and codes between 128 and 255
      signify that an error occurred during processing of the UPN
      message.

      Mobility Options: Contains a set of mobility options used to
      provide context to the LMA. The set of mobility options that can
      be present in the message is related to the Status field in the
      message.

6.  Security Considerations

   The protocol specified in this document uses the same security
   association as defined in [RFC5213] for use between the LMA and the
   MAG to protect the UPN messages.Support for integrity protection
   using IPsec is REQUIRED, but support for confidentiality is NOT
   REQUIRED .

7.  IANA Considerations

   The Update Notification message require a single Mobility Header Type
   (TBA1) from the Mobility Header Types registry at
   http://www.iana.org/assignments/mobility-parameters

   The Update Notification Acknowledgement message require a single
   Mobility Header Type (TBA2) from the Mobility Header Types registry
   at http://www.iana.org/assignments/mobility-parameters

   This document creates a new registry for Notification Reasons.  The

Krishnan, et al.       Expires September 15, 2013               [Page 6]
Internet-Draft         PMIPv6 Update Notifications            March 2013

   allocation policy for this field is First Come, First Served.

   This document creates a new registry for Status codes in the UPA
   message.  The allocation policy for this field is First Come, First
   Served.

8.  Acknowledgements

   The authors would like to thank Basavaraj Patil, Rajeev Koodli and
   other members of netext working group for their valuable comments to
   improve this document.

9.  References

9.1.  Normative References

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

   [RFC5213]  Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
              and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.

9.2.  Informative References

   [RFC5847]  Devarapalli, V., Koodli, R., Lim, H., Kant, N., Krishnan,
              S., and J. Laganier, "Heartbeat Mechanism for Proxy Mobile
              IPv6", RFC 5847, June 2010.

   [RFC6275]  Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
              in IPv6", RFC 6275, July 2011.

   [RFC6463]  Korhonen, J., Gundavelli, S., Yokota, H., and X. Cui,
              "Runtime Local Mobility Anchor (LMA) Assignment Support
              for Proxy Mobile IPv6", RFC 6463, February 2012.

Krishnan, et al.       Expires September 15, 2013               [Page 7]
Internet-Draft         PMIPv6 Update Notifications            March 2013

Authors' Addresses

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

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

   Sri Gundavelli
   Cisco
   170 West Tasman Drive
   San Jose, CA  95134
   USA

   Email: sgundave@cisco.com

   Marco Liebsch
   NEC
   Kurfuersten-Anlage 36
   D-69115 Heidelberg
   Germany

   Email: marco.liebsch@neclab.eu

   Hidetoshi Yokota
   KDDI

   Email: yokota@kddilabs.jp

   Jouni Korhonen
   Nokia Siemens Networks
   Linnoitustie 6
   FI-02600 Espoo
   Finland

   Email: jouni.nospam@gmail.com

Krishnan, et al.       Expires September 15, 2013               [Page 8]