idnits 2.17.1 draft-wolfner-netext-pmip6-connid-01.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 == Line 277 has weird spacing: '... option is s...' -- The document date (October 4, 2009) is 5310 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Wolfner 3 Internet-Draft J. Korhonen, Ed. 4 Intended status: Informational Nokia Siemens Networks 5 Expires: April 7, 2010 October 4, 2009 7 Connection Identifier for Proxy Mobile IPv6 8 draft-wolfner-netext-pmip6-connid-01.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on April 7, 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This document describes a Connection Identifier mobility option for 47 Proxy Mobile IPv6. The new mobility option can be used to uniquely 48 identify multiple mobility sessions to the same selected service, for 49 example, in the Evolved Packet System scope. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Proxy Mobile IPv6 Domain Assumptions . . . . . . . . . . . . . 4 56 4. Connection Identifier Mobility Option . . . . . . . . . . . . . 4 57 5. Extensions to Conceptual Data Structures and Lookups . . . . . 5 58 5.1. Binding Cache . . . . . . . . . . . . . . . . . . . . . . . 5 59 5.2. Binding Update List . . . . . . . . . . . . . . . . . . . . 5 60 5.3. Lookup Keys . . . . . . . . . . . . . . . . . . . . . . . . 5 61 6. Processing Considerations . . . . . . . . . . . . . . . . . . . 6 62 6.1. Capability Exchange . . . . . . . . . . . . . . . . . . . . 6 63 6.2. Mobile Access Gateway Considerations . . . . . . . . . . . 6 64 6.3. Local Mobility Anchor Considerations . . . . . . . . . . . 6 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 67 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 10.1. Normative References . . . . . . . . . . . . . . . . . . . 7 70 10.2. Informative References . . . . . . . . . . . . . . . . . . 8 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction 75 A Mobile Node (MN) may have several mobility sessions via a single 76 interface with the same Local Mobility Anchor (LMA). An example 77 where a MN may have several mobility sessions with the same LMA is 78 the 3GPP environment using Enhanced Packet Core (EPC) [3GPP.23.401] 79 [3GPP.23.402]. In the 3GPP environment these mobility sessions are 80 called PDN connections (PDN stands for the Packet Data Network), and 81 PDN connections to the same service defined by an Access Point Name 82 (APN) use the same LMA instance. In 3GPP access networks these PDN 83 connections of a single MN can be identified by a unique identifier 84 called EPS bearer identifier (EPS stands for the Evolved Packet 85 System). Moreover, 3GPP EPC system can be used with access networks 86 that are not defined by the 3GPP such as CDMA or WLANs. These access 87 networks are generally referred as non-3GPP accesses. Therefore, an 88 unique identification of mobility sessions of a MN with the same LMA 89 is also needed with those non-3GPP access networks. 91 It has been identified that base Proxy Mobile IPv6 (PMIPv6) [RFC5213] 92 parameters and existing IETF standardized mobility options are not 93 enough in the EPC scope. Generally in PMIPv6 and especially in the 94 EPC, different APNs are identified using the Service Selection 95 mobility option [RFC5149]. However, in a case of multiple PDN 96 connections to the same APN, and assuming that Home Network Prefixes 97 (HNP) are not always available in a Mobile Access Gateway (MAG) after 98 a handover and that the "APN name" in the Service Selection mobility 99 option cannot be decorated (i.e. making each APN unique), there is a 100 need for a new identifier to uniquely identify PDN connections to the 101 same APN. Note that an optional GRE key option defined in 102 [I-D.ietf-netlmm-grekey-option] as such does not help to 103 differentiate the mobility sessions. The reason for this is that 104 only the downlink GRE key is included in the Proxy Binding Update 105 (PBU) messages, and the downlink GRE key option is local to MAG. 106 Therefore, the preservation of the same downlink GRE key values 107 during inter-MAG handovers cannot be guaranteed. 109 This document describes a new Connection Identifier (CID) mobility 110 option for PMIPv6. The Connection Identifier mobility option enables 111 that a MN can have several mobility sessions via a single interface 112 with the same LMA by carrying an unique connection identifier. This 113 allows the MAG and the LMA to uniquely identify mobility sessions of 114 a MN. The combination of MN-Identifier + Service Selection + 115 Connection Identifier can uniquely identify mobility sessions even if 116 the selected service on each mobility session for the same MN- 117 Identifier are the same. Furthermore, if Service Selection [RFC5149] 118 is not used or supported, the Connection Identifier functionality can 119 still be used to manage multiple HNPs individually on a single 120 interface. Effectively that means a combination of MN-Identifier + 121 Connection Identifier can uniquely identify mobility sessions of a 122 MN. This allows a MN to configure additional HNPs to an interface 123 that is already assigned with a HNP. 125 How the Connection Identifier is created and learnt by the MAG, is 126 out of the scope of this document. The identifier is required to be 127 available in a MAG already when a PBU is to be sent and guaranteed to 128 preserve its value when a MN handoffs from a MAG to another. The MAG 129 may learn this identifier for example from "lower layers" or external 130 control signaling during the PDN connection setup. The identifier 131 could even be an uplink GRE key if that is readily available in a MAG 132 when a PBU gets sent. After a successful creation of a mobility 133 session, and an allocation of the Connection Identifier, both the MAG 134 and LMA MUST include the Connection Identifier in all subsequent 135 PMIPv6 signaling messages related to that mobility session. 137 2. Requirements 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in [RFC2119]. 143 3. Proxy Mobile IPv6 Domain Assumptions 145 The functionality described in this specification is supported only 146 when multiple mobility sessions to the same selected service are 147 anchored to a single LMA. Also the multiple mobility sessions to the 148 same selected service that the MN is using go via the same MAG. 150 4. Connection Identifier Mobility Option 152 At most one Connection Identifier mobility option MAY be included in 153 any PBU message sent by the MAG. The LMA MUST echo the received 154 Connection Identifier back in a Proxy Binding Acknowledgement (PBA) 155 message, assuming the LMA understands the Connection Identifier 156 mobility option in the first place. The echoed Connection Identifier 157 mobility option MUST be an unchanged copy of the Connection 158 Identifier mobility option received in the corresponding PBU message. 160 The Connection Identifier mobility option has the alignment 161 requirement of 4n+2 and the following format: 163 0 1 2 3 164 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 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | Option Type | Option Length | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Connection Identifier | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 Connection Identifier Mobility Option 173 Option Type 175 8-bit identifier set to TBD1. 177 Option Length 179 8-bit unsigned integer, representing the length in octets of the 180 mobility option, not including the Option Type and Option Length 181 fields. 183 Connection Identifier 185 A 32-bit identifier value. The value is in network order. 187 5. Extensions to Conceptual Data Structures and Lookups 189 5.1. Binding Cache 191 Each Binding Cache Entry (BCE) MUST be extended with a Connection 192 Identifier parameter. This concerns only LMAs that implement the 193 Connection Identifier mobility option and the associated 194 functionality. 196 5.2. Binding Update List 198 Each Binding Update List Entry (BULE) MUST be extended with a 199 Connection Identifier parameter. This concerns only MAGs that 200 implement the Connection Identifier mobility option and the 201 associated functionality. 203 5.3. Lookup Keys 205 Both BCE and BULE MAY be queried using the Connection Identifier 206 mobility option value as one additional lookup key. The lookup key 207 combination: 209 MN-Identifier + Service Selection + Connection Identifier 211 MUST uniquely identify a single BCE or a BULE. 213 In a case Service Selection [RFC5149] is not used at all or supported 214 by a MAG-LMA pair, then the lookup key combination: 216 MN-Identifier + Connection Identifier 218 MUST uniquely identify a single BCE or a BULE. 220 6. Processing Considerations 222 6.1. Capability Exchange 224 The Connection Identifier mobility option in the PBU is also an 225 indication to a LMA that the MAG supports multiple mobility sessions 226 to the same selected service (identified by the Service Selection 227 mobility option). Similarly, the Connection Identifier mobility 228 option in the PBA is an indication to the MAG that the LMA supports 229 the multiple mobility sessions to the same selected service. Using 230 this simple mechanism the MAG and the LMA can dynamically find out 231 whether both support the multiple mobility sessions to the same 232 selected service functionality. 234 6.2. Mobile Access Gateway Considerations 236 If the multiple mobility session to the same selected service 237 functionality is enabled and mutually supported by the MAG and the 238 LMA, then the MAG MUST include the Connection Identifier mobility 239 option in all PBUs. How the MAG maps connections originated from the 240 MN to connection identifiers is out of scope of this specification. 241 The mapping of mobility sessions and connection identifiers MUST 242 remain the lifetime of the mobility session. 244 How the MAG knows/learns the connection identifiers after a handover 245 between MAGs is out of scope of this specification. However, 246 mechanisms such as context transfer between MAGs may be used. 248 6.3. Local Mobility Anchor Considerations 250 If the multiple mobility session to the same selected service 251 functionality is enabled and mutually supported by the MAG and the 252 LMA, then the LMA MUST echo the Connection Identifier mobility option 253 in all PBAs that it received in the corresponding PBUs. 255 In a case the LMA does not support the Connection Identifier mobility 256 option, the LMA MUST silently ignore the option and process the 257 remaining of the PBU as defined in [RFC5213] and [RFC5149]. It is 258 implementation specific which BCE for a given MN-Identifier is 259 returned when e.g. the BC lookup using the MN-Identifier and the 260 Service Selection option as the lookup key match multiple BCEs. 262 7. Security Considerations 264 The protection for the Connection Identifier mobility option depends 265 on the services that are being connected to. If the Connection 266 Identifier information should not be revealed on the wire, Proxy 267 Binding Updates and Proxy Binding Acknowledgements should use 268 Encapsulating Security Payload (ESP) [RFC4303] in transport mode with 269 a non-null encryption transform to provide message confidentiality. 271 8. IANA Considerations 273 A new mobility option for the use with PMIPv6 is defined in the 274 [RFC3775] "Mobility Options" registry. The mobility options are 275 defined in Section 4: 277 Connection Identifier mobility option is set to TBD1 279 9. Acknowledgements 281 The authors thank Basavaraj Patil and Xiangsong Cui for their 282 comments and discussion on this document. 284 10. References 286 10.1. Normative References 288 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 289 Requirement Levels", BCP 14, RFC 2119, March 1997. 291 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 292 in IPv6", RFC 3775, June 2004. 294 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 295 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 297 10.2. Informative References 299 [3GPP.23.401] 300 3GPP, "General Packet Radio Service (GPRS) enhancements 301 for Evolved Universal Terrestrial Radio Access Network 302 (E-UTRAN) access", 3GPP TS 23.401 8.6.0, June 2009. 304 [3GPP.23.402] 305 3GPP, "Architecture enhancements for non-3GPP accesses", 306 3GPP TS 23.402 8.6.0, June 2009. 308 [I-D.ietf-netlmm-grekey-option] 309 Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung, 310 "GRE Key Option for Proxy Mobile IPv6", 311 draft-ietf-netlmm-grekey-option-09 (work in progress), 312 May 2009. 314 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 315 RFC 4303, December 2005. 317 [RFC5149] Korhonen, J., Nilsson, U., and V. Devarapalli, "Service 318 Selection for Mobile IPv6", RFC 5149, February 2008. 320 Authors' Addresses 322 Gyorgy Wolfner 323 Nokia Siemens Networks 325 Email: gyorgy.wolfner@nsn.com 327 Jouni Korhonen (editor) 328 Nokia Siemens Networks 329 Linnoitustie 6 330 FIN-02600 Espoo 331 FINLAND 333 Email: jouni.nospam@gmail.com