Network Working Group T. Melia Internet-Draft Alcatel-Lucent Bell Labs Intended status: Informational C. Bernardos Expires: January 6, 2010 Universidad Carlos III de Madrid JC. Zuniga InterDigital Communications, LLC July 5, 2009 3GPP MN-AR interface draft-melia-netext-3gpp-mn-ar-if-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 6, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Melia, et al. Expires January 6, 2010 [Page 1] Internet-Draft 3GPP MN-AR interface July 2009 Abstract This ID documents the interface between the Mobile Node and the Mobility Access Gateway in the context of 3GPP Evolved Packet Core networks. The main goal is to support the Netext working group in the discussions on the MN to AR interface showing how RFC 5213 has been deployed by other SDOs. This document has been inspired by considerations expressed in [I-D.gundavelli-netext-extensions-motivation]. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Differences between 3GPP and IETF specifications . . . . . . . 5 4. Reference point S5 . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Network attachment . . . . . . . . . . . . . . . . . . . . 5 4.2. Network Detachment . . . . . . . . . . . . . . . . . . . . 6 5. Reference point S2a . . . . . . . . . . . . . . . . . . . . . 7 5.1. Network Attachment . . . . . . . . . . . . . . . . . . . . 7 5.2. Network detachment . . . . . . . . . . . . . . . . . . . . 8 6. Reference point S2b . . . . . . . . . . . . . . . . . . . . . 9 6.1. Network Attachment . . . . . . . . . . . . . . . . . . . . 9 6.2. Network Detachment . . . . . . . . . . . . . . . . . . . . 10 7. Common aspects in Handover Management procedures . . . . . . . 10 8. Multiple Interfaces support . . . . . . . . . . . . . . . . . 11 9. General Considerations . . . . . . . . . . . . . . . . . . . . 11 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 13.1. Normative References . . . . . . . . . . . . . . . . . . . 12 13.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Melia, et al. Expires January 6, 2010 [Page 2] Internet-Draft 3GPP MN-AR interface July 2009 1. Terminology This document uses the following terminology: PDN Packet Data Network EPS Evolved Packet System EPC Evolved Packet Core S-GW Serving Gateway P-GW PDN Gateway UE User Equipment GTP GPRS Tunneling Protocol APN Access Point Name 2. Introduction The 3GPP standardization body specified the Evolved Packet System (EPS) architecture (release 8). EPS relies on a fully IP-based core network, the Evolved Packet Core (EPC), and provides heterogeneous wireless access to multi mode mobile devices. EPC supports different type of wireless access networks, namely the evolved UTRAN (i.e. LTE), a trusted non-3GPP access (i.e. WIMAX) and a non-trusted and non-3GPP access (i.e. WIFI). Melia, et al. Expires January 6, 2010 [Page 3] Internet-Draft 3GPP MN-AR interface July 2009 _.----------. ,-'' `--. / +-------+ ( EUTRAN | S-GW |\\ \ ACCESS +-------+ \\ `--. _.-' \\ S5 interface `----------'' \\ \\ _.----------. \\ ,-'' `--. \\ / +-------+ S2a interface \\+-------+ ( WIMAX | S-GW |======================| P-GW | \ ACCESS +-------+ //+-------+ `--. _.-'ASN-GW // `----------'' // // _.----------. // ,-'' `--. // / +-------+ // S2b interface ( WIFI | S-GW |// \ ACCESS +-------+ `--. _.-'ePDG `----------'' Figure 1: 3GPP Evolved Packet Core Figure 1 shows a simplified overview of the EPS architecture (please note that only the key components relevant for the understanding of this document are highlighted). The Serving GW (S-GW) is the first layer three hop in the network and is the default router for the mobile node (i.e. Recipient of Router Solicitation and sender of Router Advertisement messages). It provides layer three configuration parameters. In case of non- 3GPP trusted access the S-GW is implemented by the ASN-GW standardized by the Wimax Forum. In case of non-3GPP, non-trusted access (e.g. WIFI) the S-GW is implemented by the evolved Packet Data Gateway (ePDG). The P-GW is the anchor point for all the uplink and downlink traffic to/from the mobile node. The Home Address assigned to the mobile node is anchored at the P-GW who is in charge of tunneling management towards the S-GW. The reference point between S-GW and P-GW in the context of LTE access is S5/S8, between the P-GW and the ASN-GW in the context of WiMAX access is S2a and between the ePDG and the P-GW in the context of WIFI interworking is S2b. S5, S2a and S2b interfaces support mobility management of mobile devices and they can be implemented, among others, via the Proxy Mobile IPv6 protocol[RFC5213]. In this case the P-GW integrates the LMA functionality and the S-GW the MAG functionality. In the remainder of this document we assume PMIPv6 is the selected mobility management Melia, et al. Expires January 6, 2010 [Page 4] Internet-Draft 3GPP MN-AR interface July 2009 protocol. 3. Differences between 3GPP and IETF specifications The EPC architecture is specified in [3GPP.23.401]. Non-3GPP access is detailed in [3GPP.23.402] The PMIPv6 protocol is specified in [3GPP.29.275] (stage 3) and additional parameters in [3GPP.29.282] and [3GPP.24.008]. The main difference between the PMIPv6 protocol specified in [RFC5213] and the PMIPv6 protocol specified by 3GPP is the introduction of the Access Point Name. The APN is introduced as parameter in the PBU signaling and is used by the P-GW to allocate the right Home Address (PDN selection). To support Multiple PDNs the MAG and LMA perform lookups on the extended data structure compared to the standard PMIPv6 as defined in [RFC5213]. In standard PMIPv6 as defined in [RFC5213], a PMIPv6 BCE is looked up based on the Mobile Node Identifier (MN_ID), the access technology types (ATT) and if it exist the MN's link-layer identifier (MN_LL_ID). In EPC the MN_LL_ID is not used and the EPC supports handover between non-3GPP and 3GPP accesses. Since a distinct PMIPv6 BCE exists for each of the PDN connections of an UE, and since multiple PDN connections of a UE can be distinguished based on an APN, there is a one-to-one mapping between a PMIPv6 BCE, a PDN connection, and the (MN_ID, APN) tuple. Thus, an UE PDN connection can be uniquely identified by a (MN_ID, APN) tuple and the BC/BUL are accordingly looked up on a per (MN_ID, APN) tuple basis. It should be noted that the APN parameter is conveyed by the MN to the access network during the access authentication procedure. 4. Reference point S5 Reference point S5 can be implemented via the GTP protocol or via PMIP protocol. As stated before we focus here on the use of PMIPv6. We summarize in the following attachment procedures and detachment procedures focusing on the parameters required by the MAG to correctly form a PBU. 4.1. Network attachment When the MN initiates an attachment procedure it sends to the access network among others the following parameters: PDN type, Protocol Configuration Options (PCO), Attach type. PDN type indicates the requested IP version (IPv4, IPv6, IPv4/IPv6). PCO is used to transfer additional parameters between the MN and the LMA (P-GW). Parameters are sent transparently through the MAG (S-GW). Attach Melia, et al. Expires January 6, 2010 [Page 5] Internet-Draft 3GPP MN-AR interface July 2009 type indicates "Handover" when the MN has already a mobility session registered at the LMA due to mobility from non-3GPP access. To handle situation where the MN might have multiple PDN connections with the LMA the MN should also send the APN. For default bearer creation the MAG (S-GW) sends a Proxy Binding Update to the LMA (P-GW) including the following parameters: MN NAI, Lifetime, Access Technology Type, Handover Indicator, APN, GRE key for downlink traffic, MN Address Info Additional Parameters. The MN NAI identifies the user equipment for whom the message is being sent. The Lifetime field must be set to a nonzero value in the case of a registration. Access Technology Type is set to indicate the Radio Access Technology type (E-UTRAN). Handover Indication option is set to indicate attachment over a new interface as no Handover indication is indicated in the Attach type. The APN may be necessary to differentiate the intended PDN from the other PDNs supported by the same PDN GW. The optional Additional Parameters may contain information, for example, Protocol Configuration Options. The UE Address Info IE is used to request an IPv6 prefix, IPv4 address, or both IPv4 address and IPv6 prefix. Based on PDN Type parameter received the MAG (S-GW) includes request for IPv4 Home Address (PDN Type set to IPv4), or IPv6 Home Network Prefix (PDN type set to IPv6) or both IPv4 home address and IPv6 HNP (PDN type set to IPv4v6) in the PBU as specified in PMIPv6 specification. The PDN GW responds with a PMIPv6 Binding Acknowledgment message to the S-GW including the following parameters: MN NAI, Lifetime, UE Address Info, GRE key for uplink traffic, Additional Parameters. The MN NAI is identical to the MN NAI sent in the Proxy Binding Update. The Lifetime indicates the duration the binding will remain valid. The PDN GW takes into account the request from S-GW and the operator's policies when allocating the UE Address Info. It should be noted that the S-GW learns from the PBA if the P-GW supports multiple PDN connections to the same APN or not. It should be noted that critical parameters to fill in mandatory parameters in PBU/PBA messages are conveyed during network access. 4.2. Network Detachment In case of network detachment all the bearers at the S-GW are terminated. The S-GW sends a Proxy Binding Update message to the P-GW including the following parameters: MN NAI, APN, and lifetime set to value 0. The MN NAI and APN identify the PDN connection of the UE. The lifetime field indicates that the message is used to release the PDN connection of the UE at the PDN-GW. The PDN GW responds to the S-GW with the result of the PDN connection Melia, et al. Expires January 6, 2010 [Page 6] Internet-Draft 3GPP MN-AR interface July 2009 release with Proxy Binding Update Acknowledgment 5. Reference point S2a Reference point S2a may implement PMIPv6 to grant network access for non-3GPP networks. 5.1. Network Attachment Upon layer two access procedures (which are not in scope of 3GPP) the MN performs EAP authentication with the AAA infrastructure. Among other parameters, the 3GPP AAA server return to the S-GW the MN NAI to be used to identify the UE in the PBU message. If this is supported by the non-3GPP access network the Attach Type is indicated to the S-GW by the UE. The support for attach type indication is access technology specific and not in scope of 3GPP specifications. An Attach Type set to value "handover" indicates that the UE has already an active mobility session at the P-GW due to mobility from 3GPP to non-3GPP access. After successful authentication and authorization, the non-3GPP access specific L3 attach procedure is triggered. The UE may send requested APN to the Non-3GPP IP access in this step (note that Attach Type and APN can be sent as part of L3 signaling as suggested in [I-D.patil-dhc-apn-attachtype-options]). If the UE sends a requested APN in this step, the Trusted non-3GPP Access verifies that it is allowed by subscription. If the UE does not send a requested APN the Trusted non-3GPP Access uses the default APN. The PDN Gateway selection takes place. If the PDN subscription profile returned by the 3GPP AAA Server contains a PDN GW identity for the selected APN and the Attach Type does not indicate "Handover", the Non-3GPP access GW may request a new PDN GW to allocate a PDN GW that allows for more efficient routing. The UE may request the type of address (IPv4 address or IPv6 prefix or both) during this step. If supported by the non-3GPP access, the UE may send Protocol Configuration Options in this step using access specific mechanisms (note that other IP based mechanisms have been proposed [I-D.melia-dhc-pco]). The Protocol Configuration Options provided by the UE may include the user credentials for PDN access authorization. In that case, in order to handle situations where the UE may have subscriptions to multiple PDNs, the UE should also send a requested APN to the non-3GPP IP access. The MAG function of Trusted Non-3GPP IP Access sends a Proxy Binding Update to the P-GW including the following parameters: MN-NAI, Lifetime, Access Technology Type, Handover Indicator, APN, GRE key for downlink traffic, Additional Parameters. The MN NAI identifies Melia, et al. Expires January 6, 2010 [Page 7] Internet-Draft 3GPP MN-AR interface July 2009 the UE. The Lifetime field must be set to a nonzero value. Access Technology Type is set to a value matching the characteristics of the non-3GPP access. Handover Indicator is set to "initial" attach as the UE has provided Attach Type indicating "Initial" attach or as the Attach Type indicates "Handover" and the PDN subscription profile contains no PDN GW. The Additional Parameters include the Protocol Configuration Options provided by the UE and may also include other information. The MAG requests the IP address types (IPv4 address and/or IPv6 Home Network Prefix) based on requested IP address types and subscription profile in the same way as the PDN type is selected during the E UTRAN Initial Attach in [3GPP.23.401]. If the PDN requires an additional authentication and authorization with an external AAA Server, the P-GW performs such an additional authentication and authorization at the reception of the Proxy Binding Update. The P-GW processes the proxy binding update and creates a binding cache entry for the UE. The P-GW allocates IP address(es) for the UE. The P-GW then sends a Proxy Binding Acknowledgment message to the MAG including the following parameters: MN NAI, Lifetime, UE Address Info, GRE key for uplink traffic, Additional Parameters and the IP address(es) allocated for the UE. The UE Address Info includes one or more IP addresses. The Lifetime indicates the duration of the binding. The Additional Parameters may include Protocol Configuration Options and other information.If UE requests for both IPv4 and IPv6 addresses, both are allocated. If the P-GW operator dictates the use of IPv4 addressing only or IPv6 addressing only for this APN, the P-GW shall allocate only IPv4 address or only IPv6 prefix to the UE. If the UE requests for only IPv4 or IPv6 address only one address is allocated accordingly. 5.2. Network detachment If the UE in the trusted non-3GPP access triggers either detach or disconnection of a PDN connection by means of access specific procedures the MAG (S-GW) sends a Proxy Binding Update message to the P-GW with the following parameters: MN NAI, APN, lifetime value set to 0. The MN NAI identifies the UE to deregister from the PDN GW. When only one PDN connection to the given APN is allowed the APN is needed in order to determine which PDN to deregister the UE from, as some PDN GWs may support multiple PDNs. When multiple PDN connections to the given APN are supported the APN and the PDN connection identity are needed in order to determine which PDN to deregister the UE from. The P-GW deletes existing entries implied in the Proxy Binding Update message from its Binding Cache and sends a Proxy Binding Acknowledgment message to the MAG. Melia, et al. Expires January 6, 2010 [Page 8] Internet-Draft 3GPP MN-AR interface July 2009 6. Reference point S2b Reference point S2b is used to grant network access to MN in the context of non-trusted non-3GPP networks (e.g. WLAN access). As shown in Figure 1 it is assumed that the MAG functionality is co- located with the ePDG. Between the MN and the ePDG an IPsec tunnel is used to convey the required parameters for PMIPv6 operation between the MAG and the LMA (P-GW). 6.1. Network Attachment Prior to IKEv2 tunnel establishment the MN configures an IP address from the local non-trusted non-3GPP access network. The ePDG IP address to which the UE needs to form IPsec tunnel is discovered via DNS. The UE may request connectivity to a specific PDN providing an APN, that is conveyed with IKEv2. For networks supporting multiple mobility protocols, if there was any dynamic IP mobility selection decision involved in this step, the decision is stored in the 3GPP AAA Server. The P-GW information is returned as part of the reply from the 3GPP AAA Server to the ePDG. If the UE has provided an APN the ePDG verifies that it is allowed by subscription. If the UE has not provided an APN the ePDG uses the default APN. The P-GW selection takes place at this point. The UE indicates the type of address(es) (IPv4 address or IPv6 prefix /address or both) in the CFG_Request sent to the ePDG during IKEv2 message exchange. The ePDG sends the Proxy Binding Update message to the P-GW including the following parameters: MN-NAI, Lifetime, APN, Access Technology Type, Handover Indicator, GRE key for downlink traffic, UE Address Info, Charging Characteristics , Additional Parameter. Access Technology Type option is set to a value matching the characteristics of the non-3GPP IP access. Handover Indicator is set to indicate attachment over a new interface. The MN NAI identifies the UE. The Lifetime field must be set to a nonzero value in the case of a registration and a zero value in the case of a de-registration. The APN is used by the P-GW to determine which PDN to establish connectivity for, in the case that the P-GW supports multiple PDN connectivity. The ePDG creates and includes a PDN connection identity if the ePDG supports multiple PDN connections to a single APN. The P-GW processes the Proxy Binding Update and creates a binding cache entry for the UE. The P-GW allocates an IP address for the UE. The P-GW then sends a Proxy Binding Ack message to the S-GW including the following parameters: MN NAI, UE Address Info, GRE Key for uplink traffic, Charging ID and the IP address(es) allocated for the UE (identified by the MN NAI). If the corresponding Proxy Binding Update contains the PDN connection identity, the P-GW shall Melia, et al. Expires January 6, 2010 [Page 9] Internet-Draft 3GPP MN-AR interface July 2009 acknowledge if multiple PDN connections to the given APN are supported. 6.2. Network Detachment The release of the IKEv2 tunnel triggers PMIPv6 disconnection. The MAG in the ePDG sends a Proxy Binding Update (MN NAI, APN, lifetime=0) message to the PDN GW. The MN NAI identifies the UE. When only one PDN connection to the given APN is allowed the APN is needed in order to determine which PDN to deregister the UE from, as some PDN GWs may support multiple PDNs. When multiple PDN connections to the given APN are supported, the APN and the PDN connection identity are needed in order to determine which PDN to deregister the UE from. The lifetime value set to zero, indicates this is a PMIP de-registration. The P-GW deletes all existing entries for the indicated HoA from its Binding Cache and sends a Proxy Binding Ack (MN NAI, lifetime=0) message to the MAG in the ePDG. The P-GW sends a Proxy Binding Ack message to the ePDG. The MN NAI value and the lifetime=0 values indicate that the UE has been successfully deregistered. 7. Common aspects in Handover Management procedures Generally when the UE, upon handover trigger, attaches to the target access network it sends the Attach Type field set to value "Handover". This is an explicit indication from the UE willing to perform handover. In case the MN performs handover from non-3GPP trusted access to EUTRAN access the MAG sets the Handover Indicator in the PBU according to the Attach Type field received during the attach procedure. In case the MN performs handover from 3GPP access to non-3GPP trusted access the MN needs to provide at the latest during layer three attachment the required parameters (e.g. handover indication, APN). How the MN delivers such parameters to the access network is however not in scope of 3GPP specifications. In case the MN performs handover from 3GPP to non-3GPP non-trusted access network the MN should provide during the IKEv2 tunnel establishment an indication of address preservation during handover. The ePDG upon reception of the IKEv2 signaling will form a PBU setting the Handover Indicator field accordingly to the address preservation indication. The APN is used to determine which PDN Melia, et al. Expires January 6, 2010 [Page 10] Internet-Draft 3GPP MN-AR interface July 2009 connectivity is updated. 8. Multiple Interfaces support [3GPP.23.861] explores the possibility to use simultaneous PDN connections across different access networks. [3GPP.23.861] further specifies that a MN is able to connect at the same time two and only two wireless devices. That is, possible scenarios are a MN being connected to the LTE network and further enjoying services provided either through the non-3GPP trusted network or trough the non-3GPP non-trusted network. In this context multiple interface support can be provided by means of routing filters based solutions or by means of the PCC framework. Routing filters based solutions are described for both Dual Stack Mobile IPv6 (note that EPC also supports DSMIPv6 on reference point S2c) and Proxy Mobile IPv6. While for the S2c interface [I-D.ietf-monami6-multiplecoa] and [I-D.ietf-mext-flow-binding] completely design the solution, it is left for further study if PMIPv6 should be enhanced to convey routing filters between the MAG and the LMA as part of the PBU/PBA exchange or if PCO could be used instead. If the PCC framework is used for network based mobility management (e.g. PMIPv6) filters are installed as part of the interactions between P-GW and PCC framework during network attachment/handover. In general the MN still has to provide indication to the access network that it intends to add an additional PDN connection to the already existing mobility session at the P-GW. This is achieved transferring a "MAPIM" indicator as part of the attach procedure in the PCO field. Note that PCO is transferred at layer two during EUTRAN access, and it is not described how it is transferred in the case of non-3GPP access (trusted or not-trusted). 9. General Considerations We can safely summarize that during EUTRAN network attachment the paramters required for PMIPv6 operation (i.e. MN_ID, APN, Attach type) are transferred as part of the layer two signaling. In case of handover from a non-3GPP system to a 3GPP system the Attach Type indicates "handover". Attach type is specified by the UE and used by the MAG to fill the Handover Indicator option. In case the UE intends to enable multiple interface support and the P-GW has an already existing session the UE may include a MAPIM indicator to update the existing mobility session. Melia, et al. Expires January 6, 2010 [Page 11] Internet-Draft 3GPP MN-AR interface July 2009 During attachment to a non-3GPP trusted system the network attachment procedures are not in scope of 3GPP. However, such procedures can be part of layer three signaling (i.e. IP signaling). In case of mobility to a non-3GPP trusted system the Attach Type (used to fill in the Handover Indicator option) indicates handover (set by the UE). Multiple interface usage may be achieved by means of the MAPIM indicator transferred as part of PCO. During attachment to a non-trusted non-3GPP system the required parameters for PMIPv6 operation are transferred to the ePDG as part of the IKEv2 signaling. 10. IANA Considerations This document makes no request of IANA. 11. Security Considerations This document summarizes deployment choices for PMIPv6 specified in other SDOs. There are no security issues to be dealt with. 12. Acknowledgements 13. References 13.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 13.2. Informative References [3GPP.23.401] 3GPP, "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access", 3GPP TS 23.401 8.6.0, June 2009. [3GPP.23.402] 3GPP, "Architecture enhancements for non-3GPP accesses", 3GPP TS 23.402 8.6.0, June 2009. Melia, et al. Expires January 6, 2010 [Page 12] Internet-Draft 3GPP MN-AR interface July 2009 [3GPP.23.861] 3GPP, "Multi Access PDN connectivity and IP flow mobility", 3GPP TR 23.861 1.1.1, May 2009. [3GPP.24.008] 3GPP, "Mobile radio interface Layer 3 specification; Core network protocols; Stage 3", 3GPP TS 24.008 3.20.0, December 2005. [3GPP.29.275] 3GPP, "Proxy Mobile IPv6 (PMIPv6) based Mobility and Tunneling protocols; Stage 3", 3GPP TS 29.275 8.2.1, April 2009. [3GPP.29.282] 3GPP, "Mobile IPv6 vendor specific option format and usage within 3GPP", 3GPP TS 29.282 8.1.0, June 2009. [I-D.gundavelli-netext-extensions-motivation] Gundavelli, S., "Extensions to Proxy Mobile IPv6 - Motivation", draft-gundavelli-netext-extensions-motivation-00 (work in progress), May 2009. [I-D.ietf-mext-flow-binding] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G., and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and Nemo Basic Support", draft-ietf-mext-flow-binding-02 (work in progress), April 2009. [I-D.ietf-monami6-multiplecoa] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, "Multiple Care-of Addresses Registration", draft-ietf-monami6-multiplecoa-14 (work in progress), May 2009. [I-D.melia-dhc-pco] Melia, T. and Y. Mghazli, "DHCP option to transport Protocol Configuration Options", draft-melia-dhc-pco-00 (work in progress), February 2009. [I-D.patil-dhc-apn-attachtype-options] Patil, B., Chowdhury, K., and D. Premec, "DHCP options for Access Point Name and attach type indication", draft-patil-dhc-apn-attachtype-options-01 (work in progress), March 2009. Melia, et al. Expires January 6, 2010 [Page 13] Internet-Draft 3GPP MN-AR interface July 2009 Authors' Addresses Telemaco Melia Alcatel-Lucent Bell Labs Email: telemaco.melia@alcatel-lucent.com Carlos J. Bernardos Universidad Carlos III de Madrid Av. Universidad, 30 Leganes, Madrid 28911 Spain Phone: +34 91624 6236 Fax: Email: cjbc@it.uc3m.es URI: http://www.it.uc3m.es/cjbc/ Juan Carlos Zuniga InterDigital Communications, LLC Email: JuanCarlos.Zuniga@InterDigital.com Melia, et al. Expires January 6, 2010 [Page 14]