Personal A. O'Neill
Internet Draft Flarion Technologies
Document: draft-oneill-mip-rmasig-00.txt 8 May 2002
Expires: Oct 2002
Regional Mobility Agent Signalling
<draft-oneill-mip-rmasig-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
Nested MIP [NestMIP] and Concatenated MIP [ConcatMIP] provide means to
support both localization and aggregation of MIP signalling. They achieve
this by providing two distinct layers of MIP signalling and forwarding; a
local access layer that provides local mobility management and local access
services, and a remote access layer that provides remote access back to a
home subnet. The local access layer provides a regional address from a
Regional Mobility Agent (a regional HA) that is then used as a CCoA for the
remote access layer. Inter-FA movement and MIP signalling at the local access
layer then automatically supports the hand-off of potentially multiple
parallel remote access sessions. Nested MIP achieves this through
encapsulation whilst Concatenated MIP achieves it though various forms of CoA
switching.
This draft describes the localised and aggregated MIP signalling model for
managing both the Local Access and Remote Access MIP layers. This includes
inter-FA and Inter-RMA hand-offs within and between Nesting and Concatenating
Regional Mobility Agents. This is necessary to support incremental,
heterogeneous deployment that is required given that Nested MIP is deployable
now whilst Concatenated MIP requires additional and significant standards and
development work.
A.W. O'Neill Expires Oct 2002 [Page 1]
INTERNET-DRAFT Regional Mobility Agent Signalling May 2002
INDEX
Abstract
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions used in this document . . . . . . . . . . . . . . . . . 4
3. Terminology used in this document . . . . . . . . . . . . . . . . . 4
4. Motivation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. MIP Registration Overview . . . . . . . . . . . . . . . . . . . . . 5
5.1 LA Signalling Summary . . . . . . . . . . . . . . . . . . . . . 7
5.2 RA Signalling Summary . . . . . . . . . . . . . . . . . . . . . 7
5.3 Combined LA/RA Signalling Summary . . . . . . . . . . . . . . . 8
5.4. LA / RA Visitor Lists. . . . . . . . . . . . . . . . . . . . . 9
5.5. Summary of LA and RA Forwarding Modes. . . . . . . . . . . . . 11
5.6. Distinguishing LA and RA MIP Messages. . . . . . . . . . . . . 17
5.7 Summary of MIP Signalling Additions . . . . . . . . . . . . . . 19
5.8 Backwards Compatibility Issues . . . . . . . . . . . . . . . . 21
5.9 Signalling and Forwarding Evolution . . . . . . . . . . . . . . 22
6. Registration Refresh and Hand-Off Processing. . . . . . . . . . . . 23
6.1 LA Refresh. . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.2 LA Hand-off (Inter-FA). . . . . . . . . . . . . . . . . . . . . 24
6.3 LA Hand-off (Inter-RMA, Inter-FA) . . . . . . . . . . . . . . . 25
6.4 Enhanced LA Hand-off (Inter-RMA, Inter-FA). . . . . . . . . . . 26
6.5 RA Layer Registration Update. . . . . . . . . . . . . . . . . . 27
6.6 RA Hand-off (inter-RMA, optionally inter-FA). . . . . . . . . . 29
6.7 Combined LA/RA Hand-off (for the oRMA). . . . . . . . . . . . . 30
6.8 Combined RA/LA Hand-off (for other global HAs). . . . . . . . . 32
7. Summary of Inter-FA Forwarding during Hand-off. . . . . . . . . . . 32
7.1 Transient forwarding for standard FA CoA switching. . . . . . . 33
7.2 Transient forwarding for Concat CoA switching . . . . . . . . . 33
8. Summary of Inter-Region Transient Forwarding. . . . . . . . . . . . 34
8.1 Transient forwarding from Nested oRMA to Nested nFA . . . . . . 34
8.2 Transient forwarding from Concat oRMA to Nested nFA . . . . . . 34
8.3 Transient forwarding from GFA oRMA to Nested nFA. . . . . . . . 35
9. Summary of Inter-RMA Transient Forwarding during Hand-off . . . . . 35
9.1 Nested to Nested using Nested inter-RMA transient forwarding. . 36
9.2 Nested to Concat using a Concat inter-RMA transient forwarding. 37
9.3 Concat to Concat using Concat inter-RMA transient forwarding. . 38
9.4 Concat to Nested using Nested inter-RMA transient forwarding. . 39
9.5 Nested to Nested using Concat inter-RMA transient forwarding. . 40
9.6 Nested to Concat using Nested inter-RMA transient forwarding. . 41
9.7 Concat to Nested using Concat inter-RMA transient forwarding. . 41
9.8 Concat to Concat using a Nested inter-RMA transient forwarding. 42
9.9 Nested <-> Concat Option Comparisons. . . . . . . . . . . . . . 42
9.10. Inter-RMA Transient Forwarding with GFA mode. . . . . . . . . 43
A.W. O'Neill Expires Oct 2002 [Page 2]
INTERNET-DRAFT Regional Mobility Agent Signalling May 2002
10. Additional Modifications, Options and Extension Definitions. . . . 43
10.1 Hybrid Concat/GFA Modes. . . . . . . . . . . . . . . . . . . . 43
10.2 GFA and private HoAs . . . . . . . . . . . . . . . . . . . . . 43
10.3 Heterogeneous RA forwarding modes. . . . . . . . . . . . . . . 44
10.4 HA/HoA Specific Processing and Context Transfer. . . . . . . . 44
10.5 Previous Foreign Notification Extension (PFANE). . . . . . . . 46
10.6 Previous RMA Notification Extension (PRANE). . . . . . . . . . 46
10.7 Style Extension (Stylext). . . . . . . . . . . . . . . . . . . 47
10.8 HFAIPext . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
10.9 HFAext . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
10.10 HoAList . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
10.11 HoAResp . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
10.12 HoAErr. . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
10.13 FA-NAI regional structure . . . . . . . . . . . . . . . . . . 50
10.14 Unicast FAA for MN specific FA CoA assignment . . . . . . . . 50
10.15 When the LA layer is hidden from the RA Layer . . . . . . . . 50
10.16 When both the LA and RA layers are exposed to the FA. . . . . 50
10.17 When the RA/LA layers terminate on different elements . . . . 51
10.18 RoA Address Allocation. . . . . . . . . . . . . . . . . . . . 52
10.19 Proxied HA Update . . . . . . . . . . . . . . . . . . . . . . 54
11. IPv6 Considerations. . . . . . . . . . . . . . . . . . . . . . . . 56
12. Security and AAA Considerations. . . . . . . . . . . . . . . . . . 56
12.1 FA and RMA Auto-configuration. . . . . . . . . . . . . . . . . 57
12.2 AAA Key Material Distribution. . . . . . . . . . . . . . . . . 57
12.3 Inter-operator PRANE . . . . . . . . . . . . . . . . . . . . . 58
12.4 Forwarding Checks. . . . . . . . . . . . . . . . . . . . . . . 58
13. Notice Regarding Intellectual Property Rights. . . . . . . . . . . 58
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 59
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
A.W. O'Neill Expires Oct 2002 [Page 3]
INTERNET-DRAFT Regional Mobility Agent Signalling May 2002
1. Introduction
Nested MIP [NestMIP] and Concatenated MIP [ConcatMIP] provide means to
support both localization and aggregation of MIP signalling. They achieve
this by providing two distinct layers of MIP signalling and forwarding; a
local access layer that provides local mobility management and local access
services, and a remote access layer that provides remote access back to a
home subnet. The local access layer provides a regional address from a
Regional Mobility Agent (RMA) (initially simply a local HA) that is then used
as a CCoA for the remote access layer. Inter-FA movement and MIP signalling
at the local access layer then automatically supports the hand-off of
potentially multiple parallel remote access sessions. Nested MIP achieves
this through encapsulation whilst Concatenated MIP achieves it though various
forms of CoA switching.
The signalling for Nested and Concatenated MIP is wholly based on existing
MIP signalling capabilities re-using standard MIP Registration Requests and
Replies, along with the extensions to those messages in support of regional
elements. The additional signalling mechanisms are limited to new extensions
and processing rules in support of the RMA, and in support of the additional
hand-off requirements.
This draft describes the localised and aggregated MIP signalling model for
managing both the local access (LA) and remote access (RA) layers through a
series of evolutionary steps starting from standard MIP. This includes inter-
FA and Inter-RMA hand-offs within and between Nesting and Concatenating
Regional Mobility Agents. This is necessary to support incremental,
heterogeneous deployment that is inevitable given that Nested MIP is
deployable now whilst Concatenated MIP requires additional and significant
standards and development work.
2. Conventions used in this document
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].
3. Terminology used in this document
Much of the terminology used in this document borrows from Mobile IPv4
[MIPv4], MIP Regional Tunnelling [RegTun], MIP Reverse Tunnelling [RevTun]
and MIP Route Optimisation [RoutOpt]. This draft introduces the following
additional terminology.
Local access service - Internet access using a topologically local address
Remote access service - Internet access using a topologically remote address
Regional Mobility Agent (RMA) - a regional node capable of at least HA mode
Regional Address (RoA) - A HoA from the RMA HA function
RMA Region - the set of FAs able to allocate that RMA to a MN
LA/RA MIP - Local access MIP functionality between the MN and the RMA/HA
HoA visitor list - the standard MIP visitor list for HoA/CoA binding
A.W. O'Neill Expires Oct 2002 [Page 4]
INTERNET-DRAFT Regional Mobility Agent Signalling May 2002
LA visitor list - the MIP visitor list for the RoA / FA CoA binding
RA visitor list - the MIP visitor list for the HoA / CCoA=RoA binding
SHCoA - Shared CoA for multiple MNs from the FA or RMA.
MSCoA - Mobile Node specific CoA from the FA or RMA.
LA/RA Hand-off - a hand-off effected using the LA/RA MIP layer
LA/RA MIP Reg - An MIP Reg in the LA/RA layer direct to the present RMA/HA.
Inter-FA Hand-off - a hand-off between two FAs that updates the FA CoA.
Inter-RMA Hand-off - a MIP hand-off between two RMAs that changes MN RoA.
HFAIPext - the HFA IP address extension (generalization of GFAIPext)
PRANE - Previous Regional Agent Notification Extension
HoAlist - HoA/HA list extension
HoAResp - the matching HoA/HA response extension
HoAErr - extension to communicate HA/HoA specific errors
Style Extension (Stylext) - used to select LA/RA options
4. Motivation
The motivation for this work is described fully in [NestMIP] and [ConcatMIP]
but can be summarized here as extending MIP signalling (Registration and
Hand-off) to support efficient local Internet access in conjunction with
potentially multiple parallel remote access sessions. In the case of this
draft, the MIP signalling is enhanced to enable the instantiation,
maintenance and hand-off of local and remote access sessions.
5. MIP Registration Overview
There is a single LA session for an unlimited number of dependent RA
sessions. The existence of both a local access and remote access MIP layer
results in the need to support two layers of Registrations and hand-off in
the Nested/Concat MIP model. LA Registrations configure and refresh the LA
layer whilst RA Registrations configure and refresh the RA layer. Both layers
also support hand-off with the RA layer 'hand-off' updating the CCoA in the
global HA to use a new RMA, whilst the LA updates the CoA in the RMA and also
handles transient forwarding for the two types of LA hand-off. These are
called inter-RMA hand-off and inter-FA hand-off.
A region is defined as the set of FAs under a specific RMA such that an
inter-FA hand-off is occasionally also an inter-region hand-off. These hand-
offs are enabled by the LA MIP Registration Request / Reply, and by the RA
MIP Registration Request / Reply, as described in the following sections, in
support of three main forwarding modes; Nested [NestMIP], Concatenated
[ConcatMIP] and GFA as in [RegTun].
A.W. O'Neill Expires Oct 2002 [Page 5]
INTERNET-DRAFT Regional Mobility Agent Signalling May 2002
+--------+
| |
Global HAs | HA |
|HoA->CoA|
+--------+
| \
... ... ... ... ...
|
+--------+ +--------+
Regional RMAs | oRMA | | nRMA |
inter-RMA h/o | oRoA | | nRoA |
|CoA->CoA| |CoA->CoA|
+--------+ +--------+
<-------region--------> <-------region-------->
/ \ / \
+--------+ +--------+ +--------+ +--------+
Local FAs | | | | | | | |
inter-FA h/o | FA1 | | FA2 | | FA3 | | FA4 |
| CoA | | CoA | | CoA | | CoA |
+--------+ +--------+ +--------+ +--------+
| |
| +--------+ +--------+
... | | | |
| MN | | MN |
| | | |
+--------+ +--------+
Figure 1 above illustrates the topology.
The LA layer signalling specifies the type of requested/supported/assigned
LA features which include;
- the access service mode (local access only, remote access only, local
and remote access),
- the RMA RA forwarding mode (standard, nested, Concat, GFA)
- the RoA (public or private address)
- the FA CoA (shared or MN specific address).
These need to be sufficient for all the active or planned RA sessions and
commensurate with the operator policy and MN AAA profile. The default LA
layer signalling and processing is both local and remote access service,
using nested mode RA forwarding in the RMA for a public or private RoA to a
shared FA CoA. This can be seen to be equivalent to standard MIP with the RMA
acting simply as a local HA for the RoA address, with the addition that the
RoA can also be used as an interface address for local access. The MN can
then use standard MIP mechanisms to use the RoA as a MN CCoA for RA MIP
Registration directly with a global HA. The routing entries for the RoA
always point towards the RMA and the RMA uses MIP mechanisms to redirect the
packets to the MN using that RoA. The MN uses LA MIP extensions to request
changes to this default behaviour and these extensions can be checked and
modified by the FA and the RMA. The FA can inform the MN of the facilities
available at that FA and within that RMA region, and complementary
information can also be communicated through successful and failed
Registration Replies. The signalling exchanges to support the LA and RA
layers through a series of evolutionary steps are defined next.
A.W. O'Neill Expires Oct 2002 [Page 6]
INTERNET-DRAFT Regional Mobility Agent Signalling May 2002
5.1 LA Signalling Summary
There are four versions of LA MIP Registration Request/Reply.
5.1.1 LA Reg v1 (intra-RMA, intra-FA)
This is sent via the old FA to an old RMA when refreshing a binding at that
old RMA. The CoA, RMA and RoA are therefore already known when sending the LA
Reg. This is possible using existing MIP standards.
5.1.2 LA Reg v2 (intra-RMA, inter-FA)
This is sent to the old RMA via a new FA as part of an FA hand-off within
the region of the old RMA or from a new FA outside of that region that has or
can rapidly acquire an SA with the oRMA for authentication purposes. The RMA
and RoA are once again already known when the LA Reg is sent by the MN. The
need for inter-FA hand-off is detected before sending the LA Reg. The LA Reg
can then include an inter-FA hand-off extension such as PFANE to trigger a BU
back to the oFA. The BU facilitates transient forwarding from the oFA to the
nFA during the RMA changeover. This is possible using existing MIP standards.
5.1.3 LA Reg v3 (inter-RMA, inter-FA)
This is sent to the new RMA from the new FA when starting a new LA session or
when recovering from a failed RMA. This therefore requires dynamic assignment
of an RMA and an RoA from that RMA. If the MN detects the need for an inter-
RMA hand-off then it can be sent with an inter-FA hand-off extension such as
PFANE to trigger a BU back to the oFA. The BU facilitates transient
forwarding from the oFA to the nFA during the RMA changeover. This is
possible using existing MIP standards with the dynamic allocation using the
equivalent mechanisms to that for dynamic HA/HoA assignment.
5.1.4 LA Reg v4 (inter-RMA, interFA)
This is sent to the new RMA from the new FA along with an inter-FA hand-off
extension such as PFANE, and a new inter-RMA hand-off extension called a
Previous RMA Notification Extension or PRANE. Dynamic assignment of RMA and
RoA are again required. The PFANE triggered BU facilitates transient
forwarding from the oFA to the nFA during the RMA changeover. In addition,
the PRANE is added to also trigger a BU back to the oRMA from the nFA and/or
the nRMA depending on state in the new FA and in the PRANE itself. This BU is
used to facilitate more efficient transient forwarding, of in-flight packets
arriving at the old RMA, directly to the nFA and/or to the nFA via the nRMA.
This avoids excessive use of expensive inter-FA transient forwarding
especially in the case of singley-homed FAs, connected over expensive access
circuits, that is typical in cellular networks. This type of registration is
possible with existing MIP standards and simply requires a new extension to
trigger the request for oRMA transient forwarding, and associated
modifications to MN, FA and RMA (local HA).
5.2 RA Signalling Summary
The RA MIP layer manages remote access sessions between a global HA/HoA and
the MN. There are three versions of RA MIP Registration signalling.
A.W. O'Neill Expires Oct 2002 [Page 7]
INTERNET-DRAFT Regional Mobility Agent Signalling May 2002
5.2.1 RA Reg v1
This is sent directly between the MN and the global HA for the global HoA.
This is unseen by the FA and the RMA and is possible with existing MIP
standards if the MN has a CCoA. This draft extends the standard MIP
Registration definition to enable the CCoA to be the RoA assigned from the LA
MIP layer.
5.2.2 RA Reg v2
This is sent to the global HA via the FA and therefore requires the FA to be
able to process both LA and RA MIP Registrations. Whilst the MIP standard
Registration message can be sent via the FA, neither the standard MIP MN nor
FA has the required intelligence to distinguish between and appropriately
deal with LA and RA messages, and the associated packet forwarding.
5.2.3 RA Reg v3
This is sent to the global HA via the FA and the RMA from the LA layer. This
therefore requires the FA and the RMA to be able to process both LA and RA
MIP Registrations. Whilst the MIP standard Registration message can be sent
via the FA, neither the standard MIP MN nor FA has the required intelligence
to distinguish between and appropriately deal with LA and RA messages. The
RMA in the LA layer is a local HA whilst in the RA layer it is a regional
element on the way to a global HA. Again, neither existing HAs nor in fact
regional elements such as GFAs have the required intelligence to distinguish
between and appropriately deal with LA and RA MIP Registrations. Also,
neither the MN, FA, HA nor GFA have the ability to deal with subsequent
packet forwarding and the regional signalling extensions to enable
registrations through a regional element are not yet completed.
5.3 Combined LA/RA Signalling Summary
There are two forms of combined LA/RA signalling that have been designed for
efficiency reasons. These are;
5.3.1 Combined LA/RA Reg v1
This is a combination of an LA Reg v3 and an RA Reg v3. It is sent to the
oRMA for the oRoA, via the nFA and the nRMA. It carries an inter-FA hand-off
extension to trigger a BU to the oFA from the nFA to facilitate inter-FA
transient forwarding. In the FA, this registration triggers nRMA and FA CoA
assignment, and in that nRMA it triggers nRoA assignment and the type of RA
forwarding. In the oRMA, the nRoA is installed as the CoA for the oRoA (oRMA
becomes a global HA) which facilitates persistent forwarding of traffic
arriving on the oRoA address towards the nRMA. In the nRMA and nFA,
forwarding is enabled both for traffic arriving on the oRoA and the nRoA.
This enables inter-region hand-off with inter RMA forwarding and persistent
use of the oRMA and oRoA by elevating them into the RA layer (global HA/HoA)
whilst away from the region of that oRMA.
A.W. O'Neill Expires Oct 2002 [Page 8]
INTERNET-DRAFT Regional Mobility Agent Signalling May 2002
5.3.2 Combined LA/RA Reg v2
This is a combination of an LA Reg v4 and an RA Reg v3. This is therefore
sent to the global HA for the HoA via the nRMA and the nFA. Inter-FA and
inter-RMA hand-off extensions are included by the MN to trigger BUs to the
oFA and the oRMA. These BUs facilitate transient forwarding between oFA and
nFA, and between the oRMA and the nFA/nRMA. The RA session for the combined
message can be selected by the MN either based on the remaining lifetime,
order of importance or to minimise the effect of hand-off (latency/packet
redirection etc) for that particular session. This version is used instead of
the Combined LA/RA Reg v1 when the oRMA/oRoA are not required to transition
into an RA session as a persistent global HA/HoA pair for the MN, and hence
only transient forwarding is required.
5.4. LA / RA Visitor Lists
LA MIP Registrations create and update the LA visitor list in the FA and the
RMA. The LA visitor list contains forwarding entries for packets addressed to
the RoA from any source in the Internet, including HAs, but can be
constrained by the use of additional firewall entries. Firewall entries can
be created to control various remote access techniques, as well as for
controlling specific traffic sources, protocol types, port numbers etc...
The RA visitor list can be considered to be a specific type of firewall entry
maintained by MIP signalling. Logically you can imagine a packet first being
matched against state in the RA visitor list (more specific checks that can
cause a packet to be discarded, re-marked, accounted differently or to
undergo alternative forwarding) and then being checked against the LA visitor
list before undergoing default local access forwarding. Of course there are
many options for the implementation of these two lists from two distinct
layers through to a single integrated list.
RA MIP Registrations create and update the RA visitor lists in the MIP nodes
through which it is forwarded and processed. The RA visitor list specifically
ensures that data packets addressed to the MN are only received from the
correct previous MIP node as learnt during the RA Registration process. This
is a generalisation of the forwarding rules in [RegTun] to deal with Nesting,
Concat modes as well as CoA Switching. The RMA, the FA and the MN need to
keep MN specific state in the visitor list to undertake this check if the RA
Registration signalling traverses that node, and that node changes the packet
source address for the downstream node.
The RMA must check that the data packet came from the registered HA.
The FA must check that the data packet came from the registered HA or RMA.
The MN must check that the data packet came from the registered HA,RMA,FA.
The MN specific state used for this source check in the FA should not include
the HoA. Avoiding HoA specific state in the FA means that it does not need to
be maintained through inter-FA hand-off using Context Transfer (because we
want to avoid independent MIP hand-off signalling for each HoA). The problem
with HoA specific state and aggregated signalling is covered in more detail
in [ParallelMIP]. The appropriate level of RA checks in each element is a
trade-off between the processing required to undertake those checks, against
being able to efficiently eliminate incorrect packets as early as possible.
A.W. O'Neill Expires Oct 2002 [Page 9]
INTERNET-DRAFT Regional Mobility Agent Signalling May 2002
The level of checking is operator dependent. HoA specific processing
features such as accounting and QoS are particularly an issue for the
operator but in these cases are under the control of the AAA profile.
Each foreign agent MUST be configured with a shared care-of address. In
addition, for each pending or current LA registration the foreign agent
MUST maintain an LA visitor list entry containing the following
information obtained from the mobile node's LA Registration Request:
- the link-layer source address of the mobile node
- LA layer MN-NAI to identify the MN profile
- the IP Source Address (the mobile node's Home Address = RoA).
- the IP Destination Address (as specified in [MIPv4] 3.6.1.1)
- the UDP Source Port
- the Home Agent address = RMA
- the Identification field
- the requested registration Lifetime, and
- the remaining Lifetime of the pending or current registration.
In addition, for each pending or current RA registration the foreign agent
MUST maintain an RA visitor list entry containing the following
information obtained from the mobile node's RA Registration Request:
- the link-layer source address of the mobile node
- RA layer MN-NAI to identify any additional RA layer session profile
- the IP Source Address (the mobile node's CCoA = RoA).
- the IP Destination Address (as specified in [MIPv4] 3.6.1.1)
- the UDP Source Port
- the Home Agent address = global HA
- the forwarding mode (standard, Nested, Concat or GFA)
- the FA CoA (MSCoA for Concat mode)
- the Identification field
- the requested registration Lifetime, and
- the remaining Lifetime of the pending or current registration.
Both lists are then supplemented with additional information that is
particular to the chosen RA layer forwarding mode. The LA forwarding mode is
always to encapsulate towards the nFA CoA.
The LA and RA visitor lists can be implemented for example as a single list
of visitor entries containing both LA and RA state entries. The forwarding
search should check the more restrictive RA entries (specific HAs) before
checking the LA layer entries (any CN).
The RMA needs to keep the same visitor list as an existing HA for its role in
the LA layer related to the RoA address. In addition, it must be able to
store RA visitor state if the registration is routed via the RMA. The FA
knows either from configuration, from MIP Replies or from the RMA state
returned from the AAA system whether or not the RMA supports RA registration.
The HA visitor list is unchanged by this draft.
A.W. O'Neill Expires Oct 2002 [Page 10]
INTERNET-DRAFT Regional Mobility Agent Signalling May 2002
5.5. Summary of LA and RA Forwarding Modes
5.5.1 The LA Layer Forwarding
The LA layer supports the forwarding of local access traffic. There is one
type of forwarding at the LA layer and this is to 'Nest' the oRoA within a
tunnel between the RMA (the local HA) and the FA as in normal MIP forwarding.
This Nested forwarding is unaffected by the RMA RA layer features which can
support Nested, GFA and Concatenated forwarding of packets from a global HA.
Local traffic sent by a Correspondent Node (CN) to the RoA arrives at the RMA
that owns that RoA, and is then encapsulated into the FA CoA registered for
that RoA. It is then forwarded to the FA owning that CoA and through which
the MN typically sent the LA layer MIP Reg. The FA decapsulates, inspects the
RoA to identify the MN, and then forwards to that MN. The FA CoA is either a
SHCoA or a MSCoA depending on the RA forwarding mode negotiated at the LA
layer, for all RA sessions. Note that the FA must inspect the RoA within an
MSCoA to ensure it agrees with the MN LA state and to prevent packet mis-
delivery.
CN HA oRMA nRMA oFA MN
Forward LA CN----------------------------------------------------->oRoA
oRMA=============>oFACoA
Reverse LA CN<-----------------------------------------------------oRoA
RevTun LA CN<-----------------------------------------------------oRoA
(Direct) oRMA<=============oFACoA
(Encaps) oRMA<=============oFACoA x <=====oRoA
Figure 2. LA layer forwarding.
Note that the RoA is just a HoA from the RMA and therefore reverse tunnelling
features [RevTun] are unaffected, including the ability in 'Encapsulating
style' to revtun some packets via the RMA and reverse some directly to the
CN. Note also that the FA needs to undertake a source address check on the
RoA to ensure that RoA is registered in that FA for that MN.
A range of forwarding models for the RA layer are then possible depending on
the evolution stage, the deployed RMA/FA operator capabilities, the MN AAA
profile and the MN LA Registration contents. The LA layer is however
responsible for preparing the RA layer forwarding mode, which should
generally be the same for all RA access sessions through that RMA for that
MN. This requires the discovery, negotiation and agreement at the LA layer of
the required forwarding mode. This is necessary so that each LA hand-off can
immediately acquire the correct type of FA CoA and then configure the RA mode
via the nRMA before the RA sessions are refreshed.
Before examining the RA forwarding options, a special mention needs to be
made of Route Optimisation here [RouteOpt]. Initially, a MN will register
through to a HA and packets will come through that HA to the MN, experiencing
the RA layer forwarding to be discussed next. However, after subsequent
signalling between MN and CN, the two nodes can tunnel directly to each other
and bypass the HA. At this point these packets are from the CN to the RoA and
from the RoA to the MN which are therefore forwarded as local access traffic.
A.W. O'Neill Expires Oct 2002 [Page 11]
INTERNET-DRAFT Regional Mobility Agent Signalling May 2002
If the RA visitor list inspects inner packet headers to identify them as
remote access traffic, those packets can still be exposed to RA layer
processing (that may even be HoA specific). The state required to undertake
this check can be built from the route optimisation messages that are
exchanged via the HA, although this creates CN specific state which is only
practical to maintain in the RMA. One benefit though that the architecture
brings to route optimisation is the fact that the RoA changes much less
frequently and so binding update traffic is significantly reduced, with the
reduction improving as the size of regions is increased at the cost of less
optimal forwarding via the RMA.
There are four types of forwarding possible at the RA layer between the
global HA and the MN, three of which are defined in this draft. These are
covered in the next sections.
5.5.2 Standard MIP remote access
This is a direct tunnel from the global HA to the MN CCoA from the oFA
subnet, with any optional reverse tunnel being between the MN CCoA and the
HA. This tunnel is used whether or not the MN registers via the FA at the RA
layer.
CN HA oRMA nRMA oFA MN
Forward RA CN------------------------------------------------------>HoA
HA==========================================>oCCoA
Reverse RA CN<------------------------------------------------------HoA
RevTun RA HA<==========================================oCCoA
Figure 3. Standard MIP RA.
Note that the CCoA here is from the FA subnet and hence must be updated on
every FA hand-off.
5.5.3 Nested MIP remote access
RA Nested Forwarding is as for LA Nested forwarding in that the RMA
encapsulates packets addressed to the RoA, in the FA SHCoA that was LA
registered by the MN via the present FA. The FA then decapsulates and
forwards to the MN that has been assigned that RoA. Nested MIP RA can be
configured using any of RA Reg v1, v2 or v3 as described above because
neither the RMA nor the FA need to receive any additional RA information to
successfully forward the traffic towards the MN CCoA. This is because the HA
is sending to the RoA, and the RMA and FA can forward this at the LA layer.
A.W. O'Neill Expires Oct 2002 [Page 12]
INTERNET-DRAFT Regional Mobility Agent Signalling May 2002
CN HA oRMA nRMA oFA MN
Forward RA CN------------------------------------------------------->HoA
HA===========================================>oRoA
oRMA================>oSHCoA
Reverse RA CN--------------------------------------------------------HoA
(PCCoA only using RevTun LA) oRMA<================oRoA
RevTun CN--------------------------------------------------------HoA
RevTun RA HA<===========================================oRoA
RevTun RA/LA oRMA<================oSHCoA
Figure 4. Nested MIP RA
There is a forward tunnel from the HA to the MN CCoA within a tunnel between
the RMA and the FA. The RMA to FA tunnel is managed by the LA layer whilst
the HA to MN CCoA is managed by the RA layer. Reverse tunnelled remote access
traffic does not need to traverse the oRMA but is sent from the MN CCoA=RoA
to the HA. LA reverse tunnelling can be used to ensure that the RMA is also
traversed if that is necessary for policy/feature reasons.
Forward and reverse traffic that is not tunnelled at the RA layer over the
air interface is not generally supported with CCoAs in this model. However,
proxy CCoAs [PCCoA] potentially offer a way to achieve this, and save
encapsulation overhead or header compression load if the FA is visited by the
registration signalling and end to end IPSEC is not employed. A PCCoA is a
CCoA whose tunnel management is handled at the other end of the link in the
FA. In the forward direction this causes the FA to also decapsulate from the
RoA and forward to the MN with a HoA destination address. In the reverse
direction, the packet now has a HoA source address and so some form of
ingress filtering must be performed. This can be undertaken by the FA if it
has HoA state supported using Context Transfer. Preferably though, the FA can
simply process based on the incoming link-layer address (to identify the MN
and hence the RoA entry) and then reverse tunnel the packet at the LA layer
from the oRoA to the RMA where HoA state can practically undertake the source
address check for that MN. PCCoA processing is clearly complex however and
the cost benefits of this mode need to be determined.
The major difference compared to standard MIP remote access mode is that the
MN CCoA is the Regional Address (RoA) which comes from the RMA, rather than a
CCoA from the FA subnet as in standard MIP specs. In the latter case, the FA
hand-offs result in CCoA changes and a need to update the global HA, wheras
with Nested MIP the RoA is valid across a number of FAs beneath a single RMA.
The RA visitor list in the MN ensures that the correct HA sent the correct
HoA in the correct RoA, and that the packet was received from the registered
FA. If the RA Registration traverses the FA then an RA visitor list in the FA
can ensure, after decapsulating from the FA CoA, that the packet came via the
registered RMA for that RoA by checking the source address on the
encapsulation towards the FA CoA. If the RA Registration traverses the RMA
then the RA visitor list in the RMA checks that the source HA has been
registered for that RoA.
A.W. O'Neill Expires Oct 2002 [Page 13]
INTERNET-DRAFT Regional Mobility Agent Signalling May 2002
Note that the FA and RMA may also undertake HoA specific processing which
also requires the inner HoA to be interrogated. An optional RA visitor list
in the RMA, based on the received RoA, may check that the HA address is
correct for the encapsulated HoA and that the HoA is registered for that RoA
and MN. The FA can check that the MN that owns that RoA also owns the HoA or
it can simply rely on the fact that this check may be performed by the RMA
and must be by the MN.
5.5.4 GFA CoA switching
This is CoA switching from [RegTun] which uses a HoA specific RA visitor list
in the RMA (acting like a GFA) and FA to route packets arriving on shared RMA
and FA CoAs (SHCoAs). This mode is supported in this document for backwards
compatibility and transition reasons if GFAs and GFA aware MNs have been
deployed.
CN HA oRMA nRMA oFA MN
Forward RA CN------------------------------------------------------>HoA
HA====>oRMA x oRMA===============>oSHCoA
RevTun RA CN-------------------------------------------------------HoA
HA<====oRMA x oRMA<===============oSHCoA
Figure 5. GFA MIP RA
The forward tunnel is from the HA to the RMA CoA, and then from the RMA to
the FA CoA. The reverse tunnel is the exact reverse of the forward tunnel.
Reverse traffic that is not tunnelled at the RA, and therefore has the HoA as
the source address, can clearly be supported in this model because the FA has
HoA specific state. In this case, the RoA is not needed by the RA layer and
is used simply for the LA layer that is not shown.
This mode of forwarding can only be supported with an RA MIP v3 Reg because
specific state needs to be installed into the RMA and the FA for the
switching. The GFA forwarding should only generally be supported for MNs
that are limited to a single remote access session (a single HoA) and that
are using a globally unique HoA, these being known limitations of GFA
forwarding. The HoA specific RA visitor list state must be maintained at each
new FA and RMA, for multiple RA sessions, using the HoA independent LA layer
signalling. This can be accomplished, for a single RA session, by the LA MIP
Reg including the HoA information, in a HFAext, to support inter-FA and
inter-RMA hand-off. For multiple RA sessions (HoAs), the HFAext can be
replaced with the HoAList extension and Context transfer mechanisms are then
required between FAs and RMAs, triggered by the aggregated LA hand-off, which
is discussed in more detail in section 10.
The RA visitor list in the MN ensures that a correct HoA was used and that
the packet was received from the registered FA. The RA visitor list in the
RMA must check that the HA address is valid for the received HoA. After
decapsulating from the FA CoA, the FA checks that the packet came via the
registered RMA for that MN by checking the source address on the
encapsulation towards the FA CoA. The FA and/or RMA must undertake HoA
specific processing as part of the GFA model, which can be useful for other
previously mentioned reasons, based on AAA profile or operator policy.
A.W. O'Neill Expires Oct 2002 [Page 14]
INTERNET-DRAFT Regional Mobility Agent Signalling May 2002
Note that if local access is also requested, then the RMA needs to be able to
distinguish between encapsulated packets sent from a specific HA as part of
RA GFA forwarding, and unencapsulated/encapsulated packets sent from CNs as
part of the local access service. This is to avoid the RMA attempting to
incorrectly strip the RoA. Therefore, to support LA as well as RA access, the
GFA needs to inspect the incoming source address to match it against a known
HA before undertaking CoA switching. Alternatively, because local access
traffic arrives on the RoA whilst remote access traffic arrives to a SHCoA,
then the SHCoA can trigger the forwarding to the GFA module where the HA
source address can be checked. This is a change from the [RegTun] GFA
mechanism which enables local access traffic to bypass the GFA module in the
RMA (and equivalently in the FA for packets arriving to the RoA and the FA
SHCoA).
5.5.5 Concatenated CoA Switching
This is a new form of somewhat complex CoA switching to overcome the
perceived limitations in the GFA model. This mode of forwarding can only be
supported with an RA MIP v3 Reg or Combined Reg because specific state needs
to be installed into the RMA and the FA for the switching. The concatenated
processing, unlike GFA processing, can be supported for public and private
HoA addresses and for multiple concurrent RA sessions. The concatenated
request can be refused as a result of AAA state in the FA, which can then
convert the request to either GFA or Nested MIP.
CN HA oRMA nRMA oFA MN
Forward RA CN------------------------------------------------------->HoA
HA====>oRoA x oRMA===============>oMSCoA=====>oRoA
ReverseRA CN---------------------------------------------------------HoA
(PCCoA only) oRMA<===============oMSCoA
CN---------------------------------------------------------HoA
RevTun RA only HA<===========================================oRoA
RevTun LA/RA HA<====oRoA x oRMA<===============oMSCoA<=====oRoA
Figure 6. Concatenated MIP RA
The forward tunnel is between the HA and the RMA which switches traffic into
a second tunnel between the RMA and the FA. The RA layer reverse tunnel is
similar to that for Nested though in that it can bypass the oRMA. Note that
the RA traffic in Concat, as in Nested, requires a tunnel over the air
interface, whilst it is not required for GFA. If either or both LA and RA
reverse tunnelling is selected then the processing rules ensure that the
source address is correct for the information in the destinations binding for
the forward direction.
Forward and reverse traffic that is not tunnelled at the RA layer over the
air interface is not generally supported with CCoAs in this model. However,
proxy CCoAs [PCCoA] potentially offer a way to achieve this, and save
encapsulation overhead or header compression load if the FA is visited by the
registration signalling and end to end IPSEC is not employed. The reverse
forwarding is then as for Nested by reverse tunnelling to the RMA, but this
time from the oMSCoA to match on the forward entry in the RMA.
A.W. O'Neill Expires Oct 2002 [Page 15]
INTERNET-DRAFT Regional Mobility Agent Signalling May 2002
The other modifications wrt [RegTun] are that the RMA CoA and FA CoA are MN
specific (MSCoAs) so that neither the RMA nor the FA need to keep HoA
specific state for forward or reverse RA tunnels. This enables a single LA
MIP Reg to move all the RA sessions together and also ensures that Context
Transfer of HoA specific state, for basic RA forwarding, can be avoided
during FA hand-off. Note that Context Transfer might still be required to
optionally support HoA specific processing in the FA and/or RMA, and is
discussed in detail in section 10. If HoA specific state is added in the RMA
and FA for such reasons then the MN specific CoA and RoA can also be used to
assure that the concatenation of the MSCoA+HoA or RoA+HoA is always locally
unique. An example of this HoA specific processing is the source address
check in the RMA for reverse packets that are not tunnelled at the RA layer.
The RA visitor list in the MN ensures that a correct HoA was used and that
the packet was received from the registered FA. A mandatory RA visitor list
in the RMA must check that the HA address is valid for the received RoA. An
RA visitor list in the FA must keep MSCoA and RoA state to be able to
correctly identify and forward to the receiving MN by switching from the
MSCoA into the RoA destination address whilst generally ignoring the inner
destination address (ie the HoA). Of course, if the inner destination address
is the RoA (local access traffic) then the RoA re-encapsulation is not
required. This complicates the FA visitor compared to the Nested Model where
the RoA is always visible. After decapsulating from the FA CoA, the FA checks
that the packet came via the registered RMA for that MN by checking the
source address on the encapsulation towards the FA. The FA and/or RMA may
also undertake HoA specific processing for other previously mentioned
reasons, based on AAA profile or operator policy. The HoA is made locally-
unique in the FA through the concatenation with the MSCoA, and in the RMA
through concatenation with the RoA.
Note that if local access is also requested, then the RMA needs to be able to
distinguish between encapsulated packets sent from a specific HA as part of
RA RMA forwarding, and unencapsulated/encapsulated packets sent from CNs as
part of the local access service. This is to avoid the RMA attempting to
incorrectly strip the RoA. In both cases, the packets are addressed to the
RoA. Therefore, to support LA as well as RA access, the RMA Concat module
must inspect the incoming source address to match it against a known HA
before undertaking concatenated switching. Similarly, the FA needs to have an
additional entry for the LA visitor list for the RoA, which is created as
part of the LA MIP Layer signalling. The Concat module must therefore analyse
all packets whilst the GFA module only inspects packets from registered HAs.
However, when the GFA module needs to inspect and switch a packet, this
processing is more intensive (source, dest, HoA check) than necessary for the
Concat module which simply uses the incoming interface (source/dest check).
This enables the Concat module to easily switch packets, encapsulated from a
registered HA to a specific RoA (RA layer), whilst encapsulating packets from
arbitrary CNs (whether encapsulated or not) to the same RoA (LA layer) in a
single module.
5.5.6 RMA Availability
A detailed comparison between the four modes, and specifically between the
two new modes and the existing standard and GFA modes, is distributed
throughout this document. A specific and very important issue covered here is
the RMA availability and its impact on the system.
A.W. O'Neill Expires Oct 2002 [Page 16]
INTERNET-DRAFT Regional Mobility Agent Signalling May 2002
GFA mode here and in [RegTun] requires a highly stateful core node that is
tied into both the MN and the HA through installed registration state. Such a
core box, which can have a large number of installed flows needs to be
high availability such that its failure is very rare, but even then still
catastrophic. This is because recovery requires each MN to re-install
bindings into the remote HAs as well as into the regional element. Hot
standby can be used between regional nodes to quickly recover the MN to GFA
state but this does not help with the remote access layer binding in the
global HA and incures obvious complexity and cost.
A major benefit of the design of Nested and Concat modes is that the CoA in
the HA is the RoA. This means that multiple RMAs can advertise routes to
prefixes covering the RoAs so that if one RMA is lost then traffic to the RoA
from global HAs will automatically be redirected to the next best RMA
according to routing, so enabling prefixes to be distributed across the
remaining RMAs. Note also that the RMA protection mechanisms are almost
exactly the same as the mechanisms used today for HAs, and given the RMAs
role as a local HA it is clear that these protection mechanisms would already
be required. In addition, the it is also clear that the RMA can also play the
role of a global HA, allocating out regional and global home addresses from
its subnet. Once again, the protection mechanisms envisaged for the RMA are
constent with that which is required for its role as a HA.
Replication between these boxes of the LA and RA state in the RMA can then
enable the LA and RA to recover quickly without MN activity. The replication
state for nested mode is significantly smaller than that required for Concat
mode but Concat mode forwarding is less bandwidth expensive. Alternatively,
each FA could use the routing entry failure for an RMA as indication that it
should trigger any mobiles that use that failed RMA to re-register to an
alternate RMA. This can be done simply by immediately sending
the address of the standby RMA address in an FAA to make the MNs not using
that standby RMA but were using the failed RMA (1+1 protection) to undertake
an RMA hand-off. This will cause them to issue a new LA Reg to the standby
RMA but because the region hasn't changed in the FAA will avoid them
achieving that by issuing a Combined RA/LA Reg to the oRMA. They will instead
simply issue an LA Reg v3 or v4. This is much less costly than replication
but requires MN activity. It is also slower than replicating LA and RA state
due to the time to detect the route failures to the RMA.
5.6. Distinguishing LA and RA MIP Messages
LA MIP messages and RA MIP messages need to be distinguished from each other
in the elements through which they are both forwarded. It may therefore be
appropriate to use new MIP messages type fields, flags or extensions for
these messages so that the required processing can be cleanly identified. The
correct balance between backwards compatibility and forward feature
enhancement needs to be determined. However, the following rules show how,
without these changes, that an MIP node can distinguish between LA, RA and
Combined LA/RA messaging when using standard MIP Registration messages and
the regional extensions from [RegTunMods].
LA messages are sent from a zero source address to the FA, and then onto a
dynamically allocated RMA. The RMA address may be advertised by the FA and
inserted either by the MN into the HA field or by the FA into the HFAIPext.
A.W. O'Neill Expires Oct 2002 [Page 17]
INTERNET-DRAFT Regional Mobility Agent Signalling May 2002
LA messages are subsequently sent from the RoA address to the RMA address via
each new FA. The CoA in the message is the FA CoA, which is either entered by
the MN or the FA, and can be either shared or MN specific. If the FA adds the
CoA then it is inserted into a HFAext and forwarded to the RMA. At each new
RMA, the LA must revert to sending the first LA message with a zero source
address until the new RoA is known.
RA MIP messages are always sent by the MN from the RoA address to the HA with
a CoA=RMA CoA which can be either a MN specific CoA (MSCoA=RoA) or an RMA
shared CoA (SHCoA). The message is potentially routed via the FA and/or the
RMA.
The FA can therefore distinguish between LA and RA messages because an LA
message will either be sent from a zero source address, or sent from the
RoA address with a HA field set to a local RMA. In contrast, RA messages
are never sent to the FA with a zero source address and when they are sent
from the RoA address they never have a HA field=local RMA because that by
definition is an LA MIP message.
The RMA can distinguish between LA MIP messages and RA MIP messages by
checking the HA (which might be zero) or the HFAIPext of the message. An
LA message will have one of these set to the address of the RMA. Otherwise
it is an RA message and the HA or HFAIPext will be set to a global HA.
A HA is only visited by RA messages and the HA (which might be zero) or
HFAIPext will then match the address of the HA.
Combined LA/RA messages are only sent during inter-RMA hand-off via a new
RMA. They are always sent with a zero source address with the HA field set to
either the global HA or the oRMA.
The FA can distinguish this from an LA Reg because the HA field is neither
zero nor a local RMA at that FA. The FA can distinguish this from an RA
Reg because of the zero source address.
The nRMA can distinguish this from the LA Reg because the HA field is set
and not equal to the nRMA address. The nRMA can distinguish this from a
normal RA because the HFAIPext from the FA is included and contains the
nRMA address
The oRMA/HA can distinguish this from a normal RA or LA message because
the HFAIPext and HFAext is included.
It is for further study if these rules are sufficient for all scenarios or
ideal from an inplementation perspective. Specifically, the RA layer is the
standard MIP remote access layer and this should clearly not change MIP
message types. A new type for LA layer MIP messages will make RA v LA message
detection in the FA and RMA much more efficient with no backwards
compatibility consequences because the LA does not presently exist. The RA
layer can undertake MIP hand-offs and utilise regional signalling as
presently proposed in MIP but only the LA layer will support aggregated
regional hand-off, and the RMA discovery and state construction in support of
this. A major area of development and standards work is to ensure through LA
and RA stack communications and AS, AA message processing that the activities
of the two layers are clean and coordinated. This is discussed in section 10.
A.W. O'Neill Expires Oct 2002 [Page 18]
INTERNET-DRAFT Regional Mobility Agent Signalling May 2002
5.7 Summary of MIP Signalling Additions
The FAA, LA and RA messages can behave initially very much like existing
standard MIP messages in Nested Mode but become more complex as features are
added and specifically regional extensions (RA RREQ v3 etc) are supported.
5.7.1 Feature selection
The LA layer elements all need to agree between options such as;
Service mode Is LA service required ?
RMA RA forwarding mode Standard, Nested, Concat, GFA for all RA sessions
RoA address type Public or private address
NAT Option Permitted or barred (for private RoA)
FA CoA type MSCoA or SHCoA
The LA layer needs to indicate if the MN is seeking local access service and
if so whether a private or public RoA is requested. If the RoA is private
then the MN can request to also access NAT features to be able to gain public
Internet access. This has implications on the reverse tunnelling requirements
which are discussed in section 10. The default RA forwarding mode needs to be
agreed in advance at the LA layer for all RA sessions above that LA layer so
that the correct type of FA CoA can be assigned. This default can be
overruled though for a specific RA session at the RA layer potentially
causing a change in the type of CoA for all RA sessions (MSCoA instead of
SHCoA for example).
The RA layer elements need to select and agree between options such as;
Service Mode Is RA service required ?
RMA RA forwarding mode Standard, Nested, Concat, GFA for one RA session
HoA address type Public or private HoA
NAT Traversal Option Permitted or Barred (for RA MIP RREQ/RREP)
RMA CoA type MSCoA or SHCoA
This time it is the RA service layer that is being configured and includes
the type of HoA address and RMA CoA, for the specific RA session. If re-using
the LA default values then these are merely repeated here. The NAT traversal
option is to enable permission for the RA layer registration to traverse a
NAT if the RoA is private. This enables the MN to request and the operator to
restrict the scope of registration which might be intra or inter-domain.
The style extension is used to communicate these various settings and is
optionally carried in all Registration messages, as discussed in section 10.
If it is absent then the default settings according to either operator policy
as modified by the MN profile are applied. The LA layer can include both LA
and RA layer stylexts so that the AAA requirements back to the AAAH can be
determined in one RTT. In addition, both LA and RA layer stylext can be
included in the RA layer for a Combined RA/LA MIP Reg. If the stylext was
understood and correctly processed by the FA and RMA then the returned
stylext will indicate the RMA/FA capabilities and installed
features. The specific type of support at the RMA, is known to the FA, as it
shares a close topological and configuration relationship with its RMA(s).
The FA can therefore tailor the stylext settings to match the known/learned
RMA capabilities before forwarding the LA MIP Reg to the RMA.
A.W. O'Neill Expires Oct 2002 [Page 19]
INTERNET-DRAFT Regional Mobility Agent Signalling May 2002
5.7.2 FAA Modifications
The FAA needs to include the FA-NAI and the shared FA CoA for movement
detection purposes. The FA-NAI must be structured to indicate the FA, the
region of that FA and the domain of that FA. This is used for inter-region
movement detection in the absence of the 'I' bit being set in the FAA. An FA-
NAI with region information informs a MN that it is capable of at least
Nested Mode.
The FAA needs to additionally indicate through the 'R' bit if the MN should
RA register through the FA for remote access sessions. The MN can then decide
whether to send an RA Reg v1 or RA Reg v2.
The FAA must indicate if regional signalling is supported via the 'I' bit.
The 'I' bit is advertised in FAAs if the FA knows in advance that it has at
least one RMA that supports regional registration. The 'I' bit also indicates
that the FAA contains RMA address information for tracking regional movement.
The 'I' bit is therefore rescoped from [RegTun] and used to indicate to the
MN, in combination with an FA-NAI with region structure, that RA Reg v3,
combined LA/RA Signalling, and GFA/Concatenated Mode are likely supported in
the FA/RMA pair, as well as HFAext and HFAIPext extensions and associated
authentication.
A number of other FAA changes are then required depending on how the LA and
RA layers are implementated. These are discussed in section 10.
5.7.3 Regional Signalling
To support the full range of service and forwarding modes, the following
changes to MIP signalling are required which are outlined in [RegTunMods].
The LA message needs to be able to be sent with a zero CoA so that the FA can
dynamically allocate a MN specific CoA and insert it into the HFAext when
Concat mode is added. This can be avoided if the FA is alternatively able to
advertise a MN specific CoA to the MN in a unicast FAA when Concat mode is
mandated. The FA must always return the HFAext to the MN in the RREP.
The LA message needs to be sent with a zero HA address so that the FA can
dynamically allocate the RMA, from a set of RMAs, rather than the MN always
using the default RMA that is advertised in the FAA. The FA inserts the
allocated RMA address into the HFAIPext and returns it to the MN in the RREP.
The RA message needs to occasionally be sent with a zero CoA when using Reg
v3 and Combined RA/LA signalling. This is specifically necessary in the case
of Reg v3 for GFA mode. The RMA uses the HFAext to inform both the HA (RREQ)
and the MN (RREP) of the RMA CoA. The GFA CoA can alternatively be generated
in advance of the RA Reg, as a result of the LA layer Registration, with the
RMA returning the GFA CoA to the MN in an HFAext. This is the GFA SHCoA that
is required for GFA mode only. This is because the GFA CoA for Nested and
Concat is the RoA which is already returned in the LA Reply. The GFA CoA
should be suitable for the default RA forwarding mode identified in the LA
Reg. The RA Reg can then generally avoid using a CoA=0 except when the GFA
CoA is HA specific due to disparate addressing plans. For combined
signalling, the GFA CoA is always zero through a new RMA because the GFA CoA
is not known yet for any RA mode.
A.W. O'Neill Expires Oct 2002 [Page 20]
INTERNET-DRAFT Regional Mobility Agent Signalling May 2002
The HA needs to be able to receive and process HFAext and HFAIPext for
combined LA/RA signalling.
The PFANE and BU semantics for inter-FA hand-off need to be generalised to
support other transient forwarding modes by being able to carry both MN
specific and shared FA CoAs.
The LA and RA layer needs to be able to carry the PRANE extension for inter-
RMA and oRMA-nFA transient forwarding.
The LA and RA layers need to be able to carry the Style extension (stylext).
Specifically, the LA layer must be able to carry both LA and RA stylext so
that a single AAA exchange from the FA can fetch the required state for both
layers. In addition, the RA layer also needs to carry both LA and RA stylext
so that combined signalling is possible at each new RMA.
The LA layer needs to carry a MN-NAI and a MN-AAA auth ext so that the MN can
obtain AAA state via the FA, from the home wireless operator via the local
wireless operator. The RA layer also needs to be able to carry an NAI and AAA
auth to be able to fetch RA session specific state from a third party service
provider that is specifically not the home wireless operator. The discussion
underpinning these requirements are detailed in [NestMIP].
Other changes are detailed in the text in this draft.
5.8 Backwards Compatibility Issues
5.8.1 General
A legacy FA cannot support this draft without being able to advertise the FA-
NAI and undertaking configuration changes to restructure the FA-NAI scheme. A
compliant MN can detect the difference between a legacy and non-legacy FA by
the FA-NAI structure whilst a legacy MN will either ignore the FA-NAI or
process it and correctly miss the additional regional information in the NAI.
A compliant FA must at least advertise a FA-NAI with the region information,
and must undertake ingress filtering on the dynamically assigned RoA. With
the 'R' bit set, the FA must be able to also support both LA and RA visitor
lists as documented above. This simply means that a single MN must be able to
have two active Registrations with two HAs (the RMA and the global HA). The
FA must then update both LA and RA visitor lists when an LA hand-off occurs.
A legacy MN will not interpret the FAA regional information and therefore
will be unaware of the existence of regions or the ability to undertake two
coordinated LA and RA MIP layers. This MN can undertake standard MIP and
request either LA (local HA) or RA access (global HA) at the RA layer, which
the AAA system may accept. It is likely that the RA layer request might be
refused if the HA is not owned by specific operators, whose HA availability
and performance is trusted, and will most likely be refused if another MIP
session already exists due to issues identified in [ParallelMIP].
The RMA is a new element and in the basic Nested model with RA RREQ v1/v2 can
be a standard HA that supports dynamic HA and HoA assignment with associated
AAA and security mechanisms.
A.W. O'Neill Expires Oct 2002 [Page 21]
INTERNET-DRAFT Regional Mobility Agent Signalling May 2002
When the 'I' bit in the FAA is not set, a legacy global HA sees only a
request to forward to a CCoA with the 'D' bit set, and therefore is fully
supported because the HA/HoA/CoA fields will have been populated by the AAA
system and by the LA layer.
For the FA, RMA and the global HA, the following specific issues also occur
when the 'I' bit is advertised to the MN in the FAA.
5.8.2 LA RREQ Zero CoA field (dynamic FA CoA assignment)
The MN should only send a zero CoA in the MIP Reg if the 'I' bit is set which
indicates that the RMA supports this feature. Dynamic FA CoA assignment
requires the FA to send the CoA to the RMA in the HFAext. If the RMA does not
support this (a configuration error condition given the FA-RMA relationship)
then the RREQ will be refused and the HFAext will not be returned to the FA
as confirmation. This will be detected by the FA, which then inserts the
HFAext into the RREP so that the MN can set the FACoA in a second attempt.
5.8.3 RA RREQ zero CoA field (Dynamic RMA CoA Assignment)
The MN should only send this if it believes that the HA supports this
extension. The RMA assigns the CoA and forwards it to the global HA in the
HFAext. If the HA does not support this extension then the HA will fail to
return the HFAext which will be detected by the RMA. The RMA then inserts the
HFAext so that the MN can set the CoA field itself in a second attempt.
5.8.4 LA RREQ zero HA field (dynamic RMA assignment)
The MN can allow the FA to assign the RMA, potentially via the AAA system. If
this is achieved by routing the request through the AAA system, then the RREP
will include the RMA and RoA. If the 'I' bit is set then this can
alternatively be achieved using the HFAIPext. The FA should then return the
HFAIPext including the dynamically assigned RMA to the MN in the RREP if the
RREQ was successful at the RMA. Any local HA (RMA) that supports dynamic
assignment can therefore support LA signalling in some form.
5.9 Signalling and Forwarding Evolution
From an evolutionary perspective, it can be seen that Nested MIP can be
supported with very little changes to MIP standards, with these changes
limited to the co-existance and cooperation between two MIP signalling layers
in the MN, with the FA undertaking ingress filtering checks on the
dynamically assigned RoA (local HoA), and the FA-NAI being structured to
identify the FA as well as the region so that the MN can execute inter-region
hand-offs as well as inter-FA hand-offs. These two MIP layers can next be
exposed to the FA by enabling RA registration via that FA (setting the 'R'
bit) and by adding the RA visitor list to the LA visitor list. The RA layer
MIP stack needs to see FAAs to be able to detect the 'R' bit setting and such
issues are discussed in more detail in section 10. In either case, inter-
region hand-off is supported by using inter-FA transient forwarding and
potentially by oRMA to nFA transient forwarding. Finally, the LA signalling
can be enhanced to support inter-region forwarding from the oRMA to the nFA,
and from the oRMA to the mRMA, using the Previous RMA Notification Extension
(PRANE), and/or existing inter-regional SAs between the oRMA and nFA/nRMA.
A.W. O'Neill Expires Oct 2002 [Page 22]
INTERNET-DRAFT Regional Mobility Agent Signalling May 2002
Major modifications are however required to MNs, FAs and HAs to enable RA
Registration v3 signalling and efficient combined LA/RA signalling, to enable
the FA to advertise the default RMA address in an FAA, and to enable the FA
to undertake dynamic RMA and FA CoA assignment. Almost all of these changes
are however equivalent to those proposed for Regional Registration {RegTun]
and a common signalling plan should be devised. Once RA Reg v3 is possible
then the HA FA and MN can be extended to support all four types of forwarding
(standard HA, Nested, GFA and Concat) using the Style Extension to indicate
the requested mode. Modifications are then possible in MNs, FAs and HAs to
support the new inter-RMA hand-off extensions to enable hand-off between the
different forwarding models to facilitate incremental and heterogeneous
deployment.
Essentially therefore, this draft documents an evolution of backwards
compatible capabilities as MIP standards are evolved, yielding a flexible
platform where the forwarding and hand-off can be optimised on a per MN, per
region or per operator basis. At all stages, the operator is able to decide
how stateful an element the RMA becomes with the benefit being the improved
bandwidth efficiencies through switching rather than encapsulated forwarding.
The operator is also able to use simple LA and RA signalling with inter-FA
transient forwarding or scale up the LA and/or RA signalling complexity to
first enable oRMA to nFA transient forwarding and finally inter-RMA transient
forwarding. The additional complexity of the signalling improves the
efficiency of the transient forwarding and reduces the burstiness of the RA
layer hand-offs by giving the MN more time to execute these hand-offs.
Restated, the increasing period for RA hand-offs increases the number of RA
sessions that a single MN can maintain.
6. Registration Refresh and Hand-Off Processing
In summary, the LA layer messaging creates and moves the LA visitor list
state between FAs and RMAs during hand-offs. This enables transient
forwarding of the local access traffic on the oRoA. The LA hand-off also
preserves RA layer traffic through transient forwarding by generally making
the RA traffic look like LA traffic on the nRoA, that is valid in the updated
LA visitor list. After transient forwarding ceases, the forwarding for the
oRoA will be lost but the nRoA will then be in place and will be used for new
local access sessions. This will in addition enable traffic to continue to be
forwarded from the oRoA via that nRoA until the RA layer updates occur. The
RA layer hand-off then bypasses the oRMA and can also optionally elevate the
oRMA to global HA status so that any long term sessions on the oRoA can be
maintained.
6.1 LA Refresh
-- LAReg +---+ LAReg +----+
|MN| --------> |oFA| --------> |oRMA|
-- +---+ +----+
Figure 7. LA Refresh
This is based on a standard MIP Registration (LA Reg v1) from the MN through
the FA to the assigned RMA (local HA).
A.W. O'Neill Expires Oct 2002 [Page 23]
INTERNET-DRAFT Regional Mobility Agent Signalling May 2002
This enables the RMA to continue to forward any local access packets arriving
at that RMA, addressed to the RoA, to the stated FA CoA. The basic LA MIP
Registration / Reply is the same for Nested, Concatenated and GFA forwarding
modes.
Major changes between the forwarding modes are only seen during inter-FA, and
inter-RMA LA hand-offs, and of course in RA forwarding.
6.2 LA Hand-off (Inter-FA)
-- +---+
:MN: |oFA|
-- +---+
^
: ª
: MOVE ªBU (PFANE)
V ª
ª
-- LAReg +---+ LAReg +----+
|MN| --------> |nFA| --------> |oRMA|
-- +---+ +----+
Figure 8. LA Hand-off
This uses an LA MIP Reg v2 to the present RMA, through the new FA, to update
the FA CoA for the MN specific RoA. This will cause any local access and
remote access traffic for the MN to be redirected to the new FA CoA. The
hand-off can in addition use the mechanisms from [RoutOpt] and [LowLat] to
enable in-flight LA and RA packets, that have been tunnelled towards the old
FA CoA, to be forwarded to the new FA CoA. This exchange can also enable the
MN-FA SA to be context transferred to the nFA.
The Inter-FA LA Hand-off can always be undertaken from a new FA that is
within the region of the present RMA (intra-RMA). It can also be undertaken
from a new FA that is outside the region of the present RMA if that new FA
meets a number of special inter-region hand-off constraints, including having
access to a suitable SA with the present RMA to authenticate the hand-off,
and having a suitable way to authenticate the Binding Updates such as the
PFANE extension. This mechanism would typically only be used if the new FA
did not have an available RMA or access to that RMA was in some way delayed
or constrained. This may well be the case for inter-technology hand-off.
6.2.1 Nested Version (using PFANE)
This LA Regv2 installs a persistent forwarding entry in the oRMA for the old
RoA that points local and remote access packets for that MN to the new FA
CoA. The LA Reg also installs a persistent entry in the newFA for the old RoA
and the PFANE/BU reports the new FA CoA to the old FA for the existing oRoA
to facilitate transient forwarding. Nested transient forwarding is based on
the RoA and is towards the new FA SHCoA. This is the same as existing MIP
specs with the exception that the RoA is being used for LA traffic and all RA
layer sessions (with HoAs).
A.W. O'Neill Expires Oct 2002 [Page 24]
INTERNET-DRAFT Regional Mobility Agent Signalling May 2002
6.2.2 Concatenated Version (using PFANE for RA RREQ v3 only)
This LA Regv2 installs a forwarding entry in the RMA for the RoA (local and
remote access) that points local and remote access packets for that MN to the
new FA MSCoA and away from the old FA MSCoA. The PFANE installs a persistent
entry in the newFA for the new MSCoA (local and remote access) pointing to
the MN interface from either the oRMA or the oFA. The PFANE triggered BU
causes the old FA to switch local and remote access traffic from the old FA
MSCoA to the new FA MSCoA and forwards to the new FA. This is different to
existing MIP specs but re-uses the same signalling messages.
6.2.3 GFA Version (using PFANE for RA RREQ v3 only)
This is as for Concatenated MIP except that the old and new CoA are FA SHCoAs
and forwarding in the oRMA, oFA and nFA is for the RoA (local access) and the
HoA (remote access). HoA and RoA state is therefore required and transient
forwarding is as per existing MIP specs towards the new FA SHCoA. Note that
the oRMA CoA is a SHCoA and not the oRoA.
6.3 LA Hand-off (Inter-RMA, Inter-FA)
-- +---+ +----+
:MN: |oFA| |oRMA|
-- +---+ +----+
^
: ª
: MOVE ªBU(PFANE)
V ª
ª
-- LAReg +---+ LAReg +----+
|MN| --------> |nFA| --------> |nRMA|
-- +---+ +----+
Figure 9. LA Hand-off with PFANE
The inter-RMA, inter-FA LA hand-off is normally be undertaken by sending a LA
MIP Reg v3 to the new RMA, via a new FA (and FA CoA), and in the process
acquiring a new RoA. The hand-off can in addition use the mechanisms from
[RoutOpt] and [LowLat] to enable in-flight packets towards the old FA to be
forwarded to the new FA. Note that the state for the nRoA is not in place
until the RREP returns to the MN. This is fine because no traffic will have
been initiated from the MN to that new local address. In addition, no inter-
RMA forwarding that uses that nRoA is being requested.
The visitor lists must temporarily support both the old RoA and the new RoA
for this to succeed. The host RA/LA stack sees this hand-off as the addition
of a new interface with the new RoA and the subsequent loss of the old
interface with the old RoA. The network driver sees the RMA, FA, FA CoA and
RoA change, deals with relaying of packets sent via the oFA, and also handles
the timing of the interface up and down signals. The nature of the inter-FA
forwarding depends on the capabilities of the old and new FA, as well as the
requested type of RMA forwarding from the newRMA. There are two permutations
that are covered in detail in section 7.
A.W. O'Neill Expires Oct 2002 [Page 25]
INTERNET-DRAFT Regional Mobility Agent Signalling May 2002
There are nine types of old RMA / new RMA mode combinations with three simple
examples given below but the full nine combinations are analysed in section 9
as part of inter-RMA forwarding. Note that five of these combinations can be
avoided, if GFA deployment does not occur, and hence avoiding the backwards
compatibility requirement.
6.3.1 Nested Version (Nested RMA to Nested RMA using PFANE)
The LA Registration is directed to the new RMA rather than the old RMA. The
new FA SHCoA is of course used to create the binding in the new RMA. The
modified PFANE extension is used to trigger a BU in the newFA back to the
oldFA. This installs a forwarding entry in the oFA that points local and
remote access packets for that MN to the new FA SHCoA. The PFANE installs a
temporary entry in the newFA for the old RoA as well as a new persistent
entry for the new RoA that will be constructed by the LA Reg to the new RMA.
6.3.2 Concatenated Version (Concat RMA to Concat RMA using PFANE)
The LA Reg is as previously described in section 6.2.1. but this time
installs the new FA MSCoA from the new FA into the new RMA. The PFANE
triggered BU installs a forwarding entry in the oFA for the previous oRoA
(local access) and MSCoA (remote access) that points packets for that MN to
the new FA MSCoA. The modified PFANE installs a temporary entry in the newFA
for the old RoA from the oFA (local and remote access), as well as a
persistent entry for the new RoA from CNs (local access) and for the new FA
MSCoA from the nRMA (remote access).
6.3.3 GFA Version (GFA RMA to GFA RMA using PFANE)
This is as for Concatenated MIP except that the old and new FA CoA are shared
and forwarding is for the RoA (local access) and the HoA (remote access).
6.4 Enhanced LA Hand-off (Inter-RMA, Inter-FA)
-- +---+ +----+
:MN: |oFA| |oRMA|
-- +---+ +----+
^ / ^
: ª / ª
: MOVE ªBU(PF) / ªBU (PRANE)
V ª /BU(PRANE)ª
ª / ª
-- LAReg +---+ LAReg +----+
|MN| --------> |nFA| --------> |nRMA|
-- +---+ +----+
Figure 10. LA hand-off with PRANE
The inter-RMA, inter-FA LA hand-off in 6.2 can be enhanced by the MN
including a Previous RMA Notification Extension (PRANE) in the LA Reg along
with the PFANE (PF) (creating an LA Reg v4). The nFA can send an
authenticated BU to the oRMA to facilitate inter-region transient forwarding
from the oRMA (to the nFA) instead of simply relying on the more expensive
(latency, bandwidth) inter-FA forwarding.
A.W. O'Neill Expires Oct 2002 [Page 26]
INTERNET-DRAFT Regional Mobility Agent Signalling May 2002
The MN pre-calculates the BU authentication for the nFA in a similar manner
to that used for PFANE in [RoutOpt]. This forwarding relies on the existing
MN-oRMA SA and ensures that the oRMA can safely redirect the forwarding away
from the oFA to the nFA. The constraints on this are covered in section 10,
with the transient forwarding shown in section 8.
If the nRMA shares an authenticating SA with the oRMA, then the PRANE can
trigger the nRMA to issue a BU to the oRMA on behalf of the MN with the BUack
again being returned to the MN. The SA is required to authenticate the
dynamically allocated RMA CoA that must be added by the nRMA as it cannot be
known in advance by the MN and hence authenticated. This SA also enables the
oRMA to forward the MN-RMA SA and the oRMA-HA SAs to the nRMA as part of the
hand-off. This inter region SA will be common within an operators domain and
may be even be available across operator boundaries to ensure that inter-RMA
traffic is exposed to inter-operator policy in the core of the network, and
to minimise the need for extensive inter-FA inter-operator security
configuration. In the latter case, the short period of inter-FA forwarding
across operator boundaries could be enabled simply on the PFANE and in
advance of the authentication check for the MN in the new operators domain.
Note that the state for forwarding the nRoA is not fully in place until the
RREP returns to the MN, because the nRoA was not in the RREQ. This is fine
because no traffic will have been initiated from the MN to that new local
address. In addition, any inter-RMA forwarding that uses that nRoA is being
requested by a BU whilst the RMA returns the RREP to the MN. The nRMA does
not therefore wait for the result of the BU as the MN will see the BUack
itself and any failure will be compensated by the other forms of inter-region
forwarding. There may be a requirement to slightly delay the forwarding by
the oRMA towards the nRMA using the nRMA to ensure that the RREP has reached
the MN. This dependence on the RREP being received is a specific week point
in the design and is not generally applicable to GFA forwarding when it uses
a known GFA CoA in the RREQ. Other strategies to overcome this can therefore
include using a GFA SHCoA instead of the nRoA for transient forwarding of
traffic on the oRoA, but this is not further detailed here as the
cost/benefit of this needs further assessment.
Another technique might be to modify the BUack so that in this case it
contains the nRoA and not the oRoA, and hence can enable the MN to resend the
RREQ for the nRMA, nRoA pair, if received before the RREP, to ensure the
visitor list entries are in place.
6.5 RA Layer Registration Update
The MN populates the CoA field with the RoA (Nested, Concat) that was
assigned at the LA layer to create a CCoA and sets the 'D' bit. In the case
of GFA mode, the RMA SHCoA (GFA) is instead used and the 'D' bit is not set.
The message is directed to the HA for the HoA of the Remote Access session
via a range of routes as discussed below.
A.W. O'Neill Expires Oct 2002 [Page 27]
INTERNET-DRAFT Regional Mobility Agent Signalling May 2002
6.5.1 RA RREQ v1 (Nested only)
-- RAReg +----+
|MN| ------------------------------------------> | HA |
-- +----+
Figure 11. RA Reg v1
This uses a standard MIP Registration with the MN populating the HA/HoA
fields with its statically assigned address information from the home subnet,
or using MIP to dynamically assign those elements. The MN then forwards the
MIP Reg directly to the global HA with the 'D' bit set. Forwarding by the HA
is into a tunnel with the RoA as a destination address, and the RMA adds an
additional tunnel to forward to the present FA CoA. This is default Nested
MIP forwarding.
The Style Extension is optionally be used here to overrule the default RA
forwarding mode that was agreed at the LA layer.
The RA visitor list is maintained in the MN to ensure that packets for the
HoA are only received from the registered HA. There is no RA visitor list in
the FA because the FA is not visited by the Registration signalling. This
means however that injected packets towards the HoA, from illegal 'HA'
sources can only be detected at the MN and after consuming backhaul and air-
link resources. The operator can however configure a firewall in the FA to
snoop packets and to therefore indirectly control allowed packet flows.
6.5.2 RA RREQ v2 (Nested Only)
-- RAReg +---+ RAReg +----+
|MN| --------> :oFA: -------------------------> | HA |
-- +---+ +----+
Figure 12. RA Reg v2
This uses a standard MIP CCoA Registration via the FA. The FA forwarding
option can be used by the MN when the FA indicates support for this by
setting the 'R' bit in the FAA. The 'R' bit is not specific to Nested MIP and
therefore a MN should not assume that the 'R' bit signifies support for the
Nested MIP feature. This can only be discovered through the processing of the
Style Extension at the LA layer. The stylext can be included at the RA layer
to control RA service features. If the Stylext is missing or ignored, then
the Registration looks like a standard remote access registration with a CCoA
via an FA, and no Nested MIP specific additional features will be invoked.
The RA visitor list is again maintained in the MN to ensure that packets for
the HoA are only received in the MN from the correct HA, via the correct FA.
The RA visitor list in the FA can check that the RoA flow arrived from the
correct RMA source address.
A.W. O'Neill Expires Oct 2002 [Page 28]
INTERNET-DRAFT Regional Mobility Agent Signalling May 2002
The RA visitor list in the FA can optionally check to make sure that the HoA
within the RoA flow was originally sent from the correct HA, and that the RoA
and HoA are owned by the same MN. This enables some falsely injected packets,
from unknown remote access gateways, to be removed before they consume air-
link resources. However, this HoA specific state must then be maintained
using Context Transfer, triggered by aggregated LA MIP Reg signalling, to
survive inter-FA hand-off.
6.5.3 RA RREQ v3 (Nested, Concat or GFA)
-- RAReg +---+ RAReg +----+ or RAReg +----+
|MN| --------> :oFA: --------> :oRMA: --------> | HA |
-- +---+ +----+ +----+
Figure 13. RA Reg v3
This re-uses a similar model to the Home MIP Registration from [RegTun] as
modified by [RegTunMods] and is available if the 'I' bit is set in the FAA.
The MN forwards the MIP Reg to the FA as a result of the 'R' bit. The FA then
makes an operator policy decision, based on the LA layer state, the RA Reg
contents as well as operator and MN specific AAA state, whether to forward
via the RMA (v3) or whether to send directly to the HA (v2). If the RREG is
routed via the RMA then the full range of forwarding models are possible.
The Style Extension is optionally used here simply for the MN to request a
non default RA service features, as opposed to simply relying on the features
in the MN AAA profile, and the forwarding mode agreed at the LA layer.
The RA visitor list is maintained in the MN, and may be maintained in the FA
and the RMA based on operator policy. These visitor lists act to ensure that
packets for the HoA are only received in the MN from the correct HA. The
checks in the FA and RMA minimize opportunities for falsely injected packets
from consuming expensive backhaul and air-link resources.
6.6 RA Hand-off (inter-RMA, optionally inter-FA)
-- +---+ +----+
:MN: |oFA| |oRMA|
-- +---+ +----+
^
: |
: MOVE | RAReg
V |
|
-- RAReg +---+ RAReg +----+ or RAReg +----+
|MN| --------> :nFA: --------> :nRMA: --------> | HA |
-- +---+ +----+ +----+
Figure 14. RA Reg v3 Hand-off
The LA MIP hand-off configures the new RMA/RoA and installs the inter-region
forwarding (inter-FA, inter-RMA and/or RMA->FA) for the RA MIP updates.
A.W. O'Neill Expires Oct 2002 [Page 29]
INTERNET-DRAFT Regional Mobility Agent Signalling May 2002
The RA MIP Reg is then used, to each HA with which the MN has a remote access
session, to update the CCoA (the RoA) of the HoA used for that session.
In either the HA=oRMA or global HA cases, the CCoA (which was the old RoA
from the old RMA), is replaced with the new RoA from the new RMA in the RA
Reg. The updated visitor list in the HA causes remote access packets to now
bypass the old RMA and instead be routed directly to the new RMA by using the
nRoA. Here it will be handled by the RA visitor list installed by the RA
hand-off message. If the RA hand-off is directed at the oRMA then it prepares
the old RMA/RoA for continued use via remote access to the nRoA address.
This is only possible if the oRMA-nRMA or the HA-nRMA share or can generate
an authenticating SA to protect the extensions between these elements. These
can be acquired from the AAA system based on the optional local and home AAA-
NAIs, or the HA-RMA SA can be CTed from the oRMA at the LA layer if an RMA-
RMA SA is in place, and the RMA-RMA SA can be manually or automatically
configured in sympathy with the RMA LA hand-off neighbours.
The RA MIP hand-off does not need to immediately follow the LA MIP hand-off
for the following reasons.
If the RA MIP hand-off was preceded by an LA MIP Reg v4 then inter-RMA
forwarding will be valid for a significant number of inter-FA hand-offs in
the new region. The MN can therefore distribute the RA MIP signalling load
(across potentially multiple remote access sessions), and refresh them in
order of the remaining lifetimes of the visitor list entries. Inter-FA
forwarding in this case is only needed to forward the packets that are in-
flight between the old RMA and the old FA, to the new FA. This is because
in-flight packets between the HA and the old RMA will instead use inter-
RMA forwarding. Note that if oRMA -> nFA forwarding is in place then the
MN will preferably need to execute all of its RA MIP hand-offs before
another two inter-FA hand-offs occur to avoid any inter-FA chaining.
If the RA MIP hand-off was preceded by a LA MIP Regv3 then no inter-RMA
forwarding will be in place but there will still be inter-FA forwarding.
In this case the MN will preferably need to execute all of its RA MIP
hand-offs before another inter-FA hand-off occurs to avoid any chaining.
Methods for improving the speed of RA updates are discussed in section 10.
6.7 Combined LA/RA Hand-off (for the oRMA)
-- +---+ +----+
:MN: |oFA| |oRMA|
-- +---+ +----+
^ ^
: ª ª
: MOVE ªBU (PFANE) ªCReg
V ª ª
ª ª
-- CReg +---+ CReg +----+
|MN| --------> |nFA| --------> |nRMA|
-- +---+ +----+
Figure 15. Combined RA/LA v1
A.W. O'Neill Expires Oct 2002 [Page 30]
INTERNET-DRAFT Regional Mobility Agent Signalling May 2002
Combined LA/RA Signalling is a basic feature of this draft when the 'I' bit
is set in the FAA (for HFAIPext and HFAext support) and no additional flags
or extension mechanisms are required to support it. New error codes may be
appropriate though but this is for further study.
The LA layer is typically used to dynamically acquire the RMA and the RoA at
each RMA, to trigger the fetching of the MN AAA profile, to negotiate the RA
forwarding mode and to agree the access mode. The RA layer can also undertake
this LA processing automatically by the FA using the HFAIPext (that is used
in GFA) to inform the MN of the assigned RMA, and the HFAext can be used to
carry the RMA CoA to the HA and the MN.
This particular Combined Registration is based on a combination of a LA MIP
Reg v3 and an RA MIP Reg v3. This Registration is routed via the new FA and
the new RMA to the old RMA. The CoA in the oRMA, for forwarding to the nRMA,
is the nRoA if Nested or Concat mode is requested at the nRMA. In GFA mode,
this CoA is generally a nRMA SHCoA. The Combined LA/RA MIP Reg is routed via
the new RMA to enable dynamic allocation of the new RoA. It is then sent to
the old RMA to transition the oRMA into the RA layer and thereby become a
global HA/HoA pair for the oRoA local address. This also cancels the LA
forwarding in the oRMA towards the oFA CoA. The Combined LA/RA Reg therefore
initialises persistent forwarding of LA traffic on the oRoA to the nRMA. This
forwarding is then subsequently maintained using RA MIP messages as with any
RA session.
The Combined LA/RA Reg also initializes transient forwarding towards the
nRMA, for remote access traffic from other global HAs sent towards the oRMA.
This transient forwarding continues for the lifetime of the temporary binding
signalled by the Reg. The precise mechanism for this forwarding depends on
the nature of the existing and new registrations (Nested, Concat or GFA) and
is discussed in section 9. A stylext should be used for both the LA and RA
layers to indicate the required features in each layer away from the default
features of this draft.
The message routing to the oRMA via the nRMA requires the two RMAs to share a
preconfigured or dynamically allocated security association to authenticate
the message exchanges. The nRMA only forwards the message to the oldRMA if it
has such an association otherwise the Combined LA/RA Reg fails to update the
oRMA but still returns the LA MIP Reg state from the nRMA in an LA MIP RREP,
returning the identification field from the RREQ.
Note that if the inter-RMA forwarding relies on the nRoA then it is correctly
installed by the RREQ in the nRMA and oRMA, but will not yet have been
installed in the nFA because this nRoA address was not in the RREQ until it
reached the oRMA where the nRoA is assigned. The oRMA must not therefore
start forwarding via the nRMA until sufficient time is given for the RREP to
return to the nFA via the nRMA. It is therefore preferable for the nRMA LA
layer to immediately send a RREP and then have the RA layer send a second
RREP from the oRMA in response to the Combined RREQ (although Identification
field issues have yet to be addressed here).
A.W. O'Neill Expires Oct 2002 [Page 31]
INTERNET-DRAFT Regional Mobility Agent Signalling May 2002
6.8 Combined RA/LA Hand-off (for other global HAs)
-- +---+ +----+
:MN: |oFA| |oRMA|
-- +---+ +----+
^ ^
: ª ª
: MOVE ªBU (PFANE) ªBU (PRANE)
V ª ª
ª ª
-- CReg +---+ CReg +----+ CReg +----+
|MN| --------> |nFA| --------> |nRMA| --------> | HA |
-- +---+ +----+ +----+
Figure 16. Combined RA/LA Reg v2
This is a combination of an LA Reg v4 and an RA Reg v3. It is used when only
transient forwarding is required from the oRMA for local and remote access
traffic. A stylext should be used for both the LA and RA layers to indicate
the required features in each layer away from the default features of this
draft. Note that there is a risk that forwarding to a distant HA like this
could result in an extended delay for the return of the combined Reg reply
and the associated LA parameters for the LA hand-off. However, during this
time, inter-RMA and inter-FA forwarding will continue for the oRoA.
The oRoA is lost once the transient forwarding has finished on the expiry of
the BU lifetime that is known to the MN. The oRMA in this case does not
transition to become a global HA and the oRoA does not become another HoA for
the MN. The target HA for the Combined RA/LA Reg can be any HA whether or not
it is presently an active RA session for the MN. The MN selects the target HA
based on local preference.
The security requirements are as for the component LA and RA messages
although the fact that the messages are combined places greater emphasis on
the need for a pre-configured RMA-RMA SA to be in place to avoid a AAA look-
up delaying any hand-off.
Once again, if the RA aspects of the Combined Reg fails then the LA Reg
aspects should still complete if possible, leaving in place an LA v4 hand-off
with transient forwarding. The converse is not applicable because if the LA
fails to the new RMA then the RA layer can also not complete as defined.
Once again, the FA visitor list state for the nRoA is not in place until the
RREP returns with that address. The GFA SHCoA, BU ack and the RREP solutions
from the nRMA can be again used here to assist in avoiding packets being
forwarded towards a black-hole.
7. Summary of Inter-FA Forwarding during Hand-off
The Inter-FA transient forwarding can be initiated using any mechanism
associated with an MIP inter-FA hand-off from [LowLat] or [RoutOpt]. The
below analysis assumes a PFANE triggered BU as in [RoutOpt] is used, being
sent from the nFA to the oFA, pre-authenticated by the MN. This can be
associated with an LA MIP RREQ v2,v3 or v4.
A.W. O'Neill Expires Oct 2002 [Page 32]
INTERNET-DRAFT Regional Mobility Agent Signalling May 2002
For LA MIP RREQ v2, which is never used for an inter-RMA hand-off, the RMA
forwarding mode is unchanged and so the BU does not need to indicate the nRMA
forwarding mode. For LA MIP RREQ v3 and v4, the BU also does not need to
inform the old FA of the nFA forwarding model because the only change is that
the nFA CoA is either a SHCoA or a MSCoA.
7.1 Transient forwarding for standard FA CoA switching
CN HA oRMA oFA nFA MN
Forward oLA CN----------------------------------------------------->oRoA
oRMA===>oFACoA x oFA===>nSHCoA
Forward RA CN------------------------------------------------------>HoA
HA==========================================>oRoA
oRMA===>oFACoA x oFA===>nSHCoA
Figure 17. FA CoA switching
The oFA decapsulates from the oFACoA inspects its binding cache for the
oRoA(Nested), oRoA+HoA(GFA), or incoming oMSCoA. This identifies the nFA and
so the oFA re-encapsulates into the nFA SHCoA. The nFA must then have visitor
list state for the oRoA (Nested) or oRoA+HoA (GFA) so that the arriving
packets can be forwarded to the correct MN. Note that when moving to or from
an FA that does not support Nested or Concat MIP, nor even supports RMAs, the
inter-FA forwarding is still installed towards the FA SHCoA due to the BU
being unchanged by this draft. Forwarding is only changed at the nFA
supporting Concat mode and only when moving to that nFA.
7.2 Transient forwarding for Concat CoA switching
CN HA oRMA oFA nFA MN
Forward oLA CN----------------------------------------------------->oRoA
oRMA===>oFACoA x oFA===>nMSCoA
Forward RA CN------------------------------------------------------>HoA
HA============================================>oRoA
oRMA===>oFACoA x oFA===>nMSCoA
Figure 18. Concat CoA Switching
The oFA decapsulates from the oFACoA inspects its binding cache for the
oRoA(Nested), HoA(GFA), or incoming oMSCoA. This identifies the nFA and so
the oFA re-encapsulates into the nFA MSCoA. The nFA must then have visitor
list state for the nFA MSCoA so that the arriving packets can be forwarded to
the correct MN.
A.W. O'Neill Expires Oct 2002 [Page 33]
INTERNET-DRAFT Regional Mobility Agent Signalling May 2002
8. Summary of Inter-Region Transient Forwarding (oRMA->nFA)
When a MN is equipped with an LA MIP v4 (PRANE capability) then it can
register with the nRMA and can in addition send a BU from the nFA to the oRMA
to instigate inter-region forwarding. Inter-region forwarding from the oRMA
to the nFA is more efficient (bandwidth, latency) which improves performance
and reduces the load on expensive access circuits.
The oRMA encapsulates LA packets sent to the oRoA into the nFA CoA. The oRMA
also encapsulates RA packets into the nFA CoA, sent from the HA to either the
oRoA (nested/concat) or the RMA SHCoA (GFA). The nFA does not yet know the
agreed nRMA forwarding mode and so should request Nested mode which is
supported by all RMAs and FAs. This also ensures that the MN can insert the
FA SHCoA into the PFANE and calculate the authenticator for the BU which it
could not do with a dynamically allocated FA MSCoA. The oRMA knows that such
all BUs from nFAs are for Nested forwarding and knows its own forwarding
mode. This means that once again the BU does not need to deal with signalling
the nFA mode.
8.1 Transient forwarding from Nested oRMA to Nested nFA
CN HA oRMA oFA nFA MN
Forward oLA CN----------------------------------------------------->oRoA
oRMA================>nSHCoA
Forward RA CN------------------------------------------------------>HoA
HA===========================================>oRoA
oRMA================>nSHCoA
Figure 19. Nested to Nested inter-region forwarding
The oRMA receives the BU containing the nFA CoA and the oRoA and encapsulates
traffic sent to the oRoA, into the nFA SHCoA based on the RoA state in the RA
visitor list. Both LA and RA traffic arrives at the nFA and is forwarded
based on the oRoA.
8.2 Transient forwarding from Concat oRMA to Nested nFA
CN HA oRMA oFA nFA MN
Forward oLA CN----------------------------------------------------->oRoA
oRMA================>nSHCoA
Forward RA CN------------------------------------------------------>HoA
HA==>oRoA x oRMA==============================>nRoA
oRMA================>nSHCoA
Figure 20. Concat to Nested Inter-region forwarding
A.W. O'Neill Expires Oct 2002 [Page 34]
INTERNET-DRAFT Regional Mobility Agent Signalling May 2002
The oRMA receives the BU containing the nFA CoA and the oRoA and switches
traffic from the HA to the oRoA, into a tunnel from oRMA to the oRoA, based
on the RA visitor list state. The oRMA then encapsulates this into the nFA
SHCoA based on the RoA state in the LA visitor list.
8.3 Transient forwarding from GFA oRMA to Nested nFA
CN HA oRMA oFA nFA MN
Forward oLA CN----------------------------------------------------->oRoA
oRMA================>nSHCoA
Forward RA CN------------------------------------------------------>HoA
HA==>oRMA x oRMA==============================>oRoA
oRMA================>nSHCoA
Figure 21. Concat to Nested Inter-region forwarding
This is as for Concat except that the traffic is received on the oRMA SH CoA,
and the RA visitor list contains HoA state as well as RoA state.
9. Summary of Inter-RMA Transient Forwarding during Hand-off
Inter-RMA transient forwarding is between two regional nodes rather than
between two edge FA nodes or a combination of RMA and FA. This is useful
because it is more scalable for neighboring regional nodes to share pre-
configured SAs and policies to secure and control the inter-regional
forwarding. It also enables early exposure to the policing, QoS and
accounting controls in the newRMA. The use of inter-RMA forwarding is also
useful during inter-domain handoffs where inter-operator service and
accounting policies need to applied. Finally, the transient forwarding can be
for a significant amount of time due to the much slower hand-off dynamics at
that layer, during which the MN can issue multiple RA MIP hand-offs to
multiple other global HAs to update them with the new RoA address.
The Inter-RMA transient forwarding can be initiated using either a BU from
the nRMA to the oRMA as part of an LA MIP RREQ v4, or by using an RA MIP RREQ
v3 to the oRMA via the nRMA after an LA MIP RREQ v3. The following examples
assume an LA MIP RREQ v4 and cover the combinations from and to Nested and
Concat RA layer forwarding modes in the old and new RMA. The examples are
without proxy CCoAs and therefore with encapsulation over the air interface
and only the forward directions are shown in a futile attempt for brevity.
A.W. O'Neill Expires Oct 2002 [Page 35]
INTERNET-DRAFT Regional Mobility Agent Signalling May 2002
9.1 Nested to Nested using Nested inter-RMA transient forwarding
CN HA oRMA nRMA FA MN
a)
Forward oLA CN----------------------------------------------------->oRoA
oRMA================>oSHCoA
Forward RA CN------------------------------------------------------>HoA
HA===========================================>oRoA
oRMA================>oSHCoA
b)
Forward oLA CN----------------------------------------------------->oRoA
oRMA============================>nRoA
nRMA===>nSHCoA
Forward RA CN------------------------------------------------------>HoA
HA===========================================>oRoA
oRMA============================>nRoA
nRMA===>nSHCoA
c)
Forward nLA CN----------------------------------------------------->nRoA
nRMA===>nSHCoA
Forward RA CN------------------------------------------------------>HoA
HA===========================================>nRoA
nRMA===>nSHCoA
Figure 22. Forwarding for Nested to Nested via Nested
a)Before LA Hand-off in the oFA/oRMA
The local access traffic (CN:oRoA) is being encapsulated into the oFA SHCoA
and then the oFA is decapsulating and forwarding to the MN using the oRoA.
Any remote access (HA:oRMA[CN:HoA]) is being encapsulated into the oFA SHCoA
and then the oFA is decapsulating and forwarding to the MN using the oRoA.
Note that the FA could also be decapsulating the oRoA header to check for
registered HA/HoAs if the FA optionally has HA/HoA specific processing.
For LA Hand-off.
The LA MIP Reg v4 sends the information to the nRMA, and a BU to the oRMA.
The LA Reg (nest) prepares the nFA to decapsulate packets from the nFA SHCoA
and forward nRoA and oRoA traffic to the MN (new state). The LA Reg (nest)
prepares the nRMA to encapsulate packets sent to the nRoA (from CNs and oRMA)
into the nFA SHCoA (new state, oRMA undertaking HA check). The inter-RMA BU
(nest) prepares the oRMA to encaps packets sent to the oRoA (from CNs and
registered HAs) into the nRoA and to cancel forwarding to the oFA SHCoA. All
packets now go from the oRMA to the nRMA, to the nFA, to the MN as in (b).
For RMA Hand-off
MN now leisurely sends an RA Reg (Nest) for each HoA/HA pair via nFA/nRMA.
The RA Reg (nest) prepares the nFA to decapsulate packets from the nFA SHCoA
and forward any RoAs to the MN (note FA already doing this). The RA Reg
(nest) prepares the nRMA to encapsulate packets from registered HAs to the
nRoA, into the nFA SHCoA. (nRMA now doing HA check). The RA Reg (nest)
prepares the HA to encapsulate packets to the HoA into the nRoA instead of
into the oRoA (new state for oRMA bypass).
A.W. O'Neill Expires Oct 2002 [Page 36]
INTERNET-DRAFT Regional Mobility Agent Signalling May 2002
c) After RA Hand-off completion
HoA packets are encapsulated into the nRoA in the HA. Packets to the nRoA are
encapsulated into the nFA SHCoA in the nRMA. Packets to the nFA SHCoA are
decapsulated in the nFA, the nRoA inspected and the packets sent to the MN.
9.2 Nested to Concat using a Concat inter-RMA transient forwarding
CN HA oRMA nRMA FA MN
a)
Forward oLA CN----------------------------------------------------->oRoA
oRMA================>oSHCoA
Forward RA CN------------------------------------------------------>HoA
HA==========================================>oRoA
oRMA================>oSHCoA
b)
Forward oLA CN----------------------------------------------------->oRoA
oRMA==>nRoA x nRMA==>nMSCoA
Forward RA CN------------------------------------------------------>HoA
HA==========================================>oRoA
oRMA==>nRoA x nRMA==>nMSCoA
c)
Forward nLA CN----------------------------------------------------->nRoA
nRMA==>nMSCoA
Forward RA CN------------------------------------------------------>HoA
HA=================>nRoA x nRMA==>nMSCoA====>nRoA
Figure 23. Forwarding for Nested to Concat via Concat
a)Before LA Hand-off in the oFA/oRMA
The local access traffic (CN:oRoA) is being encapsulated into the oFA SHCoA
and then the oFA is decapsulating and forwarding to the MN using the oRoA.
Any remote access (HA:oRMA[CN:HoA]) is being encapsulated into the oFA SHCoA
and then the oFA is decapsulating and forwarding to the MN using the oRoA.
Note that the FA could also be decapsulating the oRoA header to check for
registered HA/HoAs if the FA optionally has HA/HoA specific processing.
For LA Hand-off
The LA MIP Reg v4 (concat) sends the information to the nRMA, and a BU to the
oRMA. The LA Reg (concat) prepares the nFA to decapsulate packets from the
nFA MSCoA and forward oRoA, nRoA and HoA traffic to the MN that owns that
MSCoA (new state). The LA Reg (concat) prepares the nRMA to encapsulate
packets sent to the nRoA (from CNs) and to switch packets sent to the nRoA
(from the oRMA), into the nFA MSCoA (new state, oRMA undertaking HA check).
The inter-RMA BU (nest) prepares the oRMA to encaps packets sent to the oRoA
(from CNs and registered HAs) into the nRoA and to cancel forwarding to the
oFA SHCoA. All packets now go via the oRMA, nRMA, the nFA and the MN (b).
For RMA Hand-off
MN now leisurely sends an RA Reg (Concat) for each HoA/HA pair via nFA/nRMA.
The RA Reg (concat) prepares the nFA to decapsulate packets from the nFA
MSCoA and forward any oRoA, nRoA and HoAs to the MN that owns that MSCoA
(note FA already doing this).
A.W. O'Neill Expires Oct 2002 [Page 37]
INTERNET-DRAFT Regional Mobility Agent Signalling May 2002
The RA Reg (concat) prepares the nRMA to encapsulate packets from registered
HAs sent to the nRoA, into the nFA MSCoA (nRMA now doing HA check). The RA
Reg (concat) prepares the HA to encapsulate packets to the HoA into the nRoA
instead of into the oRoA (new state for oRMA bypass).
c) After RA Hand-off completion
HoA packets are encapsulated into the nRoA in the HA. In the nRMA, packets to
the nRoA from registered HAs are then switched into the nFA MSCoA. Packets to
the nRoA from CNs are encapsulated by the nRMA into the nFA MSCoA.
Registering via the RMA is therefore beneficial to the operator because of
the reduced encapsulation. The nFA decapsulates from the FA MSCoA, identifies
the target MN that owns that MSCoA, and the packets are then sent to the MN.
9.3 Concat to Concat using Concat inter-RMA transient forwarding
CN HA oRMA nRMA FA MN
a)
Forward oLA CN----------------------------------------------------->oRoA
oRMA================>oMSCoA
Forward RA CN------------------------------------------------------>HoA
HA===>oRoA x oRMA================>oMSCoA===>oRoA
b)
Forward oLA CN----------------------------------------------------->oRoA
oRMA==>nRoA x nRMA==>nMSCoA
Forward RA CN------------------------------------------------------>HoA
HA===>oRoA x oRMA==>nRoA x nRMA==>nMSCoA===>nRoA
c)
Forward nLA CN----------------------------------------------------->nRoA
nRMA==>nSHCoA
Forward RA CN------------------------------------------------------>HoA
HA=================>nRoA x nRMA==>nMSCoA===>nRoA
Figure 24. Forwarding for Concat to Concat via Concat
a)Before LA Hand-off in the oFA/oRMA
The local access traffic (CN:oRoA) is being encapsulated into the oFA MSCoA
and then the oFA is decapsulating and forwarding to the MN using that
oMSCoA/oRoA. Any remote access (HA:oRMA[CN:HoA]) is being encapsulated into
the oFA MSCoA and then the oFA is decapsulating and forwarding to the MN
using the oMSCoA. Note that the FA could also be decapsulating the oRoA
header to check for registered HA/HoAs if the FA optionally has HA/HoA
specific processing.
For LA Hand-off
The LA MIP Reg v4 (concat) sends the information to the nRMA, and a BU to the
oRMA. The LA Reg (concat) prepares the nFA to decapsulate packets from the
nFA MSCoA and forward oRoA, nRoA and HoA traffic to the MN that owns that
MSCoA (new state). The LA Reg (concat) prepares the nRMA to encapsulate
packets sent to the nRoA (from CNs) and to switch packets sent to the nRoA
(from the oRMA), into the nFA MSCoA (new state, oRMA undertaking HA check).
The inter-RMA BU (nest) prepares the oRMA to encaps packets sent to the oRoA
(from CNs and registered HAs) into the nRoA and to cancel forwarding to the
oFA MSCoA. All packets now go via the oRMA, nRMA, the nFA and the MN (b).
A.W. O'Neill Expires Oct 2002 [Page 38]
INTERNET-DRAFT Regional Mobility Agent Signalling May 2002
For RMA Hand-off MN now leisurely sends an RA Reg (Concat) for each HoA/HA
pair via nFA/nRMA. The RA Reg (concat) prepares the nFA to decapsulate
packets from the nFA MSCoA and forward any oRoA, nRoA and HoAs to the MN that
owns that MSCoA (note FA already doing this). The RA Reg (concat) prepares
the nRMA to encapsulate packets from registered HAs sent to the nRoA, into
the nFA MSCoA (nRMA now doing HA check). The RA Reg (concat) prepares the HA
to encapsulate packets to the HoA into the nRoA instead of into the oRoA (new
state for oRMA bypass).
c) After RA Hand-off completion
HoA packets are encapsulated into the nRoA in the HA. In the nRMA, packets to
the nRoA from registered HAs are then switched into the nFA MSCoA. Packets to
the nRoA from CNs are encapsulated by the nRMA into the nFA MSCoA.
Registering via the RMA is therefore beneficial to the operator because of
the reduced encapsulation. The nFA decapsulates from the FA MSCoA, identifies
the target MN that owns that MSCoA, and the packets are then sent to the MN.
9.4 Concat to Nested using Nested inter-RMA transient forwarding
CN HA oRMA nRMA FA MN
a)
Forward oLA CN----------------------------------------------------->oRoA
oRMA================>oMSCoA
Forward RA CN------------------------------------------------------>HoA
HA===>oRoA x oRMA================>oMSCoA===>oRoA
b)
Forward oLA CN----------------------------------------------------->oRoA
oRMA===========================>nRoA
nRMA===>nSHCoA
Forward RA CN------------------------------------------------------>HoA
HA===>oRoA x oRMA===========================>nRoA
nRMA===>nSHCoA
c)
Forward nLA CN----------------------------------------------------->nRoA
nRMA===>nSHCoA
Forward RA CN------------------------------------------------------>HoA
HA==========================================>nRoA
nRMA===>nSHCoA
Figure 25. Forwarding for Concat to Nested via Nested
a)Before LA Hand-off in the oFA/oRMA
The local access traffic (CN:oRoA) is being encapsulated into the oFA MSCoA
and then the oFA is decapsulating and forwarding to the MN using that
oMSCoA/oRoA. Any remote access (HA:oRMA[CN:HoA]) is being encapsulated into
the oFA MSCoA and then the oFA is decapsulating and forwarding to the MN
using the oMSCoA. Note that the FA could also be decapsulating the oRoA
header to check for registered HA/HoAs if the FA optionally has HA/HoA
specific processing.
A.W. O'Neill Expires Oct 2002 [Page 39]
INTERNET-DRAFT Regional Mobility Agent Signalling May 2002
For LA Hand-off.
The LA MIP Reg v4 sends the information to the nRMA, and a BU to the oRMA.
The LA Reg (nest) prepares the nFA to decapsulate packets from the nFA SHCoA
and forward nRoA and oRoA traffic to the MN (new state). The LA Reg (nest)
prepares the nRMA to encapsulate packets sent to the nRoA (from CNs and oRMA)
into the nFA SHCoA (new state, oRMA undertaking HA check). The inter-RMA BU
(nest) prepares the oRMA to encaps packets sent to the oRoA (from CNs and
registered HAs) into the nRoA and to cancel forwarding to the oFA MSCoA. All
packets now go from the oRMA to the nRMA to the nFA to the MN as shown in (b)
For RMA Hand-off
MN now leisurely sends an RA Reg (Nest) for each HoA/HA pair via nFA/nRMA.
The RA Reg (nest) prepares the nFA to decapsulate packets from the nFA SHCoA
and forward the oRoA and nRoA to the MN (note FA already doing this). The RA
Reg (nest) prepares the nRMA to encapsulate packets from registered HAs to
the nRoA, into the nFA SHCoA. (nRMA now doing HA check). The RA Reg (nest)
prepares the HA to encapsulate packets to the HoA into the nRoA instead of
into the oRoA (new state for oRMA bypass).
c) After RA Hand-off completion
HoA packets are encapsulated into the nRoA in the HA. Packets to the nRoA are
encapsulated into the nFA SHCoA in the nRMA. Packets to the nFA SHCoA are
decapsulated in the nFA, the nRoA inspected and the packets then sent to the
MN that owns that nRoA.
9.5 Nested to Nested using Concat inter-RMA transient forwarding
CN HA oRMA nRMA FA MN
a)
Forward oLA CN----------------------------------------------------->oRoA
oRMA==================>oSHCoA
Forward RA CN------------------------------------------------------>HoA
HA==========================================>oRoA
oRMA==================>oSHCoA
b)
Forward oLA CN----------------------------------------------------->oRoA
oRMA===>nRoA x nRMA===>nMSCoA
Forward RA CN------------------------------------------------------>HoA
HA==========================================>oRoA
oRMA===>nRoA x nRMA===>nMSCoA
c)
Forward nLA CN----------------------------------------------------->nRoA
nRMA===>nSHCoA
Forward RA CN------------------------------------------------------>HoA
HA==========================================>nRoA
nRMA===>nSHCoA
Figure 26. Forwarding for Nested to Nested via Concat
From Nested RN to Nested RN using concatenated LA MIP Reg is possible but
neither preferred nor covered in detail here.
A.W. O'Neill Expires Oct 2002 [Page 40]
INTERNET-DRAFT Regional Mobility Agent Signalling May 2002
9.6 Nested to Concat using Nested inter-RMA transient forwarding
CN HA oRMA nRMA FA MN
a)
Forward oLA CN----------------------------------------------------->oRoA
oRMA=================>oSHCoA
Forward RA CN------------------------------------------------------>HoA
HA==========================================>oRoA
oRMA=================>oSHCoA
b)
Forward oLA CN----------------------------------------------------->oRoA
oRMA===========================>nRoA
nRMA===>nSHCoA
Forward RA CN------------------------------------------------------>HoA
HA==========================================>oRoA
oRMA===========================>nRoA
nRMA===>nSHCoA
c)
Forward nLA CN----------------------------------------------------->nRoA
nRMA===>nSHCoA
Forward RA CN------------------------------------------------------>HoA
HA=================>nRoA x nRMA===>nMSCoA===>nRoA
Figure 27. Forwarding for Nested to Concat via Nested
From Nested RN to Concatenated RN using nested LA MIP Reg is possible but
neither preferred nor covered in detail here.
9.7 Concat to Nested using Concat inter-RMA transient forwarding
CN HA oRMA nRMA FA MN
a)
Forward oLA CN----------------------------------------------------->oRoA
oRMA================>oMSCoA
Forward RA CN------------------------------------------------------>HoA
HA===>oRoA x oRMA================>oMSCoA===>oRoA
b)
Forward oLA CN----------------------------------------------------->oRoA
oRMA==>nRoA x nRMA==>nMSCoA
Forward RA CN------------------------------------------------------>HoA
HA===>oRoA x oRMA==>nRoA x nRMA==>nMSCoA===>nRoA
c)
Forward nLA CN----------------------------------------------------->nRoA
nRMA==>nSHCoA
Forward RA CN------------------------------------------------------>HoA
HA=========================================>nRoA
nRMA==>nSHCoA
Figure 28. Forwarding for Concat to Nested via Concat
A.W. O'Neill Expires Oct 2002 [Page 41]
INTERNET-DRAFT Regional Mobility Agent Signalling May 2002
Concat to Nested via LA MIP Reg is possible but neither preferred nor covered
in detail here.
9.8 Concat to Concat using a Nested inter-RMA transient forwarding
CN HA oRMA nRMA FA MN
a)
Forward oLA CN----------------------------------------------------->oRoA
oRMA================>oMSCoA
Forward RA CN------------------------------------------------------>HoA
HA===>oRoA x oRMA================>oMSCoA===>oRoA
b)
Forward oLA CN----------------------------------------------------->oRoA
oRMA==========================>nRoA
nRMA===>nSHCoA
Forward RA CN------------------------------------------------------>HoA
HA===>oRoA x oRMA==========================>nRoA
nRMA===>nSHCoA
c)
Forward nLA CN----------------------------------------------------->nRoA
nRMA===>nSHCoA
Forward RA CN------------------------------------------------------>HoA
HA================>nRoA x nRMA===>nMSCoA===>nRoA
Figure 29. Forwarding for Concat to Concat via Nested
Concat to Concat via a Nested LA MIP Reg is possible but neither preferred
nor covered in detail here.
9.9 Nested <-> Concat Option Comparisons
The following table summarises the various choices when moving between RMAs
using Nested and Concat modes, using Nested or Concat transient forwarding as
described above.
From oRMA To nRMA Via LA RREQ Comments
Nested Nested Nested Triple encapsulations, simple
Nested Concatenated Concatenated Single FA CoA, consistent
Concatenated Nested Nested Single FA CoA, consistent
Concatenated Concatenated Concatenated Minimal Encaps,
Nested Nested Concatenated MSCoA and SHCoA assigned
Nested Concatenated Nested MSCoA and SHCoA assigned
Concatenated Nested Concatenated MSCoA and SHCoA assigned
Concatenated Concatenated Nested MSCoA and SHCoA assigned
The summary is intended to indicate why the last four options are not
presently preferred which is because they result in the nRMA mode changing
between the LA hand-off and the RA hand-off.
A.W. O'Neill Expires Oct 2002 [Page 42]
INTERNET-DRAFT Regional Mobility Agent Signalling May 2002
This is against the basic LA hand-off model whereby the RA layer uses the
default RA forwarding behaviour agreed at the LA layer. There may be good
reasons why a specific RA session may need to overrule the LA layer decision
in which case the non-preferred modes do need to be supported. In addition,
avoiding the triple encapsulation may justify Nested to Nested via Concat for
example. The other comparison is between the cost of the triple encapsulation
when moving from Nested to Nested via Nested transient forwarding whilst
Concat to Concat via Concat is more complex and requires MSCoAs. Given the
different characteristics and deployment requirements there is a potential
need for both, which therefore requires the Nested <-> Concat hand-offs.
9.10. Inter-RMA Transient Forwarding with GFA mode
This is not covered in detail but is summarised briefly. When leaving a GFA
oRMA, the oRMA look-up uses HoA state but is forwarded using a nRMA CoA that
is commensurate with the nRMA mode. When moving to a nRMA that is using GFA
mode, from an oRMA in Nested, Concat or GFA mode, the nRMA provides the oRMA
with a SH CoA and Context Transfer is used to move the HA/HoA state to the
nRMA to support RA layer GFA forwarding in advance of RA layer RREQ/RREP
hand-off.
10. Additional Modifications, Options and Extension Definitions
10.1 Hybrid Concat/GFA Modes
The RA MIP Reg v3 sends the RoA to the HA where it is used as the destination
address for the HoA encapsulation. The RoA is also used as the LA layer
address for local access service. If local access is not required, and the
HoA is a public address, then the RMA can instead allocate a SHCoA for the
HoA binding and then forward based on the inner HoA as in GFA mode. This
saves RoA addresses when they are not needed but avoids the need for HoA
specific state in the FA by still using an MSCoA in the FA. The MN cannot
know this RMA SHCoA in advance and so must use a blank CoA field in the RA
MIP Reg v3. The RMA then adds the SHCoA into the HFAext, sends it to the HA,
and the RMA returns it in a HFAext to the MN. The MN can of course populate
the CoA field in subsequent refreshes via the same RMA.
Equally, in GFA mode, a RMA SHCoA is used but this can be avoided if the MN
also has Local access and an RoA. The RoA can be inserted into the HA such
that an RMA failure can be locally recovered in another RMA without having to
update the HA. In addition, the RoA is known at the LA layer and so the
backwards compatibility issue with a CoA=0 is avoided.
10.2 GFA and private HoAs
Private HoAs cannot safely be supported in GFA or hybrid mode because
forwarding is dependent on a potentially non-unique private HoA. This limits
GFA mode, and the above hybrid mode to public HoAs. This restriction can be
relaxed however if a FA MSCoA is used instead of a FA SHCoA because the
concatenation of the MSCoA+HoA ensures uniqueness. This is not necessary in
the RMA because the HoA can be made unique through the concatenation of the
HA and the HoA, making an RMA SHCoA permissible.
A.W. O'Neill Expires Oct 2002 [Page 43]
INTERNET-DRAFT Regional Mobility Agent Signalling May 2002
10.3 Heterogeneous RA forwarding modes
In section 5,it was explained how the LA MIP Reg identifies the capabilities
of the RMA and installs a single mode of RA forwarding for all RA sessions
from that MN. This is reasonable because the HA is not aware of the RMA
forwarding mode and the HA changes are simply to be able to support
[RegTunMods] home registration extensions to enable the use and transfer of
dynamically assigned CoAs and RMA addresses. However, there may well be
reasons why the MN (possible as a result of the home operator AAA profile)
will have a preference over which mode is used by the MN to that HA. If such
a preference does exist then this can be easily supported using the following
rules.
Firstly, the LA layer must include a request in the stylext for the default
LA mode which should be the Nested mode as this places the lowest burden on
CoA resources and matches the LA forwarding mode.
Each RA MIP Reg can then overule this default by including a stylext that
indicates either Concatenated or GFA forwarding. The use of combined
signalling means therefore that the LA and RA styleext must be able to be
distinguished using a flag bit. When multiple RA sessions are in progress
then there is a danger that a MN could acquire both a MSCoA (for concat) and
a SHCoA (for GFA/Nested) at the FA, as well as a SHCoA at the RMA (GFA with
no local access). This can be avoided by the LA layer always using a MSCoA
instead of a SHCoA at the LA layer for all RA sessions once a MSCoA has been
assigned. This requires the FA and RMA to update the visitor lists
accordingly for the MN.
Secondly, during inter-FA hand-off, the LA MIP Reg must be able to support
all the different dependent RA layer sessions at the new FA in advance of the
RA visitor list being refreshed. The LA MIP Reg should therefore signal
wildcard mode to the FA/RMA using a FA SHCoA, unless a FA MSCoA is required
by one of the RA sessions. The FA then installs visitor list entries
sufficient for any interpretation (superposition) of the information in the
stylext of the LA Reg. Finally, the RMA uses the correct installed forwarding
for the installed session specific RA state towards that FA. The FA removes
unexercised visitor list entries when the MN leaves that FA.
10.4 HA/HoA Specific Processing and Context Transfer
HA/HoA specific state can be installed by the RA layer into the FA and RMA.
It can also be installed by the LA MIP layer in the case of GFA mode. This
state may simply be the HoA, the HA, or both and is used to supplement the RA
visitor list for the associated MN/RoA. This requires the relevant node to
potential look into an encapsulation to discover the HoA and/or HA source
address in a packet before forwarding that packet. HA/HoA specific state must
be installed in GFA mode to satisfy basic forwarding rules of that mode.
HA/HoA specific state can be optionally stored and inspected in Nested and
Concat mode in both the FA and the RMA. It is required in the RMA for both
Nested and Concat modes when the MN is allowed to avoid RA reverse tunnelling
and hence to send with the HoA as a source address. In this case, the packet
must be LA reverse tunneled to the RMA to undergo a source check and the
HA/HoA state must be CTed between RMAs on hand-off.
A.W. O'Neill Expires Oct 2002 [Page 44]
INTERNET-DRAFT Regional Mobility Agent Signalling May 2002
HA/HoA state can also be inspected to distinguish between multiple ongoing RA
sessions so that HA/HoA specific accounting, QoS and policy can be applied.
HA/HoA Specific QoS processing is required to enable specific HA/HoA flows
to get preferential forwarding services over the air or through the
network.
HA/HoA Specific Accounting processing is required so that accounting
records can be built and delivery to the correct home operator and third
party service providers.
HA/HoA Specific Policy can be used to bar or allow specific HAs and HoA
address ranges from being supported. For uplink traffic, discard is most
efficient at the FA whilst for downlink it is at the RMA.
During inter-FA LA hand-off, any RA layer HA/HoA state will be missing in the
new FA and will not be immediately rebuilt at that FA due to the longer
binding lifetimes used in the RA layer to avoid excessively loading global
HAs. This state must therefore be Context Transfered between the FAs during
the inter-FA hand-off. Similarly, during an inter-RMA hand-off, it is
necessary to space out the RA layer updates via the nRMA to avoid a flood of
such messages during the hand-off. Therefore, for a short while the HA/HoA
specific state will be missing in the nRMA which could impact accounting, QoS
or policing. The state is however still at the oRMA which is on the
forwarding path until the RA layer update to the HA and so some functionality
may not be lost. However, it may still be necessary for the HA/HoA specific
state to be Context Transferred from the oRMA to the nRMA when either the BU
or the Combined LA/RA Reg v1 is received at the oRMA. Again, the likely need
for this is known at the oRMA by the type of HA/HoA specific processing.
Therefore, in either FA or RMA cases, the need for CT is known at the oFA
and/or old RMA and will be triggered by the BU from the newFA / new RMA.
Note that the Context Transfer of HA/HoA state can be synchronized with the
CT of other state such as the general AAA profile for the MN, the MN-FA SA
between FAs, the MN-RMA SA between RMAs, along with the HoA specific profile
information for those HoAs and for the base RoA. The Context Transfer ideally
needs to be reliable because otherwise HA/HoA state will be lost. In the case
of GFA mode, the loss of such state is catastrophic to that RA flow and is
one reason that Concat mode is preferred. In Nested and Concat mode, CT is
used simply to transfer state that is not needed for basic forwarding and
hence late or lost state can be tolerated in general and then be rebuilt on
the next RA refresh. The lost value added processing is that some packets
will not be correctly accounted (undercount), flows may not receive
preferential service for a while, and incorrect packets will progress further
in the network than intended. Each of these situations have their own
commercial consequences and the CT layer should therefore have suitable
reliability mechanisms commensurate with those consequences however it should
be restated that basic forwarding is still always ok ensuring graceful
degradation.
Note also that Context Transfer can be avoided by instead storing such state
in a coordinated way in the local AAA servers. The nFA and nRMA can then
fetch this state when the hand-off Registration is received which should
contain the AAA-NAI for that state.
A.W. O'Neill Expires Oct 2002 [Page 45]
INTERNET-DRAFT Regional Mobility Agent Signalling May 2002
10.5 Previous Foreign Notification Extension (PFANE)
The traditional PFANE extension is used to trigger a BU to the oFA to cause
the oFA to switch packets addressed to the HoA towards the new FA CoA. During
inter-RMA hand-off, the LA layer forwarding between these two elements may be
required in support of nested, concat or GFA from the old FA to Nested,
Concat or GFA mode at the new FA. The PFANE and the associated BU do not
however need to be modified because the behaviour between all the various
mode combinations only varies at the nFA by the type of FA CoA (shared or MN
specific) that is assigned. The oFA simply forwards towards that FA CoA and
does not need to be aware of the CoA type or the nFA subsequent processing.
The only change therefore is that the FA CoA can be MN specific. Note however
that the MN can only pre-calculate the BU authentication if the FA CoA is
advertised to the MN in the FAA. Therefore, for Concat mode, this requires
the MSCoA to be unicast in an FAA in advance of the MN sending the LA RREQ.
The PRANE is formatted the same as the PFANE but includes the oRMA address
and the nFA CoA rather than the oFA address and the nFA CoA. The MN
calculates the authenticator as for PFANE but can only do so if the FA CoA is
advertised to it in an FAA before sending the LA RREQ or combined LA/RA RREQ
to the HA via the nFA and nRMA. When the PRANE is protected by the MN-FA auth
extension then this tells the FA that it should initiate the BU to the oRMA
to instigate oRMA to nFA forwarding.
The BU is sent from the FA to the oRMA and contains the HoA=oRoA and the
CoA=nFA SHCoA as Nested mode in the nFA is always supported because it is
required for LA layer forwarding for local access traffic. The BU does not
then need to be modified in any way to deal with the various types of RA
forwarding at the nFA because of this default feature. This decision is in
preference to enabling the PRANE and the BU to be sent with a stylext to
identify the required forwarding mode from the oFA.
The PRANE can instead be wrapped in the MN-HA or MN-nRMA auth extension to
instead cause the nRMA to send the BU to the oRMA. The MN-HA SA is used if
the MN-nRMA SA is not immediately available but means that the nRMA cannot
authenticate the PRANE but instead leaves authentication to the oRMA of the
BU. The MN-nRMA can be used immediately if it is the same as the MN-oRMA SA
and will be CTed to the nRMA, or fetched by the nRMA from the AAA system.
The PRANE to the nRMA includes the oRMA address and the nRMA address
advertised in the FAA (as the RMA SH CoA). The MN calculates the
authenticator based on the MN-oRMA SA. The BU is sent by the nRMA to the oRMA
for the oRoA and if authenticated will cause traffic on or associated with
the oRoA to be forwarded to the nRMA using either the oRoA or the RMA SHCoA.
The nRMA knows which forwarding mode is to be provided at the nRMA and so the
BU needs to include this information in the BU (the Stylext) so that the oRMA
can undertake the correct forwarding as recommended in section 9. The BUack
is sent to the MN again via the tunnel created by the BU from the oRMA to the
nRMA. The use of the RMA SHCoA for the RMA address advertised in the FAA
limits this technique to intra-domain, inter-region forwarding where the nRMA
SHCoA = RMA address in the FAA.
A.W. O'Neill Expires Oct 2002 [Page 46]
INTERNET-DRAFT Regional Mobility Agent Signalling May 2002
On inter-operator boundaries, the nRMA CoA for the oRMA will likely not be
the same as the nRMA address in the FAA from the MN and nFA perspective. With
an oRMA/nRMA SA in place, which is most likely necessary and useful in the
case of the inter-operator boundary, the MN would include the PRANE and leave
the nRMA CoA field blank. The MN would pre-calculate the authenticator
including the zero address. The nRMA would generate a BU from the PRANE in
the LA MIP RREQ, using the MN authenticator and forward it to the oRMA,
attaching a HFAext for the nRMA CoA chosen by the nRMA (nRoA or nRMA SH CoA)
based on the forwarding mode and secured by the inter-operator SA. Once again
the BU Ack is returned to the MN via the nRMA and nFA to confirm to the MN
that inter-operator forwarding is in place. Note that the nRMA CoA=0 rather
than nRMA CoA=nRMA in the FAA is only used to avoid operator addresses
leaking out of the domain. For an intra-domain inter-RMA hand-off, the nRMA
CoA in the PFANE should always be the nRMA address in the FAA. The nRMA can
then inspect this address and decide if it wishes to add a HFAext = new nRMA
CoA to override the value in the CoA field, secured by the inter-RMA SA.
10.7 Style Extension (Stylext)
The LA layer needs to select the options for the following parameters;
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
'L' Layer flag set for RA, unset for LA (unset here)
'S' Access flag set to access service at that layer
'P' Address flag set if public, unset if private address (RoA)
'N' NAT flag set if NAT is requested for a private address RoA
'A' CoA flag set if FA MSCoA, unset if FA SHCoA
'G' GFA flag set if the common RA mode at LA layer is GFA
'C' Concat flag set of the common RA mode at LA layer is Concat
The RA layer needs to select the options for the following parameters;
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
'L' Layer flag set for RA, unset for LA (set here)
'S' Access flag set to access service at that layer
'P' Address flag set if public, unset if private address (HoA)
'N' NAT flag set if NAT traversal is requested
'A' CoA flag set if RMA MSCoA, unset if RMA SHCoA
'G' GFA flag set if the session specific RA mode is GFA
'C' Concat flag set if the session specific RA mode concat
A.W. O'Neill Expires Oct 2002 [Page 47]
INTERNET-DRAFT Regional Mobility Agent Signalling May 2002
Nested MIP, being the LA default mode, does not need to be signalled but if
it is signalled is represented by the G and C flags being unset. In the case
of the RA layer, both the G and C flags being unset also indicates a request
for RA session specific nested mode, whilst both being set indicates that the
LA layer common RA mode setting should be used.
Combined LA/RA Registrations can include an LA stylext, an RA stylext or both
depending on the level of feature complexity.
The MN does not dynamically and explicitly request, via the Stylext, HoA/HA
specific processing in the RMA and FA, nor Context Transfer services in
support of the maintenance of such state during hand-off. These are instead
operator features that may be determined based on the AAA profile and
operator policy. They may also be mandated by specific combinations of the
Stylext flags, and the MIP Reg flags, as stated below.
In Concat mode, if the RA layer reverse tunnelling bit is not set, then the
LA layer reverse tunnelling bit must be set so that the RMA can undertake the
source address check. The RMA RA state is copied from the RA Reg v3
RREQ/RREP. Context Transfer of this state between RMAs required to enable the
nRMA to undertake these checks in advance of the RA Registrations via the
nRMA.
In GFA mode, the RA layer must be given a public HoA and HoA specific state
must be installed into the FA and RMA by copying it from the RA Reg v3
RREQ/RREP.
10.8 HFAIPext
This is a generalized form of the GFAIPext in RegTun with the addition of a
sub-type to indicate the address sub-type and the associated required
processing. This is used to inform an upstream or downstream node of the
address of a dynamically assigned upstream node so that the downstream node
can direct MIP messages and data to that upstream node. Examples include the
RMA and HA addresses.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | sub-type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HFA IP Address |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
The HFAIPext must have sufficient flags to differentiate between a range of
IP addresses that can be carried, which for this draft can include the
dynamically assigned HA or RMA.
10.9 HFAext
This is a generalized form of the HFAext in RegTun with the addition of a
sub-type to indicate the address sub-type and the associated required
processing.
A.W. O'Neill Expires Oct 2002 [Page 48]
INTERNET-DRAFT Regional Mobility Agent Signalling May 2002
This is used to inform an upstream node of the care of address assigned by a
downstream node, to which that upstream node should forward and from which
that upstream node should expect to receive reverse tunneled packets. It is
also used to inform the MN of the dynamically assigned CoA that it should use
in the Registration CoA field.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | sub-type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HFA Care of Address |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
The HFAext must have sufficient flags to differentiate between a range of IP
addresses that can be carried which for this draft can include the FA SHCoA,
FA MSCoA, RMA SHCoA and RMA MSCoA=RoA. The RoA can also be carried in the
HFAext as part of dynamic addressing in Combined messages.
10.10 HoAList
During inter RMA hand-off and especially during inter-operator hand-off it is
likely that the MN will not want to enable transient forwarding (inter-FA or
inter-region) for specific RA sessions and associated HoAs. The HoAlist
extension is an include/exclude list to inform the previous FA or RMA which
HoAs to forward for. This can be used to also constrain what HA/HoA specific
state is context transferred to the nFA from the oFA, and to the nRMA from
the oRMA. In the absence of the HoAlist, then provided an authentication
extension exists between the nodes, no HoA specific state is CTed across.
This therefore works with legacy nodes that do not support HoAList Extension
and also ensures that only explicit request to include HoAs can do so during
hand-off.
The HoAList in include form can also be used by the MN to populate the local
FA with HA/HoA state, and avoid CT, when the list is short and hence
bandwidth efficient.
The format of the message is to be determined.
10.11 HoAResp
This extension is used to confirm reception of and action on the HoAlist. It
can also be used to transfer the HA/HoA state to the nFA or nRMA from the oFA
or oRMA. Its transport and format has yet to be determined and is not needed
if the HA/HoA state is to be transferred as part of MN AAA state, or by the
MN itself.
10.12 HoAErr
This extension is required to enable a HoAResp to contain HoA specific MIP
error information for the nFA and MN.
A.W. O'Neill Expires Oct 2002 [Page 49]
INTERNET-DRAFT Regional Mobility Agent Signalling May 2002
10.13 FA-NAI regional structure
The FA-NAI is supported in legacy FAs and MNs and is required to support
inter-region movement detection. The FA-NAI is required so that MNs seeking
regional services can be suported along with legacy MNs that do not. This is
achieved by structuring the username and domain parts of the NAI as
'FAname<specialchar>RMAname@domain'. The '%' character is an obvious
suggestion.
A legacy MN will correctly interpret the domain part to detect inter-operator
hand-off and will not see the substructure in the username part, but will
correctly distinguish between FAs and hence support inter-FA hand-off. Only a
regional aware MN can see the sub-structure and will use this to determine
when inter-FA and inter-RMA hand-offs are required.
10.14 Unicast FAA for MN specific FA CoA assignment
A MN specific FAA can be sent to the MN by determining the MN link-layer
address from the LA visitor list and then sending the FAA just to that MN
over a unicast link-layer connection to either the broadcast address or the
address of the MN. The MN then uses this rather than any broadcasted FA CoA
in its MIP registration. The MN can assume that such a FA CoA is MN specific
and hence enables Concat mode to be requested without using the CoA=0 and
HFAext= MSCoA as part of dynamic FA CoA assignment.
10.15 When the LA layer is hidden from the RA Layer
A legacy MN RA layer MIP implementation will not know about this draft. The
preferred option therefore is that the LA layer is hidden from the MN OS
apart from driver calls through a standardised API. The LA layer therefore
intercepts the FAA with its FA and RMA movement information, and presents RMA
changes to the MN as interface address changes by assigning each new RoA. The
legacy RA MIP layer in the MN will then report this new interface address to
the HA with which it shares an RA session. In this model the MN RA MIP
implementation is pretty dumb and the LA layer monitors, intercepts and
controls all AS and AA activity.
This model, whilst great for initial deployment and backwards compatibility,
has the draw-back however that the RA layer is not able to track regional
movement, elect to preserve RMA/RoAs as RA sessions, know when it can use Reg
v2 and Reg v3 or use combined RA/LA signalling etc. This can be improved by
enabling the LA layer to proxy the FAA through to the RA layer but modify and
hide some of the fields in the case of a legacy MN RA MIP stack so that it is
not confused. However, not even this is adequate for many of the features.
10.16 When both the LA and RA layers are exposed to the FA
A more complete model therefore is instead to enable both the host RA layer
MIP stack and the LA layer stack to send and receive AS/AA in a coordinated
manner whilst giving the LA layer ultimate control over what is permitted to
be sent over the air-interface to protect the local mobility management
system.
A.W. O'Neill Expires Oct 2002 [Page 50]
INTERNET-DRAFT Regional Mobility Agent Signalling May 2002
This can be implemented through a sophisticated API with all MIP
messages ultimately being generated in the LA layer under OS control.
Alternatively, both the RA and lA layer can generate their own messages, but
with Combined messages only being sent by the RA layer under LA layer
control. The LA layer must in all cases have capabilities to protect the
operators local mobility management layer from abuse such as message rate
limiting, checks on message fields, firewalling and movement verification.
10.17 When the RA layer and LA layer terminate on different elements
The model above where the LA layer sends all MIP messages does not support
the case where the RA stack is separate from the device implementing the LA
stack. This would happen with a hub or router having the LA layer on air-
interface, and a LAN on the other supporting a number of nodes sharing the
hub/router for local and remote access. This provides further motivation for
the model whereby either RA or LA stacks can issue messages but with the LA
stack having specific controls.
The node with the LA stack acts as a private address allocator for the LAN.
LAN MN members use their private addresses as source addresses for local and
remote access. Directly reachable members are discovered via ARP as normal.
The MNs can also use those private addresses for remote access with the LA
stack node acting as a proxy FA.
In this case, as the hub moves in the cellular infrastructure (in a car, on a
train etc) then the LA stack acts as a proxy FA by relaying a modified FAA to
the MNs. The FAA over the air-interface reports inter-FA and inter-RMA
movement that causes the LA stack to acquire a new RoA at each new RMA. Each
newRoA, RMA is reported to the LAN in the proxied FAA (and not the FA or FA
CoA) so that the RA stacks can build fully populated RA Reg messages.
The RA layer adds the MN-HA auth and he RA MIP registrations should then be
routed via the proxy FA, learnt from the proxied FAA and have the 'D' bit set
to indicate CCoA to the cellular infrastructure as required by Nested/Concat
MIP. This enables the proxy FA to discover the HoA addresses so that the MNs
do not have to encapsulate to the proxy FA but can be sent natively towards
the RoA default gateway address. The RoA is then a form of proxy CCoA [PCCoA]
with the tunnelling functions left to the proxy FA.
The proxy FA adds the LA layer extensions and the MN-FA authenticating
extension. The packets from the LAN, are then forwarded by the proxy FA,
according to the registration state and forwarding mode to either the FA,
RMA, HA or CN. For example, reverse tunnelling in Nested mode would require
the packet to be re-encapsulated in the RoA as a source address and sent to
the HA. In the downlink direction, packets are encapsulated to the RoA
address owned by the proxy FA which strips away the HA source, RoA
destination encapsulation. The proxy FA then forwards to the MN across the
LAN based on the HoA. The Proxy FA needs to potentially also support
encapsulation from the MN to the proxy FA using the private address/RoA pair
when non-unique HoAs are evident on the LAN. This is discovered by the proxy
FA during registration and will cause the proxy FA to instruct the MN to
encapsulate remote access traffic to it (and expect encapsulated traffic in
return) and to not set the 'D' bit but to let the proxy FA set that bit as it
forwards the registration to cellular operator as normal.
A.W. O'Neill Expires Oct 2002 [Page 51]
INTERNET-DRAFT Regional Mobility Agent Signalling May 2002
As far as the rest of the cellular infrastructure is concerned, the LAN
appears to be a single node with multiple remote and one local access
session. Only the node running the proxy FA function can utilise the RoA as a
source / destination address for local access but that node can add support
for a NATP function to enable local access from the multiple private
addresses to share that single RoA out to the cellular domain. This then
provides a scalable way for multiple MNs from different home networks to
share a single wireless connection for either remote, local or remote and
local services. This is possible because of the aggregation properties of the
layered model.
10.18 RoA Address Allocation
MIP visitor list entries in the MN, FA, RMA and HA include state that enables
encapsulated packets to be correctly forwarded. The state is installed by the
MIP Registration between the MN and the RMA/HA, and then confirmed by the
Reply in the reverse direction. This ensures that downstream nodes have
visitor list state before upstream nodes so that when the visitor list is
created in the RMA/HA, arriving packets in the forward direction, from the HA
to the MN, will not hit MIP elements that lack visitor list state for that
flow.
Unfortunately, the RoA address is used by the MN but is obtained from the RMA
in each new region. Therefore, the dynamically allocated RoA is not known in
advance by the MN and therefore cannot be in the MIP Registration Request
towards the new RMA via the FA. This provides an opportunity for the FA
visitor list to be unpopulated when the MIP Request hits the RMA, which risks
packets towards that RoA being dropped at the FA because the MIP Reply
processing in the FA that creates the FA visitor list will be significantly
slower that data packets reaching the FA (and being dropped). This mainly
affects inter-RMA forwarding that is being redirected to the nRoA from the
old RMA, using either a PRANE triggered BU or a Combined RA/LA Registration
Request to the oRMA. It does not affect local access traffic because no
incoming packets will be generated towards the nRoA until the MN starts to
use that nRoA, which it will not do until it receives the MIP Reply (which
will have installed the required FA state).
The RoA can be assigned in a number of ways in the new region.
a) The RoA can be allocated by the RMA using MIP dynamic address
allocation in which case the RoA is returned in an MIP Reply message.
b) The AAA system can allocate the RoA for the RMA in which cases the
address is returned to the FA in an MIP Reply message embedded within a
AAA message.
c) The FA can act as a DHCP client and obtain the address from the RMA
that acts as a DHCP server. The message is returned to the FA in a DHCP
message and is then inserted into the MIP RREQ towards the RMA.
d) The FA can be pre-assigned a pool of RoA addresses from each RMA in the
region. The FA can then insert the RoA itself into any MIP RREQ from a MN
that has a zero RoA field at the same time that it selects the RMA
address.
A.W. O'Neill Expires Oct 2002 [Page 52]
INTERNET-DRAFT Regional Mobility Agent Signalling May 2002
Case (a) has the problem that the FA only gets to see the RoA when receiving
the RREP, by which time packets will likely already be arriving towards the
RoA (inter-RMA forwarding) and therefore would normally be dropped in MIP
because no visitor list entry exists. The use of the RoA should therefore be
delayed upstream by some safety timer to ensure that the RREP with the new
RoA has reached the FA, but this still fails if the RREP is lost
Case (b) has a similar problem but can use reliable transport of the RREP in
the AAA message. The use of AAA routing though means that the safety timer
could need to be quite large which increases the amount of expensive inter-FA
forwarding required.
Case (c) incurs additional delay at the new FA before the RREQ can be sent
although this delay, as with the safety timer, may well be fine in the case
of make before break hand-off because the old link is still available.
Case (d) requires the configuration of address pools in the FAs, that are
divided out of the RMA address blocks. This can lead to significant address
inefficiencies given that a MN can start at any FA within the region. There
is also the problem that the FA needs to know when the address is released
but that release is only presently known at the RMA, because the RoA can
continue to be used at any FA and is only released explicitly using an inter-
RMA hand-off BU.
Case (d) is the fastest approach and consistent with the FA also assigning
the RMA itself. To proceed with this method will require the RMA to provide
the FA with information of when the RoA is released. In addition, the FA
needs to be able to dynamically acquire additional addresses that it can
allocate out. This could be achieved by the FA acting as a DHCP client with
the RMA server for address management purposes. Addresses are then requested
by and handed out to FAs in advance of MN arrivals, as the FA address stores
get depleted. The RMA DHCP server tells the FA when addresses have been
returned by reporting them as revoked (ie returned to the RMA). The FA can
then reclaim that or any other address in blocks. Case (d) needs work but
looks the best option due to the speed, and avoidance of the RREP reliability
issue. In the absence of that, the order of preference is probably c, b, a
due to the RREP being a bigger issue than the delay issue.
A potential solution to the RREP issue is that if a data flow arrives from an
RMA towards an RoA that has no visitor list state, then the FA can
temporarily build a visitor list from the arriving data;
For Concat, inspect the outer address (MSCoA) which was installed by the
RREQ in the FA, to identify the MN address, dynamically build the visitor
list state from the data packet contents, and send the data towards that
MN encapsulated in the oRoA which is also already known.
For nested, decapsulate from the SHCoA, inspect the dest address to see
the nRoA, inspect the inner destination address to see the oRoA and
identify the MN (the FA knows the MN/oRoA set), build the visitor list
state and forward encapsulated within the nRoA so that the MN also learns
the nRoA address.
For GFA mode, the nRoA is only used for local access traffic and will only
arrive once used by the MN. oRoA packets arrive encapsulated in the SHCoA.
A.W. O'Neill Expires Oct 2002 [Page 53]
INTERNET-DRAFT Regional Mobility Agent Signalling May 2002
The MN on receiving packets then can optionally resend the RREQ containing
the discovered nRoA to confirm the visitor list state...If the above is
acceptable then the effect of the RREP is minimised and RoA assignment delay
then becomes the critical issue. This results in a modified preference order
of d, a, b, c.
10.19 Proxied HA Update
The architecture as described still requires each MN to update each global HA
itself with the new RoA on each inter-RMA hand-off. It does so by sending an
MIP Registration to that global HA, via the RMA, with the nRoA as the CCoA
for the HoA assigned in that HA to the MN. The architecture simply enables
these RA layer updates, for multiple HA/HoA pairs, to be once per region
rather than once per FA, and to be distributed in time, whilst the MN is in
that region, rather than having to be sent immediately as part of the inter-
RMA hand-off. This can be improved upon by enabling the oRMA to instead
update the HA for the MN.
This relies on the MN actively communicating with the oRMA as part of the
inter-RMA hand-off. The MN sends either a PRANE to the nRMA which triggers
the BU to the oRMA, or it sends a Combined RA/LA message to the oRMA via the
nRMA. Both of these messages contain the nRoA that is required to be inserted
into the global HAs with which the MN is having a remote access session.
Either the BU or the Registration Request can trigger the transfer of the
oRMA-MN SAs to the nRMA, protected by the oRMA-nRMA SA.
Context Transfer is then used between the oRMA and the nRMA to rapidly move
the Remote Access state for all the HA/HoA pairs being employed by the MN,
from the oRMA to the nRMA. This includes the oRMA-HA SA that can be used for
secure communications with the HA. Alternatively, this HA/HoA state could
instead be stored in the local AAA system and fetched directly from there by
the nRMA. Either way, the nRMA acquires the SA and the HA/HoA information.
Either oRMA or the nRMA are therefore potentially in position to update the
global HAs with the new RoA address. The alternative approaches are described
below.
10.19.1 oRMA based Proxy HA Update
The model is a hierarchical interpretation of Route Optimisation as described
in [RouteOpt]. The global HA is sending to the RMA (local HA) and from the
perspective of the RMA is a Correspondent Node at the LA layer. When the oRMA
is informed of the nRoA then the RMA can send a BU to the HA (containing the
HoA, nRoA information) using the existing oRMA-HA SA, requesting the HA to
tunnel traffic for the HoA directly to the nRoA. This will cause the oRMA to
be bypassed.
The Binding Warning Registration extension is used to carry the Warning to
the oRMA if the oRMA is the destination of the MIP RA layer RREQ. The oRMA
then inspects the oRoA, determines the HoAs for the HAs from local state, and
then issues the BUs secured by the oRMA-HA SA. The MN adds the Binding
Warning and can therefore use this to decide which HAs get handed off
immediately.
A.W. O'Neill Expires Oct 2002 [Page 54]
INTERNET-DRAFT Regional Mobility Agent Signalling May 2002
If the nRMA is instead going to be contacted via an LA layer BU from the nRMA
or nFA, then the BU is an explicit indication of an inter-region hand-off
which contains the nRoA and so this should cause the oRMA to again issue BUs
for all HA/HoA pairs tied to the oRoA, which will be forwarded to the nRoA
(or nRMA SHCoA)
If in either case the oRMA does not have the HA/HoA state, or simply wishes
to wait to see if the RA session is still active, the Binding Update to a
specific HA can be triggered by an arriving packet from that HA, addressed to
the HoA and encapsulated towards the oRoA. The oRMA can also then dynamically
determine the HoA.
Irrespective of how the BU is generated, the BUack is mandated following the
authentication check and is returned to the oRMA.
The global HA in MIP standards does not presently received Binding Updates
nor respond to them by redirecting an MIP visitor list entry to the new CoA
in the BU. The FA can however presently act like a HA and respond to the BU
by forwarding to the reported CoA but this is only allowed because the MN has
signed it.
In this case, the MN is not directly affected whether or not the BU is
processed because in either case the MN receives packets via the nRoA. This
is therefore simply a regional optimisation. The HA can be assured that this
is true because the message is authenticated by the oRMA-HA, this oRMA has
already been trusted for a long while to forward for the HA, and the action
of the message is to stop packets going through it, which is hardly the
action of an attacker. If a node somehow masquerades as the oRMA then the
BUack still goes to the valid oRMA and so the attack is detected and the
attacker can give themselves away if they actually include a nRoA in an
attempt to capture packets. Essentially, though the chain of trust should be
sufficient here between the RMA and the HA.
The BU Identification field should be set according to the multitude of
ongoing BUs sent between those nodes and independent of any MN-HA
identification field for that HoA/HA pair. This is for ordering purposes and
replay protection.
Now if the BU or BUack fails then the oRMA can resend. If the MN has
cancelled the RA session with that HA then the BU will be ignored. If the
Registration or BU to the oRMA is lost then they will be resent by the MN. If
the HA fails to redirect to the nRMA then packets will continue to arrive at
the oRMA which can again trigger resending the BU.
10.19.2 nRMA based Proxy HA update
In this case the BU is sent from the nRMA once the Context Transfer of state
has occurred from the oRMA. The BU is the same as before but at the HA this
is a redirection to a node asking for that redirection which is clearly more
dangerous, although it is still secured via a HA-nRMA SA (via CT or AAA). It
is also much slower than the oRMA based approach and should therefore only be
used if the oRMA has failed to update the HA at that stage. One advantage of
the nRMA based approach is that the HA gets to know the nRMA address as well
as the nRoA from the BU so that any redirection can be traced whilst the HA
only knows the nRoA from the BU when sent by the oRMA.
A.W. O'Neill Expires Oct 2002 [Page 55]
INTERNET-DRAFT Regional Mobility Agent Signalling May 2002
10.19.3 RA session Group HA Hand-off Extension
Ideally, either approach would be totally secure if some form of MN-HA SA was
used to protect an extension that actually stated that an inter-RMA hand-off
was requested by that MN, and the old and new, region names, RMA addresses or
RoA addresses as identified in the FAA to the MN. One such approach would be
to use a group key as is commonly used in multicast between a single sender
and a multicast group. The MN would provide the asymmetric group key to each
HA and update it in periodic RA registrations. Asymmetry is required so that
a rogue HA cannot pretend to be the MN. On an inter-RMA hand-off, the MN
would sign a Group HA Hand-Off extension containing the new and old regions,
RMA addresses and RoAs and send it to the oRMA and nRMA in the
Registration/BU. Each RMA would then include this extension in the BUs to the
HAs which would verify that they are acting on behalf of the MN and would
bound the risk depending on the information detailed in the Group HA HO
extension. For example, if the extension includes oRoA and nRoA then there is
essentially no risk although this can only be sent by the MN once the nRoA is
returned to the MN in the RREP, ie after an LA Reg to the nRMA. Therefore
first undertaking an LA Reg and subsequently undertaking a proxy HA update
via the old or newRMA is preferred. If the extension includes the oRMA/nRMA
address then BUs sent from those addresses are safe. If the extension only
includes the new region name then the HA has at least had confirmed that an
inter-RMA hand-off is required and has good information of where the MN
thinks it is going, and can compare it to a region name included by the
oRMA/nRMA in its BU, or to historical state in the HA regarding trusted
regions.
11. IPv6 Considerations
The Nested/Concat model is equally applicable to MIPv6 with the major change
being that the MN in IPv6 is able to rapidly acquire a local interface
address from each FA. This address can then be used as a MN CCoA for the LA
MIP layer to the RMA. The RMA would still allocate the RoA to the MN and the
MN would once again use this RoA as a MN CCoA for the RA layer HoA. The
remote access layer is therefore unchanged conceptually from the MIPv4 model.
The FA in MIPv6 is replaced by a Local Mobility Agent(LMA), and the LMA and
RMA could once again cooperate to control and manage local and remote access
services in sympathy with the MN privileges and the operator policies.
12. Security and AAA Considerations
The security requirements and mechanisms behind all the features within this
architecture need significant work and review. However, no major new security
issues are raised, by the basic features in this draft, than are already
considered in the design of MIPv4, regional tunnelling [RegTun], [RoutOpt]
and reverse tunnelling [RevTun]. This is because at all times all information
elements are authenticated to the same level as that demanded by existing MIP
and AAA exchanges. Some of the new or assumed security mechanisms are
highlighted below to help support this analysis.
A.W. O'Neill Expires Oct 2002 [Page 56]
INTERNET-DRAFT Regional Mobility Agent Signalling May 2002
12.1 FA and RMA Auto-configuration
The FA can authenticate itself to the local AAA system based on a FA-AAA SA,
and then have the AAA system return its regionname, default RMA address, set
of associated RMA addresses in the region, the FA-NAI and the RMA-FA key
material for those SAs. Similarly, each RMA has an RMA_AAA SA and can obtain
its regionname, role (default or associated), the set of region RMAs, the set
of region FAs, and the key material for the RMA-RMA and RMA-FA SAs. The RMA-
NAI could be for example the 'regionnameandnumber@domain'.
The FA and RMA must share a Security Association (SA) to protect FA-RMA
extensions and specifically to enable the FA to dynamically assign the FA CoA
and forward it to the RMA using the HFAext. This SA can be pre-configured,
distributed and maintained through IKE/IPSEC (or other such system), or
managed and distributed through MIP mechanisms from the RMAs in a region.
12.2 AAA Key Material Distribution
The AAA system can be used for initiation of the MN-FA, MN-RMA, MN-HA, FA-RMA
and RMA-HA SAs. These are used for the authentication extensions, to
authenticate MIP messages and contained extensions between MIP nodes. Local
AAA mechanisms already exist to configure MN-FA, FA-RMA and MN-RMA SAs for
dynamic RMA assignment where the RMA is a local HA, and the AAA request is
sent from the FA triggered by the LA RREQ. The FA-RMA can also be pre-
configured as discussed in 13.1. Any RMA dynamically assigned by the FA must
be communicated to the AAA system, for example using the equivalent of the
HA-NAI, so that it can configure the RMA with the required key material for
RMA-MN and RMA-FA (if not also preconfigured). For incremental deployment,
this draft also considers an additional capability whereby the RMA key
material can instead be delivered by the AAA system to the FA, and then
forwarded to the RMA in an undefined extension protected by the pre-existing
FA-RMA SA.The global AAA system is in many cases already able to dynamically
assign a global HA and HoA and provide the required MN-HA and FA-HA. RegTun
extends this to enable an intermediate GFA to be supported. The missing piece
however is to enable the AAA system to first assign the LA elements from the
LA Reg and then to assign the missing elements for the RA Reg. In addition, a
Combined RA/LA Reg should be able to create all the required SAs together in
a co-ordinated manner to enable efficient configuration in a single AAAH-AAAF
round trip, and to also avoid duplication for key material by sharing MN-FA
and FA-RMA between the two MIP layers. Additional RA layer signalling should
then only trigger the AAA system via the FA, to provide the additional
session specific HA/HoA parameters along with material to generate new MN-HA
and RMA-HA SAs. The AAA system must in addition be able to deliver the MN-HA
and RMA-HA generation material to the RMA and HA either through Diameter AAA
routing or via additional RADIUS look-ups at the RMA and HA when incoming
Registrations are received that demand such action as a result of a missing
SA. These activities are improved through the use of HA-NAI and AAA-NAI as
discussed in [AAA-NAI].
If the AAA system cannot support RMA-MN and MN-RMA key material distribution,
then in the case of the FA and RMA sharing a pre-configured association it is
possible that the FA can act as a security server and use a MN-FA SA obtained
through MN authentication, and the FA-RMA SA to mutually configure the MN-RMA
SAs.
A.W. O'Neill Expires Oct 2002 [Page 57]
INTERNET-DRAFT Regional Mobility Agent Signalling May 2002
12.3 Inter-operator PRANE
There is a slight concern with the inter-RMA inter-operator BU, that is
triggered by the PRANE and which has a zero nRMA CoA. This is because this is
generally not known until the nRMA is traversed. The MN calculation of the
authenticator is then still based on the oRMA-MN auth SA but does not
authenticate the missing RMA CoA. The assigned nRMA CoA is instead protected
by an inter-RMA SA and inserted in a HFAext to the oRMA. However, the MN is
still specifically stating that it is undertaking an inter-operator hand-off
in the BU, the oRMA can see that it was directed via a specific RMA and any
vulnerability is only for the duration of the transient forwarding.
12.4 Forwarding Checks
The GFA model seeks tight checks on the previous hop when packets are
tunnelled from the HA to the GFA and onto the MN. This is to ensure packets
are not falsely injected towards the HoA by a rogue element which either does
not know the HA or GFA address, or cannot use them because of ingress
filtering of source addresses. In the Nested Model and Concat models,
significant effort is made to avoid HA/HoA specific state in the FA but this
reduces the granularity of any check. In the Nested case, the MN still sees
the originating HA and so can meet the requirements but only after the air-
link has been traversed. It can also however rely on the RMA undertaking this
check by keeping HA specific state or even HoA specific state. Concat mode
again relies on a chain of trust with the FA having only MSCoA state and
relying on the RMA to check the RoA destination address and to map the flow
to the correct MSCoA. The MN cannot see the originating HA address and so the
RMA HA state to match the HA and RoA to registrations appears more critical
here although the fact that a registered RoA is used maybe sufficient and
hence we can avoid HA specific state in the RMA for basic Concat forwarding.
However, saying all that it is also apparent that a MN that also has local
access is open to traffic from a range of CNs and so maybe the need for tight
source checking is less pronounced if we can assume correct ingress filtering
is in place.
In the reverse tunnelling case, the source checking is required to avoid
packets being injected into a private domain via the GFA and HA. This again
requires a chain of trust but in both the Nested and Concat modes the RA
reverse tunnel is from the RoA direct to the HA which significantly reduces
any threats. If the LA reverse tunnel is also used then packets are routed
first to the RMA where
13. Notice Regarding Intellectual Property Rights
Flarion's submissions will conform with RFC 2026. Flarion may seek patent
protection on some or all of the technical information submitted by its
employees in connection with the IETF's standards process. If part(s) of a
submission by Flarion is (are) included in a standard and Flarion owns
patent(s) and/or pending patent application(s) that are essential to
implementation of such included part(s) in said standard, Flarion is prepared
to grant a license on fair, reasonable, reciprocal (license back) and non-
discriminatory terms on such included part(s).
A.W. O'Neill Expires Oct 2002 [Page 58]
INTERNET-DRAFT Regional Mobility Agent Signalling May 2002
14. Acknowledgements
George Tsirtsis of Flarion Technologies undertook detailed reviews of this
document.
15. References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9,
RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
[NestMIP] A.W. O'Neill, ``Nested MIP," Internet-draft, draft-ietf-oneill-mip-
nested-00.txt, April 2002.
[PCCoA] A.W. O'Neill, ``Proxy CCoA Tunnelling for Mobile IP," Internet-draft,
draft-oneill-mip-proxyCCoA-00.txt, May 2002.
[MIPv4] C.E. Perkins, Ed., "IP Mobility Support for IPv4," RFC3220, Jan 2002.
[RegTun] E. Gustafsson. Ed., " Mobile IPv4 Regional Registration,
Internet-draft, draft-ietf-mobileip-reg-tunnel-06.txt, 1March 2002
[RegTunMods] A. O'Neill, "Modifications to Regional Tunnelling", Internet-
draft, draft-oneill-mip-regtun-mods-00.txt, 9 April 2002.
[RevTun] G. Montenegro, Ed., "Reverse Tunnelling for Mobile IP, revised,"
Internet RFC 3024, January 2001.
[RevTunMods] A. O'Neill, "Hand-off Extensions for Reverse Tunnelling",
Internet-draft, draft-oneill-mip-revtun-ho-00.txt, 22 Feb 2002.
[NestMIP] A. O'Neill, "Nested MIP for IP Mobility Management", Internet
Draft, draft-oneill-mip-nested-00.txt, May 2002.
[ConcatMIP] A. O'Neill, "Concatenated MIP for IP Mobility Management",
Internet Draft, draft-oneill-mip-concat-00.txt, May 2002.
[RMAsig] A. O'Neill, "Regional Mobility Agent Signalling", Internet-draft,
draft-oneill-mip-rmasig-00.txt, May.
[MIPAAA] Charles E. Perkins, Pat R. Calhoun, "AAA Registration Keys for
Mobile IP", draft-ietf-mobileip-aaa-key-09.txt, 26 February 2002.
[RoutOpt] C. Perkins, D. Johnson, "Route Optimization in Mobile IP",
Internet-Draft, draft-ietf-mobileip-optim-11.txt, 6 September 2001.
[LowLat] K.E. Malki, Ed., "Low Latency Handoffs in Mobile IPv4", Internet-
Draft, draft-ietf-mobileip-lowlatency-handoffs-v4-03.txt, November 2001.
[MIPv6] D. Johnson, C. Perkins, ``Mobility Support in IPv6", Internet-Draft,
draft-ietf-mobileip-ipv6-16.txt (work in progress), 22 March 2002.
[AAANAI] T. Johansson, F. Johansson, 'AAA NAI for Mobile IPv4 Extension',
Internet Draft, draft-johansson-mip-aaa-nai-01.txt, 09-Apr-02.
A.W. O'Neill Expires Oct 2002 [Page 59]
INTERNET-DRAFT Regional Mobility Agent Signalling May 2002
Author's Addresses
Alan O'Neill
Flarion Technologies
Phone: +1 908 947 7033
Email: oneill@flarion.com