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]