[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
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]