Internet DRAFT - draft-krishnan-netext-update-notifications
draft-krishnan-netext-update-notifications
Netext WG S. Krishnan
Internet-Draft Ericsson
Intended status: Standards Track S. Gundavelli
Expires: April 25, 2013 Cisco
M. Liebsch
NEC
H. Yokota
KDDI
J. Korhonen
Nokia Siemens Networks
October 22, 2012
Update Notifications for Proxy Mobile IPv6
draft-krishnan-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 April 25, 2013.
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 April 25, 2013 [Page 1]
Internet-Draft PMIPv6 Update Notifications October 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. Example use case . . . . . . . . . . . . . . . . . . . . . . . 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 April 25, 2013 [Page 2]
Internet-Draft PMIPv6 Update Notifications October 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. 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.
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 messahes do not
provide the required semantics. e.g. The Heartbeat message does not
provide a reason why it was sent.
2. Example use case
Consider an 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.
Krishnan, et al. Expires April 25, 2013 [Page 3]
Internet-Draft PMIPv6 Update Notifications October 2012
+--+ +---+ +-----+ +-----+
|MN| |MAG| |rfLMA| |r2LMA|
+--+ +---+ +-----+ +-----+
| | | |
O----------O-----------------O |
| | UPN[FORCEREREG] | |
| |<----------------| |
| | PBU | |
| |---------------->| [IWK] |
| | PBA(redirect) |<--------------->|
| |<----------------| |
| | | |
| | | |
|<====================data====================>|
| | | |
. . . .
. . . .
. . . .
| | PBU | | Lifetime
| |---------------------------------->| extension
| | | |
| | | |
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
the MAG is out of the scope of this document and will be specified
for each Notification reason.
Krishnan, et al. Expires April 25, 2013 [Page 4]
Internet-Draft PMIPv6 Update Notifications October 2012
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 April 25, 2013 [Page 5]
Internet-Draft PMIPv6 Update Notifications October 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.
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 April 25, 2013 [Page 6]
Internet-Draft PMIPv6 Update Notifications October 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.
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 April 25, 2013 [Page 7]
Internet-Draft PMIPv6 Update Notifications October 2012
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
Email: marco.liebsch@nw.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 April 25, 2013 [Page 8]
