Update Notifications for Proxy Mobile IPv6
The information below is for an old version of the document.
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|Authors||Suresh Krishnan , Sri Gundavelli , Marco Liebsch , Hidetoshi Yokota , Jouni Korhonen|
|Stream||Stream state||(No stream defined)|
|RFC Editor Note||(None)|
|IESG||IESG state||I-D Exists|
|Send notices to||(None)|
Netext WG S. Krishnan Internet-Draft Ericsson Intended status: Standards Track S. Gundavelli Expires: November 22, 2012 Cisco Systems M. Liebsch NEC H. Yokota KDDI J. Korhonen Nokia Siemens Networks May 21, 2012 Update Notifications for Proxy Mobile IPv6 draft-krishnan-netext-update-notifications-00 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 November 22, 2012. Copyright Notice Copyright (c) 2012 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 November 22, 2012 [Page 1] Internet-Draft PMIPv6 Update Notifications May 2012 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. LMA Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. MAG Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Update Notification(UPN) . . . . . . . . . . . . . . . . . 4 4.2. Update Notification Acknowledgement(UPA) . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 7.2. Informative References . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Krishnan, et al. Expires November 22, 2012 [Page 2] Internet-Draft PMIPv6 Update Notifications May 2012 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 reregister. This document defines a new mobility header message for doing so and a corresponding mobility header message for the MAG to acknowledge the notification. 2. 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. 3. 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 the MAG is out of the scope of this document and will be specified for each Notification reason. Krishnan, et al. Expires November 22, 2012 [Page 3] Internet-Draft PMIPv6 Update Notifications May 2012 4. Message Formats 4.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. 4.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 November 22, 2012 [Page 4] Internet-Draft PMIPv6 Update Notifications May 2012 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. 5. 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 . 6. 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 November 22, 2012 [Page 5] Internet-Draft PMIPv6 Update Notifications May 2012 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. 7. References 7.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. 7.2. Informative References [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011. Authors' Addresses Suresh Krishnan Ericsson 8400 Blvd Decarie Town of Mount Royal, Quebec Canada Phone: +1 514 345 7900 x42871 Email: email@example.com Sree Gundavelli Cisco Systems Email: firstname.lastname@example.org Marco Liebsch NEC Email: email@example.com Krishnan, et al. Expires November 22, 2012 [Page 6] Internet-Draft PMIPv6 Update Notifications May 2012 Hidetoshi Yokota KDDI Email: firstname.lastname@example.org Jouni Korhonen Nokia Siemens Networks Linnoitustie 6 FI-02600 Espoo Finland Email: email@example.com Krishnan, et al. Expires November 22, 2012 [Page 7]