idnits 2.17.1 draft-krishnan-netext-update-notifications-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 22, 2012) is 4197 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'FORCEREREG' is mentioned on line 120, but not defined == Missing Reference: 'IWK' is mentioned on line 123, but not defined == Unused Reference: 'RFC2119' is defined on line 266, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Netext WG S. Krishnan 3 Internet-Draft Ericsson 4 Intended status: Standards Track S. Gundavelli 5 Expires: April 25, 2013 Cisco 6 M. Liebsch 7 NEC 8 H. Yokota 9 KDDI 10 J. Korhonen 11 Nokia Siemens Networks 12 October 22, 2012 14 Update Notifications for Proxy Mobile IPv6 15 draft-krishnan-netext-update-notifications-01 17 Abstract 19 Proxy Mobile IPv6 (PMIPv6) is a network based mobility management 20 protocol that enables IP mobility for a host without requiring its 21 participation in any mobility-related signaling. This document 22 proposes a mechanism for the Local Mobility Anchor to asynchronously 23 notify the Mobile Access Gateway about changes related to the 24 mobility session. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 25, 2013. 43 Copyright Notice 45 Copyright (c) 2012 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Example use case . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. LMA Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4. MAG Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . . 5 65 5.1. Update Notification(UPN) . . . . . . . . . . . . . . . . . 5 66 5.2. Update Notification Acknowledgement(UPA) . . . . . . . . . 5 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 69 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 72 9.2. Informative References . . . . . . . . . . . . . . . . . . 7 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 75 1. Introduction 77 Proxy Mobile IPv6 [RFC5213] describes the protocol operations to 78 maintain reachability and session persistence for a Mobile Node (MN) 79 without the explicit participation from the MN in signaling 80 operations at the Internet Protocol (IP) layer. In order to 81 facilitate such network-based mobility, the PMIPv6 protocol defines a 82 Mobile Access Gateway (MAG), which acts as a proxy for the Mobile 83 IPv6 [RFC6275] signaling, and the Local Mobility Anchor (LMA) which 84 acts similar to a Home Agent. The setup of the mobility session is 85 initiated by the MAG by sending a PBU message and confirmed by the 86 LMA in the PBA message. Once the mobility session is set up for a 87 given lifetime, the LMA has no mechanism to inform the MAG about 88 changes to the mobility session or any parameters related to the 89 mobility session. 91 One such scenario where such a mechanism is needed is when the LMA 92 wants to inform the MAG that it needs to reregister. It is possible 93 to achieve a similar effect by using a much shorter lifetime for the 94 mobility sessions but in several networks this results in an 95 unacceptable, and mostly unnecessary, increase in the signaling load 96 and overhead. 98 This document defines a new mobility header message for performing 99 notifications and a corresponding mobility header message for the MAG 100 to acknowledge the notification. While it is possible to use an 101 existing mobility header type for this purpose, for instance the 102 PMIPv6 Heartbeat message [RFC5847], the existing messahes do not 103 provide the required semantics. e.g. The Heartbeat message does not 104 provide a reason why it was sent. 106 2. Example use case 108 Consider an use case where an LMA (rfLMA) wants to move over one or 109 more mobility sessions from a given MAG to a different LMA (r2LMA) 110 using [RFC6463]. e.g. In order to allow planned maintenance. The 111 LMA could send an update notification to the MAG to force a re- 112 registration for one or more MNs. The MAG tries to register and gets 113 a redirect from the rfLMA towards the r2LMA. 115 +--+ +---+ +-----+ +-----+ 116 |MN| |MAG| |rfLMA| |r2LMA| 117 +--+ +---+ +-----+ +-----+ 118 | | | | 119 O----------O-----------------O | 120 | | UPN[FORCEREREG] | | 121 | |<----------------| | 122 | | PBU | | 123 | |---------------->| [IWK] | 124 | | PBA(redirect) |<--------------->| 125 | |<----------------| | 126 | | | | 127 | | | | 128 |<====================data====================>| 129 | | | | 130 . . . . 131 . . . . 132 . . . . 133 | | PBU | | Lifetime 134 | |---------------------------------->| extension 135 | | | | 136 | | | | 138 3. LMA Behavior 140 The LMA sends the Update Notification message in response to a 141 condition that is specified in the Notification Reason field. If the 142 LMA requires an acknowledgement from the MAG concerning the UPN 143 message, it MUST set the A bit to 1. If not it MUST set the A bit to 144 0. The LMA MAY retransmit the UPN messages if reliability is 145 required for the specific Notification reason. If the UPN message is 146 retransmitted, the LMA MUST reuse the same sequence number as the 147 original message. If the LMA receives an UPA message with a failure 148 Status (Status value >127) it SHOULD log an error. 150 4. MAG Behavior 152 If a received Update Notification message has the A bit set to 1, the 153 MAG MUST create and transmit an Update Notification Acknowledgement 154 message in response to the UPN message. The sequence number of the 155 UPA message MUST be copied from the UPN message that is being 156 responded to. Depending on whether the message was processed 157 successfully or not, the MAG MUST set the Status value in the UPA 158 message to an appropriate value. The actual processing required on 159 the MAG is out of the scope of this document and will be specified 160 for each Notification reason. 162 5. Message Formats 164 5.1. Update Notification(UPN) 166 The LMA sends an UPN message to a MAG to notify the MAG that some 167 information regarding the mobility session or parameters related to 168 the mobility session has changed. 170 0 1 2 3 171 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 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | Sequence # | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | Notification Reason |A| Reserved | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | | 178 . . 179 . Mobility options . 180 . . 181 | | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 Sequence Number: A monotonically increasing integer. Set by the 185 LMA and retained for retransmissions. 187 Acknowledgement Requested (A): If this bit is set, the MAG MUST 188 send an UPA message in response to the received UPN message. 190 Notification Reason: Contains the code corresponding to the reason 191 that caused the LMA to send the Update Notification to the MAG. 192 This field does not contain any structure and MUST be treated as 193 an enumeration. 195 Mobility Options: Contains a set of mobility options for the MAG 196 to act upon. The set of mobility options that can be present in 197 the message is related to the Notification Reason field in the 198 message. 200 5.2. Update Notification Acknowledgement(UPA) 202 The MAG sends an UPA message to a LMA in order to acknowledge that it 203 has received an UPN message with the A bit set. 205 0 1 2 3 206 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 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | Sequence # | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | Status | | 211 +-+-+-+-+-+-+-+-+ + 212 | | 213 . Mobility options . 214 . . 215 | | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 Sequence Number: Copied from the UPN message being acknowledged. 220 Status: Specifies the result of the MAG's processing of the UPN 221 message. The status codes between 0 and 127 signify successful 222 processing of the UPN message and codes between 128 and 255 223 signify that an error occurred during processing of the UPN 224 message. 226 Mobility Options: Contains a set of mobility options used to 227 provide context to the LMA. The set of mobility options that can 228 be present in the message is related to the Status field in the 229 message. 231 6. Security Considerations 233 The protocol specified in this document uses the same security 234 association as defined in [RFC5213] for use between the LMA and the 235 MAG to protect the UPN messages.Support for integrity protection 236 using IPsec is REQUIRED, but support for confidentiality is NOT 237 REQUIRED . 239 7. IANA Considerations 241 The Update Notification message require a single Mobility Header Type 242 (TBA1) from the Mobility Header Types registry at 243 http://www.iana.org/assignments/mobility-parameters 245 The Update Notification Acknowledgement message require a single 246 Mobility Header Type (TBA2) from the Mobility Header Types registry 247 at http://www.iana.org/assignments/mobility-parameters 249 This document creates a new registry for Notification Reasons. The 250 allocation policy for this field is First Come, First Served. 252 This document creates a new registry for Status codes in the UPA 253 message. The allocation policy for this field is First Come, First 254 Served. 256 8. Acknowledgements 258 The authors would like to thank Basavaraj Patil, Rajeev Koodli and 259 other members of netext working group for their valuable comments to 260 improve this document. 262 9. References 264 9.1. Normative References 266 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 267 Requirement Levels", BCP 14, RFC 2119, March 1997. 269 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 270 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 272 9.2. Informative References 274 [RFC5847] Devarapalli, V., Koodli, R., Lim, H., Kant, N., Krishnan, 275 S., and J. Laganier, "Heartbeat Mechanism for Proxy Mobile 276 IPv6", RFC 5847, June 2010. 278 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 279 in IPv6", RFC 6275, July 2011. 281 [RFC6463] Korhonen, J., Gundavelli, S., Yokota, H., and X. Cui, 282 "Runtime Local Mobility Anchor (LMA) Assignment Support 283 for Proxy Mobile IPv6", RFC 6463, February 2012. 285 Authors' Addresses 287 Suresh Krishnan 288 Ericsson 289 8400 Blvd Decarie 290 Town of Mount Royal, Quebec 291 Canada 293 Phone: +1 514 345 7900 x42871 294 Email: suresh.krishnan@ericsson.com 296 Sri Gundavelli 297 Cisco 298 170 West Tasman Drive 299 San Jose, CA 95134 300 USA 302 Email: sgundave@cisco.com 304 Marco Liebsch 305 NEC 307 Email: marco.liebsch@nw.neclab.eu 309 Hidetoshi Yokota 310 KDDI 312 Email: yokota@kddilabs.jp 314 Jouni Korhonen 315 Nokia Siemens Networks 316 Linnoitustie 6 317 FI-02600 Espoo 318 Finland 320 Email: jouni.nospam@gmail.com