idnits 2.17.1 draft-melia-netext-3gpp-mn-ar-if-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.gundavelli-netext-extensions-motivation]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 5, 2009) is 5381 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-11) exists of draft-ietf-mext-flow-binding-02 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Melia 3 Internet-Draft Alcatel-Lucent Bell Labs 4 Intended status: Informational C. Bernardos 5 Expires: January 6, 2010 Universidad Carlos III de Madrid 6 JC. Zuniga 7 InterDigital Communications, LLC 8 July 5, 2009 10 3GPP MN-AR interface 11 draft-melia-netext-3gpp-mn-ar-if-00 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 6, 2010. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 This ID documents the interface between the Mobile Node and the 50 Mobility Access Gateway in the context of 3GPP Evolved Packet Core 51 networks. The main goal is to support the Netext working group in 52 the discussions on the MN to AR interface showing how RFC 5213 has 53 been deployed by other SDOs. This document has been inspired by 54 considerations expressed in 55 [I-D.gundavelli-netext-extensions-motivation]. 57 Requirements Language 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 60 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 61 document are to be interpreted as described in RFC 2119 [RFC2119]. 63 Table of Contents 65 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Differences between 3GPP and IETF specifications . . . . . . . 5 68 4. Reference point S5 . . . . . . . . . . . . . . . . . . . . . . 5 69 4.1. Network attachment . . . . . . . . . . . . . . . . . . . . 5 70 4.2. Network Detachment . . . . . . . . . . . . . . . . . . . . 6 71 5. Reference point S2a . . . . . . . . . . . . . . . . . . . . . 7 72 5.1. Network Attachment . . . . . . . . . . . . . . . . . . . . 7 73 5.2. Network detachment . . . . . . . . . . . . . . . . . . . . 8 74 6. Reference point S2b . . . . . . . . . . . . . . . . . . . . . 9 75 6.1. Network Attachment . . . . . . . . . . . . . . . . . . . . 9 76 6.2. Network Detachment . . . . . . . . . . . . . . . . . . . . 10 77 7. Common aspects in Handover Management procedures . . . . . . . 10 78 8. Multiple Interfaces support . . . . . . . . . . . . . . . . . 11 79 9. General Considerations . . . . . . . . . . . . . . . . . . . . 11 80 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 81 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 82 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 83 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 13.1. Normative References . . . . . . . . . . . . . . . . . . . 12 85 13.2. Informative References . . . . . . . . . . . . . . . . . . 12 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 88 1. Terminology 90 This document uses the following terminology: 92 PDN Packet Data Network 94 EPS Evolved Packet System 96 EPC Evolved Packet Core 98 S-GW Serving Gateway 100 P-GW PDN Gateway 102 UE User Equipment 104 GTP GPRS Tunneling Protocol 106 APN Access Point Name 108 2. Introduction 110 The 3GPP standardization body specified the Evolved Packet System 111 (EPS) architecture (release 8). EPS relies on a fully IP-based core 112 network, the Evolved Packet Core (EPC), and provides heterogeneous 113 wireless access to multi mode mobile devices. EPC supports different 114 type of wireless access networks, namely the evolved UTRAN (i.e. 115 LTE), a trusted non-3GPP access (i.e. WIMAX) and a non-trusted and 116 non-3GPP access (i.e. WIFI). 118 _.----------. 119 ,-'' `--. 120 / +-------+ 121 ( EUTRAN | S-GW |\\ 122 \ ACCESS +-------+ \\ 123 `--. _.-' \\ S5 interface 124 `----------'' \\ 125 \\ 126 _.----------. \\ 127 ,-'' `--. \\ 128 / +-------+ S2a interface \\+-------+ 129 ( WIMAX | S-GW |======================| P-GW | 130 \ ACCESS +-------+ //+-------+ 131 `--. _.-'ASN-GW // 132 `----------'' // 133 // 134 _.----------. // 135 ,-'' `--. // 136 / +-------+ // S2b interface 137 ( WIFI | S-GW |// 138 \ ACCESS +-------+ 139 `--. _.-'ePDG 140 `----------'' 142 Figure 1: 3GPP Evolved Packet Core 144 Figure 1 shows a simplified overview of the EPS architecture (please 145 note that only the key components relevant for the understanding of 146 this document are highlighted). The Serving GW (S-GW) is the first 147 layer three hop in the network and is the default router for the 148 mobile node (i.e. Recipient of Router Solicitation and sender of 149 Router Advertisement messages). It provides layer three 150 configuration parameters. In case of non- 3GPP trusted access the 151 S-GW is implemented by the ASN-GW standardized by the Wimax Forum. 152 In case of non-3GPP, non-trusted access (e.g. WIFI) the S-GW is 153 implemented by the evolved Packet Data Gateway (ePDG). The P-GW is 154 the anchor point for all the uplink and downlink traffic to/from the 155 mobile node. The Home Address assigned to the mobile node is 156 anchored at the P-GW who is in charge of tunneling management towards 157 the S-GW. The reference point between S-GW and P-GW in the context 158 of LTE access is S5/S8, between the P-GW and the ASN-GW in the 159 context of WiMAX access is S2a and between the ePDG and the P-GW in 160 the context of WIFI interworking is S2b. S5, S2a and S2b interfaces 161 support mobility management of mobile devices and they can be 162 implemented, among others, via the Proxy Mobile IPv6 163 protocol[RFC5213]. In this case the P-GW integrates the LMA 164 functionality and the S-GW the MAG functionality. In the remainder 165 of this document we assume PMIPv6 is the selected mobility management 166 protocol. 168 3. Differences between 3GPP and IETF specifications 170 The EPC architecture is specified in [3GPP.23.401]. Non-3GPP access 171 is detailed in [3GPP.23.402] The PMIPv6 protocol is specified in 172 [3GPP.29.275] (stage 3) and additional parameters in [3GPP.29.282] 173 and [3GPP.24.008]. The main difference between the PMIPv6 protocol 174 specified in [RFC5213] and the PMIPv6 protocol specified by 3GPP is 175 the introduction of the Access Point Name. The APN is introduced as 176 parameter in the PBU signaling and is used by the P-GW to allocate 177 the right Home Address (PDN selection). 179 To support Multiple PDNs the MAG and LMA perform lookups on the 180 extended data structure compared to the standard PMIPv6 as defined in 181 [RFC5213]. In standard PMIPv6 as defined in [RFC5213], a PMIPv6 BCE 182 is looked up based on the Mobile Node Identifier (MN_ID), the access 183 technology types (ATT) and if it exist the MN's link-layer identifier 184 (MN_LL_ID). In EPC the MN_LL_ID is not used and the EPC supports 185 handover between non-3GPP and 3GPP accesses. Since a distinct PMIPv6 186 BCE exists for each of the PDN connections of an UE, and since 187 multiple PDN connections of a UE can be distinguished based on an 188 APN, there is a one-to-one mapping between a PMIPv6 BCE, a PDN 189 connection, and the (MN_ID, APN) tuple. Thus, an UE PDN connection 190 can be uniquely identified by a (MN_ID, APN) tuple and the BC/BUL are 191 accordingly looked up on a per (MN_ID, APN) tuple basis. 193 It should be noted that the APN parameter is conveyed by the MN to 194 the access network during the access authentication procedure. 196 4. Reference point S5 198 Reference point S5 can be implemented via the GTP protocol or via 199 PMIP protocol. As stated before we focus here on the use of PMIPv6. 200 We summarize in the following attachment procedures and detachment 201 procedures focusing on the parameters required by the MAG to 202 correctly form a PBU. 204 4.1. Network attachment 206 When the MN initiates an attachment procedure it sends to the access 207 network among others the following parameters: PDN type, Protocol 208 Configuration Options (PCO), Attach type. PDN type indicates the 209 requested IP version (IPv4, IPv6, IPv4/IPv6). PCO is used to 210 transfer additional parameters between the MN and the LMA (P-GW). 211 Parameters are sent transparently through the MAG (S-GW). Attach 212 type indicates "Handover" when the MN has already a mobility session 213 registered at the LMA due to mobility from non-3GPP access. To 214 handle situation where the MN might have multiple PDN connections 215 with the LMA the MN should also send the APN. 217 For default bearer creation the MAG (S-GW) sends a Proxy Binding 218 Update to the LMA (P-GW) including the following parameters: MN NAI, 219 Lifetime, Access Technology Type, Handover Indicator, APN, GRE key 220 for downlink traffic, MN Address Info Additional Parameters. The MN 221 NAI identifies the user equipment for whom the message is being sent. 222 The Lifetime field must be set to a nonzero value in the case of a 223 registration. Access Technology Type is set to indicate the Radio 224 Access Technology type (E-UTRAN). Handover Indication option is set 225 to indicate attachment over a new interface as no Handover indication 226 is indicated in the Attach type. The APN may be necessary to 227 differentiate the intended PDN from the other PDNs supported by the 228 same PDN GW. The optional Additional Parameters may contain 229 information, for example, Protocol Configuration Options. The UE 230 Address Info IE is used to request an IPv6 prefix, IPv4 address, or 231 both IPv4 address and IPv6 prefix. Based on PDN Type parameter 232 received the MAG (S-GW) includes request for IPv4 Home Address (PDN 233 Type set to IPv4), or IPv6 Home Network Prefix (PDN type set to IPv6) 234 or both IPv4 home address and IPv6 HNP (PDN type set to IPv4v6) in 235 the PBU as specified in PMIPv6 specification. 237 The PDN GW responds with a PMIPv6 Binding Acknowledgment message to 238 the S-GW including the following parameters: MN NAI, Lifetime, UE 239 Address Info, GRE key for uplink traffic, Additional Parameters. The 240 MN NAI is identical to the MN NAI sent in the Proxy Binding Update. 241 The Lifetime indicates the duration the binding will remain valid. 242 The PDN GW takes into account the request from S-GW and the 243 operator's policies when allocating the UE Address Info. It should 244 be noted that the S-GW learns from the PBA if the P-GW supports 245 multiple PDN connections to the same APN or not. 247 It should be noted that critical parameters to fill in mandatory 248 parameters in PBU/PBA messages are conveyed during network access. 250 4.2. Network Detachment 252 In case of network detachment all the bearers at the S-GW are 253 terminated. The S-GW sends a Proxy Binding Update message to the 254 P-GW including the following parameters: MN NAI, APN, and lifetime 255 set to value 0. The MN NAI and APN identify the PDN connection of 256 the UE. The lifetime field indicates that the message is used to 257 release the PDN connection of the UE at the PDN-GW. 259 The PDN GW responds to the S-GW with the result of the PDN connection 260 release with Proxy Binding Update Acknowledgment 262 5. Reference point S2a 264 Reference point S2a may implement PMIPv6 to grant network access for 265 non-3GPP networks. 267 5.1. Network Attachment 269 Upon layer two access procedures (which are not in scope of 3GPP) the 270 MN performs EAP authentication with the AAA infrastructure. Among 271 other parameters, the 3GPP AAA server return to the S-GW the MN NAI 272 to be used to identify the UE in the PBU message. If this is 273 supported by the non-3GPP access network the Attach Type is indicated 274 to the S-GW by the UE. The support for attach type indication is 275 access technology specific and not in scope of 3GPP specifications. 276 An Attach Type set to value "handover" indicates that the UE has 277 already an active mobility session at the P-GW due to mobility from 278 3GPP to non-3GPP access. 280 After successful authentication and authorization, the non-3GPP 281 access specific L3 attach procedure is triggered. The UE may send 282 requested APN to the Non-3GPP IP access in this step (note that 283 Attach Type and APN can be sent as part of L3 signaling as suggested 284 in [I-D.patil-dhc-apn-attachtype-options]). If the UE sends a 285 requested APN in this step, the Trusted non-3GPP Access verifies that 286 it is allowed by subscription. If the UE does not send a requested 287 APN the Trusted non-3GPP Access uses the default APN. The PDN 288 Gateway selection takes place. If the PDN subscription profile 289 returned by the 3GPP AAA Server contains a PDN GW identity for the 290 selected APN and the Attach Type does not indicate "Handover", the 291 Non-3GPP access GW may request a new PDN GW to allocate a PDN GW that 292 allows for more efficient routing. The UE may request the type of 293 address (IPv4 address or IPv6 prefix or both) during this step. If 294 supported by the non-3GPP access, the UE may send Protocol 295 Configuration Options in this step using access specific mechanisms 296 (note that other IP based mechanisms have been proposed 297 [I-D.melia-dhc-pco]). The Protocol Configuration Options provided by 298 the UE may include the user credentials for PDN access authorization. 299 In that case, in order to handle situations where the UE may have 300 subscriptions to multiple PDNs, the UE should also send a requested 301 APN to the non-3GPP IP access. 303 The MAG function of Trusted Non-3GPP IP Access sends a Proxy Binding 304 Update to the P-GW including the following parameters: MN-NAI, 305 Lifetime, Access Technology Type, Handover Indicator, APN, GRE key 306 for downlink traffic, Additional Parameters. The MN NAI identifies 307 the UE. The Lifetime field must be set to a nonzero value. Access 308 Technology Type is set to a value matching the characteristics of the 309 non-3GPP access. Handover Indicator is set to "initial" attach as 310 the UE has provided Attach Type indicating "Initial" attach or as the 311 Attach Type indicates "Handover" and the PDN subscription profile 312 contains no PDN GW. The Additional Parameters include the Protocol 313 Configuration Options provided by the UE and may also include other 314 information. The MAG requests the IP address types (IPv4 address 315 and/or IPv6 Home Network Prefix) based on requested IP address types 316 and subscription profile in the same way as the PDN type is selected 317 during the E UTRAN Initial Attach in [3GPP.23.401]. If the PDN 318 requires an additional authentication and authorization with an 319 external AAA Server, the P-GW performs such an additional 320 authentication and authorization at the reception of the Proxy 321 Binding Update. 323 The P-GW processes the proxy binding update and creates a binding 324 cache entry for the UE. The P-GW allocates IP address(es) for the 325 UE. The P-GW then sends a Proxy Binding Acknowledgment message to 326 the MAG including the following parameters: MN NAI, Lifetime, UE 327 Address Info, GRE key for uplink traffic, Additional Parameters and 328 the IP address(es) allocated for the UE. The UE Address Info 329 includes one or more IP addresses. The Lifetime indicates the 330 duration of the binding. The Additional Parameters may include 331 Protocol Configuration Options and other information.If UE requests 332 for both IPv4 and IPv6 addresses, both are allocated. If the P-GW 333 operator dictates the use of IPv4 addressing only or IPv6 addressing 334 only for this APN, the P-GW shall allocate only IPv4 address or only 335 IPv6 prefix to the UE. If the UE requests for only IPv4 or IPv6 336 address only one address is allocated accordingly. 338 5.2. Network detachment 340 If the UE in the trusted non-3GPP access triggers either detach or 341 disconnection of a PDN connection by means of access specific 342 procedures the MAG (S-GW) sends a Proxy Binding Update message to the 343 P-GW with the following parameters: MN NAI, APN, lifetime value set 344 to 0. The MN NAI identifies the UE to deregister from the PDN GW. 345 When only one PDN connection to the given APN is allowed the APN is 346 needed in order to determine which PDN to deregister the UE from, as 347 some PDN GWs may support multiple PDNs. When multiple PDN 348 connections to the given APN are supported the APN and the PDN 349 connection identity are needed in order to determine which PDN to 350 deregister the UE from. 352 The P-GW deletes existing entries implied in the Proxy Binding Update 353 message from its Binding Cache and sends a Proxy Binding 354 Acknowledgment message to the MAG. 356 6. Reference point S2b 358 Reference point S2b is used to grant network access to MN in the 359 context of non-trusted non-3GPP networks (e.g. WLAN access). As 360 shown in Figure 1 it is assumed that the MAG functionality is co- 361 located with the ePDG. Between the MN and the ePDG an IPsec tunnel 362 is used to convey the required parameters for PMIPv6 operation 363 between the MAG and the LMA (P-GW). 365 6.1. Network Attachment 367 Prior to IKEv2 tunnel establishment the MN configures an IP address 368 from the local non-trusted non-3GPP access network. The ePDG IP 369 address to which the UE needs to form IPsec tunnel is discovered via 370 DNS. The UE may request connectivity to a specific PDN providing an 371 APN, that is conveyed with IKEv2. For networks supporting multiple 372 mobility protocols, if there was any dynamic IP mobility selection 373 decision involved in this step, the decision is stored in the 3GPP 374 AAA Server. The P-GW information is returned as part of the reply 375 from the 3GPP AAA Server to the ePDG. If the UE has provided an APN 376 the ePDG verifies that it is allowed by subscription. If the UE has 377 not provided an APN the ePDG uses the default APN. The P-GW 378 selection takes place at this point. The UE indicates the type of 379 address(es) (IPv4 address or IPv6 prefix /address or both) in the 380 CFG_Request sent to the ePDG during IKEv2 message exchange. 382 The ePDG sends the Proxy Binding Update message to the P-GW including 383 the following parameters: MN-NAI, Lifetime, APN, Access Technology 384 Type, Handover Indicator, GRE key for downlink traffic, UE Address 385 Info, Charging Characteristics , Additional Parameter. Access 386 Technology Type option is set to a value matching the characteristics 387 of the non-3GPP IP access. Handover Indicator is set to indicate 388 attachment over a new interface. The MN NAI identifies the UE. The 389 Lifetime field must be set to a nonzero value in the case of a 390 registration and a zero value in the case of a de-registration. The 391 APN is used by the P-GW to determine which PDN to establish 392 connectivity for, in the case that the P-GW supports multiple PDN 393 connectivity. The ePDG creates and includes a PDN connection 394 identity if the ePDG supports multiple PDN connections to a single 395 APN. 397 The P-GW processes the Proxy Binding Update and creates a binding 398 cache entry for the UE. The P-GW allocates an IP address for the UE. 399 The P-GW then sends a Proxy Binding Ack message to the S-GW including 400 the following parameters: MN NAI, UE Address Info, GRE Key for uplink 401 traffic, Charging ID and the IP address(es) allocated for the UE 402 (identified by the MN NAI). If the corresponding Proxy Binding 403 Update contains the PDN connection identity, the P-GW shall 404 acknowledge if multiple PDN connections to the given APN are 405 supported. 407 6.2. Network Detachment 409 The release of the IKEv2 tunnel triggers PMIPv6 disconnection. 411 The MAG in the ePDG sends a Proxy Binding Update (MN NAI, APN, 412 lifetime=0) message to the PDN GW. The MN NAI identifies the UE. 413 When only one PDN connection to the given APN is allowed the APN is 414 needed in order to determine which PDN to deregister the UE from, as 415 some PDN GWs may support multiple PDNs. When multiple PDN 416 connections to the given APN are supported, the APN and the PDN 417 connection identity are needed in order to determine which PDN to 418 deregister the UE from. The lifetime value set to zero, indicates 419 this is a PMIP de-registration. 421 The P-GW deletes all existing entries for the indicated HoA from its 422 Binding Cache and sends a Proxy Binding Ack (MN NAI, lifetime=0) 423 message to the MAG in the ePDG. The P-GW sends a Proxy Binding Ack 424 message to the ePDG. The MN NAI value and the lifetime=0 values 425 indicate that the UE has been successfully deregistered. 427 7. Common aspects in Handover Management procedures 429 Generally when the UE, upon handover trigger, attaches to the target 430 access network it sends the Attach Type field set to value 431 "Handover". This is an explicit indication from the UE willing to 432 perform handover. 434 In case the MN performs handover from non-3GPP trusted access to 435 EUTRAN access the MAG sets the Handover Indicator in the PBU 436 according to the Attach Type field received during the attach 437 procedure. 439 In case the MN performs handover from 3GPP access to non-3GPP trusted 440 access the MN needs to provide at the latest during layer three 441 attachment the required parameters (e.g. handover indication, APN). 442 How the MN delivers such parameters to the access network is however 443 not in scope of 3GPP specifications. 445 In case the MN performs handover from 3GPP to non-3GPP non-trusted 446 access network the MN should provide during the IKEv2 tunnel 447 establishment an indication of address preservation during handover. 448 The ePDG upon reception of the IKEv2 signaling will form a PBU 449 setting the Handover Indicator field accordingly to the address 450 preservation indication. The APN is used to determine which PDN 451 connectivity is updated. 453 8. Multiple Interfaces support 455 [3GPP.23.861] explores the possibility to use simultaneous PDN 456 connections across different access networks. [3GPP.23.861] further 457 specifies that a MN is able to connect at the same time two and only 458 two wireless devices. That is, possible scenarios are a MN being 459 connected to the LTE network and further enjoying services provided 460 either through the non-3GPP trusted network or trough the non-3GPP 461 non-trusted network. In this context multiple interface support can 462 be provided by means of routing filters based solutions or by means 463 of the PCC framework. 465 Routing filters based solutions are described for both Dual Stack 466 Mobile IPv6 (note that EPC also supports DSMIPv6 on reference point 467 S2c) and Proxy Mobile IPv6. While for the S2c interface 468 [I-D.ietf-monami6-multiplecoa] and [I-D.ietf-mext-flow-binding] 469 completely design the solution, it is left for further study if 470 PMIPv6 should be enhanced to convey routing filters between the MAG 471 and the LMA as part of the PBU/PBA exchange or if PCO could be used 472 instead. 474 If the PCC framework is used for network based mobility management 475 (e.g. PMIPv6) filters are installed as part of the interactions 476 between P-GW and PCC framework during network attachment/handover. 477 In general the MN still has to provide indication to the access 478 network that it intends to add an additional PDN connection to the 479 already existing mobility session at the P-GW. This is achieved 480 transferring a "MAPIM" indicator as part of the attach procedure in 481 the PCO field. Note that PCO is transferred at layer two during 482 EUTRAN access, and it is not described how it is transferred in the 483 case of non-3GPP access (trusted or not-trusted). 485 9. General Considerations 487 We can safely summarize that during EUTRAN network attachment the 488 paramters required for PMIPv6 operation (i.e. MN_ID, APN, Attach 489 type) are transferred as part of the layer two signaling. In case of 490 handover from a non-3GPP system to a 3GPP system the Attach Type 491 indicates "handover". Attach type is specified by the UE and used by 492 the MAG to fill the Handover Indicator option. In case the UE 493 intends to enable multiple interface support and the P-GW has an 494 already existing session the UE may include a MAPIM indicator to 495 update the existing mobility session. 497 During attachment to a non-3GPP trusted system the network attachment 498 procedures are not in scope of 3GPP. However, such procedures can be 499 part of layer three signaling (i.e. IP signaling). In case of 500 mobility to a non-3GPP trusted system the Attach Type (used to fill 501 in the Handover Indicator option) indicates handover (set by the UE). 502 Multiple interface usage may be achieved by means of the MAPIM 503 indicator transferred as part of PCO. 505 During attachment to a non-trusted non-3GPP system the required 506 parameters for PMIPv6 operation are transferred to the ePDG as part 507 of the IKEv2 signaling. 509 10. IANA Considerations 511 This document makes no request of IANA. 513 11. Security Considerations 515 This document summarizes deployment choices for PMIPv6 specified in 516 other SDOs. There are no security issues to be dealt with. 518 12. Acknowledgements 520 13. References 522 13.1. Normative References 524 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 525 Requirement Levels", BCP 14, RFC 2119, March 1997. 527 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 528 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 530 13.2. Informative References 532 [3GPP.23.401] 533 3GPP, "General Packet Radio Service (GPRS) enhancements 534 for Evolved Universal Terrestrial Radio Access Network 535 (E-UTRAN) access", 3GPP TS 23.401 8.6.0, June 2009. 537 [3GPP.23.402] 538 3GPP, "Architecture enhancements for non-3GPP accesses", 539 3GPP TS 23.402 8.6.0, June 2009. 541 [3GPP.23.861] 542 3GPP, "Multi Access PDN connectivity and IP flow 543 mobility", 3GPP TR 23.861 1.1.1, May 2009. 545 [3GPP.24.008] 546 3GPP, "Mobile radio interface Layer 3 specification; Core 547 network protocols; Stage 3", 3GPP TS 24.008 3.20.0, 548 December 2005. 550 [3GPP.29.275] 551 3GPP, "Proxy Mobile IPv6 (PMIPv6) based Mobility and 552 Tunneling protocols; Stage 3", 3GPP TS 29.275 8.2.1, 553 April 2009. 555 [3GPP.29.282] 556 3GPP, "Mobile IPv6 vendor specific option format and usage 557 within 3GPP", 3GPP TS 29.282 8.1.0, June 2009. 559 [I-D.gundavelli-netext-extensions-motivation] 560 Gundavelli, S., "Extensions to Proxy Mobile IPv6 - 561 Motivation", 562 draft-gundavelli-netext-extensions-motivation-00 (work in 563 progress), May 2009. 565 [I-D.ietf-mext-flow-binding] 566 Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G., 567 and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and Nemo 568 Basic Support", draft-ietf-mext-flow-binding-02 (work in 569 progress), April 2009. 571 [I-D.ietf-monami6-multiplecoa] 572 Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., 573 and K. Nagami, "Multiple Care-of Addresses Registration", 574 draft-ietf-monami6-multiplecoa-14 (work in progress), 575 May 2009. 577 [I-D.melia-dhc-pco] 578 Melia, T. and Y. Mghazli, "DHCP option to transport 579 Protocol Configuration Options", draft-melia-dhc-pco-00 580 (work in progress), February 2009. 582 [I-D.patil-dhc-apn-attachtype-options] 583 Patil, B., Chowdhury, K., and D. Premec, "DHCP options for 584 Access Point Name and attach type indication", 585 draft-patil-dhc-apn-attachtype-options-01 (work in 586 progress), March 2009. 588 Authors' Addresses 590 Telemaco Melia 591 Alcatel-Lucent Bell Labs 593 Email: telemaco.melia@alcatel-lucent.com 595 Carlos J. Bernardos 596 Universidad Carlos III de Madrid 597 Av. Universidad, 30 598 Leganes, Madrid 28911 599 Spain 601 Phone: +34 91624 6236 602 Fax: 603 Email: cjbc@it.uc3m.es 604 URI: http://www.it.uc3m.es/cjbc/ 606 Juan Carlos Zuniga 607 InterDigital Communications, LLC 609 Email: JuanCarlos.Zuniga@InterDigital.com