idnits 2.17.1 draft-ietf-netext-logical-interface-support-11.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 date (March 6, 2015) is 3333 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-18) exists of draft-ietf-netext-pmipv6-flowmob-13 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETEXT WG T. Melia, Ed. 3 Internet-Draft Alcatel-Lucent 4 Intended status: Informational S. Gundavelli, Ed. 5 Expires: September 7, 2015 Cisco 6 March 6, 2015 8 Logical-interface Support for Multi-access enabled IP Hosts 9 draft-ietf-netext-logical-interface-support-11 11 Abstract 13 A Logical-interface is a software semantic internal to the host 14 operating system. This semantic is available in all popular 15 operating systems and is used in various protocol implementations. 16 The Logical-interface support is required on the mobile node attached 17 to a Proxy Mobile IPv6 domain, for leveraging various network-based 18 mobility management features such as inter-technology handoffs, 19 multihoming and flow mobility support. This document explains the 20 operational details of Logical-interface construct and the specifics 21 on how the link-layer implementations hide the physical interfaces 22 from the IP stack and from the network nodes on the attached access 23 networks. Furthermore, this document identifies the applicability of 24 this approach to various link-layer technologies and analyzes the 25 issues around it when used in conjunction with various mobility 26 management features. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 7, 2015. 45 Copyright Notice 47 Copyright (c) 2015 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Hiding Link-layer Technologies - Approaches and 67 Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3.1. Link-layer Abstraction - Approaches . . . . . . . . . . . 5 69 3.2. Link layer support . . . . . . . . . . . . . . . . . . . . 6 70 3.3. Logical Interface . . . . . . . . . . . . . . . . . . . . 6 72 4. Technology Use cases . . . . . . . . . . . . . . . . . . . . . 7 74 5. Logical Interface Functional Details . . . . . . . . . . . . . 8 75 5.1. Configuration of a Logical Interface . . . . . . . . . . . 9 76 5.2. Logical-Interface Forwarding Table . . . . . . . . . . . . 9 78 6. Logical Interface Use-cases in Proxy Mobile IPv6 . . . . . . . 11 79 6.1. Multihoming Support . . . . . . . . . . . . . . . . . . . 11 80 6.2. Inter-Technology Handoff Support . . . . . . . . . . . . . 12 81 6.3. Flow Mobility Support . . . . . . . . . . . . . . . . . . 13 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 85 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 87 9. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 89 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 91 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 92 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 93 11.2. Informative References . . . . . . . . . . . . . . . . . . 17 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 97 1. Introduction 99 Proxy Mobile IPv6 (PMIPv6) [RFC5213] is a network-based mobility 100 management protocol standardized by IETF. One of the key goals of 101 the PMIPv6 protocol is to enable a mobile node to perform handovers 102 across access-networks based on different access technologies. The 103 protocol was also designed with the goal to allow a mobile node to 104 simultaneosly attach to different access networks and perform flow- 105 based access selection [I-D.ietf-netext-pmipv6-flowmob]. The base 106 protocol features specified in [RFC5213] and [RFC5844] has support 107 for these capabilities. However, for supporting these features, the 108 mobile node is required to be enabled with with specific software 109 configuration known as logical-interface support. The logical- 110 interface configuration is essential for a mobile node to perform 111 inter-access handovers without impacting the IP sessions on the host. 113 A Logical Interface construct is internal to the operating system. 114 It is an approach of interface abstraction, where a logical link- 115 layer implementation hides a variety of physical interfaces from the 116 IP stack. This semantic was used on a variety of operating systems 117 to implement applications such as Mobile IP client [RFC6275] and 118 IPsec VPN client [RFC4301]. Many host operating systems have support 119 for some form of such logical interface construct. But, there is no 120 specification which documents the behavior of these logical- 121 interface, or the requirements of a logical interface for supporting 122 the above mentioned mobility management features. This specification 123 attempts to document these aspects. 125 The rest of the document provides a functional description of a 126 Logical Interface on the mobile node and the interworking between a 127 mobile node using a logical interface and the network elements in the 128 Proxy Mobile IPv6 domain. It also analyzes the issues involved with 129 the use of logical-interface and characterizes the contexts in which 130 such usage is appropriate. 132 2. Terminology 134 All the mobility related terms used in this document are to be 135 interpreted as defined in Proxy Mobile IPv6 specifications, [RFC5213] 136 and [RFC5844]. In addition, this document uses the following terms: 138 PIF (Physical Interface) - It is a network interface module on the 139 host that is used for connecting to an access network. An host 140 typically has number of network interface modules, such as 141 Ethernet, Wireless LAN, LTE ..etc. Each of these network 142 interfaces can support specific link technology. 144 LIF (Logical Interface) - It is a virtual interface in the IP stack. 145 Logical interface appears to the IP stack just as any other 146 physical interface, provides similar semantics with respect to 147 packet transmit and receive functions to the upper layers of the 148 IP stack. However, it is only a logical construct and is not a 149 representation of an instance of any physical hardware. 151 SIF (Sub Interface) - It is just any other physical interface, but 152 is part of a logical interface construct. For example, a logical 153 interface may have been created abstracting two physical 154 interfaces, LTE and WLAN. These physical interfaces, LTE and WLAN 155 are referred to as sub-interfaces of that logical interface. In 156 some cases, a sub-interface can also be another logical interface, 157 such as an IPsec tunnel interface. 159 3. Hiding Link-layer Technologies - Approaches and Applicability 161 There are several techniques that allow hiding of changes in access- 162 technology changes from the host layer. These changes in access 163 technology is primarily due to host's movement between access 164 networks. This section classifies these existing techniques into a 165 set of generic approaches, according to their most representative 166 characteristics. Later sections of this document analyze the 167 applicability of these solution approaches for supporting features 168 such as, inter-technology handovers and IP flow mobility support for 169 a mobile node. 171 3.1. Link-layer Abstraction - Approaches 173 The following generic mechanisms can hide access technology changes 174 from host IP layer: 176 o Link-layer Support - Certain link-layer technologies are able to 177 hide physical media changes from the upper layers. For example, 178 IEEE 802.11 is able to seamlessly change between IEEE 802.11a/b/g 179 physical layers. Also, an 802.11 STA can move between different 180 Access Points within the same domain without the IP stack being 181 aware of the movement. In this case, the IEEE 802.11 MAC layer 182 takes care of the mobility, making the media change invisible to 183 the upper layers. Another example is IEEE 802.3, that supports 184 changing the rate from 10Mbps to 100Mbps and to 1000Mbps. Another 185 example is the situation in the 3GPP Evolved Packet System 186 [TS23401] where a UE can perform inter-access handovers between 187 three different access technologies (2G GERAN, 3G UTRAN, and 4G 188 E-UTRAN) that are invisible to the IP layer at the UE. 190 o A logical interface denotes a mechanism that logically groups 191 several physical interfaces so they appear to the IP layer as a 192 single interface (see Figure 1). Depending on the type of access 193 technologies, it might be possible to use more than one physical 194 interface at a time -- such that the node is simultaneously 195 attached via different access technologies -- or just to perform 196 handovers across a variety of physical interfaces. Controlling 197 the way the different access technologies are used (simultaneous, 198 sequential attachment, etc) is not trivial and requires additional 199 intelligence and/or configuration within the logical interface 200 implementation. The configuration is typically handled via a 201 connection manager, and based on a combination of user preferences 202 on one hand, and operator preferences such as those provisionned 203 by the Access Network Discovery and Selection Function (ANDSF) 204 [TS23402] on the other hand. 206 3.2. Link layer support 208 Link layer mobility support applies to cases when the same link layer 209 technology is used and mobility can be fully handled at that layer. 210 One example is the case where several 802.11 access points are 211 deployed in the same subnet with a common IP layer configuration 212 (DHCP server, default router, etc.). In this case the handover 213 across access points need not to be hidden to the IP layer since the 214 IP layer configuration remains the same after a handover. This type 215 of scenario is applicable to cases when the different points of 216 attachment (i.e. access points) belong to the same network domain, 217 e.g. Enterprise, hotspots from same operator, etc. 219 Since this type of link layer technology does not typically allow for 220 simultaneous attachment to different access networks of the same 221 technology, the logical interface would not be used to provide 222 simultaneous access for purposes of multihoming or flow mobility. 223 Instead, the logical interface can be used to provide inter-access 224 technology handover between this type of link layer technology and 225 another link layer technology, e.g., between IEEE 802.11 and IEEE 226 802.16. 228 3.3. Logical Interface 230 The use of a logical interface allows the mobile node to provide a 231 single interface perspective to the IP layer and its upper layers 232 (transport and application). Doing so allows to hide inter-access 233 technology handovers or application flow handovers across different 234 physical interfaces. 236 The logical interface may support simultaneous attachment, in 237 addition to sequential attachment. It requires additional support at 238 the node and the network in order to benefit from simultaneous 239 attachment. For example special mechanisms are required to enable 240 addressing a particular interface from the network (e.g. for flow 241 mobility). In particular extensions to PMIPv6 are required in order 242 to enable the network (i.e., the MAG and LMA) to deal with logical 243 interface, instead to IP interfaces as current RFC5213 does. RFC5213 244 assumes that each physical interface capable of attaching to a MAG is 245 an IP interface, while the logical interface solution groups several 246 physical interfaces under the same IP logical interface. 248 It is therefore clear that the Logical Interface approach satisfies 249 the multi technology and the sequential vs: simultaneous access 250 support. 252 4. Technology Use cases 254 3GPP has defined the Evolved Packet System (EPS) for heterogeneous 255 wireless access. A mobile device equipped with 3GPP and non-3GPP 256 wireless technologies can simultaneously or sequentially connect any 257 of the available devices and receive IP services through any of them. 258 This document focuses on employing a logical interface for 259 simultaneous and sequential use of a variety of access technologies. 261 As mentioned in the previous sections the Logical Interface construct 262 is able to hide to the IP layer the specifics of each technology in 263 the context of network based mobility (e.g. in multi-access 264 technology networks based on PMIPv6). The LIF concept can be used 265 with at least the following technologies: 3GPP access technologies 266 (3G, LTE), IEEE 802.16 access technology, and IEEE 802.11 access 267 technology. 269 In some UE implementations the wireless connection setup is based on 270 creation of a PPP interface between the IP layer and the wireless 271 modem that is configured with the IPCP and IPv6CP protocol [RFC5072]. 272 In this case the PPP interface does not have any L2 address assigned. 273 In some other implementations the wireless modem is presented to the 274 IP layer as a virtual Ethernet interface. 276 5. Logical Interface Functional Details 278 This section identifies the functional details of a logical interface 279 and provides some implementation considerations. 281 On most operating systems, a network interface is associated with a 282 physical device that offers the services for transmitting and 283 receiving IP packets from the network. In some configurations, a 284 network interface can also be implemented as a logical interface 285 which does not have the inherent capability to transmit, or receive 286 packets on a physical medium, but relies on other physical interfaces 287 for such services. Example of such configuration is an IP tunnel 288 interface. 290 An overview of a logical interface is shown in Figure 1. The logical 291 interface allows heterogeneous attachment while making changes in the 292 underlying media transparent to the IP stack. Simultaneous and 293 sequential network attachment procedures are therefore possible, 294 enabling inter-technology and flow mobility scenarios. 296 +----------------------------+ 297 | TCP/UDP | 298 Session to IP +---->| | 299 Address binding | +----------------------------+ 300 +---->| IP | 301 IP Address +---->| | 302 binding | +----------------------------+ 303 +---->| Logical Interface | 304 Logical to +---->| IPv4/IPv6 Address | 305 Physical | +----------------------------+ 306 Interface +---->| L2 | L2 | | L2 | 307 binding |(IF#1)|(IF#2)| ..... |(IF#n)| 308 +------+------+ +------+ 309 | L1 | L1 | | L1 | 310 | | | | | 311 +------+------+ +------+ 313 Figure 1: General overview of logical interface 315 From the perspective of the IP stack and the applications, a Logical 316 interface is just another interface. In fact, the logical interface 317 is only visible to the IP and upper layers when enabled. A host does 318 not see any operational difference between a Logical and a physical 319 interface. As with physical interfaces, a Logical interface is 320 represented as a software object to which IP address configuration is 321 bound. However, the Logical interface has some special properties 322 which are essential for enabling inter-technology handover and flow- 323 mobility features. Following are those properties: 325 1. The logical interface has a relation to a set of physical 326 interfaces (sub-interfaces) on the host that it is abstracting. 327 These sub-interfaces can be attached or detached from the Logical 328 Interface at any time. The sub-interfaces attached to a Logical 329 interface are not visible to the IP and upper layers. 331 2. The logical interface may be attached to multiple access 332 technologies. 334 3. The Transmit/Receive functions of the logical interface are 335 mapped to the Transmit/Receive services exposed by the sub- 336 interfaces. This mapping is dynamic and any change is not 337 visible to the upper layers of the IP stack. 339 4. The logical interface maintains IP flow information for each of 340 its sub-interfaces. A conceptual data structure is maintained 341 for this purpose. The host may populate this information based 342 on tracking each of the sub-interface for the active flows. 344 5.1. Configuration of a Logical Interface 346 A host may be statically configured with the logical interface 347 configuration, or an application such as a connection manager on the 348 host may dynamically create it. Furthermore, the set of sub- 349 interfaces that are part of a logical interface construct may be a 350 fixed set, or may be kept dynamic, with the sub-interfaces getting 351 added or deleted as needed. The specific details related to these 352 configuration aspects are implementation specific and are outside the 353 scope of this document. 355 The IP layer should be configured with a default router reachable via 356 the logical interface. The default router can be internal to the 357 logical interface, i.e., it is a logical router that in turns decide 358 which physical interface is to be used to transmit packets. 360 5.2. Logical-Interface Forwarding Table 362 The logical interface maintains the list of sub-interfaces that are 363 part of logical-interface construct. This is a conceptual data 364 strucure, called as the Logical-Interface Forwarding Table. 366 The logical interface also maintains the list of flows associated 367 with a given sub-interface and this conceptual data structure is 368 called as the PIF Table. Both of these data structures have to be 369 associated with a logical interface, and are depicted in Figure 2. 371 LIF TABLE FLOW table 372 +===============================+ +=============================+ 373 | PIF_ID | FLOW Routing Policies| | FLOW ID | Physical_Intf_Id | 374 | | Link Status | +-----------------------------+ 375 +-------------------------------| | FLOW_ID | Physical_Intf_Id | 376 | PIF_ID | FLOW Routing Policies| +=============================+ 377 | | Link Status | + .... | .... | 378 +-------------------------------+ +=============================+ 379 | .... | .... | 380 +===============================+ 382 Figure 2: Logical Interface Table 384 The LIF table maintains the mapping between the LIF and each PIF 385 associated to the LIF (refer to property #3, Figure 1). For each PIF 386 entry the table should store the associated Routing Policies, and the 387 Link Status of the PIF (e.g. active, not active). The method by 388 which the Routing Policies are configured on the host is out of scope 389 for this document. 391 The FLOW table allows the logical interface to properly route each IP 392 flow over the right interface. The logical interface can identify 393 the flows arriving on its sub-interfaces and associate them to those 394 sub-interfaces. This approach is similar to reflective QoS performed 395 by the IP routers. For locally generated traffic (e.g. unicast 396 flows), the logical interface should perform interface selection 397 based on the Flow Routing Policies. In case traffic of an existing 398 flow is suddenly received from the network on a different sub- 399 interface than the one locally stored, the logical interface should 400 interpret the event as an explicit flow mobility trigger from the 401 network and it should update the PIF_ID parameter in the FLOW table. 402 Similarly, locally generated events from the sub-interfaces, or 403 configuration updates to the local policy rules can cause updates to 404 the table and hence trigger flow mobility. 406 6. Logical Interface Use-cases in Proxy Mobile IPv6 408 This section explains how the Logical interface support on the mobile 409 node can be used for enabling some of the Proxy Mobile IPv6 protocol 410 features. 412 6.1. Multihoming Support 414 A mobile node with multiple interfaces can attach simultaneously to 415 the Proxy Mobile IPv6 domain. If the host is configured to use 416 Logical interface over the physical interfaces through which it is 417 attached, following are the related considerations. 419 LMA Binding Table 420 +========================+ 421 +----+ | HNP MN-ID CoA ATT | 422 |LMA | +========================+ 423 +----+ | HNP-1 MN-1 PCoA-1 5 | 424 //\\ | HNP-1 MN-1 PCoA-2 4 | 425 +---------//--\\-----------+ 426 ( // \\ ) 427 ( // \\ ) 428 +------//--------\\--------+ 429 // \\ 430 PCoA-1 // \\ PCoA-2 431 +----+ +----+ 432 (WLAN) |MAG1| |MAG2| (3GPP) 433 +----+ +----+ 434 \ / 435 \ / 436 \ / 437 \ / 438 \ / 439 +-------+ +-------+ 440 | if_1 | | if_2 | 441 |(WLAN) | |(3GPP) | 442 +-------+-+-------+ 443 | Logical | 444 | Interface | 445 | (HNP-1) | 446 +-----------------| 447 | MN | 448 +-----------------+ 450 Figure 3: Multihoming Support 452 6.2. Inter-Technology Handoff Support 454 The Proxy Mobile IPv6 protocol enables a mobile node with multiple 455 network interfaces to move between access technologies, but still 456 retaining the same address configuration on its attached interface. 457 The protocol enables a mobile node to achieve address continuity 458 during handoffs. If the host is configured to use Logical interface 459 over the physical interface through which it is attached, following 460 are the related considerations. 462 LMA's Binding Table 463 +==========================+ 464 +----+ | HNP MN-ID CoA ATT | 465 |LMA | +==========================+ 466 +----+ | HNP-1 MN-1 PCoA-1 5 | 467 //\\ (pCoA-2)(4) <--change 468 +---------//--\\-----------+ 469 ( // \\ ) 470 ( // \\ ) 471 +------//--------\\--------+ 472 // \\ 473 PCoA-1 // \\ PCoA-2 474 +----+ +----+ 475 (WLAN) |MAG1| |MAG2| (3GPP) 476 +----+ +----+ 477 \ / 478 \ Handoff / 479 \ / 480 \ / 481 +-------+ +-------+ 482 | if_1 | | if_2 | 483 |(WLAN) | |(3GPP) | 484 +-------+-+-------+ 485 | Logical | 486 | Interface | 487 | (HNP-1) | 488 +-----------------| 489 | MN | 490 +-----------------+ 492 Figure 4: Inter-Technology Handoff Support 494 o When the mobile node performs an handoff between if_1 and if_2, 495 the change will not be visible to the applications of the mobile 496 node. 498 o The protocol signaling between the network elements will ensure 499 the local mobility anchor will switch the forwarding for the 500 advertised prefix set from MAG1 to MAG2. 502 6.3. Flow Mobility Support 504 For supporting IP flow mobility, there is a need to support vertical 505 handoff scenarios such as transferring a subset of prefix(es) (hence 506 the flows associated to it/them) from one interface to another. The 507 mobile node can support this scenario by using the Logical interface 508 support. This scenario is similar to the Inter- technology handoff 509 scenario defined in Section 6.2, only a subset of the prefixes are 510 moved between interfaces. 512 Additionally, IP flow mobility in general initiates when the LMA 513 decides to move a particular flow from its default path to a 514 different one. The LMA can decide on which is the best MAG that 515 should be used to forward a particular flow when the flow is 516 initiated e.g. based on application policy profiles) and/or during 517 the lifetime of the flow upon receiving a network-based or a mobile- 518 based trigger. However, the specific details on how the LMA can 519 formulate such flow policy is outside the scope of this document. 521 7. IANA Considerations 523 This specification does not require any IANA Actions. 525 8. Security Considerations 527 This specification explains the operational details of Logical 528 interface on an IP host. The Logical Interface implementation on the 529 host is not visible to the network and does not require any special 530 security considerations. 532 9. Authors 534 This document reflects contributions from the following authors 535 (listed in alphabetical order): 537 Carlos Jesus Bernardos Cano 539 cjbc@it.uc3m.es 541 Antonio De la Oliva 543 aoliva@it.uc3m.es 545 Yong-Geun Hong 547 yonggeun.hong@gmail.com 549 Kent Leung 551 kleung@cisco.com 553 Tran Minh Trung 555 trungtm2909@gmail.com 557 Hidetoshi Yokota 559 yokota@kddilabs.jp 561 Juan Carlos Zuniga 563 JuanCarlos.Zuniga@InterDigital.com 565 10. Acknowledgements 567 The authors would like to acknowledge all the discussions on this 568 topic in NETLMM and NETEXT working groups. The authors would also 569 like to thank Joo-Sang Youn, Pierrick Seite, Rajeev Koodli, Basavaraj 570 Patil, Peter McCann, Julien Laganier, Maximilian Riegel, Georgios 571 karagian for their inputs to the document. 573 11. References 574 11.1. Normative References 576 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 577 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 579 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 580 Mobile IPv6", RFC 5844, May 2010. 582 11.2. Informative References 584 [I-D.ietf-netext-pmipv6-flowmob] 585 Bernardos, C., "Proxy Mobile IPv6 Extensions to Support 586 Flow Mobility", draft-ietf-netext-pmipv6-flowmob-13 (work 587 in progress), February 2015. 589 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 590 Internet Protocol", RFC 4301, December 2005. 592 [RFC5072] Varada, S., Haskins, D., and E. Allen, "IP Version 6 over 593 PPP", RFC 5072, September 2007. 595 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 596 in IPv6", RFC 6275, July 2011. 598 [TS23401] "3rd Generation Partnership Project; Technical 599 Specification Group Services and System Aspects; General 600 Packet Radio Service (GPRS) enhancements for Evolved 601 Universal Terrestrial Radio Access Network (E-UTRAN) 602 access.", 2009. 604 [TS23402] "3rd Generation Partnership Project; Technical 605 Specification Group Services and System Aspects; 606 Architecture Enhancements for non-3GPP Accesses.", 2009. 608 Authors' Addresses 610 Telemaco Melia (editor) 611 Alcatel-Lucent 612 Route de Villejust 613 Nozay 91620 614 France 616 Email: telemaco.melia@alcatel-lucent.com 617 Sri Gundavelli (editor) 618 Cisco 619 170 West Tasman Drive 620 San Jose, CA 95134 621 USA 623 Email: sgundave@cisco.com