One document matched: draft-bernardos-netext-pmipv6-mih-00.txt
NETEXT Working Group CJ. Bernardos
Internet-Draft A. de la Oliva
Intended status: Informational UC3M
Expires: April 19, 2010 JC. Zuniga
InterDigital Communications, LLC
T. Melia
Alcatel-Lucent Bell Labs
S. Das
Telcordia Technologies Inc.
October 16, 2009
PMIPv6 operation with IEEE 802.21
draft-bernardos-netext-pmipv6-mih-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 April 19, 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 19, 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 IEEE 802.21 Media Independent Handover (MIH)
Services 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.
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 19, 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. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Bernardos, et al. Expires April 19, 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 [IEEE.802.21] 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
working group 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 19, 2010 [Page 4]
Internet-Draft PMIPv6 & IEEE 802.21 October 2009
An entity that uses the MIH SAPs to access MIHF services, and
which is responsible for initiating and terminating MIH signaling.
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 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 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 19, 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. We use a multiple-interface/access technology
scenario, although the use of IEEE 802.21 would also be helpful in
single technology access network deployments. In this version of the
draft, 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 Evolved
Packet Core -- EPC -- 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 ))
< Y > ( o ) ( o )
| | |
| ----- | ----- |
--|MN1|-- |MN2|--
(if2) ----- (if1) ----- (if1)
Figure 1: Dual technology (WLAN & 3GPP EPC) PMIPv6 scenario
Bernardos, et al. Expires April 19, 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 entitiy resides in the MAG, while the PoA entity
resides in 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 ))
< Y > ( o ) ( o )
| | |
| ----- | ----- |
--|MN1|-- |MN2|--
(if2) ----- (if1) ----- (if1)
Figure 2: Dual technology (WLAN & 3GPP EPC) 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:
Bernardos, et al. Expires April 19, 2010 [Page 7]
Internet-Draft PMIPv6 & IEEE 802.21 October 2009
o MN-Identifier: this is a stable identifier of the MN that
identifies it in the PMIPv6 domain. In an IEEE 802.21-enabled
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 attach 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 attachement, 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 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 guess
the correct value to be included in the HI option. The
OldAccessRouter parameter is optional and contains the Link
address of old Access Router. The IPRenewalFlag parameter is also
optional and indicates whether the MN needs to change IP Address
in the new PoA. Based on the presence and values of these two
options, 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
over 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 (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 19, 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 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
from the LinkIdentifier parameter included in the
MIH_Link_Up.indication message.
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.
7. Acknowledgements
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
[IEEE.802.21]
"Information technology - Telecommunications and
information exchange between systems - Local and
metropolitan area networks - Specific requirements - Media
Independent Handover Services", IEEE Standard 802.21,
Bernardos, et al. Expires April 19, 2010 [Page 9]
Internet-Draft PMIPv6 & IEEE 802.21 October 2009
January 2008.
[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.
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
Bernardos, et al. Expires April 19, 2010 [Page 10]
Internet-Draft PMIPv6 & IEEE 802.21 October 2009
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 19, 2010 [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-24 05:35:21 |