D. Corujo
Internet-Draft A. Matos
Intended status: Experimental R. Aguiar
Expires: January 13, 2008 IT Aveiro
T. Melia
J. Abeille
NEC
July 12, 2007
Problem Statement for Common Interface Support in Localized Mobility
Management
draft-corujo-ps-common-interfaces-lmm-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 13, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Corujo, et al. Expires January 13, 2008 [Page 1]
Internet-Draft PS Common Interfaces for LMM July 2007
Abstract
This memo is a problem statement on the use of link events for
enhanced handover control in network based localized mobility
management. Starting from existing solutions for fast link detection
the document aims at discussing possibilities to extend with a 2.5
layer the interface between MN and AR for handover control. The
document also presents a set of considerations and identifies
conditions where a layer 2.5 based interface offers significant
advantages compared to a pure layer three solution. The document
addresses separately scenarios for Localized Mobility Management and
scenarios involving interactions between PMIP and CMIP.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Problem Space . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. DNA and FRD with 802.21 Integration . . . . . . . . . . . 6
3.1.1. DNA and FRD considerations . . . . . . . . . . . . . . 6
3.1.2. 802.21 Integration . . . . . . . . . . . . . . . . . . 7
3.2. Localized Mobility Management . . . . . . . . . . . . . . 7
3.2.1. Proxy Mobile IPv6 . . . . . . . . . . . . . . . . . . 8
3.2.2. MN/AR Interfaces . . . . . . . . . . . . . . . . . . . 8
3.2.3. Fast Handovers for Proxy Mobile IPv6 . . . . . . . . . 9
3.3. Providing interfaces with 802.21 . . . . . . . . . . . . . 10
3.4. Issue Summary . . . . . . . . . . . . . . . . . . . . . . 11
4. Scenarios and Requirements . . . . . . . . . . . . . . . . . . 13
4.1. Localized Mobility Management Scenarios . . . . . . . . . 13
4.1.1. Boot-up . . . . . . . . . . . . . . . . . . . . . . . 13
4.1.2. Proactive handover . . . . . . . . . . . . . . . . . . 13
4.1.3. Reactive handover . . . . . . . . . . . . . . . . . . 14
4.1.4. LMP Engine as an MIH user . . . . . . . . . . . . . . 15
4.1.5. Co-located ARs and APs . . . . . . . . . . . . . . . . 15
4.1.6. Network-generated Event for Mobile Terminal
Attachment . . . . . . . . . . . . . . . . . . . . . . 16
4.1.7. Requirements . . . . . . . . . . . . . . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Informative References . . . . . . . . . . . . . . . . . . 21
8.2. Normative References . . . . . . . . . . . . . . . . . . . 22
Appendix A. Technical Annex . . . . . . . . . . . . . . . . . . . 23
A.1. MSCs for Localized Mobility Management Scenarios . . . . . 23
A.1.1. Bootstrap . . . . . . . . . . . . . . . . . . . . . . 23
A.1.2. Reactive Scenario . . . . . . . . . . . . . . . . . . 24
Corujo, et al. Expires January 13, 2008 [Page 2]
Internet-Draft PS Common Interfaces for LMM July 2007
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . . . . . 27
Corujo, et al. Expires January 13, 2008 [Page 3]
Internet-Draft PS Common Interfaces for LMM July 2007
1. Introduction
Recently, there have been proposals advocating the use of IEEE 802.21
[802.21] services supporting different mobility related procedures.
Starting from [I-D.ietf-dna-frd], where the IEEE 802.21 event service
notification system is used for fast link change detection,
[I-D.xia-netlmm-fmip-mnagno] further exploits the possibility to use
link events to improve handover procedures in environments deploying
network based localized mobility management. The fact that network
based localized mobility management protocols do not require host
modifications as described in [I-D.ietf-netlmm-nohost-ps] suggests
the design of a single interface between mobile node and access
router, technology independent, and, potentially complemented with
2.5 techniques.
In [I-D.ietf-netlmm-mn-ar-if] a first attempt to design such
interface is provided. We argue, however, that having a solution
that relies on layer three connectivity for link change detection and
consequent IP address configuration update is time consuming,
especially in environment offering real time services (e.g. VoIP).
A first attempt to speed up such procedure is provided in
[I-D.ietf-dna-frd].
We suggest to further explore this approach by complementing IP based
solutions with 2.5 (technology independent) techniques [802.21]. In
this document we explore the extension of such an interface based on
the upcoming IEEE 802.21 standard. The document aims at providing a
general overview on current draft solutions arguing the need for a
generalized interface framing existing and upcoming solutions.
Corujo, et al. Expires January 13, 2008 [Page 4]
Internet-Draft PS Common Interfaces for LMM July 2007
2. Terminology
o PoA (Point of Access) - Network side endpoint of an L2 link
including the host as the other endpoint.
o LMD (Local Mobility Domain) - A domain where mobility is
transparent to the core network.
o MIH (Media Independent Handovers) - A set of services and
procedures that enable more optimized handovers.
o MIHF (Media Independent Handovers Function) - An implementation,
both at network entities and hosts, of MIH services.
o Link-layer events - triggers, originated at the link layers,
indicating changes in sate and transmission behavior of those
layers.
o 802.21 Protocol [802.21]- A protocol that allows 802.21 services
to be exchanged remotely between MIH Functions.
o Access Router (AR) - entity responsible for managing the last hop
packet communication in the Access Network
Corujo, et al. Expires January 13, 2008 [Page 5]
Internet-Draft PS Common Interfaces for LMM July 2007
3. Problem Space
As described in Section 1 this document aims at identifying a common
problem space for the design of a MN-AR multi-purpose interface
covering fast link change detection, proactive and reactive handovers
in LMD environments (such as Proxy MIPv6 solutions, and Proxy MIPv6
solutions interacting with MIPv6). To identify similarities among
available approaches we report in the following a brief summary
focusing on the support of the link layer events and their relation
with the IEEE 802.21 upcoming standard.
3.1. DNA and FRD with 802.21 Integration
This section presents current considerations from the Detecting
Network Attachment procedure, including Fast Router Discovery with L2
support. We also present key points for 802.21 integration with DNA
and Fast Router Discovery.
3.1.1. DNA and FRD considerations
The validity of an IP configuration requires that the host checks for
link change. DNA [I-D.ietf-dna-protocol] is the procedure of
detecting that the IP subnet has changed (after L2 link change) then
initiating a new IP configuration. When the host verifies that it
has remained in the same link, it can assume its IP configuration is
still valid. Otherwise, the present one is invalid and a new
configuration must be obtained. During the process of checking for a
link change, the host may obtain some of the required configuration
information, and use it to reduce handover delay and minimize
signalling in obtaining a new IP configuration. DNA schemes are
typically run per interface and the DNA process does not include the
actual IP configuration procedure.
In order for the DNA procedure to take place, a trigger is required.
Network-layer indications can be helpful in detecting subnet changes,
but they can not always be readily available after changing its point
of attachment. Link-layer events, on the other hand, can report that
the host has established a new link-layer connection allowing the
node to probe the network for configuration changes. In
[I-D.ietf-dna-link-information] a catalogue of available link-layer
events from various access technologies is provided. More
concretely, the most important type of trigger in a DNA scheme is the
"Link Up" event, which is a notification that is delivered when a L2
connection is established on a specific link interface, and it is
capable of communicating data frames. This event can aid in
detecting a change of subnet, triggering the DNA procedure. Also,
additional information can be supplied along with the event,
containing network configuration parameters and identifiers.
Corujo, et al. Expires January 13, 2008 [Page 6]
Internet-Draft PS Common Interfaces for LMM July 2007
The importance of link-layer events is also reflected on their
source. On one hand, the event be triggered on the host and
processed thereon to trigger the DNA procedure on the host. On the
other hand, said trigger can instead be sent by the Point of Access
to the Access Router and, according to [I-D.ietf-dna-frd], trigger an
unicast Router Advertisement. In cellular environments, the use of
unicast RAs is a more cost-effective procedure than broadcasting the
RA over the wireless link. When the trigger is supplied to the
Access Router, it is even possible to obtain the said trigger without
forwarding from the Point of Access, as is the case of host
authentication to an AR in a WiMAX network. It is also possible for
the Point of Access to use the event to send a previously cached
Router Advertisement. This caching can either be done through manual
configuration, or scanning L2 frames for RA messages, and issuing a
802.21 command to the AR requesting a RA message. However, under a
PMIP environment, since the terminal has to be supplied with a RA
advertising the Home Address prefix of the terminal, it might not be
feasible to cache RAs at the PoA: the PoA will have to supply
different RAs per terminal, per home network.
3.1.2. 802.21 Integration
Regarding DNA, more specifically Fast Router Discovery, some
integration work is already under discussion. 802.21 services are
used in [I-D.ietf-dna-frd] to add fast Router Advertisement
triggering (or proxying, in case the Point of Access sends the Router
Advertisement for itself) on a Point of Access, without changing the
IPv6 standard. More concretely, the MIH event "Link Up", containing
the host's MAC address, is forwarded by the Point of Access to the
Access Router upon attachment detection. Also, a new 802.21 command
is defined for a Point of Access to request a Router Advertisement
message from an Access Router and permission to proxy the RA.
Similarly, the Access Router can use the command and MIH Protocol to
send a suitable Router Advertisement to the Point of Access and
delegate the Point of Access to deliver the Router Advertisement to a
new host upon network attachment.
3.2. Localized Mobility Management
Localized Mobility Management poses several news challenges deriving
from the stated requirements in [I-D.ietf-netlmm-nohost-req]. The
currently proposed architectures required unmodified, vanilla network
stacks. While this allows unaware mobility of the MN, it lacks in
control mechanisms, in order to provide different approaches to
mobility - reactive and proactive - that are mostly controlled by the
LMD.
Corujo, et al. Expires January 13, 2008 [Page 7]
Internet-Draft PS Common Interfaces for LMM July 2007
3.2.1. Proxy Mobile IPv6
Proxy Mobile IPv6 (PMIPv6), as explained in
[I-D.ietf-netlmm-proxymip6], is a network-based mobility management
protocol aimed at local mobility support, while reusing when possible
Mobile IPv6 (MIPv6) [RFC3775] entities and concepts. In this
protocol the mobile nodes (MN), are differentiated by an identifier
(e.g. NAI), which has an associated set of information stored on the
network, such as a profile containing the home prefix. This
information is typically kept in a policy store (e.g. AAA),
accessible by all the PMIPv6 entities in the LMD.
PMIPv6 assumes that upon L2 network attachment, the node is
authenticated. This attachment provides the necessary information
(e.g. the nodes NAI) to ensure that the network is able to retrieve
the Home Network prefix. The prefix will then be used in Router
Advertisements to the node, informing that it is on the Home Domain.
In this scenario the MN configures its Home Address on the network
interface, even when roaming across foreign networks, transforming
the visited LMD into a single link, from the node's point of view.
While it is possible to use any type of identifier as MN_ID, current
trends point to the use of MAC Address, since it is the identifier
assured to be sent upon the L2 attachment process. This is
restrictive, since the MN is restricted to the L2 address. For
instance, using a multihomed terminal, the MN_ID changes with each
interface and limits the solution space for multihoming on the LMD.
It would be desirable to have mechanisms that allow an exchange of a
pre-selected identifier during or after the L2 attachment process,
possibly using Layer 2.5 technology such as 802.21.
The Proxy Mobile Agent (PMA), located in the access router, performs
signaling on behalf of the node and is also the entity that retrieves
the MN information and sends the customized Router Advertisements,
emulating the home network behavior. The PMA mobility signaling
consists on Binding Updates to the MN's Home Agent, informing the HA
that the current Care-of Address of the registered MN is the PMA's
address. These procedures also lead to the establishment of tunnels
between HA and PMA.
3.2.2. MN/AR Interfaces
Draft [I-D.ietf-netlmm-mn-ar-if] specifies a mechanism to trigger the
localized mobility management protocol while terminals roam across
access routers belonging to the same LMD. While it focuses on
initial proposed protocols for NetLMM, it could be applied to other
LMM protocols. The proposed interfaces assume that there is no
specific layer two solution available on the terminal side and
Corujo, et al. Expires January 13, 2008 [Page 8]
Internet-Draft PS Common Interfaces for LMM July 2007
exposes a solution based on existing IP protocols, namely SEND
[RFC3971], CGA [RFC3972] and DNA [I-D.ietf-dna-protocol].
In case of stateless auto-configuration, when a mobile terminal
powers on in a NetLMM domain it generates a link local address based
on its public key (CGA). Upon ND exchange (DAD) the access router
updates the LMA for routes setup using the MN's public key as MN_ID.
After DAD is completed, the RS/RA exchange allows the MN to configure
one or more global CGA addresses which need to be all registered in
the LMA. In case of DHCP the main difference is the use of DHCP
SOLICIT/REPLY messages for global addresses configuration. While
abstractions provided by extended interfaces, such as 802.21, cannot
play a big role in a boot-up scenario because the DAD procedures need
to be performed, they can enhance the information exchange.
Furthermore, once the address is correctly assigned and granted
access to the LMD then technologies such as 802.21 could be of great
help because there is no need to further perform DAD mechanisms,
there is just the need to detect that the link did change and trigger
the LMP engine.
When the terminal moves into a NetLMM domain it first performs a link
detection as per [I-D.ietf-dna-protocol]. Upon link detection the
terminal discards the current address, performs DAD on the link local
and configures global IPv6 addresses by means of stateless auto-
configuration or via DHCP. In this scenario, the terminal needs to
perform DAD to defend the address while entering into the NetLMM
domain. But, even in these non proactive conditions, common
interfaces such as 802.21, can help by aiding the link detection
process as defined in [I-D.ietf-dna-frd] by means of fast Router
Advertisements.
MN/AR interfaces entirely based on the Neighbor Discovery Protocol
(NDP) [RFC2461] provide a consistent platform regardless of L2
technology. Furthermore, if secured with SEND, it also has the added
value of security. But, while security is a very important issue,
the MN/AR interface must address a wider set of issues, such as
proactive and reactive handovers, alongside with information
provisioning interfaces, PoA information exchange and MN
identification. They also can be used to speedup the attachment
process.
3.2.3. Fast Handovers for Proxy Mobile IPv6
In [I-D.xia-netlmm-fmip-mnagno] the possibility of using link layer
events to improve handover procedures in environments deploying
network based localized mobility management is exploited, as well as
using Fast MIPv6 [RFC4068] PAR-NAR signalling to improve handover
performance. This scheme relies on 802.21 link layer events to
Corujo, et al. Expires January 13, 2008 [Page 9]
Internet-Draft PS Common Interfaces for LMM July 2007
trigger the establishment of a tunnel between the PAR and the NAR,
prior to handover. Upon attachment to the new access point, another
link layer event triggers the NAR to send a Router Advertisement to
the host, facilitating the MN to send packets.
3.3. Providing interfaces with 802.21
The IEEE 802.21 Media Independent Handover [802.21] standard provides
with a Media Independent Function which can abstract different access
technologies to higher level entities (or MIH-users), and contains a
set of services that can be used to provide input to the DNA
procedures. The Event Service provides event classification,
filtering and reporting. The Command Service enables MIH users to
manage and control link behavior. Information services can provide
information to a MIH-User using a request/reply mechanism.
Furthermore, these services can either operate on a local-stack
level, or remotely, between different network entities, using the MIH
Protocol [I-D.hepworth-mipshop-mih-problem-statement]
MIH-users can also register for receiving specific events, allowing
them to be collected not only to the IP stack, triggering DNA
procedures, but also to other entities such as a Localized Mobility
module. MIH-enabled entities can announce and discover MIH
capabilities, allowing MIH-users to identify events to which they can
register, and obtain link layer information. They can also verify
which link commands are supported, enabling MIH-users to control
lower layers at remote entities.
ACCESS ROUTER
..................
| ........ |
| | LMP | |
| |ENGINE| |
| `'''''' |
| / \ |
| MIH / \ |
|EVENT | | |
LINK EVENT | | | |
____________ +----------+ |
FROM MN \| MIH | |
OR PoA ____________/| FUNCTION | |
| +----------+ |
..................
Figure 1: MIH User receiving remote link layer event
802.21 can also help dealing with access technologies issues
identified in [RFC4135]. For example, regarding the unpredictable
Corujo, et al. Expires January 13, 2008 [Page 10]
Internet-Draft PS Common Interfaces for LMM July 2007
radio conditions that in one instant produce a link-layer event that,
in the next instant, is no longer viable, 802.21 allows the
configuration of thresholds that can trigger events whenever these
are crossed. This functionality allows, for example, events to
reflect situations long enough for the DAD procedure to be executed.
Optionally, these events can also be reported on a periodic basis.
Regarding identifiers, each entity's MIHF has an identifier used to
identify MIHF endpoints involved in a 802.21 protocol transaction.
This MIH ID, for example, allows the 802.21 protocol to be transport
agnostic, because it involves two unique identifiers. This MIHF ID
can be assigned to the MIHF during the configuration process. The
MIHF can be viewed as an entity which abstracts the underlying
technologies available at a host, allowing it to surpass a limitation
of identifying the host by a single L2 address, which can be limiting
in multihomed hosts scenarios.
3.4. Issue Summary
o Using the Link Layer address is the common procedure to uniquely
identify a node. It would be preferable to have a common
interface to exchange the MN Identifier, for more flexible
solutions to problems such as Multihoming and Security.
o Context transfer on proactive, and even reactive, handovers is
desired feature. Performing it at the network layer is subversive
to the NetLMM requirements [I-D.ietf-netlmm-nohost-req], and
should be considered on a lower layer (2.5) and as part of the
standard operation procedure.
o There is the need to clearly define at least the interfaces
between the MN and Access Routers, either PMAs or MAGs, to enable
extension for proactive and reactive handover scenarios to work,
regardless of the LMD protocol. This also requires the need to
understand what are the common interfaces and how they should be
provided.
o RA caching is not considered worthy due to PMIP mechanisms: the
Router Advertisement that is sent to the terminal always includes
the host's Home Address. Due to the multiple number of terminals
that can handover to a specific Access Point, all with their own
Home Address being advertised, we believe it is not worthy to
cache Router Advertisements at the Access Point.
o 802.21 allows MIH-users to register for link layer events. If no
restrictions are posed for this matter, a single event can trigger
more than one high level entity, stimulating different behaviors
which will proceed in parallel causing concurrency issues. For
Corujo, et al. Expires January 13, 2008 [Page 11]
Internet-Draft PS Common Interfaces for LMM July 2007
example, the Link Up event might be used to trigger both the IP
stack (for DNA) and the LMP Engine.
o Another issue that has to be considered is the 802.21 Capability
Discovery procedure that is required for hosts and network
entities to verify which events and commands are available.
Although L2 management frames can be used to broadcast this
capability, certain events may need to be forwarded to the network
entities in the exact time of attachment (i.e., the Link Up
event), which indicates that previous event registration already
occurred.
Corujo, et al. Expires January 13, 2008 [Page 12]
Internet-Draft PS Common Interfaces for LMM July 2007
4. Scenarios and Requirements
This section provides scenarios and requirements for enabling the
MN/AR interface with 802.21 mechanisms under a common framework.
4.1. Localized Mobility Management Scenarios
The scenarios presented in this section consider a terminal
booting-up inside an LMD, proactive and reactive handovers, and the
LMP engine as an MIH user. Also, scenarios where APs and ARs are co-
located are also considered.
4.1.1. Boot-up
The boot-up scenario encompasses a host which has activated its
interface(s) inside an LMD. In this case, it can be assumed that the
host contains no information from a previously connected subnet
(i.e., network prefix, gateway, etc.).
In this scenario, the host should be able to supply link layer events
(such as supplying the list of possible points of attachment detected
at boot-up, using for example the Link Detected event), and
indications of successful attachments if they occur (using for
example the Link Up event). Also, the PoA to which the terminal
associates can also trigger link events to the AR, supplying
information regarding the host.
4.1.2. Proactive handover
A proactive handover scenario is verified when the terminal is able
to supply to the AR that a new AP was found, and that actual
conditions at the current PoA are deteriorating.
Corujo, et al. Expires January 13, 2008 [Page 13]
Internet-Draft PS Common Interfaces for LMM July 2007
+-----+ Inter AR Comm. +-----+
| oAR | <-----------------> | nAR |
+-----+ +-----+
| |
| |
| |
| |
+----+ +----+
|oPoA| |nPoA|
+----+ +----+
^
|
..............
| Event w/ |
|{nAR_ID, | +--+
| LINK_ |--|MN| ----------->
| CONDITIONS}| +--+ Movement
..............
Figure 2: Predictive handover
This information can be obtained through link layer events detected
at the host, and be used by the oAR to transfer information from the
nAR. Also, link-layer information can be directly sent from the oPoA
to the nPoA. This information is available to the terminal upon
attachment to the nPoA. This attachment can be indicated by a Link
Up event (supplied by either the host of the nPoA), initiating DNA
procedures.
4.1.3. Reactive handover
In a reactive handover scenario, the PoA can supply a link layer
event indicating attachment.
Corujo, et al. Expires January 13, 2008 [Page 14]
Internet-Draft PS Common Interfaces for LMM July 2007
+---+
|AAA|
+---+
^
| Get Information +-----+
------------------ | nAR |
| +-----+
v |
+-----+ |
| oAR | |
+-----+ |
............
| Event w/ |
|{MN_NAI, |
| previous |
| net_info}|
............
|
|
+--+ +----+
|MN|------------|nPoA|
+--+ +----+
Figure 3: Reactive handover
Also, it can provide information from the previous network
configuration to the AR, which can trigger it to obtain further
information from the previous AR or from some kind of AAA entity, or
use that information to more rapidly infer the host's new
configuration.
4.1.4. LMP Engine as an MIH user
Having a LMP Engine as the high-level entity that collects the
terminal's and PoAs link layer events, can enhance localized mobility
mechanisms to operate based on information supplied at L2 level.
4.1.5. Co-located ARs and APs
Co-located ARs and APs is an envisioned possibility in today's
network design. An envisioned framework where MIH-users register for
receiving events allows flexibility on which network points they can
reside. Also, when APs and ARs are not co-located, the MIHF can work
as a kind of proxy, forwarding link layer events from the terminal to
the AR.
Corujo, et al. Expires January 13, 2008 [Page 15]
Internet-Draft PS Common Interfaces for LMM July 2007
4.1.6. Network-generated Event for Mobile Terminal Attachment
L2 link attachment can be detected at both the terminal and the
network point of attachment. As stated previously, 802.21 supplies
an event, Link_Up, indicating a sucessful attachment. Regarding
PMIPv6, the usage of 2.5 mechanisms to detect network attachment is
preferable to L3 only mechanisms. Also, the usage of these
mechanisms, like for example the link layer events, by the network
entities involved in link attachment is motivated by the requirement
to avoid the involvement of the MN in PMIPv6 triggering. In a 802.21
point-of-view, events are sent from their source towards an entity
that has previously registered to receive them. In case of an
handover where the reception of this event is required at the target
network, the time required for the registry allowing the reception of
the event would be time-consuming. Having the point of attachment
detecting the terminals' connection and reporting it to the required
entity, allows the triggering of the required PMIPv6 mechanisms.
However, it is worth noting that an identifier is required by PMIPv6
to identify the terminal, which has to be technology independent.
The IEEE 802.21 standard considers the Link_Up event as only
containing the MAC address of the terminal, which does not satisfy
the technology-independent requirement. As such, it is required to
extend this network-generated event with an identifier (e.g., such as
NAI) to be provided to the MAG, which is not defined in the standard.
4.1.7. Requirements
This section reports requirements inferred from the previous
scenarios.
o This framework should accommodate with future instances of the
NetLMM protocol, and be flexible enough to allow and support
possible optimizations of the NetLMM procedures.
o This framework does not aim at replacing L3 procedures rather to
improve them by facilitating the information exchange between the
host and the AR even prior to full network configuration.
o While section Section 4.1 presents possible deployments of the
MIHF and its relation to the upper layers (IP stack, LMP engine),
a more clear communication model needs to be agreed and specified.
o Previous sections described the use of several identifiers at
different levels (e.g. L2 identifiers in LMP protocols, MIHF ID
for 802.21). To improve protocol interaction it would be
desirable to align identifiers under a common policy.
Corujo, et al. Expires January 13, 2008 [Page 16]
Internet-Draft PS Common Interfaces for LMM July 2007
o The NAI should be used as the 802.21 MIHF ID, in order to align
the Media Independent Interfaces, with the specific LMM
interfaces, both on the network side and on the host side.
o Link layer events have to be carefully registered by whoever can
use them to trigger procedures. A single event can be forwarded
to more than one high level entity, inducing parallel behavior
that might not be desirable.
o The host must be able to store the previous network configuration
information, both for detecting subnet changes upon attachment,
and also to report it to the nAR upon a reactive handover.
o Sufficient authentication of devices supplying link-layer events
has to be considered. For example, reachibility and attachment
notifications may be falsely asserted by an attacker.
o It is required that network-generated 802.21 Link_Up events to
contain a technology-independent identifier of the terminal, to be
supplied to the MAG, for the realization of PMIPv6 operations.
Corujo, et al. Expires January 13, 2008 [Page 17]
Internet-Draft PS Common Interfaces for LMM July 2007
5. Security Considerations
As stated in [RFC4135] unsufficiently authenticated devices can
originate wrong events, causing unecessary signalling and
configuration on other devices, and making a host preferentially
select a particular configuration or network access. The problem
statement described herein focuses on the use of 802.21 mechanisms to
complement layer three solutions such as the SEND/CGA approach. A
framework considering the approaches defined here should not affect
in any way the well established security mechanisms.
Also, part of the upcoming work considering the mechanisms involved
in the framework is to identify potential problems, and to consider
other on-going work. For example, security solutions being developed
within the IEEE 802.21 standard, envolving authentication and
freshness of link-layer information as well as transport, are assumed
and have to be considered. Although the framework considers layer
two information, in case it is deemed to rely on layer three
transport, the MIPSHOP Design Team is expected to draw a solution for
MIH transport.
Lastly, another issue is the binding of identifiers to public keys,
such as in the case of SEND/CGA.
Corujo, et al. Expires January 13, 2008 [Page 18]
Internet-Draft PS Common Interfaces for LMM July 2007
6. IANA Considerations
This document makes no request of IANA.
Corujo, et al. Expires January 13, 2008 [Page 19]
Internet-Draft PS Common Interfaces for LMM July 2007
7. Acknowledgements
This work is partly funded by the Daidalos project, a research
project supported by the European Commission under its Sixth
Framework Program. The views and conclusions contained herein are
those of the authors and should not be interpreted as necessarily
representing the official policies or endorsements, either expressed
or implied, of the Daidalos project or the European Commission.
Corujo, et al. Expires January 13, 2008 [Page 20]
Internet-Draft PS Common Interfaces for LMM July 2007
8. References
8.1. Informative References
[I-D.hepworth-mipshop-mih-problem-statement]
Hepworth, E., "Media Independent Handovers: Problem
Statement",
draft-hepworth-mipshop-mih-problem-statement-02 (work in
progress), June 2006.
[I-D.ietf-dna-frd]
Choi, J., "Fast Router Discovery with L2 support",
draft-ietf-dna-frd-02 (work in progress), August 2006.
[I-D.ietf-dna-link-information]
Yegin, A., "Link-layer Event Notifications for Detecting
Network Attachments", draft-ietf-dna-link-information-06
(work in progress), February 2007.
[I-D.ietf-dna-protocol]
Kempf, J., "Detecting Network Attachment in IPv6 Networks
(DNAv6)", draft-ietf-dna-protocol-06 (work in progress),
June 2007.
[I-D.ietf-netlmm-mn-ar-if]
Narayanan, S. and J. Laganier, "Network-based Localized
Mobility Management Interface between Mobile Node and
Mobility Access Gateway", draft-ietf-netlmm-mn-ar-if-02
(work in progress), May 2007.
[I-D.ietf-netlmm-nohost-ps]
Kempf, J., "Problem Statement for Network-based Localized
Mobility Management", draft-ietf-netlmm-nohost-ps-05 (work
in progress), September 2006.
[I-D.ietf-netlmm-nohost-req]
Kempf, J., "Goals for Network-based Localized Mobility
Management (NETLMM)", draft-ietf-netlmm-nohost-req-05
(work in progress), October 2006.
[I-D.ietf-netlmm-proxymip6]
Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6",
draft-ietf-netlmm-proxymip6-01 (work in progress),
June 2007.
[I-D.xia-netlmm-fmip-mnagno]
Xia, F. and B. Sarikaya, "Mobile Node Agnostic Fast
Corujo, et al. Expires January 13, 2008 [Page 21]
Internet-Draft PS Common Interfaces for LMM July 2007
Handovers for Proxy Mobile IPv6",
draft-xia-netlmm-fmip-mnagno-01 (work in progress),
July 2007.
8.2. Normative References
[802.21] "Draft IEEE Standard for Local and Metropolitan Area
Networks: Media Independent Handover Services", IEEE
P802.21 D5.00, April 2007.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005.
[RFC4068] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068,
July 2005.
[RFC4135] Choi, JH. and G. Daley, "Goals of Detecting Network
Attachment in IPv6", RFC 4135, August 2005.
Corujo, et al. Expires January 13, 2008 [Page 22]
Internet-Draft PS Common Interfaces for LMM July 2007
Appendix A. Technical Annex
This section presents possible generic signalling flows for the
considerations described in this draft, in respect to Bootstrap and
Reactive scenarios.
Relating to Proactive scenarios, a solution will be considered at a
later version of this draft.
A.1. MSCs for Localized Mobility Management Scenarios
A.1.1. Bootstrap
+----+ +----+ +----+ +----+ +----+ +----+
| MT | | AP1| |MAG1| |MAG2| | AP2| | AAA|
+----+ +----+ +----+ +----+ +----+ +----+
| | | | | |
+-+-------+-+ | | | |
|L2 Attach. | | | | |
+-+-------+-+ | | | |
|1. Router Sol. | | | |
|-------+------>| | | |
| | | 2. GET_MN_PROFILE | | |
| | |---------------------------+--------+-------->|
| | | 3. SEND_MN_PROFILE | | |
| | |<--------------------------+--------+---------|
|2. Router Adv. | | | |
|<------+-------| | | |
+-+-------+-------+-+ | | |
| MIH Capability | | | |
| Discovery Negotia.| | | |
+-+-------+-------+-+ | | |
|3. MIH_Registration.req | | |
|-------+------>| | | |
|4. MIH_Registration.resp | | |
|<--------------| | | |
|5. MIH_Event_Subscription.req | | |
|-------------->| | | |
|6. MIH_Event_Subscription.resp | | |
|<--------------| | | |
| | | | | |
Figure 4: Bootstrap
Corujo, et al. Expires January 13, 2008 [Page 23]
Internet-Draft PS Common Interfaces for LMM July 2007
A.1.2. Reactive Scenario
+----+ +----+ +----+ +----+ +----+ +----+
| MT | | AP1| |MAG1| |MAG2| | AP2| | AAA|
+----+ +----+ +----+ +----+ +----+ +----+
| | | | | |
+--------------------------------------------------------+ |
| L2 ATTACHMENT | |
+--------------------------------------------------------+ |
| | | | +--+--+-+ |
| | | | |Detect | |
| | | | |Attach.| |
| | | | +--+--+-+ |
| | | |1. Link_Up.ind |
| | | |<-------| |
| | | | 2. GET_MN_PROFILE|
| | | | |-------->|
| | | |3. SEND_MN_PROFILE|
| | | | |---------|
| | |4. Neighbor Solicitation | | |
|<------+-------+---------------------------| | |
| | |5. Neighbor Advertisement | | |
|-------+-------+-------------------------->| | |
| | |6. RADVD | | |
|<------+-------+---------------------------| | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
Figure 5: Reactive Scenario
Corujo, et al. Expires January 13, 2008 [Page 24]
Internet-Draft PS Common Interfaces for LMM July 2007
Authors' Addresses
Daniel Corujo
IT Aveiro
Campus Universitario de Santiago
Aveiro P-3810-193
Portugal
Phone: +351 234 377900
Fax: +351 234 377901
Email: dcorujo@av.it.pt
Alfredo Matos
IT Aveiro
Campus Universitario de Santiago
Aveiro P-3810-193
Portugal
Phone: +351 234 377900
Fax: +351 234 377901
Email: alfredo.matos@av.it.pt
Rui L. Aguiar
IT Aveiro
Campus Universitario de Santiago
Aveiro P-3810-193
Portugal
Phone: +351 234 377900
Fax: +351 234 377901
Email: ruilaa@ua.pt
Telemaco Melia
NEC Europe Network Laboratories
Kufuerstenanlage 36
Heidelberg 69115
Germany
Phone: +49 6221 4342 142
Email: telemaco.melia@netlab.nec.de
Corujo, et al. Expires January 13, 2008 [Page 25]
Internet-Draft PS Common Interfaces for LMM July 2007
Julien Abeille
NEC Europe Network Laboratories
Kufuerstenanlage 36
Heidelberg 69115
Germany
Phone: +49 6221 4342 115
Email: julien.abeille@netlab.nec.de
Corujo, et al. Expires January 13, 2008 [Page 26]
Internet-Draft PS Common Interfaces for LMM July 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Corujo, et al. Expires January 13, 2008 [Page 27]