Personal A. O'Neill
Internet Draft Flarion Technologies
Document: draft-oneill-mip-parallel-00.txt 8 May 2002
Expires: Oct 2002
Parallel MIP for Aggregated Mobility Management
<draft-oneill-mip-parallel-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. Nested MIP and an
associated proposal, Concatenated MIP [ConcatMIP] are necessary because
existing MIP signalling is HA/HoA specific and therefore not easily amenable
to aggregation for supporting multiple MIP sessions per MN.
This document describes an alternative proposal for introducing aggregation
that has significantly lower functionality but that is a smaller change from
existing MIP standards and implementations. It is described here for
completeness as part of the overall problem space. The solution uses a single
HA/HoA specific MIP Registration as a master signal within which is carried
an extension that defines an include/exclude list of the other HA/HoA pairs
that should/should not be handed off. This extension can be carried in inter-
FA hand-off signals and in regional registrations, and is also used within
Nested/Concat MIP.
A.W. O'Neill Expires Oct 2002 [Page 1]
INTERNET-DRAFT Parallel MIP for Aggregated 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. The Parallel Model. . . . . . . . . . . . . . . . . . . . . . . . . 3
5.1. Registration and Visitor Lists. . . . . . . . . . . . . . . . . . 3
5.2. Inter-FA Hand-off . . . . . . . . . . . . . . . . . . . . . . . . 4
5.3. Regional Regsitration . . . . . . . . . . . . . . . . . . . . . . 4
5.4. Backwards Compatibility . . . . . . . . . . . . . . . . . . . . . 5
6. Hand-off Limitations . . . . . . . . . . . . . . . . . . . . . . . 5
7. Other Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . . . . 6
9. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . . . . . 6
10. Notice Regarding Intellectual Property Rights. . . . . . . . . . . 7
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
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. Nested MIP and an
associated proposal, Concatenated MIP [ConcatMIP] are necessary because
existing MIP signalling is HA/HoA specific and therefore not easily amenable
to aggregation for supporting multiple MIP sessions per MN.
This document describes an alternative proposal for introducing aggregation
that has significantly lower functionality but that is a smaller change from
existing MIP standards and implementations. The solution uses a single HA/HoA
specific MIP Registration as a master signal within which is carried an
extension that defines an include/exclude list of the other HA/HoA pairs that
should/should not be handed off. This extension can be carried in inter-FA
hand-off signals and in regional registrations, and is also used within
Nested/Concat MIP. A complementary HoA Response Extension is used to confirm
that the aggregated hand-off has been undertaken by returning the
include/exclude list to the MN via the FA. Essentially, this means that the
aggregated signals become MN centric rather than HA/HoA centric and is
clearly only possible when the MIP Registration is not actually directed at
the HA.
A.W. O'Neill Expires Oct 2002 [Page 2]
INTERNET-DRAFT Parallel MIP for Aggregated Mobility Management May 2002
Parallel MIP is described here for completeness as part of the overall
problem space covered by Nested and Concatenated MIP, and specifically its
limitations contribute strongly to the architecture developed for
Nested/Concat MIP.
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 Tunneling [RegTun], MIP Reverse Tunneling [RevTun], MIP
Route Optimisation [RoutOpt] and Nested/Concatenated MIP. This draft
introduces the following additional terminology.
HoA Request List Extension (HoAList) - HA/HoA pairs in aggregate
HoA Response List Extension (HoAResp) - Modified HA/HoA pairs returned
4. Motivation
The motivation for this work is described fully in [NestMIP] and in the
introduction text. The intension is to describe the limitations of an
aggregation model that is parallel rather than layered, but that can
potentially be more readily deployed in constrained circumstances.
5. The Parallel Model
5.1 Registration and Visitor lists
Each MIP session still clearly requires a Registration between the MN and the
HA via the FA when necessary. This registration is HA/HoA specific and
installs HA/HoA/CoA state in the MIP elements where the CoA can be shared
across multiple such registrations from the same MN (CCoA) or FA (FA CoA). If
the MN needs many such sessions then existing MIP will lead to a signalling
round trip to each HA for each HA/HoA pair. Clearly though the visitor list
state in the MN and FA can be aggregated such that the MN specific state
(link-layer address, CoA etc) is stored once with each registration
generating additional HA/HoA pairs, MN-HA and FA-HA SAs, Identification field
maintenance, flags etc. This is however a minor benefit from aggregation
A.W. O'Neill Expires Oct 2002 [Page 3]
INTERNET-DRAFT Parallel MIP for Aggregated Mobility Management May 2002
5.2 Inter-FA hand-off
When a MN moves between access routers that contain FAs, the opportunity
exists to undertake transient forwarding and CT between those FAs to forward
arriving in-flight packets to the new FA and to also transfer control state.
Presently, the [lowlat] and [RoutOpt] mechanisms for achieving this are
HA/HoA specific and not MN specific. Therefore, a MN that has multiple MIP
sessions with distant HAs will need to generate a registration per HA/HoA
pair towards the HA as well as (in the case of PFANE) a BU to the old FA per
HA/HoA pair. The HA update is clearly unavoidable but a single BU, to
represent the movement of the MN rather than of its MIP sessions should be
possible. Nested/Concat MIP use such a MN specific signal but a similar
result can be achieved by using a BU for a single master HA/HoA pair along
with a HoAlist extension that lists the other HA/HoA pairs to move through an
include/exclude list. The include/exclude idea is borrowed from IGMPv3 to
enable an efficient representation to be made by the MN. For example, the
presence of the extension in exclude mode with a zero list will cause all
HA/HoA pairs to be forwarded. An extension is required here so that the
return of a HoAResp can be triggered at the oFA so that the nFA and MN know
that the sessions are being forwarded and hence provides backwards
compatibility.
The FA should prime its HA/HoA state from the Registrations towards the HAs
and inter-FA forwarding should be supported for those HA/HoA pairs implied by
the HoAlist as modified by the changes described in the HoAResp
include/exclude list. The HoAResp should echo the HoAList if no additional
changes are necessary. The HoAResp can exclude a HA/HoA pair for policy
reasons or due to a registration timeout at the old FA, and can include a
HA/HoA pair that was missing from the HoAlist as a reminder or to indicate an
error, and should not forward for that HA/HoA pair unless an additional BU is
sent.
The HoAlist and HoAResp extensions need to be protected by authentication. In
the case of PFANE, the MN needs to calculate an authenticator that includes
the HoAlist extension which must not therefore be modified by the FA. The MN-
FA protects the HoAlist extension over the air interface. The HoAResp in the
BUack is protected by the oFA-MN auth extension and can be read by the nFA
but any changes from the HoAlist must not acted on by the FA which should
wait for any triggered MN action. The HoAlist/Resp extensions are defined in
[RMAsig].
5.3 Regional Registration
When a MN is using a GFA, an additional opportunity exists for aggregation of
signalling between the MN-FA-GFA during a regional registration rather than a
home registration. The MN issues parallel home registration messages via the
GFA and gets back multiple identifications fields for matching, ordering and
replay protection purposes. The MN then needs to start a separate
identification field exchange as part of the regional registration using a
master HA/HoA pair to refresh the FA CoA. The regional registration also
however includes the HoAlist extension that enables a single MIP regional
registration to update the CoA field for all HA/HoA pairs in that GFA.
A.W. O'Neill Expires Oct 2002 [Page 4]
INTERNET-DRAFT Parallel MIP for Aggregated Mobility Management May 2002
This is only possible if all the MIP flags and other features are shared
for all the HA/HoA specific sessions between the MN, FA and GFA. Restating,
the flags in the home registration, for each HA/HoA pair, are interpreted as
only representing the features between the GFA and that HA. The regional
registration overrules the features on the section between the GFA and FA/MN
when the HoAlist extension is included. The GFA then needs to map between the
common features and the HA specific features wrt tunneling technique. One
exception to this is reverse tunneling which can clearly be handled
independently at the FA based on the home registration flags.
Once again, the HoAResp is used to indicate addition HA/HoA pairs that can
trigger an additional regional registration. This can also indicate a failure
for a specific HA/HoA pair that might trigger a HA specific home
registration. Note also that in general, returned error codes now need to be
indexed by the HA/HoA pair in a new HoAErr extension unless they are general
or associated with the master HA/HoA pair.
5.4 Backwards Compatibility
Clearly, if a HoAlist extension is not sent by a MN then the FA and GFA will
only act on the HA/HoA included in the MIP registration.
If a HoAResp extension is not returned by a GFA or FA then the MN needs to
issue multiple registrations as the extensions are not supported.
If the FA does not understand the HoAlist/Resp extensions then they are
stripped so that the GFA and the MN can determine that no aggregated
forwarding is possible.
6. Hand-off Limitations
Special mention needs to be made of the consequences of each FA and/or GFA
hand-off. In the case of the FA hand-off, some aggregation benefits are
achieved for the inter-FA forwarding by avoiding the need for multiple Bus.
No such forwarding however exists between GFAs (although is supported in
Nested MIP), during inter-GFA hand-off. One of the benefits of supporting
inter-GFA, and old GFA to new FA transient forwarding is to enable time in
which the home registrations can be spread out to reduce data interference,
with only the master registration needing to be sent immediately to acquire
the new GFA and to set-up transient forwarding from the old GFA. Therefore,
the aggregation benefits in the GFA model only come with subsequent messaging
following the immediate flood of MIP home registrations that is triggered by
the new GFA, to configure that new GFA in the HAs.
The aggregated regional registration to the GFA is also fine for refreshing
state from an old FA but, most critically, on FA hand-off, is unable to
rebuild the state at the new FA that exists at the old FA. This state, in the
absence of a GFA, is built by the individual registrations back to the HA
that are triggered by the inner-FA hand-off. By analogy, the aggregated
regional registration must therefore list all HA/HoA pairs in the HoAlist so
that the new FA can install this new state into the visitor list, and
additional extensions must be devised to carry the aggregation of the all
flags and features for this MN in the old FA. This clearly completely
compromises the aggregation objective.
A.W. O'Neill Expires Oct 2002 [Page 5]
INTERNET-DRAFT Parallel MIP for Aggregated Mobility Management May 2002
An alternative is to use the inter-FA HoAlist extension and the BU to trigger
Context Transfer of all the old FA state, for the implied HA/HoA pairs,
forward to the new FA. This is however potentially a significant amount of
information, and it must be very reliably and instantaneously delivered to
the new FA. With the laws of physics preventing either of these objectives
being possible it is clear that the architecture is pretty flawed in the case
of a GFA, and is equally limited in the absence of a GFA due to flood of home
registrations.
This therefore fully motivates the alternative architecture behind
Nested/Concat MIP where this critical limitation is avoided.
7. Other Limitations
Firstly, in the case of inter-FA and GFA signalling it is clear that as the
number of HA/HoA pairs grows then the HoAlist/Resp can potentially become
cumbersome when all the sessions are not to be transferred. In addition, the
HoAErr extension could also become damaging when a large number of errors are
generated. In both cases, the extension size must be strictly limited to
avoid disturbing traffic at the cost of loss of forwarding or information.
Secondly, HA/HoA specific hand-off features and tunnelling features are not
supported but this is a natural consequence of aggregation. Features are also
arranged on a master RA layer HA/HoA pair rather than on a separate LA layer
as used in Nested/Concat MIP. This leads to complications when the MIP
session of the master pair is lost due to an error or dropped intentionally.
More problematic, in the case of GFA, is the fact that the GFA is intended to
be a node at the top of a domain and hence for a large domain, with many such
GFAs, aggregation through a single GFA comes at the cost of indirectness of
forwarding for many of the HA/HoA specific sessions. The RMA from Nested MIP
is in contrast low in the domain and close to the FAs at the nearest POP.
Finally, the GFA model as with the Concat model has a common regional tunnel
for a number of HA/HoA sessions, whose preferences for that tunnel must be
potentially overruled. This is not the case in Nested MIP where the RA layer
features are unaffected by the LA layer features to a large extent.
8. IPv6 Considerations
The Parallel model is equally applicable, and equally problematic, to MIPv6
with the major changes being that the MN in MIPv6 is able to rapidly acquire
a local interface address from each edge subnet and the obvious absence of an
FA. The aggregation is once again achieved through a simple extension request
and response mechanism.
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.
A.W. O'Neill Expires Oct 2002 [Page 6]
INTERNET-DRAFT Parallel MIP for Aggregated Mobility Management May 2002
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).
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 for mobility management," Internet-
draft, draft-ietf-oneill-mip-nested-00.txt, May 2002.
[ConcatMIP] A.W. O'Neill, ``Concatenated MIP for mobility management,"
Internet-draft, draft-ietf-oneill-mip-nested-00.txt, May 2002.
[RegTunMods] A.W. O'Neill, ``Modifications to Regional Tunneling," Internet-
draft, draft-ietf-oneill-mip-regtun-mods-00.txt, April 2002.
[RevTunHO] A.W. O'Neill, ``Hand-Off Extensions for Reverse Tunneling,"
Internet-draft, draft-ietf-oneill-mip-revtun-ho-00.txt, April 2002.
[PCCoA] A.W. O'Neill, ``Proxy CCoA Tunneling for Mobile IP," Internet-draft,
draft-oneill-mip-proxyCCoA-00.txt, May 2002.
[MIPv4] C.E. Perkins, Ed., `` IP Mobility Support for IPv4, revised,"
Internet-draft, draft-ietf-mobileip-rfc2002-bis-08.txt, 19 September 2001
[RegTun] E. Gustafsson. Ed., " Mobile IPv4 Regional Registration, Internet-
draft, draft-ietf-mobileip-reg-tunnel-06.txt, 1March 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.
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 7]