NETEXT Working Group CJ. Bernardos Internet-Draft A. de la Oliva Intended status: Informational UC3M Expires: April 29, 2010 JC. Zuniga InterDigital Communications, LLC T. Melia Alcatel-Lucent Bell Labs S. Das Telcordia Technologies Inc. October 26, 2009 PMIPv6 operation with IEEE 802.21 draft-bernardos-netext-pmipv6-mih-01 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 April 29, 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. Bernardos, et al. Expires April 29, 2010 [Page 1] Internet-Draft PMIPv6 & IEEE 802.21 October 2009 Abstract The NETLMM WG standardized Proxy Mobile IPv6 (PMIPv6). PMIPv6 enables mobile devices to connect to a PMIPv6 domain and roam across gateways without changing the IP address. PMIPv6 also provides limited multi-homing support to multi-mode mobile devices. While the basic scenario addressed by PMIPv6 considers MNs with just one interface, PMIPv6 also allows an MN to connect to the same PMIPv6 domain through different interfaces. This limited support of multi- interfaced MNs is not fully specified, since the MAG needs to obtain/ guess additional information from the MN, in order to decide whether to treat an MN's interface attachment as a handover or as new interface attachment (i.e. meaning the creation of a new mobility session and, therefore, the allocation of new home network prefixes to the MN). The use of the Media Independent Handover (MIH) Services as defined in the IEEE 802.21-2008 specification [IEEE80221] may help in obtaining this additional information. This I-D describes how PMIPv6 would work in an 802.21-enabled scenario, and in particular, analyzes how MIH primitives can be used to help the MAG deal with multi-technology scenarios. The main objective of the IEEE 802.21- 2008 standard is to provide link layer intelligence to upper layers. Hence, a more intelligent decision making capability leading to more reliable and efficient handovers between heterogeneous networks can be enabled. 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]. Bernardos, et al. Expires April 29, 2010 [Page 2] Internet-Draft PMIPv6 & IEEE 802.21 October 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. PMIPv6 (RFC 5213) and IEEE 802.21 operation . . . . . . . . . 6 4. PMIPv6 Extensions and IEEE 802.21 . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Bernardos, et al. Expires April 29, 2010 [Page 3] Internet-Draft PMIPv6 & IEEE 802.21 October 2009 1. Introduction Proxy Mobile IPv6 (PMIPv6), specified in [RFC5213], provides network based mobility management to hosts connecting to a PMIPv6 domain. PMIPv6 introduces two new functional entities, the Local Mobility Anchor (LMA) and the Mobile Access Gateway (MAG). The MAG is the first layer three hop detecting Mobile Node's (MN) attachment and providing IP connectivity. The LMA is the entity assigning one or more Home Network Prefixes (HNPs) to the MN and is the topological anchor for all traffic from/to the MN. While the basic scenario addressed by PMIPv6 considers MNs with just one interface, [RFC5213] also allows an MN to connect to the same PMIPv6 domain through different interfaces. This limited support of multi-interfaced MNs is not fully specified, since the MAG needs to obtain/guess additional information from the MN, in order to decide whether to treat an MN's interface attachment as a handover or as new interface attachment (i.e. meaning the creation of a new mobility session and, therefore, the allocation of new home network prefixes to the MN). The use of IEEE 802.21 Media Independent Handover (MIH) Services [IEEE80221] may help in obtaining this additional information. This I-D describes how PMIPv6 would work in an 802.21- enabled scenario, and in particular, analyzes how MIH primitives can be used to help the MAG deal with multi-technology scenarios. 2. Terminology Readers are expected to be familiar with all the terms defined in the [RFC5213]. In addition, the following acronyms and terminology (related to the IEEE 802.21 standard) are used in this document: MIH (Media Independent Handover) The handover support architecture defined by the IEEE 802.21-2008 specification that consists of the MIH Function (MIHF), MIH Network Entities and MIH protocol messages. MIHF (Media Independent Handover Function) A switching function that provides handover services including the Event Service (ES), Information Service (IS), and Command Service (CS), through service access points (SAPs) defined by the IEEE 802.21 working group. MIH User Bernardos, et al. Expires April 29, 2010 [Page 4] Internet-Draft PMIPv6 & IEEE 802.21 October 2009 An entity that uses the MIH SAPs to access MIHF services. MIHF_ID (MIHF Identifier) The MIHF_ID is a network access identifier (NAI). NAI shall be unique as per IETF RFC 4282 [RFC5164]. MoS (Mobility Services) Those services, as defined in the MIH problem statement document [RFC5164], which includes the MIH IS, CS, and ES services defined by the IEEE 802.21-2008 standard. ES (Event Service) A MoS that originates at a remote MIHF or the lower layers of the local protocol stack and sends information to the local MIHF or local higher layers. The purpose of the ES is to report changes in link status (e.g., Link Detected, Link Up, and Link Going Down messages) and various lower layer events. CS (Command Service) MoS that sends commands from the remote MIHF or local upper layers to the remote or local lower layers of the protocol stack to switch links or to get link status. PoS (Point of Service) A network-side MIHF instance that exchanges MIH messages with a MN-based MIHF. PoA (Point of attachment) Endpoint of a layer 2 link that includes the MN as the other endpoint. PMIPv6 client From an IEEE 802.21 viewpoint, a mobility protocol making use of the MIH Services (i.e. an MIH User) is called client. Therefore, a PMIPv6 client on a given node (e.g., a MAG) is the PMIPv6 mobility stack of that node, which makes use of the MIH Services. Bernardos, et al. Expires April 29, 2010 [Page 5] Internet-Draft PMIPv6 & IEEE 802.21 October 2009 3. PMIPv6 (RFC 5213) and IEEE 802.21 operation This section describes how Proxy Mobile IPv6 works in an IEEE 802.21- enabled network. Although the use of IEEE 802.21 would also be helpful in single technology access network deployments, in this version of the draft we use a multiple-interface/access technology scenario and we only consider mobile-initiated handovers. Figure 1 shows an example of a multiple-access technology PMIPv6 deployment scenario (in this example WLAN and Cellular 3GPP Long Term Evolution -- LTE -- are the access networks considered). In this scenario, MNs can attach and roam using one or multiple interfaces. Note that we also depict layer-2 entities (WLAN Access Points -- APs -- and enhanced Nodes B -- eNBs) in the figure for completeness. +-----+ | LMA | +-----+ // \\ +---------//---\\-------------+ ( // \\ ) PMIPv6 domain ( // \\ ) +------//---------\\----------+ // \\ 3GPP EPC// \\ WLAN +---------+ +-------+ |S-GW/MAG1| |AR/MAG2| +---------+ +-------+ /\ /\ / \ / \ / \ / \ ----- ----- ---- ---- |eNB| |eNB| --|AP| |AP|-- -+--- ---+- | ---- ---- | | | | | << v >> << v >> (( o )) (( o )) < v > ( o ) ( o ) | | | | ----- | ----- | --|MN1|-- |MN2|-- (if2) ----- (if1) ----- (if1) Figure 1: Dual technology (WLAN & 3GPP LTE) PMIPv6 scenario Bernardos, et al. Expires April 29, 2010 [Page 6] Internet-Draft PMIPv6 & IEEE 802.21 October 2009 The equivalent IEEE 802.21-enabled scenario of Figure 1 is shown in Figure 2. The PoS entity resides in the MAG, and the PoAs are the layer-2 access points. The PMIPv6 client on the MAG plays the role of MIHF user. We next focus on the signaling for the two main PMIPv6 procedures: bootstrapping (or initial MN attachment) and MN handover. +-----+ | LMA | +-----+ // \\ +---------//---\\-------------+ ( // \\ ) PMIPv6 domain ( // \\ ) +------//---------\\----------+ // \\ 3GPP EPC// \\ WLAN +---------+ +-------+ |S-GW/MAG1| PoS1 |AR/MAG2| PoS2 +---------+ +-------+ /\ /\ / \ / \ PoA1a / \PoA1b PoA2a/ \PoA2b ------- ------- ------ ------ |eNB a| |eNB b| --|AP a| |AP b|-- --+---- ----+-- | ------ ------ | | | | | << v >> << v >> (( o )) (( o )) < v > ( o ) ( o ) | | | | ----- | ----- | --|MN1|-- |MN2|-- (if2) ----- (if1) ----- (if1) Figure 2: Dual technology (WLAN & 3GPP LTE) IEEE 802.21-enabled PMIPv6 scenario For both the initial MN's attachment and handover cases, the candidate MAG needs to detect that a new MN is on its access link, and then obtain all the parameters that are required to be included in the Proxy Binding Update (PBU) message. We only list below those where IEEE 802.21 may help: o MN-Identifier: this is a stable identifier of the MN that identifies it in the PMIPv6 domain. For instance, in an IEEE Bernardos, et al. Expires April 29, 2010 [Page 7] Internet-Draft PMIPv6 & IEEE 802.21 October 2009 802.21-enabled handover scenario, the PMIPv6 client in the MAG receives an MIH_N2N_HO_Commit.indication message, informing about the intention of the MN to perform a handover to the target network. This message contains -- among other information -- the MNIdentifier, which is the MIHF_ID of the MN that commits to perform a handover (and therefore attaches to the candidate/new MAG). The MIHF_ID can be used as MN-Identifier for PMIPv6 management and signaling purposes. According to [RFC5213], the new MAG, after detecting an MN's attachment, has to identify the MN, acquire its MN-Identifier and determine whether the network- based mobility management service needs to be offered to the MN. If so, the MAG will send a PBU message to the LMA. o Handover Indicator (HI) option. This handoff hint is required for the network to find out if the MN is either performing a handover (and which type of handover) or not (just attaching a new interface). The OldAccessRouter and IPRenewalFlag parameters contained in the MIH_Link_Up.indication message may be used to help the MAG detect the correct value to be included in the HI option. The OldAccessRouter parameter contains the Link address of old Access Router. The IPRenewalFlag parameter indicates whether the MN needs to change IP Address in the new PoA. Based on the presence and values of these two parameters, the HI can be chosen by the MAG as follows: * (OldAccessRouter and NewAccessRouter parameters are different) AND (IPRenewalFlag == TRUE) ==> HI=1 (Attachment over a new interface). If OldAccessRouter and NewAccessRouter parameters are different and IPRenewalFlag is TRUE, it indicates a new interface attachment. Therefore, the MAG has to request the LMA to create a new mobility session for the MN. * (no OldAccessRouter parameter present) AND (IPRenewalFlag == FALSE) ==> HI=2 (Handoff between two different interfaces of the mobile node). Again, the MN is not performing a handover on the same interface (the layer-2 address of the old AR is not provided) and the MN indicates that it wants to keep using the same IP address(es). This means that the MN is performing a vertical handover between two different interfaces. * (OldAccessRouter parameter present) AND (IPRenewalFlag == FALSE) ==> HI=3 (Handoff between mobile access gateways for the same interface). The MN is performing a handover from a previous PoS/MAG (the layer-2 address of the old AR is available) and the MN wants to keep using the same IP address(es). This means that the MN is performing a horizontal handover. Bernardos, et al. Expires April 29, 2010 [Page 8] Internet-Draft PMIPv6 & IEEE 802.21 October 2009 * Any other combination ==> HI=4 (Handoff state unknown). o Mobile Node Link-layer Identifier option. This identifies the attached interface of a mobile node and can be obtained from the LinkIdentifier parameter included in the MIH_Link_Up.indication message received by the PMIPv6 client on the PoS/MAG. o Access Technology Type (ATT) option. This option indicates the type of access technology by which the MN is currently attached to the MAG. This information may be obtained by the PMIPv6 client on the PoS/MAG from the LinkIdentifier parameter included in the MIH_Link_Up.indication message. There are a number of parameters required for the proper use of PMIP which are obtained from the MIH_Link_Up.indication message. The remote exchange of events in IEEE 802.21 is defined as a service based on subscription, where a network entity is able to receive remote events generated, for example, in the MN, by subscribing to these specific events through a defined set of primitives. The new MAG, in order to receive the MN's MIH_Link_Up.Indication message, must have subscribed to it previously. Note that this subscription must be done before the handover. In order to do that, we propose the following method: previously to the MN handover, the nMAG receives a message indicating that a handover is going to be performed. This message is the MIH_N2N_HO_Commit.indication and it must be replied with an MIH_N2N_HO_Commit.response before the MN performs the handover. In the MIH_N2N_HO_Commit.indication message there is the information required to contact the MN, such as the MN's MIHF_ID. Prior to send the MIH_N2N_HO_Commit.response message, the new MAG must perform the remote event subscription to the Link_Up message, by exchanging the appropriate IEEE 802.21 primitives. 4. PMIPv6 Extensions and IEEE 802.21 TBD in future revisions of this I-D. 5. IANA Considerations This document makes no request of IANA. 6. Security Considerations None. Bernardos, et al. Expires April 29, 2010 [Page 9] Internet-Draft PMIPv6 & IEEE 802.21 October 2009 7. Acknowledgments The research of Carlos J. Bernardos and Antonio de la Oliva leading to these results has received funding from the European Community's Seventh Framework Programme (FP7/2007-2013) under grant agreement n. 214994 (CARMEN project). The work of Carlos J. Bernardos has also received funding from the Ministry of Science and Innovation of Spain, under the QUARTET project (TIN2009-13992-C02-01). 8. References 8.1. Normative References [IEEE80221] ""IEEE Standard for Local and Metropolitan Area Networks - Part 21: Media Independent Handover Services", IEEE LAN/ MAN Std 802.21-2008, January 2009, http://www.ieee802.org/ 21/private/Published%20Spec/802.21-2008.pdf (access to the document requires membership). Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Media Independent Handover Services", IEEE Standard 802.21. [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. 8.2. Informative References [RFC5164] Melia, T., "Mobility Services Transport: Problem Statement", RFC 5164, March 2008. Bernardos, et al. Expires April 29, 2010 [Page 10] Internet-Draft PMIPv6 & IEEE 802.21 October 2009 Authors' Addresses Carlos J. Bernardos Universidad Carlos III de Madrid Av. Universidad, 30 Leganes, Madrid 28911 Spain Phone: +34 91624 6236 Email: cjbc@it.uc3m.es URI: http://www.it.uc3m.es/cjbc/ Antonio de la Oliva Universidad Carlos III de Madrid Av. Universidad, 30 Leganes, Madrid 28911 Spain Phone: +34 91624 8803 Email: aoliva@it.uc3m.es URI: http://www.it.uc3m.es/aoliva/ Juan Carlos Zuniga InterDigital Communications, LLC Email: JuanCarlos.Zuniga@InterDigital.com Telemaco Melia Alcatel-Lucent Bell Labs Email: Telemaco.Melia@alcatel-lucent.com Subir Das Telcordia Technologies Inc. Email: subir@research.telcordia.com Bernardos, et al. Expires April 29, 2010 [Page 11]