One document matched: draft-oneill-mip-concat-00.txt
Personal A. O'Neill
Internet Draft Flarion Technologies
Document: draft-oneill-mip-concat-00.txt 8 May 2002
Expires: Oct 2002
Concatenated MIP for Mobility Management
<draft-oneill-mip-concat-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] provides a means to support both localization and
aggregation of MIP signalling. It achieves 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
produces the hand-off of potentially multiple parallel remote access
sessions. The consequences of this model are however reductions in bandwidth
efficiency due to the additional layers of temporary and permanent
encapsulation.
This draft describes a complementary model for MIP forwarding, called
Concatenated MIP that re-uses, and extends the localised and aggregated MIP
signalling model from [NestMIP]. The enhanced forwarding model is intended to
co-exist both with [NestMIP] and [RegTunMods] so that the appropriate trade-
offs can be made on a per session basis between bandwidth efficiency and
other features. Inter-RMA hand-offs between Nesting and Concatenating
Regional Mobility Agents is also supported.
A.W. O'Neill Expires Oct 2002 [Page 1]
INTERNET-DRAFT Concatenated MIP for IP Mobility Management May 2002
INDEX
Abstract
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . . . . 3
3. Terminology used in this document . . . . . . . . . . . . . . . . . 3
4. Motivation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Forwarding Models . . . . . . . . . . . . . . . . . . . . . . . . . 4
5.1. Nested MIP Forwarding. . . . . . . . . . . . . . . . . . . . . 4
5.2. Regional Tunnel Forwarding . . . . . . . . . . . . . . . . . . 4
5.3. HoA Independent Switching. . . . . . . . . . . . . . . . . . . 5
5.4. Concatenated MIP Forwarding. . . . . . . . . . . . . . . . . . 5
5.5. Private addressing . . . . . . . . . . . . . . . . . . . . . . 7
5.6. Security Associations. . . . . . . . . . . . . . . . . . . . . 7
6. Basic Concatenated MIPv4 Signalling Description . . . . . . . . . . 8
6.1. Local Access Only Signalling . . . . . . . . . . . . . . . . . 9
6.2. Remote Access Only Signalling. . . . . . . . . . . . . . . . . 9
6.3. Local and Remote Access Signalling . . . . . . . . . . . . . . 9
6.4. Combined LA/RA Signalling. . . . . . . . . . . . . . . . . . . 10
6.5. Style Extension. . . . . . . . . . . . . . . . . . . . . . . . 10
7. AAA Support for Concatenated MIP. . . . . . . . . . . . . . . . . . 10
7.1. FA AAA Requests. . . . . . . . . . . . . . . . . . . . . . . . 10
7.2. RA AAA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . . . . 11
10. Notice Regarding Intellectual Property Rights. . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
Nested MIP [NestMIP] provides a means to support both localization and
aggregation of MIP signalling. It achieves 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
produces the hand-off of potentially multiple parallel remote access
sessions. The consequences of this model are however reductions in bandwidth
efficiency due to the additional layers of temporary and permanent
encapsulation.
A.W. O'Neill Expires Oct 2002 [Page 2]
INTERNET-DRAFT Concatenated MIP for IP Mobility Management May 2002
The additional encapsulations can be avoided by adding support for CoA
switching to the Regional Mobility Agents and Foreign Agents. The CoA
switching techniques described here are broader than those presently
supported by Foreign Agents (for smooth forwarding) and by Gateway/Regional
Foreign Agents for Regional Tunnelling, to preserve the aggregation
capabilities.
This draft therefore describes a complementary model for MIP forwarding,
called Concatenated MIP that re-uses, and extends the localised and
aggregated MIP signalling model from [NestMIP]. The enhanced forwarding model
is intended to co-exist both with [NestMIP] and [RegTun] so that the
appropriate trade-offs can be made on a per session basis between bandwidth
efficiency of other features. Inter-RMA hand-offs between Nesting and
Concatenating Regional Mobility Agents is also supported.
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 HA/FA type behaviour
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
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
LA/RA-NAI - the MN-NAI included in the LA/RA MIP Registration for AAA
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 results in RoA change
HFAIPext - the HFA IP address extension (generalization of GFAIPext)
4. Motivation
The motivation for this work is described fully in [NestMIP] 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
forwarding is enhanced with two forms of CoA switching to reduce the number
of layers of transient and persistent encapsulation both during and after
hand-off. In addition, the work seeks to co-exist with the [RegTun] model.
A.W. O'Neill Expires Oct 2002 [Page 3]
INTERNET-DRAFT Concatenated MIP for IP Mobility Management May 2002
5. Forwarding Models
5.1. Nested MIP Forwarding
Nested MIP incurs a remote access encapsulation between the HA and the MN
CCoA, with an additional encapsulation between the Regional Mobility Agent
(RMA) and the Foreign Agent (FA) CoA. The MN is allocated a Regional Address
(RoA) from the RMA which is used by the MN both as an interface address for
Local Access (LA) traffic and as the CCoA for Remote Access (RA) traffic.
Reverse tunneled LA traffic can be sent using either direct (from RoA to CN)
or encapsulating delivery style (RoA to CN, within RoA to FA address) and
then the FA encapsulates from FA CoA to the RMA address. Reverse tunneled RA
traffic is encapsulated from the CCoA to the HA address and bypasses the RMA.
Reverse RA plus reverse LA results in the reverse RA traffic visiting the
RMA. These options are shown graphically in figure 1.
CN HA RMA FA MN
Forward LA CN----------------------------------------------->RoA
RMA=====>FACoA
Reverse LA CN<-----------------------------------------------RoA
RMA<=====FACoA
Forward RA CN------------------------------------------------>HoA
HA==================================>RoA
RMA=====>FACoA
Reverse RA CN<------------------------------------------------HoA
RevTun RA CN<------------------------------------------------HoA
(RMA bypass) HA<==================================RoA
RevTun LA/RA CN<------------------------------------------------HoA
HA<==================================RoA
RMA<=====FACoA
Figure 1. Forward and reverse tunnelling in Nested MIP
5.2. Regional Tunnel Forwarding
Regional Tunnelling uses a GFA that undertakes CoA switching. The remote
access traffic is encapsulated by the HA from the HA address to the shared
GFA CoA (SHCoA). The GFA decapsulates and inspects the visitor list based on
the HoA, before re-encapsulating from the GFA address to the shared FA CoA
(SHCoA). The FA then decapsulates, again inspects the visitor list based on
the HoA, and then forwards to the MN. In the case of a MN CCoA, the GFA sends
to that CCoA directly, bypassing the FA. Reverse tunneled traffic uses the
visitor list bindings in the reverse direction as shown in figure 2. Note
that this architecture does not support multiple HoAs efficiently, does not
offer support for aggregated hand-offs, cannot easily support concurrent
local access or mixed public and private addressing, and the GFA must always
be visited in both directions.
A.W. O'Neill Expires Oct 2002 [Page 4]
INTERNET-DRAFT Concatenated MIP for IP Mobility Management May 2002
CN HA GFA FA MN
Forward RA CN<------------------------------------------------HoA
HA=====>SHCoA X GFA=====>SHCoA
Reverse RA CN<------------------------------------------------HoA
HA<=====SHCoA X GFA<=====SHCoA
Figure 2 Forwarding and reverse tunnelling with the GFA
5.3 HoA independent switching
The limitation with HoA based forwarding is two fold. Firstly, the MIP
registration and hand-off signalling to update the HoA state is clearly HoA
specific. This is counter to the desire to support multiple concurrent HoAs
because each hand-off then requires multiple parallel MIP signalling phases.
HoA based forwarding also naturally requires that the HoAs from multiple
independent home subnets (corporates, home nets etc) must be globally unique.
This means that the HoAs must be addressed from either the global Internet
space or mapped into a single private address space resulting in obvious
deployment complexity and/or constraints. The nested model avoids both of
these problems by basing forwarding on the Roaming address (RoA) used to hide
the potentially multiple MN HoAs, rather than on each HoA. This however leads
to additional tunnelling overhead that is next addressed by Concatenated MIP.
The other limitation is that the GFA does not provide an address for local
service that is coordinated with the remote access state. Specifically, the
GFA is forwarding based on HoA, and detunnels/tunnels based on CoAs.
5.4. Concatenated MIP Forwarding
Concatenated MIP seeks to keep the benefits of the Nested MIP model in terms
of private address support, multiple HoAs and concurrent local and remote
access, whilst eliminating the additional encapsulation between the RMA and
the FA, when compared to Nested forwarding as shown in figures 1 and 2. This
is achieved by the MN continuing to acquire an RoA from the RMA, and then
registering this RoA as the CCoA in each global HA for each remote access
session. The HA behaviour is therefore identical with Nested MIP in that it
encapsulates arriving HoA packets into the RoA, which causes them to be
routed to the RMA. In the Nested MIP model, the RMA acts like a HA and adds
the additional encapsulation to the FA CoA maintained by the LA MIP
signalling. In the Concatenated MIP, the RMA instead acts as a CoA switch but
in a very different manner to that of the GFA.
Firstly, to maintain support for private addressing, the RMA must switch on
RoA rather than HoA specific state. The RoA is contained in the LA MIP Reg in
the HoA field whilst the new FA CoA is in the CoA field. Therefore any hand-
off at the LA layer will cause the RMA to update the next hop to be the new
FA CoA for all traffic arriving for that RoA. This state is used to ensure
that any packets (from any HoA) arriving encapsulated to the RoA, are
switched (not encapsulated) into a tunnel from the RMA address to the FA CoA.
With the RA MIP Reg being forwarded via the RMA, that RMA can limit this
switching to those packets arriving from the HAs registered for that RoA
address.
A.W. O'Neill Expires Oct 2002 [Page 5]
INTERNET-DRAFT Concatenated MIP for IP Mobility Management May 2002
Secondly, the FA must also switch on globally unique and MN specific state so
that the MN can be reached and to enable clean support for private
addressing. However, in this case the arriving packets from the RMA do not
now contain the RoA address and so HoA specific forwarding is potentially
required. This is fine for globally unique addresses but clearly prevents
private HoAs due to the problem of ensuring their uniqueness. In addition,
using HoA state in the FA means that it must be maintained during inter-FA
hand-off using Context transfer because we wish to avoid non-aggregated HoA
specific Registrations to the RMA.
A further refinement can however avoid this problem through the additional
step of making the FA CoA MN specific. A MN Specific FA CoA (FA MSCoA) can be
allocated to the MN by the FA, when the MN wishes to avoid HoA specific
state. The FA either advertises the MSCoA to the MN on arrival using a
unicast FAA (based on AAA state), or adds the dynamically allocated MN
specific FA CoA into the HFAext sent to the RMA (as in [RegTun]). The LA MIP
Reply carries the RoA and the MSCoA back to the FA and MN. The RA MIP Reg in
contrast registers the RoA into the HA for the HoA. Then, when packets arrive
at the RMA encapsulated to the RoA (for any HA/HoA pair), the RMA looks in a
switching table and replaces the HA:RoA encapsulation with the RMA: MSCoA
encapsulation. This reaches the FA where the FA decapsulates from the
RMA:MSCoA and determines the RoA from the incoming tunnel destination address
(the MSCoA). The FA then encapsulates into that RoA if the destination
address is not already that RoA (ie is a HoA) and then forwards based on that
RoA instead of the HoA address that was encapsulated. Clearly, for LA layer
traffic the destination will already be the RoA and so additional
encapsualtion is not required. This therefore produces HoA independent RA
forwarding by virtue of the incoming tunnel addresses in the RMA and FA being
MN specific (the RoA and the MSCoA respectively). The resulting forward and
reverse forwarding and tunnelling is shown in figure 3. Note that the MSCoA
can be a private address and that the tunnel between the FA and the MN can be
avoided using proxy Care of Addresses [PCCoA].
CN HA RMA FA MN
Forward LA CN------------------------------------------------>RoA
RMA=====>MSCoA
Reverse LA CN<------------------------------------------------RoA
RMA<=====MSCoA
Forward RA CN------------------------------------------------>HoA
HA=======>RoA X RMA=====>MSCoA=======>RoA
Reverse RA CN<------------------------------------------------HoA
RevTun RA CN<------------------------------------------------HoA
HA<===================================RoA
RevTun RA/LA CN<------------------------------------------------HoA
HA<=======RoA X RMA<=====MSCoA<=======RoA
Figure 3. Forwarding and reverse concatenated tunnelling
A.W. O'Neill Expires Oct 2002 [Page 6]
INTERNET-DRAFT Concatenated MIP for IP Mobility Management May 2002
Meanwhile LA traffic towards the RoA arrives at the RMA and is not matched on
any RA layer HA:RoA pair, but matches simply on the LA layer RoA entry. This
results in the packet simply being encapsulated into the FA MSCoA and
forwarded to the FA as per Nested MIP. The FA decapsulates and forwards
according to the MSCoA/RoA/MN state.
Concatenated MIP can co-exist with GFA type forwarding, and the RMA can
therefore offer CoA switching with specific constraints. Firstly, the HoA
must be globally unique, RMA and FA must be able to store HoA state, and the
MN should only employ a single RA session such that a single non-aggregated
LA MIP Reg can hand-off the session state between FAs. The GFA mode is useful
because it enables backwards compatibility with RegTun, offers more efficient
support for HoA specific processing, does not require MN specific FA CoAs and
avoids the need for RoA assignment when a local access is not required.
Finally, it should be noted that in IPv6 the MN can instantly acquire a CCoA
from each FA and can therefore use that CCoA instead of an FA based MSCoA to
register into the RMA. In this case there is still a tunnel over the air
interface as is the case with all CCoA based MIP forwarding.
CN HA RMA LMA MN
Forward RA CN-------------------------------------------->HoA
HA====>RoA X RMA===============>CCoA
Reverse RA CN<--------------------------------------------HoA
HA<==============================RoA
Reverse RA/LA CN-------------------------------------------->HoA
HA<====RoA X RMA<===============CCoA
Figure 4. Concat forwarding in IPv6
5.5. Private addressing Implications
The HoA is now forwarded natively between the CN and the HA and at all other
times is protected by an encapsulation. The HoA address type therefore only
needs to match the routing in the HA - CN domain which can be public or
private. The RoA must be routable between the HA and the MN, including both
sides of the RMA. The RoA can be a public address or a NAT can be used to map
a private RoA address into the public address space. The MSCoA is only known
by the RMA and FA, and therefore can be public or private. It is guaranteed
to be unique to each MN because of the RMA managing its address block. In
IPv6, the CCoA can be public or private but the necessity for private
addresses is clearly significantly removed.
5.6. Security Associations
The two MIP layers would continue to use the family of authentication
extensions (and associated SAs) that are required in MIP standards docs
[MIPv4, RegTun, RevTun, RoutOpt etc]. These include the MN-FA, FA-HA and MN-
HA auth extensions, with the RMA being treated as a HA in the LA MIP Layer.
A.W. O'Neill Expires Oct 2002 [Page 7]
INTERNET-DRAFT Concatenated MIP for IP Mobility Management May 2002
The only significant differences though are that each FA can now practically
employ a pre-configured security association (SA) with each RMA, and the RMA
and FA can potentially dynamically allocate to the MN an SA with the RMA. The
system can of course also rely on [MIPAAA] by the FA informing AAA of the
allocated RMA address and the foreign AAA returning the key material for the
FA/MN to use with that RMA. In either case, the MN-FA and the FA-RMA can be
shared across both LA and RA MIP traffic. Finally, LA hand-off continues to
make use of the authentication mechanisms associated with the particular MIP
hand-off solution (inter-FA SAs, PFANE etc). Minor extensions to the existing
security mechanisms are required for supporting inter-RMA hand-off and these
are described in [RMAsig].
6. Concatenated MIPv4 Signalling Description
This re-uses the same signalling plane as that designed for Nested MIP with
the restriction that Concatenated MIP features are only available if the
signalling is directed through the FA and the RMA. The RMA must be visited to
enable the RMA to learn the switching state. Re-using the same signalling
plane ensures that Nested, Concatenated and GFA MIP can to some extent co-
exist both from an evolution and efficiency perspective.
The LA Reg message is used to update the RMA with the evolving FA MSCoA. It
is also used to undertake combined RMA and FA hand-off, to obtain the new RoA
at the new RMA and to put in place inter-FA, inter-RMA and/or old RMA new FA
temporary forwarding. Specifically, hand-off between Nested, Concatenated and
GFA capable RMAs is supported. This is described in detail in [RMAsig]. The
RA MIP Reg message is used to update the HA with the new RoA and to refresh
the LA FA CoA in the RMA.
In all cases, the information fields in the standard MIP Reg/Reply message
fields are consistent with Nested MIP, and only the way in which that
information is used in the RMA and FA changes. The decision about whether the
MN forwards to the FA is again dictated by the setting of the 'R' bit whilst
the FA configuration and the AAA state returned to the FA dictates whether
the RA registration is sent via the RMA. This is because the routing via the
RMA is to install awareness into the RMA of HA/HoA state for value-added
processing that is optional both for the operator to support and for the MN
to require via its AAA profile. The processing in the HA is the same for the
Nested and Concatenated models and similar for the GFA model. However, it is
essential that the FA and RMA can distinguish between Nested, Concatenated
and GFA Reg requests and this can be achieved either through an MIP flag
and/or a Style extension (Stylext).
The MIP flag option is to use a one bit flag to indicate a request for
Concatenated or Nested MIP processing for this registration. The absence of
the flag, and hence the backwards compatible option, is Nested MIP as this
can be achieved today with existing MIP standards. GFA is a subset of
Concatenated and is selected by the nature of the allocated FA CoA. The flag
space is however exhausted but use could be made of the 'I' bit which could
be used to indicate support for generic regional signalling.
A.W. O'Neill Expires Oct 2002 [Page 8]
INTERNET-DRAFT Concatenated MIP for IP Mobility Management May 2002
The extension option would be for the MN to include a Stylext that includes
additional flags to supplement the MIP header flags. This flag space can then
be used to provide Nested/Concat/GFA service specific signalling options to
the MN without consuming the more generic MIP Reg flag space. This then
enables the MN to dynamically control invoked features rather than relying on
the more static AAA profile option. The Stylext could contain flags for
public/private address allocation control, NAT control, RMA routing, service
level as well selecting between a shared or MN specific CoA. Other Stylext
flags can be used to control how broadcast and multicast is forwarded in the
LA and RA layers, and to select between local access, remote access and
remote+local access service.
The combined approach, whereby the MIP Reg flag space is used to
differentiate between the Nested and Concat signalling from the MN (maybe by
expanding the scope of the 'I' bit), and the Stylext flag space is used by
the MN and operator to over-rule or enhance that request, is probably the
best approach going forward. This ensures the basic functionality can be
supported with zero overhead, but at the cost of the Stylext overhead comes
the added opportunity for controlling additional optional service features.
6.1 Local Access Only Signalling
Local Access signalling is unchanged from Nested MIP as a shared FA CoA is
only required and local access traffic is always encapsulated (Nested) in the
FA CoA. Clearly though, if a FA MSCoA is assigned then it can be used instead
of a FA SHCoA.
Remote access is prevented by the FA blocking MIP Registrations not addressed
to the allocated RMA and/or by appropriate blocking of data packets in an FA
located firewall. A private RoA can also be used in conjunction with a NAT to
prevent remote access MIP signalling to destinations outside of the local
operator private addressing domain (intra-domain RA only)
6.2 Remote Access Only Signalling
The MN first undertakes LA MIP signalling to obtain an RMA and an RoA, and to
bring the MN privileges into the FA. These privileges will indicate that the
MN is not allowed to use the local access service but is permitted to
undertake remote access. This results in the FA blocking any packets to/from
the RoA, other than those necessary for LA/RA MIP signalling.
The MN privileges might also indicate that only a specific remote access
registration is allowed based on specific HA and/or HoA. The FA and/or RMA
can then easily block encapsulated packets sent from/to addresses other than
the permitted HA/RoA/MSCoA parameters because the FA (and the RMA) are on the
path of the Registrations. HoA specific controls can also be added.
6.3 Local and Remote Access Signalling
This is the same as section 6.2 except that the MN privileges enable local
access service as well as remote access service. The RMA and FA will
therefore allow both encapsulated and unencapsulated packets using the
RoA/MSCoA state. Once again local access can be provided in addition to only
a specific remote access service as indicated by the MN privileges.
A.W. O'Neill Expires Oct 2002 [Page 9]
INTERNET-DRAFT Concatenated MIP for IP Mobility Management May 2002
6.4 Combined RA/LA Signalling
Given that Concatenated MIP requires the RA MIP Reg to visit both the FA and
the RMA, it is always possible to combine LA updates into the RA MIP
messaging to the HA, and only use LA messaging to otherwise refresh LA state
as described in [NestedMIP] and [RMAsig].
6.5 Style Extension (Stylext)
The following basic information needs to be explicitly signalled in MIP
messages to distinguish between Nested, Concatenated and GFA MIP features. In
addition, LA and RA MIP messages must be distinguishable which is discussed
further in [RMAsig] along with other stylext requirements.
Request for LA service
Request for Public or Private RoA
Request for RA service
Request for Public or Private HoA
Nested, Concat or GFA mode in RMA for all dependent RA sessions
RA service in nested mode with public or private HoA results in a FA SHCoA.
RA service in concat mode with a public or private HoA results in a FA MSCoA.
RA service in GFA mode is suitable for a single RA session with no local
access and results in a SHCoA.
7. AAA Support for Concatenated MIP
The following sections detail some additional optional mechanisms within, and
hence requirements for, AAA systems supporting the Basic Nested MIP model.
7.1. FA AAA Requests
LA MIP is provided to MNs following a AAA check which is triggered at the FA,
based on the NAI in the LAMIP Registration as per RFC 2794. This "LA-NAI" is
used to route the AAA request to the home AAA server for the MN via any
foreign AAA server as per AAA Roaming. This triggers appropriate
authentication and authorization results in the MN privileges being returned
to the FA. This indicates the authorized service allowances in the foreign
wireless network as well as controlling the accounting requirements for the
session.
Concatenated MIP requires special processing in the FA/RMA and so the AAA
response needs to inform the FA as to whether Nested or Concatenated MIP is
to be supported for all the MN RA sessions, and should do so in a way that
causes Nested to be supported by default. Concatenated uses a MN specific FA
CoA to ensure HoA independence and forwarding to the correct MN from the FA.
Nested, Concatenated and GFA also potentially require [MIPAAA] assistance to
secure the signalling plane and so the Stylext must make the security
requirements explicit in the FA/AAA system.
A.W. O'Neill Expires Oct 2002 [Page 10]
INTERNET-DRAFT Concatenated MIP for IP Mobility Management May 2002
7.2. RMA AAA Behaviour
There are also benefits in being able to deliver the MN privileges to the RMA
so that policing, accounting and QoS functions can be appropriately
distributed between the FA and the RMA. The way in which this processing is
conducted is different between Nested and Concatenated Models but the
appropriate processing is signalled via MIP and not as a result of RA AAA
state. RA AAA Behaviour is therefore unchanged between Nested and
Concatenated MIP.
8. IPv6 Considerations
The Concatenated model is equally applicable to IPv6 with the major changes
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 and is clearly already MN specific. 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 in the HA. This is to ensure that each new MN CCoA
does not need to be communicated to the HA. The model was shown in figure 4.
The remote access layer is therefore unchanged conceptually from the MIPv4
model but is nested within a CCoA rather than a FA CoA at the LA layer. This
is necessary because the FA is missing in IPv6. If this is replaced by a
Local Mobility Agent(LMA) with similar capabilities, then 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. This
may also enable something similar to a FA CoA to be supported.
9. Security Considerations
No new security issues are raised by this draft than are already considered
in the design of MIPv4, regional tunnelling [RegTun], [RoutOpt] and reverse
tunnelling [RevTun]. At all times all information elements are authenticated
to the same level as that demanded by MIP and AAA exchanges. New
authentication extensions are required but are generated and distributed
using established techniques.
10. 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 11]
INTERNET-DRAFT Concatenated MIP for IP Mobility Management May 2002
11. 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,
January 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.
[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 (work in progress), 26
February 2002
[RoutOpt] C. Perkins, D. Johnson, "Route Optimization in Mobile IP",
Internet-Draft, draft-ietf-mobileip-optim-11.txt (work in progress), 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.
Author's Addresses
Alan O'Neill
Flarion Technologies
Phone: +1 908 947 7033
Email: oneill@flarion.com
A.W. O'Neill Expires Oct 2002 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-24 04:30:13 |