NetLMM Working Group J. Abeille
Internet-Draft M. Liebsch
Expires: November 24, 2007 NEC Network Laboratories
May 23, 2007
Route Optimization for Proxy Mobile IPv6
draft-abeille-netlmm-proxymip6ro-00.txt
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 November 24, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abeille & Liebsch Expires November 24, 2007 [Page 1]
Internet-Draft Proxy Mobile IPv6 RO May 2007
Abstract
The IETF is specifying a protocol for network-based localized
mobility management, which takes basic operation for registration,
tunnel management and de-registration into account. This document
specifies a protocol for route optimization in networks, which
support network-based mobility management. The specified protocol
focuses on efficient set up and maintenance of a route optimized path
between two mobile nodes and suits complex mobility scenarios as well
as networks with multiple mobility anchors.
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology and Functional Components . . . . . . . . . . . . 6
4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 7
4.1. General procedure . . . . . . . . . . . . . . . . . . . . 7
4.2. Route Optimization - Direct Mode . . . . . . . . . . . . . 8
4.2.1. RO Setup Procedure . . . . . . . . . . . . . . . . . . 8
4.2.2. RO Handover Procedure . . . . . . . . . . . . . . . . 10
4.3. Route Optimization - Proxy Mode . . . . . . . . . . . . . 12
4.3.1. RO Setup Procedure . . . . . . . . . . . . . . . . . . 12
4.3.2. RO Handover Procedure . . . . . . . . . . . . . . . . 14
5. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 17
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7. Normative References . . . . . . . . . . . . . . . . . . . . . 19
Appendix A. MAG-local Route Optimization . . . . . . . . . . . . 20
Appendix B. Early State Activation (ESA) Policy . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . . . 23
Abeille & Liebsch Expires November 24, 2007 [Page 2]
Internet-Draft Proxy Mobile IPv6 RO May 2007
1. Requirements notation
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 [RFC2119].
Abeille & Liebsch Expires November 24, 2007 [Page 3]
Internet-Draft Proxy Mobile IPv6 RO May 2007
2. Introduction
The NetLMM WG is specifying a protocol for network-based localized
mobility management (NetLMM), taking basic support for registration,
de-registration and handover into account in a first protocol
release. The specification of extensions and optimization is for
further study and subject for either being incorporated into future
versions of the protocol or specified in separate documents. In
scope of the base protocol specification is the set up and
maintenance of a forwarding tunnel between an MN's Mobility Access
Gateway (MAG) and its selected Local Mobility Anchor (LMA). Data
packets will always traverse the MN's MAG and its LMA, irrespective
of the location of the MN's remote communication endpoint. Even
though two communicating MNs might be located close to each other or
within the same local mobility domain, packets will traverse the MNs'
LMA(s).
This document specifies a protocol for route optimization in networks
which enable mobility and reachability to nodes by means of network-
based mobility management. Even though the concept behind the
proposed protocol is agnostic to the details of the NetLMM protocol,
this document focuses on the operation of the protocol with Proxy
MIPv6 [I-D.ietf-netlmm-proxymip6] as base protocol for network-based
mobility.
Control for route optimization in Mobile IPv6 is assigned to MNs and
Correspondent Nodes (CNs). MNs can send Binding Update (BU)
signaling to a CN to create a binding between the MN's home address
(HoA) and its care-of address (CoA) at the CN. [RFC3775] specifies
the Return Routability Test procedure between the CN and the MN to
help validate an MN's binding, as a CN might not have a security
association (SA) with the MN. Key concept of PMIPv6 is to relocate
the responsibility for maintaining a node's binding on the LMA from
the client (MN) to the functional entity MAG, which is co-located
with the infrastructure's access routers. To create and update a
binding at the MN's LMA, the MAG sends a Proxy BU (PBU) to the MN's
LMA and receives the LMA's Proxy BACK (PBACK) on behalf of the MN.
The binding establishes a valid tunnel for routing the MN's data
packets from the MAG to the LMA (uplink) and from the LMA to the MAG
(downlink). Relocating full control for route optimization from the
client to the MAG function according to the PMIPv6 architecture is
possible, but might not be the optimal approach. The set up and
maintenance of a route optimized path in network-based mobility
scenario is considered different from client-based mobility. This
document focuses on the establishment of a route optimized path
between two nodes, which are attached to the network by means of
PMIPv6. The set up of an optimized route between an MN's MAG and a
CN is not considered, as it reveals the address of the MN's MAG,
Abeille & Liebsch Expires November 24, 2007 [Page 4]
Internet-Draft Proxy Mobile IPv6 RO May 2007
which can be mapped to the MN's location. Furthermore, it might be
against an operator's policy to reveal address information of its
infrastructure's network nodes. The MIPv6 Return Routability Test
procedure is not considered either, as the two MN's MAGs might share
an SA to protect signaling between MAGs. An alternative approach is
proposed to avoid relying on an SA between MAGs.
This protocol aims at efficient set up and maintenance of a route
optimized path between two MNs' MAGs, while taking difficult mobility
scenarios into account. Such scenarios comprise the set up of route
optimization between two MNs which are registered with different
LMAs, and the maintenance of the route optimized path in case one or
both terminals hand over. To coordinate the set up and maintenance
of the route optimized path efficiently, this protocol introduces the
function Route Optimization Controller (RO controller), which is
assigned to LMAs. During the set up of the route optimized path, one
LMA is dynamically selected as active RO controller. In case the two
MNs are registered with different LMAs, only one LMA, which has the
active RO controller function assigned for the associated route
optimized path, will coordinate the maintenance of the RO path and
the establishment of the RO states on the MAG(s) upon handover.
Abeille & Liebsch Expires November 24, 2007 [Page 5]
Internet-Draft Proxy Mobile IPv6 RO May 2007
3. Terminology and Functional Components
o RO - Route Optimization
o RO Communication - RO focus is on data exchange between two mobile
nodes, MN1 and MN2, which are each registered in a NetLMM domain
(This includes the case where MN1 and MN2 are registered in two
different domains). Route optimized traffic goes from MN1 to
MAG1, then from MAG1 to MAG2 and from MAG2 to MN2 as well as vice
versa without traversing any LMA.
o RO Association - An association between MAG1 and MAG2, between
which RO is set up and maintained. To set up an association,
signaling will be used to create RO states at each MAG. The
association and state information can include MN profile data.
o RO Setup Trigger - This function is assigned to a network entity,
which first detects that RO can be established between the MAGs of
two communicating MNs.
o RO Update Trigger - When RO has been set up between MN1 and MN2
and one of them or even both initiate a handover, RO states need
to be updated or established. The relevant RO update trigger
function is assigned to an entity, which detects that RO states
need to be updated.
o RO Controller - The relevant RO controller functional entity for a
RO communication is selected the first time RO is set up between a
pair of MNs. In this protocol, the relevant active RO control
function is assigned to either MN1's or MN2's mobility anchor.
The entity which has been selected as active RO controller remains
anchored as controlling entity for the duration of the route
optimized communication and the lifetime of associated RO states.
Abeille & Liebsch Expires November 24, 2007 [Page 6]
Internet-Draft Proxy Mobile IPv6 RO May 2007
4. Protocol Operation
4.1. General procedure
When MN1 initiates traffic towards MN2, the traffic is routed via
MN1's MAG and LMA (Figure 1). Either MN1's MAG or the LMA can detect
that a route optimized path can be set up between the two MNs. As an
example, detection can be based on the two MNs' IP address or the
associated MAGs' IP address. Accordingly, either the MAG or the LMA
takes over the role of the RO setup trigger. In the following
description, the LMA will serve as RO setup trigger. During the set
up phase of the route optimized path, either MN1's LMA (LMA1) or
MN2's LMA (LMA2) will be selected as active RO controller for this
particular RO association. In case both MNs are registered with the
same LMA, this single LMA will serve as RO controller. The LMA,
which has the active RO controller function assigned, coordinates the
set up of the route optimized path and associated signaling with the
relevant MAG(s). After the route optimized path has been set up
between the two MNs' MAGs, one or both MNs might hand over to a
different MAG. In that case, the LMA, which serves as active RO
controller for this particular RO association, coordinates the re-
establishment of the RO states on the relevant MAGs.
Internet Backbone
: :
: :
| |
+----+ +----+
|LMA1|--------------|LMA2|
+----+ +----+
| |
| |
+----+ +---------+----+
| | |
+----+ +----+ +----+
|MAG1| |MAG2| |MAG3|
+----+ +----+ +----+
: :
+---+ +---+
|MN1| |MN2|
+---+ +---+
Figure 1: Reference architecture for route optimization in NetLMM
The protocol supports two modes of operation, the Direct Mode and the
Proxy Mode. In Direct Mode, the two relevant MAGs can exchange
Abeille & Liebsch Expires November 24, 2007 [Page 7]
Internet-Draft Proxy Mobile IPv6 RO May 2007
signaling to set up and maintain RO states for a particular pair of
MNs. This might require these MAGs to share an SA to protect
signaling messages. Setting up SAs between MAGs for route
optimization is different from an SA between neighbor access routers
to allow protection of handover related signaling. For route
optimization, all relevant MAGs must share an SA, independent of
whether or not they are geographically adjacent. This might impact
the amount of SA-related states on each MAG. If this is not an
issue, the protocol's Direct Mode allows MAGs to exchange signaling
directly. Alternatively, the Proxy Mode can be operated, where only
LMAs exchange signaling with MAGs to set up and maintain RO states.
Inter-MAG signaling is not required in a system which operates the
Proxy Mode for route optimization. This section describes the two
modes separately, taking initial set up as well as maintenance of a
route optimized path in case of a handover into account.
Furthermore, description of both modes distinguish setting up a route
optimized path between two MNs which are registered with the same LMA
from a scenario where both MNs are registered with different LMAs.
This document specifies the following new conceptual messages for
route optimization. All messages need to be acknowledged by means of
an associated Ack message. Ack messages carry a status code field.
o RO Initiate - This message is sent from an LMA to inform another
entity (either an LMA or a MAG, depending on the scenario) that it
has to initiate or continue a RO procedure. By default, the
receiving entity should create but not activate any forwarding
states for the route optimized path.
o RO Setup - This message is sent from an LMA (in the proxy mode) or
a MAG (in the direct mode) to a MAG to activate or update RO
forwarding states for a particular RO association.
o RO Report - This message is used to inform about the result of
setting up RO states on a MAG.
4.2. Route Optimization - Direct Mode
4.2.1. RO Setup Procedure
In all scenarios, MN1 initiates traffic to MN2.
In Figure 2, both MNs are registered with the same LMA (LMA1). The
LMA detects, that route optimization can be set up, hence, serves as
RO setup trigger [T]. As both MNs are registered with the same LMA,
LMA1 serves as active RO controller (ROC). The LMA sends the RO
Initiate message to MAG2. This message carries the ID and Home
Network Prefix of MN1, the IP address of MAG1 as well as the ID of
Abeille & Liebsch Expires November 24, 2007 [Page 8]
Internet-Draft Proxy Mobile IPv6 RO May 2007
MN2. After MAG2 has acknowledged the RO Initiate message, it sends
the RO Setup message to MAG1, carrying the ID of MN1 and MN2, as well
as the Home Network Prefix of MN2. MAG1 acknowledges the RO Setup
message. RO states are now established on MAG1 and MAG2. The result
of the set up is reported to the RO controller by means of a RO
Report message.
+----+ +----+ +----+
|MAG1| |LMA1| |MAG2|
+----+ +----+ +----+
| | |
| [T] |
| (ROC) |
| | |
| |-----RO Init----->|
| |<--RO Init Ack----|
| | |
|<---------------RO Setup--------------|
|--------------RO Setup Ack----------->|
| | |
| |<---RO Report-----|
| |--RO Report Ack-->|
| | |
Figure 2: RO Direct Mode - One relevant LMA in the topology
Figure 3 illustrates the set up of a route optimized path between two
MNs which are registered with different LMAs. MN1 is registered with
LMA1, MN2 is registered with LMA2. As MN1 initiates traffic, LMA1
detects the possibility to set up a route optimized path for this
communication [T], but does not know the IP address of MAG2. It
sends a RO Initiate message to LMA2, which carries information about
MAG1's IP address, MN1's ID and Home Network Prefix as well as the
Home Network Prefix of MN2. During this message handshake between
LMA1 and LMA2, one LMA can be selected as active RO controller for
this particular RO association. In this example, LMA2 is selected as
RO controller. Further set up of RO states is similar to Figure 2.
The only difference is that LMA2 should inform LMA1, who triggered
route optimization, of the procedure's result, which is done by means
of the RO Report message.
Abeille & Liebsch Expires November 24, 2007 [Page 9]
Internet-Draft Proxy Mobile IPv6 RO May 2007
+----+ +----+ +----+ +----+
|MAG1| |LMA1| |LMA2| |MAG2|
+----+ +----+ +----+ +----+
| | | |
| [T] | |
| | (ROC) |
| | | |
| |------RO Init---->| |
| |<---RO Init Ack---| |
| | |----RO Init---->|
| | |<--RO Init Ack--|
|<-----------------------RO Set-----------------------|
|----------------------RO Setup Ack------------------>|
| | |<--RO Report----|
| | |-RO Report Ack->|
| |<----RO Report----| |
| |--RO Report Ack-->| |
| | | |
Figure 3: RO Direct Mode - Two relevant LMAs in the topology
4.2.2. RO Handover Procedure
This section specifies the signaling to maintain RO states in a
handover case. Figure 4 refers to the case where both MNs are
registered with the same LMA (LMA1). When LMA1 receives the Proxy BU
(PBU) from MN1's new MAG1 (nMAG1), it knows that RO states at MAGs
need to be updated (at MAG2) and established (at nMAG1). As LMA1
represents the RO trigger function as well as the active RO
controller for this RO association, LMA1 can send the RO Initiate to
nMAG1 to initiate the establishment of RO states. RO states on pMAG1
might expire or be explicitly deleted with MN1's Binding Update List
(BUL) entry. Whereas nMAG1 established the RO states, existing
states in MAG2 are updated through this procedure. The remaining
procedure is according to Figure 2.
Abeille & Liebsch Expires November 24, 2007 [Page 10]
Internet-Draft Proxy Mobile IPv6 RO May 2007
+-----+ +-----+ +----+ +----+
|nMAG1| |pMAG1| |LMA1| |MAG2|
+-----+ +-----+ +----+ +----+
| | | |
| | (ROC) |
| | [T] |
|----------------- PBU- ------------->| |
|<----------------PBAck --------------| |
| | | |
| | | |
|<----------------RO Init-------------| |
|---------------RO Init Ack---------->| |
| | | |
| | | |
|-------------------------RO Setup -------------------->|
|<----------------------RO Setup Ack--------------------|
| | | |
| | | |
|----------------RO Report----------->| |
|<-------------RO Report Ack----------| |
| | | |
| | | |
Figure 4: RO Direct Mode - One relevant LMA in the topology, MN1
handover
Figure 5 illustrates the case where MN1 and MN2 are registered with
different LMAs. Again, MN1 initiates a handover from pMAG1 to nMAG1,
which results in nMAG1 sending a PBU to LMA1. In this scenario, we
assume that LMA2 serves as active RO controller, therefore LMA1 has
to initiate the update procedure by means of sending a RO Initiate
message to LMA2. Even though LMA2 is under control of the RO setup
and maintenance, it is preferable to send the RO Initiate from LMA1
to nMAG1, as there might be no SA established between LMA2 and nMAG1
and such cross-signaling should be avoided in any case. Hence, LMA2
controls LMA1 to send the RO Initiate to nMAG1 by means of the first
RO Initiate/Ack message handshake. LMA1 sends a RO Initiate message
to nMAG1 to initiate the RO Setup handshake between nMAG1 and MAG2.
The remaining procedure is similar to Figure 3, including the
notification of the procedure's result to the RO controller by means
of sending a RO Report message from LMA1 to LMA2.
Note: in the case where the RO update trigger and active RO
controller function are on the same LMA, this one does not send a RO
Initiate message to the other LMA, but directly sends a RO Initiate
message to its MAG.
Abeille & Liebsch Expires November 24, 2007 [Page 11]
Internet-Draft Proxy Mobile IPv6 RO May 2007
+-----+ +-----+ +----+ +----+ +----+
|nMAG1| |pMAG1| |LMA1| |LMA2| |MAG2|
+-----+ +-----+ +----+ +----+ +----+
| | | | |
|------------PBU------------>| (ROC) |
|<----------PBAck -----------| | |
| | [T] | |
| | |----RO Init---->| |
| | |<--RO Init Ack--| |
| | | | |
|<----------RO Init----------| | |
|---------RO Init Ack------->| | |
| | | | |
| | | | |
|------------------------RO Setup--------------------------->|
|<---------------------RO Setup Ack--------------------------|
| | | | |
| | | | |
|----------RO Report-------->| | |
|<-------RO Report Ack-------| | |
| | | | |
| | |---RO Report--->| |
| | |<-RO Report Ack-| |
| | | | |
| | | | |
Figure 5: RO Direct Mode - Two relevant LMAs in the topology, MN1
handover
4.3. Route Optimization - Proxy Mode
In this mode, MAGs do not exchange signaling directly. A MAG
exchanges signaling only with the LMA, which is associated with the
attached MN. As a consequence, LMAs will proxy signaling messages
between MAGs to set up and update RO states.
4.3.1. RO Setup Procedure
The description in this section still assumes that MN1 initiates
traffic with MN2. The LMA serves as RO setup trigger and controller,
as in Direct Mode. According to Figure 6, the LMA sends a RO
Initiate message to MAG2 to create RO states. The RO Initiate
message indicates to MAG2 that the message sender (LMA1) serves as
proxy to set up the RO communication between MAG1 and MAG2. The
message contains MN2's ID, MN1's ID and Home Network Prefix, as well
as MAG1's IP address. MAG2 acknowledges the RO Initiate with the
associated Ack message. Subsequently, the LMA sends a RO Setup
Abeille & Liebsch Expires November 24, 2007 [Page 12]
Internet-Draft Proxy Mobile IPv6 RO May 2007
message to MAG1 to proxy the signaling between MAG2 and MAG1. The
message contains MN1's ID, MN2's ID and Home Network Ptrefix, as well
as MAG2's IP address. At the reception of the RO Setup message, MAG1
creates and activates RO states for bi-directional route optimized
path for this particular RO association between between MAG1 and
MAG2. At reception of the associated Ack message, the LMA sends a RO
Setup message to MAG2 to indicate that MAG1's RO states have been
established and activated, as well as to activate MAG2's RO states
for a bi-directional route optimized path.
Note: RO states are established on MAG2 after the reception of the RO
Initiate message. For secure and stable operation, RO states on MAG2
should be activated only after the reception of the RO Setup message,
which indicates the status of MAG1's RO states.
+----+ +----+ +----+
|MAG1| |LMA1| |MAG2|
+----+ +----+ +----+
| | |
| [T] |
| (ROC) |
| | |
| |-------RO Init------>|
| |<----RO Init Ack-----|
| | |
|<-----RO Setup------| |
|----RO Setup Ack--->| |
| | |
| |------RO Setup------>|
| |<----RO Setup Ack----|
| | |
Figure 6: RO Proxy Mode - One relevant LMA in the topology
In the scenario with two LMAs (Figure 7), LMA1 serves as RO trigger,
whereas LMA2 is selected as active RO controller for this particular
RO association. As LMA1 has no information about MN2's MAG2, it
sends the RO Initiate message to LMA2 to request setting up RO
between MAG1 and MAG2. LMA2 establishes RO states at MAG2 by means
of the RO Initiate message.
As in the previous topology with a common LMA, MAG2 acknowledges the
RO Initiate message. LMA2 notifies LMA1 about the created RO states
at MAG2 by means of a RO Report handshake. The result causes LMA1 to
proxy the RO Setup message, which is sent to MAG1. MAG1 has now all
RO states set up and activated, whereas MAG2 waits for the RO Setup
from LMA2 to activate its states according to MAG1's status.
Abeille & Liebsch Expires November 24, 2007 [Page 13]
Internet-Draft Proxy Mobile IPv6 RO May 2007
+----+ +----+ +----+ +----+
|MAG1| |LMA1| |LMA2| |MAG2|
+----+ +----+ +----+ +----+
| | | |
| [T] (ROC) |
| | | |
| |-----RO Init---->| |
| |<---RO Init Ack | |
| | | |
| | |----RO Init---->|
| | |<--RO Init Ack--|
| | | |
| |<---RO Report----| |
| |--RO Report Ack->| |
| | | |
|<----RO Setup-----| | |
|---RO Setup Ack-->| | |
| | | |
| | | |
| |----RO Report--->| |
| |<-RO Report Ack--| |
| | | |
| | |----RO Setup--->|
| | |<-RO Setup Ack--|
| | | |
Figure 7: RO Proxy Mode - Two relevant LMAs in the topology
4.3.2. RO Handover Procedure
After MN's handover, nMAG1 notifies the LMA (LMA1) about MN1's
arrival by means of the PBU message. LMA1 recognizes that RO states
for this particular RO association need to be established at nMAG1
and updated on MAG2. As LMA1 is assigned the function of the RO
update trigger as well as the active RO controller, it coordinates
maintenance of the route optimized path according to Figure 8.
Signaling sequence between nMAG1, LMA1 and MAG2 is the same as for
the set up of RO states (Figure 6)
Abeille & Liebsch Expires November 24, 2007 [Page 14]
Internet-Draft Proxy Mobile IPv6 RO May 2007
+-----+ +-----+ +----+ +----+
|nMAG1| |pMAG1| |LMA1| |MAG2|
+-----+ +-----+ +----+ +----+
| | | |
| | (ROC) |
| | | |
|-----------------PBU--------------->| |
|<---------------PBAck---------------| |
| | [T] |
|<--------------RO Init--------------| |
|-------------RO Init Ack----------->| |
| | | |
| | |----RO Setup---->|
| | |<--RO Setup Ack--|
| | | |
|<-------------RO Setup--------------| |
|------------RO Setup Ack----------->| |
| | | |
| | | |
Figure 8: RO Proxy Mode - One relevant LMA in the topology, MN1
handover
In the scenario, where MN1 and MN2 are tracked by different LMAs
(Figure 9), LMA1 recognizes the need to update the RO association and
serves as RO update trigger. In this scenario, we assume that LMA2
has been selected as active RO controller for this particular RO
association, hence LMA1 sends a RO Initiate message to LMA2, which
coordinates the update procedure. After having received the RO
Initiate Ack from LMA2, LMA1 can start the RO update procedure by
means of sending a RO Initiate message to MAG1. The remaining
message sequence is according to Figure 9 and the same as for the RO
setup procedure with two LMAs (Figure 7).
Note: in the case where the RO update trigger and active RO
controller function are on the same LMA, this one does not send a RO
Initiate message to the other LMA, but directly sends a RO Initiate
message to its MAG.
Abeille & Liebsch Expires November 24, 2007 [Page 15]
Internet-Draft Proxy Mobile IPv6 RO May 2007
+-----+ +-----+ +----+ +----+ +----+
|nMAG1| |pMAG1| |LMA1| |LMA2| |MAG2|
+-----+ +-----+ +----+ +----+ +----+
| | | | |
|------------PBU------------>| (ROC) |
|<----------PBAck------------| | |
| | [T] | |
| | |-----RO Init--->| |
| | |<--RO Init Ack--| |
| | | | |
|<---------RO Init-----------| | |
|--------RO Init Ack-------->| | |
| | | | |
| | |----RO Report-->| |
| | |<-RO Report Ack-| |
| | | | |
| | | |---RO Setup--->|
| | | |<-RO Setup Ack-|
| | | | |
| | |<----RO Report--| |
| | |-RO Report Ack->| |
| | | | |
|<---------RO Setup----------| | |
|--------RO Setup Ack------->| | |
| | | | |
| | | | |
Figure 9: RO Proxy Mode - Two relevant LMAs in the topology, MN1
handover
Abeille & Liebsch Expires November 24, 2007 [Page 16]
Internet-Draft Proxy Mobile IPv6 RO May 2007
5. Message Format
To suit the format of the Proxy MIPv6 messages, the three
differential messages RO Initiate, RO Setup and RO Report as well as
the associated Ack messages are encoded according to the message data
encoding rules for the Mobility Header (MH) as specified in
[RFC3775]. Messages for RO are extensions to
[I-D.ietf-netlmm-proxymip6] and identified by the MH Type.
Parameters being carried by any of these messages are encoded as
message options according to the type-length-value format specified
in [RFC3775]. The following message option is specified for this
protocol: MAG IP Address Option.
Details about the message and message option format are t.b.d.
Note: As an option to the RO protocol's direct mode, a Proxy BU
message handshake can be used to substitute the RO Setup message
handshake between MAGs. In this case, the RO Initiate message from
an LMA serves as trigger to release the PBU to establish RO states on
MAGs according to the protocol operation described in Section 4.2.
Abeille & Liebsch Expires November 24, 2007 [Page 17]
Internet-Draft Proxy Mobile IPv6 RO May 2007
6. Security Considerations
Security threats for route optimization in network-based mobility
management comprise the danger of unauthorized set up or redirect of
an established forwarding path by a malicious node. Signaling
messages of this protocol between a MAG and an LMA as well as between
LMAs must be authenticated by means of IPsec [RFC4301]. The use of
IPsec between an LMA and a MAG follows [I-D.ietf-netlmm-proxymip6].
Protection of signaling messages between an LMA and a MAG uses the
mechanisms of Encapsulating Security Payload (ESP) [RFC4303] in
transport mode with mandatory data origin authentication by means of
a non-null payload authentication algorithm. The use of encryption
is optional. The same requirements apply to signaling between LMAs
as well as between MAGs. In particular, if the network which
interconnects two LMAs and/or two MAGs is not trusted, the use of
encryption is recommended to support confidentiality protection
between LMAs and between MAGs respectively.
In case setting up a security association between MAGs appears
difficult, the protocol's proxy mode allows secure operation without
mandating such security association.
In case RO is established between two MNs which are registered with
different LMAs, the proposed RO protocol avoids direct signaling
between one MN's LMA and the other MN's MAG. Instead, MAGs exchange
signaling only with LMAs which maintain a registration for attached
MNs. This avoids dependency on an existing security association
between all possible MAG-LMA-pairs.
Abeille & Liebsch Expires November 24, 2007 [Page 18]
Internet-Draft Proxy Mobile IPv6 RO May 2007
7. Normative References
[I-D.ietf-netlmm-proxymip6]
Gundavelli, S., "Proxy Mobile IPv6",
draft-ietf-netlmm-proxymip6-00 (work in progress),
April 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
Abeille & Liebsch Expires November 24, 2007 [Page 19]
Internet-Draft Proxy Mobile IPv6 RO May 2007
Appendix A. MAG-local Route Optimization
In some scenarios, both MNs could be attached to the same MAG. The
MNs can be registered to the same LMA or two different LMAs (though
the PMIP final standard may not allow this). In this case, the most
efficient path is to route the traffic from MN1 to MN2 directly via
the MAG, without going through the LMA(s).
Establishing this direct path could be done as part of the PMIP base
standard, as currently discussed in the NetLMM Working Group.
However, if it is so, and if one MN hands off, RO states would have
to be installed after the handover. We believe that it is more
efficient and consistent to install the optimized path as part of a
RO service and treat the handover case with the RO handover
procedures described in Section 4.
This would just require to refine the MAG and LMA operation described
in that section. Indeed, as only one MAG is involved, some messages
exchanges described there will not be used.
Abeille & Liebsch Expires November 24, 2007 [Page 20]
Internet-Draft Proxy Mobile IPv6 RO May 2007
Appendix B. Early State Activation (ESA) Policy
In the procedures described in Section 4, the MAGs are provided with
the relevant information needed to setup RO one after the other.
Additionally, the MAG being contacted first only activates the states
when it receives the notification of the success of the RO setup on
the second MAG. As an example, in Figure 2, the first MAG contacted,
MAG2, activates the RO states after having received and processed the
RO setup Ack from MAG1. In a similar fashion, in Figure 6, MAG2
activates the RO states after having received and processed the RO
Setup from LMA1.
This approach avoids to start using the RO path in the case where the
RO setup failed on either MAG. However, the setup of the RO path can
be slightly optimized at the cost of suppressing this mechanism: the
first MAG could create and activate the RO states without waiting for
the notification concerning the second MAG. We call this enhancement
Early State Activation.
As an example in Figure 2, MAG2 could activate the RO states after
having received and processed the RO Initiate message from LMA1. In
a similar fashion in Figure 6, MAG2 could activate the RO states
after having received and processed the RO Initiate message from
LMA1.
In case ESA is used, additional mechanisms need to be defined to
handle RO setup failure. Indeed, the second MAG contacted could be
unable to create the states for some reason, while the RO states and
forwarding would already be active on the other MAG.
Abeille & Liebsch Expires November 24, 2007 [Page 21]
Internet-Draft Proxy Mobile IPv6 RO May 2007
Authors' Addresses
Julien Abeille
NEC Network Laboratories
Kurfuersten-Anlage 36
69115 Heidelberg,
Germany
Phone: +49 6221 4342119
Email: abeille@netlab.nec.de
Marco Liebsch
NEC Network Laboratories
Kurfuersten-Anlage 36
69115 Heidelberg,
Germany
Phone: +49 6221 4342146
Email: liebsch@netlab.nec.de
Abeille & Liebsch Expires November 24, 2007 [Page 22]
Internet-Draft Proxy Mobile IPv6 RO May 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).
Abeille & Liebsch Expires November 24, 2007 [Page 23]