idnits 2.17.1 draft-gundavelli-netext-pmipv6-retransmit-option-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 date (June 02, 2009) is 5442 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) == Unused Reference: 'ID-PMIP6-IPv4' is defined on line 287, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: A later version (-18) exists of draft-ietf-netlmm-pmip6-ipv4-support-12 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETEXT WG S. Gundavelli 3 Internet-Draft K. Leung 4 Intended status: Standards Track Cisco 5 Expires: December 4, 2009 R. Koodli 6 Starent Networks 7 June 02, 2009 9 Retransmitted Message Identification Option for Proxy Mobile IPv6 10 draft-gundavelli-netext-pmipv6-retransmit-option-00.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on December 4, 2009. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 The Proxy Mobile IPv6 base protocol does not provide any mechanism 49 for the receiver of a mobility signaling message to determine if the 50 received message is the original message or a retransmitted message 51 of an earlier sent message. The absence of such a semantic in some 52 cases results in inefficient processing of the signaling messages and 53 will lead to additional processing load and network traffic. 55 This document defines a new mobility option, Retransmitted Message 56 Identification option for use in Proxy Binding Update and Proxy 57 Binding Acknowledgement messages. This option enables the mobility 58 entities to use proper message identifiers and retransmit markings on 59 the signaling messages. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Signaling and other Considerations . . . . . . . . . . . . . . 3 66 4. Retransmitted Message Identification (RMI) Option . . . . . . . 5 67 5. Protocol Configuration Variables . . . . . . . . . . . . . . . 6 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 70 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 73 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 76 1. Introduction 78 The Proxy Mobile IPv6 protocol [RFC-5213] does not provide the 79 ability for the sender of a signaling message to mark retransmitted 80 messages with a proper tag, so the receiver can differentiate between 81 the original message to a retransmitted message. This semantic is 82 important for the receiver to determine when to ignore processing a 83 retransmitted packet, or for various other reasons. 85 This document defines a new mobility option, Retransmitted Message 86 Identification (RMI) option, that can be used by a local mobility 87 anchor and a mobile access gateway for exchanging message and 88 retransmit identifiers. Following explains how the option helps in 89 detecting retransmitted messages. 91 MAG LMA 92 | PBU RMI(MesgId: 1, RetransId: 0) | 93 |---------------------------------------------->| * New message 94 | PBA RMI(MesgId: 1, RetransId: 0) | 95 |<----------------------------------------------| 96 | | 97 | | 98 | PBU RMI(MesgId: 2, RetransId: 0) | 99 |---------------------------------------------->| * Lost message 100 | No Response from MAG | 101 | | 102 | PBU RMI(MesgId: 2, RetransId: 1) | 103 |---------------------------------------------->| * Retransmitted 104 | | message 105 | PBA RMI(MesgId: 2, RetransId: 1) | 106 |<----------------------------------------------| 108 Figure 1: RMI Option Usage 110 2. Conventions 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in RFC 2119 [RFC-2119]. 116 3. Signaling and other Considerations 118 The following are the signaling considerations with respect to 119 supporting the retransmitted message identification capability. 121 o The mobile access gateway can choose to enable the retransmitted 122 message identification feature by including the Retransmitted 123 Message Identification (RMI) option (Section 4.0) in the Proxy 124 Binding Update that it sends to the local mobility anchor. The 125 configuration variable, EnableRetransmittedMessageIdentification, 126 can be used for controlling this aspect. 128 o For constructing the RMI option, each newly generated message MUST 129 have a unique message identifier (mid). This identifier is 130 specified in the mid field of the RMI option. The retransmit 131 identifier (rid) for the initial message will be set to value of 132 zero, this is specified in the rid field of the RMI option. The 133 mobile access gateway can maintain this message identifier as a 134 monotonically increasing counter maintained on a per packet basis 135 for each mobile node's session. 137 o The mobile access gateway may retransmit a Proxy Binding Update 138 message if it did not get a response to the previously transmitted 139 request. When retransmitting a message, the message identifier in 140 the RMI option MUST remain fixed and the retransmit identifier 141 MUST be increased by one. All other content in the message 142 including the options MUST be identical, except the sequence 143 number and the value in the Time Stamp option which can be 144 different. 146 o The conceptual Binding Update List entry data structure maintained 147 by the mobile access gateway, described in Section 6.1 of [RFC- 148 5213], MUST be extended to store the last sent message identifier 149 and the retransmit identifier. 151 o The local mobility anchor MUST include the RMI option in the Proxy 152 Binding Acknowledgement message, if the same option was present in 153 the received Proxy Binding Update. Otherwise, it MUST NOT include 154 the option. When this option is included in the message, the 155 message identifier and the retransmit identifier MUST be set to 156 the option values present in the request. 158 o If the local mobility anchor does not support the RMI option, it 159 SHOULD ignore the option and continue processing the rest of the 160 Proxy Binding Update message. The absence of the RMI option in 161 the Proxy Binding Acknowledgement indicates that the sender does 162 not support the Retransmitted Message Identification capability 163 and in such case the mobile access gateway MUST NOT include the 164 RMI option in the subsequent Proxy Binding Update messages that it 165 sends to that local mobility anchor. 167 o If the local mobility anchor receives a Proxy Binding Update 168 message while in the middle of processing a request (such as 169 waiting for response from AAA) with the same message identifier, 170 but with a different retransmit identifier, the message MUST be 171 silently ignored. 173 o The conceptual Binding Cache entry data structure maintained by 174 the local mobility anchor, described in Section 5.1 of [RFC-5213], 175 MUST be extended to store the last received message identifier and 176 the retransmit identifier. 178 4. Retransmitted Message Identification (RMI) Option 180 A new option, Retransmitted Message Identification (RMI) option is 181 defined for using it in Proxy Binding Update and Proxy Binding 182 Acknowledgement messages exchanged between a local mobility anchor 183 and a mobile access gateway. This option is used for carrying 184 message and retransmission identifiers. 186 The alignment requirement for this option is 4n. 188 0 1 2 3 189 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 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | Type | Length | Reserved | Retransmit-Id | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Message Identifier (mid) | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 Type 198 200 Length 202 8-bit unsigned integer indicating the length in octets of 203 the option, excluding the type and length fields. The value 204 for this field MUST be set to 6. 206 Retransmission Identifier (rid) 208 A 8-bit field for carrying the retransmission identifier. This 209 value will be set to zero for the first transmission of any 210 newly generated signaling message and the value will be 211 monotonically increased in each of the subsequent 212 retransmissions of the same message uniquely identified by the 213 message identifier. 215 Message Identifier (mid) 217 A 32-bit field for identifying the message. Each newly 218 generated Proxy Binding Update message will have a unique 219 identifier, however the Proxy Binding Acknowledgement will 220 always carry the identifier that was present in the request. 221 Any retransmitted messages will carry the same identifier that 222 was present in the initial message. 224 Figure 2: Retransmitted Message Identification (RMI) Option 226 5. Protocol Configuration Variables 228 The mobile access gateway MUST allow the following variables to be 229 configured by the system management. The configured values for these 230 protocol variables MUST survive server reboots and service restarts. 232 EnableRetransmittedMessageIdentification 233 This flag indicates whether or not the mobile access gateway 234 should include the retransmitted message identification option in 235 the mobility signaling messages that it sends to the local 236 mobility anchor. 238 The default value for this flag is set to FALSE, indicating that 239 the mobile access gateway MUST NOT include this option in any of 240 the Proxy Binding Update messages. 242 When the value for this flag is set to TRUE, the mobile access 243 gateway MUST include this option in all the Proxy Binding Update 244 messages. 246 6. IANA Considerations 248 This specification defines a new Mobility Header option, the 249 Retransmitted Message Identification option. This option can be 250 carried in mobility header messages. This option is described in 251 Section 4.0. The Type value for this option needs to be assigned 252 from the same numbering space as allocated for the other mobility 253 options, as defined in [RFC-3775]. 255 7. Security Considerations 257 The Retransmitted Message Identification option defined in this 258 specification is for use in mobility signaling messages, Proxy 259 Binding Update and Proxy Binding Acknowledgement messages. This 260 option is carried like any other mobility header option as specified 261 in [RFC-3775] and does not require any special security 262 considerations. The required security mechanisms specified in the 263 base Proxy Mobile IPv6 protocol [RFC-5213] for protecting these 264 signaling messages are sufficient when carrying these mobility 265 options. 267 8. Acknowledgements 269 The authors would like to thank Venkatesh Gota, Ashwin Kabadi and 270 Vojislav Vucetic on the discussions related to the similar semantics 271 present in GTP and making the motivation for this work stronger. 273 9. References 274 9.1. Normative References 276 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 277 Requirement Levels", BCP 14, RFC 2119, March 1997. 279 [RFC-3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in 280 IPv6", RFC 3775, June 2003. 282 [RFC-5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 283 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 285 9.2. Informative References 287 [ID-PMIP6-IPv4] R. Wakikawa and S. Gundavelli, "IPv4 Support for 288 Proxy Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-12, April 289 2009. 291 Authors' Addresses 293 Sri Gundavelli 294 Cisco 295 170 West Tasman Drive 296 San Jose, CA 95134 297 USA 299 Email: sgundave@cisco.com 301 Kent Leung 302 Cisco 303 170 West Tasman Drive 304 San Jose, CA 95134 305 USA 307 Email: kleung@cisco.com 309 Rajeev Koodli 310 Starent Networks 311 30 International Place 312 Tewksbury, MA 314 Email: rkoodli@starentnetworks.com