One document matched: draft-oneill-ema-mip-00.txt
Personal A. O'Neill
G. Tsirtsis
BT
Internet Draft S. Corson
Document: draft-oneill-ema-mip-00.txt Ansible Systems
Category: Informational July 2000
EMA Enhanced Mobile IPv6/IPv4
<draft-oneill-ema-mip-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 [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.
Abstract
It is well recognised by all micro and macro-mobility routing
protocols that Mobile IP (MIP) is likely to be used to support
inter-domain mobility. It is also widely accepted that Mobile IP
could be used as the basis for signalling between the mobile and the
micro-mobility domains for simplicity of the mobile terminal and
interoperability purposes. The Edge Mobility Architecture (EMA)
defines a generic IP hand-over model which operates in conjunction
with a Mobility Enhanced Routing (MER) protocol to provide large-
scale, intra-domain, IP address mobility. The aim of this document
is to describe the minimum MIP signalling requirements for EMA:MER,
and to propose additional changes necessary to [MIPv6] and [MIPv4]
for them to support EMA:MER. The document deals with mobiles moving
inside and between EMA:MER domains as well as coming and going
from/to non-EMA:MER domains, demonstrating EMA/MIP interoperability
and inter-domain hand-overs. The document also demonstrates the
benefits a mobile and an operator will see when a mobile host is
within an EMA domain.
O'Neill, Corson, Tsirtsis 1
Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000
INDEX
Abstract
1. Introduction
2. Conventions used in this document
3. EMA and Mobile IP Architectural Considerations
4. Combined EMA:MER and Mobile IP Architecture
4.1 EMA and MIP with Co-located Care of Addresses . . . . . .
4.2 Non Co-located Care of Addresses with FA/Attendants . . .
5. Inter-domain Considerations
5.1 Non-EMA MN and/or movement between non-EMA domains . . . .
5.2 EMA MN Moves from any domain into an EMA domain. . . . . .
5.3 EMA MN Moves from an EMA to a Non EMA domain . . . . . . .
5.4 EMA MN Moves from one EMA to another EMA domain. . . . . .
5.5 Subsequent Movement. . . . . . . . . . . . . . . . . . . .
5.6 Returning to a previously visited domain . . . . . . . . .
5.7 Returning to the Home Domain . . . . . . . . . . . . . . .
6. Summary of Hand-over Processing
7. EMA enhanced MIPv6
7.1 Basic EMA Extensions to MIPv6 . . . . . . . . . . . . . . .
7.2 Hand-over Examples. . . . . . . . . . . . . . . . . . . . .
7.2.1 Unplanned Reverse Hand-over (MN not trusted). . . . .
7.2.2 Unplanned Reverse Hand-over (MN / NAR assisted) . . .
7.2.3 Planned Forward Hand-over (MBB or BBM). . . . . . . .
7.2.4 Moving into an EMA domain-MN Supports EMAext. . . . .
7.2.5 Moving into an EMA domain-MN does not support EMAext.
7.2.6 EMA MN has a CRCoA from a previous domain . . . . . .
7.3 Source Address Selection Rules. . . . . . . . . . . . . . .
7.4 Implications of EMA:MIPv6 Convergence on MIPv6. . . . . . .
7.5 Ongoing work. . . . . . . . . . . . . . . . . . . . . . . .
8. EMA enhanced MIPv4
8.1 Basic EMA Extensions to MIPv4 . . . . . . . . . . . . . . .
8.2 MIPv4 Hand-over Examples. . . . . . . . . . . . . . . . . .
8.2.1 Unplanned Reverse Hand-over (MN not trusted). . . . .
8.2.2 Unplanned Reverse Hand-over (MN / NAR). . . . . . . .
8.2.3 Planned Forward Hand-over (MBB or BBM). . . . . . . .
9. MIPv6 vs MIPv4 in respect to EMA
10. Security Considerations
10.1 Authenticating users within a domain . . . . . . . . . . .
11. References
O'Neill, Corson, Tsirtsis 2
Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000
1. Introduction
Mobile IP (MIP) (versions 4 and 6) provides for the potential
movement of a Home IP address throughout the Internet, from a home
domain subnet, throughout foreign domain subnets equipped with MIP.
It does so by providing a Mobile Node (MN) with a local and
potentially short-term IP Care of Address (CoA) in a foreign domain,
towards which packets can be directly or indirectly tunnelled. This
CoA is reported back to a Home Agent (HA), who then tunnels packets,
sent by any Correspondent Node (CN) to the Home address, towards
this CoA. In addition, direct tunnelled communication, bypassing the
HA, can be achieved through additional signalling between the MN and
the CN. A Foreign Agent (FA) entity can also optionally exist to
assist the MN in the foreign domain by terminating tunnels and
acting as a proxy CoA, a CoA allocator and a proxy signalling point
for MIP signalling.
The Edge Mobility Architecture (EMA) provides a generic hand-over
model between two Access Routers (AR) for supporting the movement of
Mobile Nodes between ARs which are equipped with any Mobile Enhanced
Routing (MER) Protocol (modified MANET or general intra-domain
routing protocols). A MER protocol is able to rapidly adjust the
routing tables so that the route pointing to the IP address of a MN
can be moved in sympathy with the EMA hand-over signals to provide
seamless, native IP forwarding within an EMA domain.
The IP address of the MN is given to it by the first AR (called the
Allocating Access Router or AAR) it visits in the domain, out of its
aggregated prefix. A hand-over can be initiated either by a MN or
the network, and can be rooted (i.e. initiated) at either the old or
new Access Router. The Old Access Router (OAR) is used to co-
ordinate a forward hand-over when the New Access Router (NAR) is
known in advance as a result of either network or MN-based movement
prediction and associated performance measurements. The NAR is used
to co-ordinate a reverse hand-over when the NAR is not known in
advance by the MN or the network, as a result of either network
failure (e.g. old radio link lost), insufficient network
intelligence (no inter-technology hand-over signalling) or
unpredictable user behaviour (swapping PCMCIA network cards).
MIP is required between domains to support the movement of a MN IP
address out of the local domain (no inter-domain MER yet proposed),
and is also required to support MIP hand-over in domains that are
not equipped with a MER protocol. To facilitate the co-existence of
MIP and EMA options, the MIP signalling capabilities with
appropriate additions are obvious candidates for providing the User
-AR signalling plane for EMA hand-over.
MIP signalling between MN, FA/CoR, HA and CN is presently being
reviewed to establish appropriate enhancements to support fast IP
hand-over within 3/4G networks, and between other types of link
O'Neill, Corson, Tsirtsis 3
Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000
layer technologies supporting ARs and MNs. This draft outlines the
inter-working architecture for EMA and Mobile IPv6/v4 that provides
mutual co-existence and benefits, both for the user and the
operator. The draft then describes the specific additions to Mobile
IPv6/v4 signalling to provide the required features, with associated
issues and uncertainties that need to be raised for discussion with
the MIP working group. The aim of the draft, above and beyond its
specific technical content, is to raise understanding of the EMA
capabilities and requirements so that fast hand-over developments in
MIP are equally applicable to domains supporting routed mobility and
native forwarding.
Among the advantages of EMA are that when a MN is in its Home EMA
Domain, as it will become apparent later, there is essentially no
use of tunneling over the air interface, very little signalling over
the radio link, greatly reduced signalling in the network and little
need for persistent tunnels in the network. Most of the mechanisms
described in this document deal with corner cases and exceptions
when special signalling and tunnels are needed in order to provide
seamless inter-domain services using MIP signalling.
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.1 Terminology used in this document
Much of the terminology used in this document borrows from Mobile IP
(versions 4 and 6) and this will be obvious to those familiar with
these protocols. The following introduces new terminology as well
as slight extensions to existing terminology.
Access Router (AR)
a combined IP router, network access server and Mobile IP
agent
NAR, nFA, nCoR
New AR with either FA (v4) or CoR (v6) functionality
OAR, oFA, oCoR
Old AR with either FA (v4) or CoR (v6) functionality
AA, AS/RA, RS
Mobile IP v4/v6 advertisements from AR used interchangeably,
O'Neill, Corson, Tsirtsis 4
Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000
possibly extended with EMA options
Forward BU (FBU)
Binding Update sent by MN (or Network) to OAR. Results in
OAR generating a BU Acknowledgement (BUAck) sent
'forward' (in direction of hand-over) to NAR and then to MN.
Creates temporary horizontal tunnel at OAR to MN for oCCoA
Reverse BU (RBU)
Binding Update sent by MN to NAR over new link and then
'reverse' (opposite direction of hand-over) to OAR
Binding Update Ack (BUAck)
Binding Update Acknowledgement sent by OAR to NAR and then to
MN in response to FBU or RBU. If network sent FBU, then MN
may receive unsolicited HAck.
EMA Hand-over Request Destination Option (EHORQ)
Sent by MN to O/NAR over old/new link requesting hand-over
EMA Hand-over Response Destination Option (EHORP)
Sent by NAR (on receipt of RUA) to MN over new link
confirming hand-over
AAA Request/AAA Response Destination Option
Sent by NAR and OAR to enable the NAR to rapidly acquire
local OAR IP configuration pertinent to the MN, such as keys,
policy information, dynamic firewall state.
Registration Request/Reply (RRQ/RRP)
Vertical Mobile IP message to HA from MN via NAR
UDU/UDU-Ack
MER TORA hand-over messages for host route redirects
Tau
Is one of the [TORA] reference values that decrements on
every handover and indicates host route freshness
Some more terms are also defined in Sections 6 and 7.2 of this
document.
O'Neill, Corson, Tsirtsis 5
Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000
3. EMA and Mobile IP Architectural Considerations
Firstly, the EMA envisages a rich set of hand-over capabilities that
encompass a range of existing, predictive (cellular) and non-
predictive (inter-technology) hand-over models and requirements. The
EMA signalling requirements are a super-set of existing MIP hand-
over capabilities as will be described in detail later, which
indicates that some additions will be required in MIP if EMA is to
solely rely on MIP signalling. Specifically, MIP does not presently
support forward hand-over rooted at the OAR, nor does it provide the
required information exchange between neighbouring ARs to facilitate
such forward hand-over in an all-IP solution. There have, however,
been drafts and discussions suggesting such additions and these are
in line with the desire for MIP to take a significant role in 3G/4G
cellular solutions.
Secondly, the MIP architecture assumes a MN is from an arbitrary
home domain, and an arbitrary HA within that domain. We therefore
cannot make any assumptions in EMA as to whether or not this Home
Domain is equipped with a MER protocol. Equally, we know that any
visited foreign domain may be either MER or non-MER equipped, and we
need to ensure that MIP continues to operate as normal as a MN moves
through MER and non-MER domains. The conclusion therefore is that
MIP functionality related to the Home Address as a source /
destination address, covering CoA registration, HA capabilities and
route optimisation/binding features, must be orthogonal to EMA. EMA
is instead associated with the CCoA, MN-AR signalling, and the
temporary forwarding (between CoA's on hand-over) features of MIP.
The specific details change slightly between MIPv6 and MIPv4, and
depend on the type of CoA (Co-located or not). Each scenario, except
the use of non-co-located CoAs, is described in the following
sections, followed by a description of the required MIP messages and
associated extensions.
Thirdly, and finally, the types of Internet access supported by MIP
and MER functionality are very different and are part of the overall
commercial opportunity. MIP facilitates roaming into foreign domains
and links, from a Home link within a Home Domain. Associated AAA
interfaces are used to control access to the foreign links where
necessary, and may also be used to install policy as to how user
traffic is forwarded. These forwarding options provide for IP
traffic associated with a home session address to go to and from the
Home Domain (forward and reverse HA tunnelling) as in the remote
access model. The other options allow for direct tunnelled
communication between CN and MN (HA bypass) through optimisation /
binding, and in the case of Co-located Care of Addresses (CCoA)
based sessions, native communication independent of the home address
and MIP tunnelling features (as in local or roaming access). The MIP
CCoA is however only a valid session address on a specific foreign
link, and the utility of this address for native service is
consequently severely limited, and it's use therefore actively
O'Neill, Corson, Tsirtsis 6
Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000
discouraged in Mobile IP. Some movement of this CCoA address is,
however, supported in MIP through the use of temporary tunnelling
between ARs, with the current CCoA at the old AR being treated like
a Home Address, and a new CCoA from the new AR acting as the tunnel
endpoint.
To aid subsequent discussions we describe temporary indirect tunnel
forwarding between adjacent ARs as "Horizontal" MIP forwarding. This
is to help the reader appreciate that this hand-over is likely to be
between geographically adjacent AR's of equivalent configuration and
status. Standard indirect tunnel forwarding via a possibly remote HA
in it's home domain is termed "Vertical" MIP forwarding. This is to
help the reader appreciate that this tunnel is likely to be in
support of communications between non-geographically adjacent nodes
of dissimilar configuration and status, where in many cases the HA
is a centralised element providing HA services to a large number of
AR's. Finally, the bypass of either horizontal or vertical
forwarding by a CN using optimisation is known as direct tunnel
forwarding as per MIP specifications.
MER, unlike MIP, also enables native communication using the CCoA as
a normal source (destination) session address, but with
significantly increased utility, as a result of the MER ability to
update the routing tables in the domain to enable the CCoA to move
with the MN. The combination of MIP and MER can therefore support
both native and remote access models, along with hybrid
combinational models. From the perspective of a foreign ISP, a
roaming MN can be offered native service and/or non-optimised /
optimised remote access depending on the user's/home operator's
privileges in the foreign domain, assuming appropriate AAA support
features are developed.
In the existing UMTS model, the benefit of the co-existence of these
models is clear because the present UMTS network can only support
the remote access model from the MN back through SGSN and GGSN to
the external 'Home' ISP (today via GTP tunnels). This external ISP
provides both the non-routable 'Home' IP address to the MN, and all
associated IP services and onward connectivity to the wider
Internet. Significant benefits would accrue to both the UMTS network
operator and to users if, in addition, the UMTS network could
support native IP services using local IP addresses, local IP
service infrastructure, and direct connectivity between users on
that network and out to the wider Internet. This commercial context
provides additional justification for the co-existence of MIP
(remote access) and EMA:MER (as an efficient means to support native
forwarding) within a future all-IP 3G/4G solution. The details below
will illustrate this in more detail.
O'Neill, Corson, Tsirtsis 7
Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000
4. Combined EMA:MER and Mobile IP Architecture
4.1 EMA and MIP with Co-located Care of Addresses
A MN has a Home address from a Home Domain and is allocated as per
normal MIP specs (static, DHCP etc). This address is installed in
any system which requires a global and reliable IP address through
which to reach the MN (DNS, SIP etc). Orthogonal to this is the CCoA
which is allocated on any foreign link, and which is equivalent to
the EMA address for the MN. For a series of Access Routers past
which a MN can move, acquiring a CCoA at each AR, the MN can
continue to use its home address as a valid IP session address.
This MIP tunnelling model works for intra and inter-domain movement
with the appropriate AAA support. The impact of EMA, and the aim of
the interworking architecture, is to enable a whole EMA domain to
appear to MIP vertical tunnelling elements as if it is a single AR,
in that a single CCoA can be used throughout the domain. By ensuring
that a MN experiences the same environment (state / signalling)
whether it is handing over between non-EMA or EMA-equipped ARs, we
can provide movement through arbitrary domains in any sequence
whilst preserving existing horizontal and vertical MIP
functionality.
When the MN first starts up, the MN gets its first CCoA in this new
domain and needs to undertake normal MIP signalling to register this
CCoA with its (possibly remote) HA to facilitate "indirect vertical
tunnelling" between the HA and the MN. In addition, the MN may wish
to also communicate its new CCoA to any CNs so that "direct
tunnelling" (HA bypass) can be achieved. For the moment we will
forget what has happened in any previous foreign domain, which may
or may not have EMA:MER capabilities. Let us then assume that the MN
is happily communicating via both direct and indirect vertical
tunnelling when it detects a change of AR (link) using well-
documented MIP techniques.
In the case of a MN in a non-MER domain, we would require that, as
per MIP specs, a new CCoA allocation on the new link be followed by
updated registrations to;
i. the HA and CNs to move indirect vertical and direct tunnels to
the new CCoA, and optionally to
ii. the old CoR/FA for horizontal MIP tunneling of packets,
addressed to the old CoA, from the old CoR/FA to the new CoA.
Note that the latter applies to both in-flight packets using
vertical forwarding to the previous CoR, and to packets sent
natively to the old CoA. The vertical and direct tunnel messages
represent signalling traffic and delay which can be avoided in an
MER-equipped domain, as follows.
An MER protocol, however, would enable the CCoA to move with the MN
as it changes ARs, by rapidly modifying the local routing tables so
O'Neill, Corson, Tsirtsis 8
Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000
that traffic addressed to the CCoA now arrive natively via the new
AR rather than via the old AR. This means that the CCoA and all MIP
registrations are still valid, and hence there is no need to update
the forwarding state in HA and CNs.
The result is faster hand-over, reduced signalling load, and in many
cases no tunnelling of IP packets between adjacent ARs. In an
EMA:MER-equipped domain, the MN therefore only needs to acquire a
single CCoA in that domain per IP session, and only needs to
register that address once to the remote HA and CNs, as the MN moves
in the domain. This constitutes a significant performance
improvement to MIP hosts if the EMA:MER domain is both practical,
from a routing perspective, and sufficiently large enough to justify
the deployment of EMA:MER.
Note that because of the clean separation between EMA:MER horizontal
operations from the MIP vertical operations, and the focus of
EMA:MER on optimising the horizontal plane (and as a result
avoiding the side-effects on the vertical plane), each domain can
independently decide on MER deployment without affecting vertical
MIP operation as a user roams through foreign domains. From a MIP
signalling perspective, the MN would still go through the motions of
requesting/updating vertical MIP tunnelling. Also, it would install
a temporary horizontal MIP forwarding tunnel as per MIP between the
old AR and the MN at the new CCoA; this being an optional MIP
feature. However, in an EMA:MER domain, these messages would also,
in parallel with installing a temporary horizontal MIP tunnel, be
used to install a new host native redirect route from the old AR to
the MN at the new CCoA.
In MIP, an obvious special case arises when the MN is on its home
link, in that it doesn't need a separate CoA and does not therefore
participate in MIP to send and receive IP packets. When the HA is
located in an EMA domain, the concept of "home" may be extended to
the entire domain due to the micro-mobility capability of an IP
address being valid anywhere in the home domain rather than just on
the home link. So, while the MN is on its home link within an EMA
domain, no MIP signalling is required as is normal, and no MER host
redirect routes are generated in the domain. When the mobile moves
from that home link but remains in the home domain, there are two
models that can be used, which offer different potential benefits to
the overall system.
The first model assumes a native 'roaming' service is offered to the
mobile anywhere away from the home LINK. As soon as the MN moves out
of the home 'link' but still remains in the same "home EMA domain",
it must acquire a CCoA at the first foreign link, and can then
continue to use that CCoA as a source address throughout the EMA
domain as it does in the general case. The MN will then need to use
MIP signalling to trigger EMA hand-overs and install MER host
redirect routes to forward traffic towards each new AR. Any ongoing
IP session using the home address is maintained using MIP vertical
tunnelling from the home link Home agent as normal. It is worth
O'Neill, Corson, Tsirtsis 9
Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000
noting that this model may well be necessary in UMTS if the HA is a
core network function, and is generally not therefore located on an
AR. In this way the MN is always "away" from its home link and is
therefore always on a foreign link (possibly in a foreign domain)
from which it always has to get a CoA to operate.
HA
+
+
+
AR1+ AR2 AR3
|+
|+
MN <---------->
Figure 1: The MN gets an address from the EMA
domain (EMA CCoA) and registers it with its Home
Agent. While in the same EMA domain no other
registration is needed.
The second model assumes a native 'roaming' service is only offered
to the mobile anywhere away from the home DOMAIN. In this case, the
MN would automatically use its Home Address as a CoA whilst on
foreign links in the home EMA domain, since its Home Address is
valid throughout this domain due to MER redirection. The HA is
considered to be the automatic AAR and the first AR the MN
encounters in the home domain simply AAA's the request to use the
home address, and acts like a NAR by injecting a host redirect route
back to the HA (the AAR). Requesting or continuing to use the Home
Address as CCoA when the MN is away from its home link offers the
following advantages.
HA AR2 AR3
|
|
MN <-------------->
Figure 2: The MN's Home Address is the same with
the EMA CCoA and thus no tunneling to HA is
required.
i. CNs communicating with the MN's home address achieve direct
native communication while the MN is anywhere in its home domain.
ii. When the MN moves to a foreign domain and acquires a new CCoA,
the MN can send vertical Binding Updates (BU) to CNs as the MN is
still using the same session source address. In contrast, if the MN
is using a CoA different from its home address as a source address
in a session, then a vertical BU to a CN will not work, and
horizontal MIP tunnelling is instead required to deliver packets to
the MN.
O'Neill, Corson, Tsirtsis 10
Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000
This use of the home address as a CCoA may have some side-effects
though as MIP attaches special significance to messages in which the
CoA=Home Address. This is normally used to cancel all bindings to
other CoAs, and to therefore reinstate native forwarding. Curiously
this is precisely what we wish to achieve in the context of the
wider home domain, but the full ramifications of this when multiple
simultaneous bindings are being supported, or following inter-domain
movement is for further study. The other implication of using the
home address as the CCoA is that the MN requires a host redirect
route back to its HA when it first starts a session, which reduces
the inherent scalability of EMA:MER routing.
4.2 Non Co-located Care of Addresses with Foreign Agents / Attendants
This draft does not describe these options within the EMA model
because of the lack of a distinct per host CoA. This prevents MER
routing from preserving the CoA (and associated tunnels and
bindings) in an EMA domain. There are however obvious ways to enable
co-existence of MIP and EMA in this case, as illustrated by the
inter-domain models of Cellular IP and HAWAII.
5. Inter-domain Considerations
MIP is required in EMA between domains to support the movement of a
MN IP address out of the local/home domain (no inter-domain MER yet
proposed), and is also required to support MIP hand-over in domains
that are not equipped with a MER protocol. To facilitate the co-
existence of MIP and EMA options, the MIP signalling capabilities
with appropriate additions are obvious candidates for providing the
signalling plane for EMA inter-domain hand-over.
5.1 Non-EMA MN and/or movement between non-EMA domains
Normal MIP mechanisms must apply to ensure we are standards
compatible, irrespective of the nature of the mobility support (EMA
or non-EMA) in either the previous or new domain. In addition, we
must make sure that any EMA extensions to MIP can co-exist with the
unmodified form of MIP so that an EMA domain can support legacy ARs
and MNs. We must therefore acquire a new CCoA from the first AR in
this domain and then update the HA and any CNs to re-orientate
vertical tunnelling. In addition the MN can optionally register the
new CCoA with the previous CoR/FA and build a temporary inter-domain
MIP horizontal forwarding tunnel so that existing communications
directed to the previous CCoA can be maintained.
We can then iteratively build subsequent MIP horizontal and vertical
forwarding tunnels in the new domain as would be required for a non-
EMA domain. This means that each time the MN changes AR, a new CCoA
has to be acquired by the MN that has to then be registered to the
previous CoR/FA, and a new temporary horizontal forwarding tunnel
built between adjacent ARs. The persistence of the horizontal and
vertical tunnels depends on the requested (or agreed) lifetime as
O'Neill, Corson, Tsirtsis 11
Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000
detailed in standard MIP signalling. It is expected that the
lifetime of temporary horizontal MIP tunnels between adjacent ARs
will be very short, on the order of seconds. Note that chaining of
multiple horizontal tunnels through a non-EMA domain results in
multiple encapsulations. These are only required though if the
vertical tunnel is not re-orientated (diverting traffic from
reaching the old CCoA), or a previous CCoA up the hand-over sequence
was used as a session address for which packet flow is continuing to
require the chain of tunnels to reach the MN.
5.2 EMA MN Moves from any domain into an EMA domain
If the MN supports EMA extensions, as soon as it steps into an EMA
domain it will behave as if it is booting up in the EMA domain and
will be required to undergo authentication. It will optionally
acquire its domain-wide hash (see section 10) which is used to
efficiently confirm the identity of the MN to AR's throughout the
domain. Then, the MN will be able to get a new CCoA from the AR to
which it first attaches to, which it can then continue to use on
subsequent hops in the new domain due to EMA:MER routing. The node
will also compute a hash based on the new CCoA that can be used to
authenticate packets over the air within this domain (see section
5). Additionally, the MN might chose to build a temporary MIP
horizontal tunnel to the last AR in the last domain so that existing
communications directed to previous CCoA's in the last domain will
not have to be dropped. Note that while in the new EMA domain this
temporary horizontal tunnel, and the associated HA/CN vertical
tunnels, will also be moved with the MN as they terminate on the
MN's mobile CCoA in this domain. Therefore, a new vertical and
horizontal tunnel will not have to be set-up at each new AR, leading
to vastly reduced signalling and faster hand-over.
Domain
Boundary HA
| +
Old non-EMA| + New EMA Domain
Domain | +
| +
OAR+++++NAR+ AR AR
| + | +
| + | +
| ++MN <------------>
|
Figure 3: The MN Registers a new CCoA to its HA
which will be its EMA CcoA in this domain and is
required.
5.3 EMA MN Moves from an EMA to a Non EMA domain
When a mobile appears at an AR in a new domain, then the present
CCoA used by the MN from the old domain is no longer valid. The MN
O'Neill, Corson, Tsirtsis 12
Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000
therefore needs to acquire a new CCoA. Present communications
though, are using the old CCoA which are being routed by EMA towards
the OAR in the previous domain. We have at least one (and possibly
two) hand-over stages to complete;
In the first stage the MN can send a binding update to the previous
AR, as in standard MIP, so that it can temporarily horizontally
tunnel packets addressed to the old CCoA forward to the new CCoA.
This however means that the old CCoA (in the previous EMA domain),
and the associated routing state from the AAR to the OAR, cannot be
released until either the binding at the OAR times out and/or the
route timer and address timer expire. This should happen very
quickly though as the horizontal tunnel is intended to be short-
lived.
In the second stage, if the old CCoA was allocated in a previous EMA
domain, and is in use as a session address, the MN now views that
CCoA session as a secondary home address, whose home agent is the
AAR in the previous domain. We call this a "Co-Located Roaming CoA"
(CRCoA)and is a deprecated address, i.e.: the MN MAY use it to
maintain existing sessions but MUST NOT use it as source address in
new sessions
.
T
he MN therefore sends another BU to that AAR so that
the AAR can AAA the request to roam with one of its CCoAs. If
permitted, the AAR then provides HA and persistent horizontal
tunnelling services to the MN for that CRCoA, and the MN can use BUs
to CNs using that CRCoA as a session address to bypass the AAR HA.
If BUs to CNs are used, the AAR HA may never need to tunnel packets
to the MN. The AAR will in any case not need to act as the HA for
the CRCoA and tunnel packets until the host routing state, directing
packets addressed to the CRCoA towards the OAR, is eliminated on
expiry of the temporary horizontal inter-domain tunnel.
Domain
Boundary
| HA
| +
Old EMA | + New Non-EMA Domain
Domain | +
| +
+++++++++++++++++++ +
+ | + +
AAR OAR++++++ +NAR+ AR AR
| + +| +
| + +| +
| ++MN+++
|
Figure 4: The MN Registers a new CCoA to its HA
and to the AAR in the old EMA domain for the
CRCoA. A temp tunnel to the OAR is optional. In
the non-EMA domain this registration will be done
one every hop.
O'Neill, Corson, Tsirtsis 13
Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000
The destination of the MIP temporary and persistent horizontal
inter-domain tunnels, is the new CCoA in the new domain. In parallel
with this, normal vertical MIP Registration of the new CCoA for the
original home address should also be sent to the HA of the MN to
update vertical tunnelling. This process will then be continued on
subsequent hops as per normal MIP, with each new local CCoA
allocation requiring both vertical and horizontal tunnelling updates
for the original home address and any acquired CRCoAs in use as
session addresses. An aggregated horizontal BU for the previous CoA
and active CRCoAs, to the previous CoR/FA, would clearly be
advantageous. Multiple CRCoAs are possible because a new CRCoA could
be collected in each EMA domain encountered. This is not considered
to be a significant scaling problem due to the rarity of inter-
domain hand-over in the EMA model.
5.4 EMA MN Moves from one EMA to another EMA domain
In this case, the MN moves from one EMA Domain to another also EMA-
enabled Domain. The hand-over and interdomain tunnel requirements
are exactly as with the previous section (5.3).
The most important difference from 5.3 is that the MN will register
all the tunnels only once since the nCCoA in the new EMA domain will
be valid throughout this domain. All these tunnels at the NAR
will then "follow" the MN naturally without the need for re-
registration. The tunnel from the OAR will be dropped quickly,
since this is the temporary horizontal one, while the others will be
maintained for as long the MN is using the CRCoA.
Domain
Boundary
| HA
| +
EMA | + EMA
Domain 1 | + Domain 2
| +
+++++++++++++++++++ +
+ | + +
AAR OAR++++++ +NAR+ AR AR
| + +| +
| + +| +
| ++MN+++ <---------->
|
Figure 5: The MN Registers a new CCoA to its HA
and to the AAR in the old EMA domain for the
CRCoA. A temp tunnel to the OAR is optional. In
EMA Domain this registration will only be done
once.
O'Neill, Corson, Tsirtsis 14
Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000
5.5 Subsequent Movement
It is clear that the use of MIP ensures that subsequent multi-domain
movement, in any sequence, between EMA and non-EMA domains, can use
MIP between and within any domain. When using EMA to move the CCoA
within a domain we can clearly detect movement to a new AR by the
absence of the advertisement of the prefix covering the existing
CCoA. If that new domain is not supporting EMA we can move to normal
MIP mechanisms and build the forwarding tunnel back to the previous
EMA domain (first to the OAR, then the AAR). From there we know we
can continue to use MIP and drop into EMA processing at any point.
Any intermediate MIP or EMA state in previous domains, and in
particular that associated with CRCoAs, only remains whilst data is
being forwarded or whilst timers are refreshed. Any intermediate EMA
state is directly equivalent to the MIP state that would have been
created by a MN, acting simply to compress multiple MIP CCoA
allocation phases into a single EMA CCoA allocation phase.
5.6 Returning to a previously visited domain
When a MN returns to a non-EMA domain that it has previously
visited, and in which it may (but probably does not) still have MIP
horizontal forwarding state, the MN can potentially re-use an
existing CCoA (and delete the horizontal tunnel). This is only
possible if the MN is returning to the same CoR/FA that owns that
CCoA. Alternatively, and after determining its new CCoA and building
the incoming inter-domain tunnel from the last domain, the MN should
move (via binding update) any persistent horizontal tunnels from the
previous CCoA in that domain to this new CCoA. This is to avoid
indirect routing, remove the outgoing inter-domain tunnel, and
release resources within visited intermediate domains on the path
out of, and back into, this domain wherever possible. The necessity
of these sequence of BU events is however questionable as it is only
required when a MN passes rapidly through intermediate domains
before returning to a previous domain during the lifetime of the
short-lived horizontal tunnel, and before vertical tunnelling has
been updated.
When a MN returns to an EMA domain that it has previously visited,
the MN may still be using the CCoA that it acquired in that domain
as a CRCoA. The MN must first find out if it has an active CRCoA (or
home address) for that domain through NAI comparisons. An active
CRCoA may or may not have a host redirect route associated with it
(AAR to OAR) but will more likely have a HA at the AAR acting as a
CRCoA forwarder. If it does have such an address then we would wish
the MN to use that address rather than acquire an additional address
from that domain, and insert additional host redirect routes into
EMA.
Once the MN has gained permission at the NAR (AAA) to use the
existing CRCoA, the MN will then build a new incoming horizontal
forwarding tunnel from the OAR in the previous domain as per normal
O'Neill, Corson, Tsirtsis 15
Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000
MIP inter-domain hand-over. The MN can then consider additional
action to avoid indirect vertical forwarding within the new domain,
and release resources as for the non-EMA domain above. This should
all cause the previous outgoing inter-domain horizontal forwarding
tunnel to be bypassed before the tunnel lifetime expires, and any
host redirect route and/or MIP state in intermediate domains to be
released where possible. The first action is to instigate an EMA
hand-over from the NAR at which the MN re-entered this domain. The
MN has two options as this point;
i. Assuming the inter-domain tunnel is at a local OAR. The MN can
inject a host redirect route back to the AAR which will partially
intercept the old host routing state to the OAR and redirect
packets away from the OAR. The OAR inactivity timers and BU
lifetime will expire if not refreshed, clearing out the old host
routing state within the domain. When the old routing state is
removed the host route to the AAR will then redirect all packets
locally to the NAR as per standard EMA:MER mechanisms.
ii. If the inter-domain tunnel is already at the AAR, we can start
an unplanned hand-over back to this node and everything is as per
normal EMA except that we can locally clear the persistent
horizontal inter-domain tunnel at the AAR.
In all cases, the MN will continue to receive in-flight packets that
are still on their way to, or have passed through, the local OAR.
The path includes the outgoing inter-domain tunnel to the foreign
domain, subsequent intermediate domain forwarding to a foreign OAR,
and then into the new inter-domain tunnel towards the new local NAR.
This path difference between the new local host route and the
existing inter-domain path means that the MN may need to buffer the
packets from the new host redirect route whilst the inter-domain
packets are delivered. This buffering is better on the host as it
has application awareness.
5.7 Returning to the Home Domain
When a MN which is using MIP returns home, MIP provides all the
mechanisms required to return to native forwarding on the home link,
or to make use of horizontal and/or vertical tunnelling as it sees
fit. If the home domain is an EMA domain then any intermediate MIP
or EMA state in previous domains only remains whilst data is being
forwarded as described above. If the MN returns home but has not
been home during this IP session then there may be some benefits in
the MN automatically setting its CCoA in the domain to its Home
address, rather than getting a CCoA from the NAR(AAR) in the home
domain. These benefits relate to the fact that all applications then
use the same address whether being tunnelled or natively forwarded
within the domain.
O'Neill, Corson, Tsirtsis 16
Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000
6. Summary of Hand-over Processing
The EMA hand-over model covers both Break-Before-Make (BBM) and
Make-Before-Break (MBB) planned and BBM unplanned hand-over . In
planned hand-over the NAR is known in advance and so a temporary
tunnel may be built from the OAR to the NAR. In unplanned hand-over
(which by definition is BBM only), the NAR is not known and any
tunnel must be requested from the NAR back to the OAR. The same
message sequence is used for both forms of hand-over. Mandatory
signalling is rooted at the NAR, but anticipatory (i.e. planned)
signalling may occur in advance of hand-over, rooted at the OAR.
Hand-over may be triggered either by the MN or the network. Five
types of MIP tunnels that may be used during EMA-based hand-over and
forwarding:
i. Temporary Horizontal from OAR to MN for oCCoA via nCCoA
ii. Vertical indirect from MN-HA to MN for Home Address via a nCCoA
iii. Direct from CN to MN for Home Address via a nCCoA
iv. Persistent horizontal from AAR-HA to MN for CRCoA via a nCCoA
v. Direct from CN to MN for CRCoA via a nCCoA
HA+ CN(HA)
(HA)+ +
+ +
OAR++++++NAR OAR +NAR OAR +NAR
(oCCoA) + + +
+ + +
+ + +
MN(nCCoA) MN(nCCoA) MN(nCCoA)
i. Temp Horizontal ii. Vertical Indirect iii. Direct
CN(CRCoA)
D1 | D2 D1 | + D2
| | +
AAR++++++NAR AAR | + NAR
(CRCoA)| + (CRCoA) | +
| + | +
| + | +
MN(nCCoA) MN(nCCoA)
iv. Persistent v. Direct
Horizontal
Figure 6: Tunnel Types supported by EMA
++++ indicates tunnel
(xx) indicates an address related to this tunnel. Which
packets use it and what is the destination of the
tunnel. For example on (i.) packets with Destination
Address=oCCoA will be tunneled to nCCoA.
O'Neill, Corson, Tsirtsis 17
Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000
oCCoA is the EMA CcoA ie. The address which is valide
throughout the EMA domain
nCCoA is a CcoA the MN gets every hop but only uses for
signaling/tunnel termination or if EMA handover fails
CRCoA in the previous domain this was an EMA CcoA. Since the
MN moved out of that domain this becomes an CRCoA and
is treated as a Home Address
The temporary horizontal tunnel (i) is expected to have a lifetime
on the order of seconds, whereas the others may be long-lived.
Only the temporary horizontal tunnel is mandatory in that it is set
up in nearly every hand-over. The tunnel may be established (i.e.
initiated) by the MN or the network. It may be rooted (i.e.
initiated) at the OAR if planned or at the NAR if unplanned.
Planned hand-over is always optional in that failure of a planned
hand-over (due to unexpected loss of the old link) can always be
overcome by resorting to unplanned hand-over via the new link when
necessary. If planned (i.e. a new link is sensed based on L2
measurements), a forward hand-over message is sent from either the
MN (or the network) to the OAR, which then forwards it to the NAR,
which then forwards it to the MN via the new link.
On arrival at the OAR, the message establishes a tunnel from the OAR
to the NAR for the MN CCoA and any active CRCoA's. The other end of
the tunnel is established on arrival at the NAR. Finally, the MN is
informed of the success of planned hand-over when it receives the
forward message via the new link. Using forward hand-over signals,
it is possible to establish multiple tunnels to one or more
potential NARs to which the MN may be hand-over. If, on arrival at a
NAR, the MN has not received a forward hand-over message, it
generates a reverse hand-over message that is sent from the MN to
the OAR to the NAR. On arrival at the NAR, a tunnel (if not already
present) is established as before. A reverse hand-over
acknowledgement (now equivalent to the forward message sent earlier)
is sent from the OAR to the NAR (completing tunnel establishment)
and on to the MN.
Once the MN (now at the NAR) is assured that the horizontal tunnel
is in place, it then updates its vertical tunnel binding for its
home address and any persistent horizontal tunnel bindings for
CRCoA's as necessary. Depending on the MN's location (within an EMA
domain or not), its configuration and current state (e.g. the nature
and number of its session address(es)), etc., some, all or none of
the aforementioned tunnels may need to be created or updated.
Additionally, if in an EMA domain, additional signalling to locally
redirect native host routing will occur simultaneously, in parallel
with the binding updates (if any).
O'Neill, Corson, Tsirtsis 18
Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000
7. EMA enhanced MIPv6
On boot up or at arrival at a new AR, the MN must listen for Routing
Adverts (RA) from the nearest Access Router (AR) and auto-generate a
new CCoA from one of the prefixes advertised as per normal IPv6
Stateless Address Autoconfiguration (or DHCPv6). The first such AR
becomes the Allocating Access Router (AAR) as far as EMA is
concerned for the duration of the active IP session. In the special
case of a home EMA domain, the MN may request to use it's home
address as the CCoA. The EMA domain is a fully mobile enhanced
routed (MER) network so the CCoA is now valid throughout the domain
by using IP hand-over to control host redirect routes. This offers a
number of significant advantages.
- Reduced HA signalling: Normally, on each hop the new CCoA would
have to be registered/bound to the HA of the MN as per normal MIPv6.
With EMA-enhanced MIP, the CCoA is registered once in the HA at the
AAR. After that no more registration of the CCoA is needed.
- Reduced CN signalling: For the same reasons as above after the
initial CCoA allocation, the MN does not need to send re-bindings to
the CNs whilst in a single domain (and in session) which is a big
improvement. Note that this also impacts the performance of CNs that
otherwise might not be able to cope with the repeated BUs due to
continuous CCoA re-bindings.
7.1 Basic EMA Extensions to MIPv6
NAI Extension to Routing Advertisements:
Each time the MN detects a new AR, it will have to determine if
it is in the same or different domain as the AAR. This can be
accomplished by adding an NAI extension to the RAs of the ARs.
This capability has already been proposed but the MN needs to be
able to store the NAI's of the AAR, OAR and NAR to appreciate the
nature of the required hand-over processing.
MR Flag Extension to Routing Advertisement:
To gain the above benefits we need to inform the MN that the AR
is EMA enabled and the EMA CCoA is valid at the new AR (while in
the same domain). A single bit "Mobile Routing" (MR) flag in the
Routing Advertisement could inform an EMA MN that it can reuse
it's current CCoA if the AAR, OAR and NAR share the same NAI
realm, and the MN satisfies EMA hand-over AAA requirements. Note
that this flag can also be re-used by HAWAII, Cellular IP and
other micro-mobility protocols if they meet the requirements of
this draft.
O'Neill, Corson, Tsirtsis 19
Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000
Destination Options
In the following Hand-over and signalling descriptions we are
assuming a conservative 'ships in the night' model for the
Destination Options in the EMA and MIP horizontal signalling
messages. This minimises for now the interactions between MIP
and EMA options but does enable minimal integration by enabling
both sets of options to reside, where possible, in the same
packet for increased efficiency. For simplicity, the following
packet formats assume this is possible with no side-effects. The
MIP Options therefore still go end to end as normal (located
after the routing header in the IP packet). In contrast, the EMA
related Options go via the NAR, under the control of the Routing
Header, and are therefore before the routing options. It is
expected that significant benefits can be gained by closer
integration of the options in terms of hand-over timing,
correctness and message efficiency. However, the security
implications, option processing and forwarding rules, and status
of both the MIPv6 draft and the EMA work in the MIP working
group, make further consideration of closer integration
inappropriate at this time. The Message processing and
forwarding rules for the key MIPv6 destination Options are
summarised below.
Option Message Processing and Forwarding
BU Cannot change on route, discard if unrecognised
Buack Cannot change on route, skip over if unrecognised
Must be covered by IPSEC AH
BUnack must contain no payload
HA Cannot change on route, discard if unrecognised
Must be covered by IPSEC AH if AH applied to packet
One per packet and mandatory for a BU
7.2 Hand-over Examples
In this section we demonstrate the use of MIP messages in an EMA:MER
domain. Draft [EMA] describes the main MER messages that enable host
route creation/deletion in an EMA domain. Figure 7 below reminds the
reader of the these basic MER messages.
O'Neill, Corson, Tsirtsis 20
Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000
|>>>>>>>>>>>>> 5.RUA/RUN >>>>>>>>>>>>>|
| |
| |<<<<<<<<<<<<<< 4.RU <<<<<<<<<<<<<| |
| | | |
|_| |_|
| | -----------> 3.HI/HD -------> | |
NTIN-----|OAR| <----------- 2.HR <---------- |NAR|
|___| -----------> 1.TIN ---------> |___|
\ /
\ /
HTIN HHR
\ /
\ /
'-------- MN--------'
Figure 7: Basic EMA:MER Hand-over Messaging
Tunnel INitiation (TIN)
Advanced warning of possible hand-over from OAR to NAR, also
indicates that temporary tunnel is set at OAR
Host TIN (HTIN)
Message from MN to OAR indicating that possible hand-over to
a NAR is requested
Network TIN (NTIN)
Message from network controller element to OAR indicating
that hand-over to a NAR is requested
Host Hand-over Request (HHR)
Message from MN to NAR requesting hand-over, contains MN's
credentials
Hand-over Request (HR)
Message from NAR to OAR which could contain MH credentials
and privileges.
Hand-over Initiation (HI)
OAR's response to a HR if hand-over is permissible. Contains
MN creditials, policy information, etc.
Hand-over Denial (HD)
OAR's response to an HR if hand-over is not permissible .
O'Neill, Corson, Tsirtsis 21
Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000
Routing Update (RU)
On receipt of the HI or HHR, the NAR also initiates routing
redirection by sending a RU towards the OAR. This is sent
reliably hop-by-hop and may be resent multiple times
RU Acknowledgement (RUA)
OAR's response to a RU confirming hand-over and transfer of
MN from OAR to NAR.
RU Negative Acknowledgement (RUN)
OAR's response to a RU denying hand-over
7.2.1 Unplanned Reverse Hand-over (MN not trusted)
Unplanned hand-over occurs as a result of a lack of, or failure of,
planned hand-over processing. This may itself be a result of the
unplanned loss of the old link at the OAR, a lack of inter-
technology hand-over communications, or unpredictable user activity
such as removing / swapping a PCMCIA card. The MN and network can
therefore only proceed with a hand-over rooted at the NAR with the
aim of setting up MIP forwarding and a MER host route, from the OAR
which is known by the MN.
The MN arrives unannounced at the NAR and receives a Router
Advertisement containing the NAI of the NAR and with the MR bit set.
It may optionally send a Router Solicitation to stimulate this RA.
The MN forms a new CCoA at the NAR which it can use temporarily and
as a source address for MIP signalling and forwarding (Home Address
Option = EMA CCoA), and for receiving horizontally forwarded packets
from the OAR and directly forwarded packets from CN's. The MN then
sends a Reverse Binding Update to the OAR via the NAR using a packet
containing a Routing Header and an EMA Hand-over Request (EHORQ)
Destination Option. This option is equivalent to the HHR message in
the EMA draft [EMA]. The EMA EHORQ is authenticated and processed
by the NAR. The NAR inserts an AAA Request Option into the packet to
request AAA information from the OAR. At this point this Option is
equivalent to the Hand-over Request (HR) message in the EMA draft
[EMA].
The Reverse Binding Update (RBU) packet containing the EHORQ and AAA
options is then sent to the OAR as per normal MIP horizontal
processing to install temporary forwarding from the EMA-CCoA to the
MN via the nCCoA at the NAR. The OAR checks the hand-over request
and installs the horizontal forwarding state with a suitably short
life-time. The OAR also checks the TORA Tau information for
correctness and modifies it if necessary. A BUAck containing the MN
nCCoA and the EMA CCoA is then sent from the OAR to the MN via the
NAR using a Routing Header. The Bu-ack packet also contains an EMA
Hand-over Response (EHORP) Destination Option and an AAA Response
O'Neill, Corson, Tsirtsis 22
Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000
Destination Option. The EMA Hand-over Response Option is equivalent
to the Tunnel Initiation (TIN) message in EMA draft whilst the AAA
Response Option is equivalent to its Hand-over Initiation/Deny (HI
/HD) messages. This packet reports the status of the EMA hand-over
to the NAR and the MN, and to provide IP session information
(policy) to the NAR. The AAA Response Option and EMA EHORP Option
are processed by the NAR which for example can be used to open the
ingress filter for the EMA CCoA. The NAR then forwards the BUAck to
MN with the updated status of the hand-over.
At the NAR, the Tau value and OAR address are copied from the EHORP
Option, compared to the locally stored values, and supercede them if
necessary to form the TORA UDU. Note that the Unicast-Directed
Update (UDU) and the UDU-Ack (UDUA) messages are MER TORA-specific
host route redirection messages equivalent to the RU/RUA messages of
the general EMA:MER hand-over model [EMA]. The remainder of this
document assumes TORA is the EMA:MER algorithm. This is sent to the
OAR and on the way installs the host route for the EMA CCoA into
intermediate routers. The UDU reaches the OAR which informs the OAR
of the successful installation of the host route. The OAR returns a
UDU-ack directly to the NAR to confirm TORA hand-over. This results
in the BU-Ack with associated EHORP information being sent to the
MN.
The UDU might in contrast indicate a routing failure, or the OAR may
for local reasons need to cancel the hand-over, which causes the OAR
to return a UDU-Nack to the NAR. UDU-Nack, signalling time-out(s) or
policy failures result in either retries or host route clear-out and
a suitable BU / EMA EHORP being returned to the MN via the NAR. A
horizontal tunnel installation failure is intended to be orthogonal
to TORA hand-over failure and it is only the latter which should
cause the MN to abandon the EMA CCoA. In this case, the MN resorts
to normal MIP processing and moves to the nCCoA before sending a
Vertical BU to the HA to install the new CCoA binding. In all other
cases, the MN can start sending natively using the EMA CCoA as a
source address when it receives a successful EMA EHORP Option.
The MN can track the progress of any hand-over by the type of
packets being received via the NAR. Packets destined for the MN will
be received encapsulated to the local CCoA until the MER routed
hand-over is completed, at which point they will be received
natively to the EMA CCoA. The MN can use the EMA CCoA as a source
address as soon as the EMA EHORP Option opens the NAR ingress filter
for the EMA CCoA which should occur before the MN receives the EMA
EHORP. The EHORP may contain modified MER information that
supercedes that in the MN.
O'Neill, Corson, Tsirtsis 23
Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000
MN NAR OAR
| | |
|<---RA(NAI,MR)-------| | MN moves to NAR
| | |
|-----RBU/EHORQ)----->| | Routing Header sends
| |---RBU/EHORQ/AAA)-->| BU to NAR and OAR.
| |<-RBUAck/EHORP/AAA--| Horizontal tunnel set.
|<--RBUAck/EHORP------| | MN can send packets.
| |-------UDU--------->| Install host route.
| |<------UDUA---------| Confirm host route.
**Overview of Packet Structures - Illustrative only**
The MN Sends to NAR:
Source Address = MN CCoA at NAR
Destination Address = NAR
Destination Options:
EMA Hand-over Request = Tau, O/NAR, EMA CCoA, NAI's, tbd
Routing Option = OAR
Destination Options:
Binding Update = H, A, bits set
Home Address = EMA CCoA
The NAR Sends to OAR:
Source Address = MN CCoA at NAR
Destination Address = OAR
Destination Options:
EMA Hand-over Request = Tau, O/NAR, EMA CCoA, NAI's, tbd
AAA Request = tbd
Routing Option = NAR
Destination Options:
Binding Update = H, A, bits set
Home Address = EMA CCoA
The OAR Sends to NAR:
Source Address = OAR
Destination Address = NAR
Destination Options:
EMA hand-over Response = tau, O/NAR, EMA CCoA, NAI's, status, tbd
AAA Response = tbd
Routing Option = IP1: MN CCoA at NAR
IP2: MN EMA CcoA
Destination Options:
Binding Ack = ok
The NAR Sends MN:
Source Address = OAR
Destination Address = MN CCoA at NAR
Destination Options:
EMA hand-over Response = tau, O/NAR, EMA CCoA, NAI's, status, tbd
Routing Option = IP1: NAR
IP2: MN EMA CCoA
Destination Options:
O'Neill, Corson, Tsirtsis 24
Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000
Binding Ack = ok
The MN Sends MN:
Source Address = OAR
Destination Address = MN EMA CCoA
Destination Options:
EMA hand-over response = tau, OAR, EMA CCoA, NAI's, status, tbd
Routing Option = IP1: NAR
IP2: MN CCoA at NAR
Destination Options:
Binding Ack = ok
7.2.2 Unplanned Reverse Hand-over (MN / NAR assisted)
In this case, the MN is trusted a priori to identify the OAR, track
the number of hand-overs for its EMA CCoA session address, and then
securely provide that number and the OAR to the NAR. The number is
converted at the NAR into the TORA hand-over routing parameter (Tau
Height) which is required for the TORA UDU message to install the
host redirect route back to the identified OAR. The NAR immediately
and simultaneously sends the RBU and UDU towards the OAR. The OAR
may still undertake local checks to confirm the validity of the Tau
value from a semantic and policy perspective. This sequence of
actions avoids the round trip to the OAR to acquire the last Tau and
for the OAR to check the validity of the hand-over. The reverse BU
is still sent to the OAR to fetch any additional 'policy'
configuration for the mobile, and optionally to validate the hand-
over in parallel with the injection of the host route.
In detail, the MN arrives unannounced at the NAR and receives a
Router Advertisement containing the NAI of the NAR and with the MR
bit set. It may optionally send a Router Solicitation to stimulate
this RA. The MN forms a new CCoA at the NAR which it can use
temporarily and as a source address for MIP signalling and
forwarding (Home Address Option = EMA CCoA), and for receiving
horizontally forwarded packets from the OAR and directly forwarded
packets from CN's. The MN then sends a Reverse Binding Update to the
OAR via the NAR using a packet containing a Routing Header and an
EMA EHORQ Destination Option. The EMA hand-over Request is
authenticated and processed by the NAR and the OAR and Tau
information is locally checked (are valid and allowed from policy
perspective). The Tau value and OAR address are then copied from the
RBU packet and used to form the TORA UDU. This is sent to the OAR
and on the way installs the host route for the EMA CCoA into
intermediate routers.
In parallel, the RBU packet is sent to the OAR as per normal MIP
horizontal processing to install temporary forwarding from the EMA-
CCoA to the MN via the nCCoA at the NAR. The OAR checks the hand-
over request and installs the horizontal forwarding state with a
suitably short life-time. A BUAck is then sent from the OAR to the
MN via the NAR using a Routing Header containing the MN nCCoA and
the EMA CCoA. The Bu-ack packet also contains an EMA Hand-over
O'Neill, Corson, Tsirtsis 25
Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000
Response Destination Option and an AAA Response Destination Option.
This packet acts to report the status of the EMA hand-over to the
NAR and the MN, and to provide IP session information (policy) to
the NAR. The AAA Response Option and EMA Hand-over Response Option
are processed by the NAR and then the NAR forwards the BUAck to MN
with the updated status of the hand-over.
In parallel, the UDU reaches the OAR which informs the OAR of the
installation of the host route. The OAR returns a UDU-ack directly
to the NAR to formalise completion of the TORA hand-over. The UDU
might in contrast indicate a routing failure, or the OAR may for
local reasons need to cancel the hand-over, which causes the OAR to
return a UDU-Nack to the NAR. For example, an OAR check of the tau
value may be incompatible with its tau value (e.g. not fresh enough
due to some error). Then the OAR sends a UDU-Nack erasing the
injected route and informing the NAR of injection failure and
providing the NAR with a feasible Tau value. Such a UDU-Nack,
signalling time-out(s) or policy failures result in either retries
or host route clear-out and a suitable BU / EMA hand-over response
being returned to the MN via the NAR. A horizontal tunnel
installation failure is intended to be orthogonal to TORA hand-over
failure and it is only the latter which should cause the MN to
abandon the EMA CCoA. In this case, the MN resorts to normal MIP
processing and moves to the nCCoA before sending a Vertical BU to
the HA to install the new CCoA binding. In all other cases, the MN
can start sending natively using the EMA CCoA as a source address
when it receives a successful EMA Hand-over Option.
MN NAR OAR
| | |
|<-RA(NAI,MR)------- | | MN moves to NAR
| | |
|----RBU/EHORQ)------>| | Routing Header sends
| |---RBU/EHORQ/AAA)-->| BU to NAR and OAR.
| |-------UDU--------->| Install host route.
| |<-RBUAck/EHORP/AAA)-| BU contains AAA info.
| |<------UDUA---------| Confirm host route.
|<--RBUAck/EHORP------| | MN can send packets.
**Overview of Packet Structures - Illustrative only**
Packet structures are the same as for the unassisted case, as only
local processing in the NAR and the timing of the UDU changes.
7.2.3 Planned Forward Hand-over (MBB or BBM)
Planned hand-over occurs as a result of predictive (or explicit
forward hand-over) processing which enables the MN (or a network
controller element) to know in advance to which NAR a MN MAY hand-
O'Neill, Corson, Tsirtsis 26
Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000
over in case of MN assist (or MUST hand-over in case of network
control).
In the case of MN assisted hand-over, the MN needs to have either
(1) concurrent connectivity in the IP signalling plane to both the
OAR and the NAR (this ensures the MN knows its nCCoA) to achieve a
planned hand-over or possibly (2) connectivity in the IP signalling
plane to the OAR and link layer connectivity to the NAR from which
the MAC address of the NAR can be obtained. In the latter case the
MN can signal the MAC address to the OAR. From previous hand-over
activity, the OAR may know the IP prefix (or CoA) of this NAR from
which it can derive the MN's future nCCoA at the NAR. The MN hand-
over tunnel is now rooted (i.e. initiated) at the OAR with the aim
of setting up optional MIP forwarding to the NAR. MER host route
redirection is still rooted at the NAR. Failure of the forward
processes during hand-over still enables the MN to recover cleanly
through an unplanned hand-over completely rooted at the NAR.
The MN now arrives unannounced at the NAR.
If the IP signalling plane is UP, the MN receives a Router
Advertisement containing the NAI of the NAR and with the MR bit set.
It may optionally send a Router Solicitation to stimulate this RA.
The MN forms a new CCoA at the NAR which it can use temporarily and
as a source address for MIP signalling and forwarding (Home Address
Option = EMA CCoA), and for receiving horizontally forwarded packets
from the OAR and directly forwarded packets from CN's. The MN then
sends a Forward Binding Update to the OAR directly over it's old
link, using a packet containing an EMA Hand-over Request (EHORQ)
Destination Option. The FBU contains an alternate CCoA suboption
which contains the nCCoA at the NAR which was determined by the MN
from the Router Advertisment over the new link. This message is
equivalent to the HTIN message of the EMA draft.
If the IP signalling plane is not UP, the MN receives a link layer
advertisement containing the MAC address of the NAR. It may
optionally send a link layer message to stimulate this
advertisement. The MN then sends this address to the OAR directly
over its old link, using a nearly FBU-equivalent packet containing
an EMA EHORQ Destination Option.
Note that the MN could in fact present multiple NAR options to the
OAR concurrently from which the OAR could select based on local or
remote information. Alternatively the MN could instruct the OAR to
build multiple tunnels if it is unsure of the ultimate NAR to which
it will hand-over.
The EHORQ is authenticated and processed by the OAR. The NAR and Tau
information is locally checked (are valid and allowed from policy
perspective).
If only the NAR's MAC address is known, the OAR checks to see if it
has a cached IP address prefix for that MAC address. If so, packets
O'Neill, Corson, Tsirtsis 27
Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000
sent with that MAC address can now be considered as fully FBU-
equivalent. Otherwise, the packet is dropped and the forward
process terminates.
The FBU (or its equivalent) is used to install temporary MIP
horizontal forwarding from the EMA-CCoA at the OAR to the MN via the
nCCoA at the NAR. A BUAck is then sent from the OAR to the MN via
the NAR using a Routing Header containing the MN nCCoA and the EMA
CCoA. The Bu-ack packet also contains an EMA Hand-over Response
(EHORP) Destination Option and an AAA Response Destination Option.
This packet acts to report the status of the EMA hand-over to the
NAR and the MN, and to provide IP session information (policy) to
the NAR. The AAA Response Option and EMA EHORP Option are processed
by the NAR and then the NAR forwards the BUAck and the EMA Hand-over
Response to MN with the updated status of the hand-over.
Absent receipt of the EMA EHORP via the NAR and the new link, the MN
can send an RBU packet back to the OAR via the NAR as per unplanned
hand-over, and the remaining processing is per unplanned hand-over.
If FBU state is already present on receipt of the RBU at the NAR (as
the NAR would have processed this packet because to the routing
header), then the NAR need not forward RBU to the OAR.
In MBB, the OAR to NAR tunnel is only used if the old link goes down
before the UDU is received which itself is triggered by the layer 3
Make at the NAR (MN-RBU). In BBM, the RA and the EMA Hand-over
Option must be advertised over a new link signalling channel (as the
data channel does not yet exist). The OAR to NAR tunnel is used when
the old data link goes down, and until the new IP data link is
installed by sending the EMA Hand-over Request over the new link and
the host route is successfully installed.
In the case of network-controlled hand-over, it is the controller
that sends the FBU to the OAR on behalf of the MN. This is a
network-generated message somewhat equivalent to the HTIN of the EMA
draft, only that its generated by the network and not the MN.
Processing then continues as above with the additional step being
that an acknowledgement is sent to the Controller from the OAR when
the BU packet is successfully processed by that OAR. The methods by
which the controller identifies the best target NAR, or set of NARs,
is outside the scope of this draft but movement prediction, radio
channel measurements and cell / channel occupancies are obvious
contributors.
O'Neill, Corson, Tsirtsis 28
Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000
MN OAR NAR
| | |
|<-RA(NAI,MR)------------------------------| MN senses NAR
| | |
|------FBU/EHORQ----->| | FBU to OAR on old link.
| | | Compared to stored
| | | state
| |---FBU/EHORP/AAA--->| Horizontal tunnel set.
|<--------------FBUAck/EHORP---------------| Offer hand-over to MN
| | | over new link
| | |
|-----------------RBU/EHORQ--------------->| MN requests hand-over
| | | over new link.
| |<-------UDU---------| Install host route.
| |-------UDUA-------->| Confirm host route.
|<--------------RBUAck/EHORP---------------| MN can send packets.
**Overview of Packet Structures - Illustrative only**
The MN Sends to OAR:
Source Address = MN CCoA at OAR
Destination Address = OAR
Destination Options:
EMA hand-over Request = Tau, NAR, EMA CCoA, NAI's, tbd
Binding Update = H, A, bits set
Alternate CCoA suboption = MN CCoA at NAR
Home Address Option = EMA CCoA
The OAR Sends to NAR:
Source Address = OAR
Destination Address = NAR
Destination Options:
EMA Hand-over Response = tau, OAR, EMA CCoA, NAI's, status, tbd
AAA Response =
Routing Option = IP1: MN CCoA at NAR
IP2: EMA CcoA
Destination Options:
Binding Ack = Ok
The NAR Sends MN:
Source Address = OAR
Destination Address = MN CCoA at NAR
Destination Options:
EMA Hand-over Response = tau, OAR, EMA CCoA, NAI's, status, tbd
Routing Option = IP1: NAR
IP2: EMA CcoA
Destination Options:
Binding Ack = ok
The MN Sends to MN:
Source Address = MN CCoA at NAR
O'Neill, Corson, Tsirtsis 29
Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000
Destination Address = EMA CCoA
Destination Options:
EMA hand-over Response = tau, OAR, EMA CCoA, NAI's, status, tbd
Routing Option = IP1: NAR
IP2: MN CCoA at NAR
Destination Options:
Binding Ack Option = ok
Start of reverse phase - as per unplanned hand-over (MN trusted)
The MN Sends to NAR:
Source Address = MN CCoA at NAR
Destination Address = NAR
Destination Options:
EMA Hand-over Request = Tau, OAR, EMA CCoA, NAI's, tbd
Routing Option = OAR
Destination Options:
Binding Update = H, A, bits set
Home Address = EMA CCoA
Matched to forward state in NAR and UDU triggered etc.
7.2.4 Moving into an EMA domain - MN Supports EMA extensions
This means that the MN understands the single bit EMA flag
indicating that no additional CCoA should be acquired as the MN
moves through the domain. We can therefore use EMA to move the CCoA
throughout the domain so that the inter-domain tunnel (to the non-
EMA domain) moves with the address.
MN AR2(d2) AR1(d2) AR(d1) HA
|<-RA(NAI,MR)--------------| | | New domain, get CCoA
| | | | |
|----BU(horizontal)--------------->| | Inter-domain MIP
|<--------BAck---------------------| |
| | | | |
|----BU(HA-CCoA)-------------------------->| Vertical BU for CoA
|<---BAck----------------------------------|
| | | | |
| | | | |
|<-RA(NAI,MR)-----| | | | MN moves to AR2(d2)
| | | | |
|-----------RBU/EHORQ----->| | | Intra-domain h/over
| | | | | Horizontal tunnel set
|<------RBUAck/EHORP-------| | | TORA h/over request
| |--UDU-->| | | Install host route
| |<-UDUA--| | | Confirm host route
No vertical BU is required on movement to AR2 as CoA is still valid
through MER host route.
O'Neill, Corson, Tsirtsis 30
Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000
7.2.5 Moving into an EMA domain -MN does not support EMA extensions
We can build new MIPv6 forwarding tunnels in the new domain as for a
non-EMA domain. The MN will act as per normal MIPv6 and will not
recognise the single bit EMA flag in the RAs. This means that each
time the MN changes AR a new CCoA will be created and a new
forwarding tunnel must be built between adjacent CoRs. The
originator and terminator of the inter-domain tunnel remains the
same and can only be removed when traffic and/or bindings cease. The
MN must also send BU's and registrations to the HA and CN's so that
indirect vertical and direct MIP forwarding can be maintained and
the forwarding tunnel can be dropped. This, of course, throws away
the benefits of EMA routing. The resultant signalling sequence is
precisely the same as above except that the MN does not request
EMA:MER hand-over so the OAR and NAR do not produce the TIN, UDU or
UDUAck.
7.2.6 EMA MN has a CRCoA from a previous domain
In this case the inter-domain hand-over is from an EMA domain to any
type of domain. The MN undertakes the horizontal inter-domain hand-
over for packets addressed to the CCoA in the previous domain to be
sent to the new CCoA in this domain. In parallel, the MN sends a BU
to the AAR in the previous domain requesting the conversion of the
CCoA in the previous domain into a CRCoA and the associated
provision of HA-like services. If accepted, a persistent horizontal
tunnel will be built between the AAR and the MN and the host route
in the previous domain can be cleared out. Movement to another AR in
the new domain requires a temporary horizontal BU to be installed
for both the oCCoA and the CRCoA at the previous AR, to forward
packets to the nCCoA at the new AR. In parallel, the MN will need to
update the binding for the persistent horizontal tunnel for the
CRCoA.
MN AR2(d2) AR1(d2) OAR(d1) AAR(d1)
|<-RA(NAI,MR)--------------| | | New domain, get CCoA
| | | | |
|----BU(horizontal for new CCoA--->| | Inter-domain MIP
|<--------BAck---------------------| |
| | | | |
|----BU(CRCoA-CCoA)----------------------->| Persistent BU for CRCoA
|<---BAck----------------------------------| VBU for HA not shown
| | | |<----->| Clear out host route
|<-------------------------------->| | HBU removed by OAR
|<-RA(NAI,MR)-----| | | | MN moves to AR2(d2)
| | | | |
|--BU(CCoA/CRCoA)--------->| | | Dual CoA Horizontal BU
|<---BUAck-----------------| | | Horizontal tunnel set
O'Neill, Corson, Tsirtsis 31
Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000
7.3 Source Address Selection Rules
We have already seen that a MN will always have a globally unique
Home Address while it will also have a new CCoA in every foreign EMA
domain it visits, at least for as long as it is using them. It might
also have a number of other CCoAs from non-EMA domains as it moves
around. The obvious question that arises is how does the MN know
which address to use and when.
Here are the simple "policy rules" that the MN MUST follow. Note
that these are superseding the "Source Address Selection" rules as
defined in [SEL].
i. CCoAs from non-EMA domain SHOULD NOT be used as source address,
as defined by [MIPv6]
ii. A CCoA from an EMA domain (EMA CCoA) SHOULD be used as source
address.
iii. The Home Address of the MN MUST be used as source address when
the MN is in a non-EMA domain but it SHOULD NOT be used as
source address when the MN is in an EMA domain; the EMA CCoA
SHOULD be used instead as defined in (ii).
iv. Once a CCoA becomes a CRCoA, by the MN moving out of an EMA-
Domain, this address SHOULD be regarded by the MN as a
deprecated address, i.e.: the MN MAY use it to maintain existing
sessions but MUST NOT use it as source address in new sessions.
This will ensure that the persistent horizontal tunnel will be
as short lived as possible. The new CCoA in the new domain
should be used instead as defined in (ii) for EMA domains, or
else the Home Address MUST be used if the new domain is a non-
EMA domain as defined in (iii)
The above rule-set ensures that a MN always takes advantage of the
functionality of EMA-Domains and thus, mostly communicates natively
and with minimum use of tunnels whilst communications are
maintained, and as the MN moves between different EMA and non-EMA
domains.
7.4 Implications of EMA:MIPv6 Convergence on MIPv6
The implications of EMA:MIP convergence as outlined in this draft
can be summarised as follows;
i. We need the MIPv6 RA to advertise the EMA capability of each AR
to MN's.
ii. We need the AR to advertise its NAI so that a MN can determine
the nature of it's last hop (intra or inter-domain) and the
applicability of its present EMA CCoA and any other CCoA or CRCoA's.
O'Neill, Corson, Tsirtsis 32
Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000
iii. The IPv6 stack needs to be able to track and distinguish CRCoAs
as well as CCoAs and HAs, and deprecate them on leaving an EMA
domain. In addition, it needs to recognise opportunities to re-use
these addresses on returning to a previously visited domain.
iv. The IPv6 stack needs to be able to apply appropriate source
address selection rules so that the EMA CCoA is preferred to either
the HA or local CCoA for data traffic in an EMA domain.
v. Packets containing EMA signalling options need to be processed by
the NAR in either direction (MN<-> OAR over new link). MIPv6
signalling options will likely also be in these packets and
opportunities for potential convergence could be explored. A routing
header is used to control NAR visitation.
vi. MIPv6 temporary horizontal forwarding needs to be extended to
enable an additional persistent tunnel to be installed to the AAR
when leaving an EMA domain. HA's on AR's must be prepared to support
horizontal tunnels to support 'loss-less' intra and inter-domain
hand-over.
vii. The ability of the MN to automatically use its HA as the EMA
CCoA session address whilst in its home domain requires the BU to
support such messaging without confusing this with an instruction to
cancel ALL bindings.
viii. MIPv6 Destination Options have specific processing and
security rules which will affect the degree of integration and
piggy-backing that can be achieved with EMA Options.
ix. The Forward BU via the old link appears to be permissible from
the base MIPv6 specification but this draft details this option in
the EMA context.
x. The policy controls required to manage the multiple Internet
Service options that are possible with EMA:MIP have not been fully
explored but contain a super-position of well established models.
7.5 Ongoing work
We are presently assessing the type, structure and ordering of the
Destination Options to provide the required functionality and secure
data exchange for EMA, whilst ensuring backwards compatibility with
standard MIPv6.
In addition, to speed up generation of the vertical BU to the HA, we
are examining a model (as in MIPv4 with R bit set) in which the
vertical BU automatically triggers the horizontal BU at the NAR
which may yield additional benefits.
O'Neill, Corson, Tsirtsis 33
Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000
We need a MN to report it's AAA information, height, optional EMA
hand-over Request, amongst other parameters, in parallel with the
Binding Updates.
We need a MN to be able to store and use CRCoA's when leaving an EMA
domain when using an EMA CCoA as an active session address, and co-
existence of this within the overall model needs additional
investigation.
We also need to further consider the use of the Home Address as a
CCoA when in the home domain, and the interactions with multiple
concurrent CCoA's.
We need to further consider the various failure modes in the
unplanned and planned message sequences.
8. EMA enhanced MIPv4
On boot up the MN must acquire a CCoA from DHCP and register the
CCoA in its HA as normal. The CCoA belongs to the subnet of the AR
the MN is connected to during boot up. This AR therefore becomes the
Allocating Access Router (AAR) as far as EMA is concerned for the
duration of the active IP session. In the special case of a home EMA
domain, the MN may request to use it's home address as the CCoA. The
EMA domain is a fully mobile enhanced routed (MER) network so the
CCoA is now valid throughout the domain by using IP hand-over to
control host redirect routes. This offers a number of significant
advantages.
- Fast hand-over: Avoids the need for the MN to get a new CCoA at
each new AR. This is very important since CCoA in MIPv4 are
allocated by DHCP, which introduces potentially significant delays
in the hand-over process.
- Less HA signalling: Normally, on each hop the CCoA would have to
be registered to the HA of the MN as per normal MIPv4. With EMA-
enhanced MIP the CCoA is registered once on the first AR. After that
no more registration of the CCoA is needed.
- Less CN Signalling: For the same reasons as above after the
initial CCoA allocation, the MN does not need to forward bindings to
HA and CNs whilst in a single domain (and in session) which is also
a big win. Note that this also impacts the performance of CNs that
otherwise might not be able to cope with the repeated BUs due to
continues CCoA change.
- Address Utilisation: As a configurable utilisation feature of EMA,
a CCoA is only valid for as long as the MN is in a session. If the
MN becomes inactive, the CCoA is returned and the host redirect
state associated with it is removed. This makes sure that the
limited IPv4 address space is highly utilised. When the MN wants to
O'Neill, Corson, Tsirtsis 34
Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000
initiate a new session, it will have to get a new CCoA from DHCP and
re-register it in the HA.
Firstly, to gain the above benefits we need to prevent MIPv4
changing CCoA at each new AR (while in the same domain). Two
mechanisms could be used:
MIP based: MIPv4 could be extended to support the following
behaviour. The ARs would need to run MIPv4 but the Agent
Advertisements would include an EMA specific extension: This would
(a) cause the MN to look for a CCoA (b) instruct the MN not to
change its CCoA if it already has one from this domain. (c) indicate
the AR's NAI in the form (ARx@realm) to inform the MN when it
changes domains. In fact the NAI may actually be advertised in the
AA.
DHCP based: In this case the ARs of the EMA domain do not send Agent
Adverts (AAs). As per normal MIPv4 the MN will attempt to get a CCoA
from DHCP. DHCP normal behaviour causes the client to try to re-use
its existing address anyway. Note that the AAA/DHCP mechanisms could
be used hop by hop to determine when/if the MN changes domain and
thus have to change CCoA..
It is clear that, although conceivable, none of the above solutions
are as optimal as the one based on MIPv6.
8.1. Basic EMA Extensions to MIPv4
MR Flag Extension to Routing Advertisement:
To gain the above benefits we need to prevent MIPv4 changing CCoA
at each new AR (while in the same domain). With MIPv4 signalling
a single bit flag in the Agent Advertisement could indicate to
the mobile to send the Binding Update message to its HA as normal
but using its current CCoA rather than creating a new one. We
will call this the "Mobile Routing-MR" flag . Note that this can
also be re-used by HAWAII, Cellular IP and other micro-mobility
protocols
NAI Extension to Routing Advertisements:
The MN every time it detects a NAR, it will have to determine if
it is in the same or different domain with the previous AR. This
can be accomplished by an NAI extension to the Agent
Advertisements of the Access Router.
8.2 MIPv4 Hand-over Examples
Firstly, the following overview of MIPv4 hand-over represents our
present view of how we believe this might work, rather than how it
should work with present/future MIPv4 specifications. It is
therefore very likely that significant changes may be required to
O'Neill, Corson, Tsirtsis 35
Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000
meet the need for backwards compatibility, security, evolution to
MIPv6 and optimised performance.
Secondly, the lack of efficient and feature-rich header extension
processing in MIPv4 requires us to mandate the setting of the R bit
in Agent Advertisements to force all registrations to go via the
NAR. Horizontal Binding updates in MIPv4 are then triggered by
vertical registrations in the NAR, with TORA hand-over failures
causing the Vertical registration to progress to the HA, and
successes causing the vertical registration to be answered by the
NAR.
Thirdly, the following examples assume that the MN must acquire a
CCoA from the NAR. It may be possible to avoid this if we terminate
the temporary horizontal tunnel on the NAR in EMA domains resulting
in a hybrid CoA / EMA CCoA model. The MN instead uses the CoA of the
NAR in signalling messages where necessary, and uses it's EMA CCoA
as the source address in registrations over the old and new links.
This approach, if clean, will delay and limit CCoA DHCP allocations
to those situations in which the EMA hand-over fails and a new CCoA
is required at the NAR/MN for a long term vertical binding. We would
expect the NAR to undertake this address allocation on behalf on the
MN and populate the necessary fields in the vertical registration
messages.
These various issues need significant further study and indicate our
preference for MIPv6 based hand-over and optimisations.
8.2.1 Unplanned Reverse Hand-over (MN not trusted)
The MN arrives at the NAR unannounced as in the MIPv6 case and sees
the MR bit and R bit set. The MN sends a Registration Request (RRQ)
to the new FA (nFA) with source address of the nFA CCoA, requesting
EMA hand-over of the existing EMA CCoA. The RRQ is authenticated by
the nFA and hand-over parameters checked. The RRQ then Triggers
Reverse BU containing PFANE to the old FA (oFA), with EMA HO
extension to request height and AAA config which is returned in the
BUack packet. The BUack packet contents confirms/denies EMA hand-
over and the status of the horizontal tunnel. Confirmed EMA hand-
over triggers the UDU to the OAR using the height information from
the OAR, and Registration Reply (RRP) to the MN. Denied EMA hand-
over triggers the RRQ to progress, somewhat delayed, to the HA to
update binding. UDU-ack, completes routing hand-over. UDU-Nack,
time-out or policy failure results in retries or host route clear-
out and RRQ to HA for new CCoA binding at the nFA.
8.2.2 Unplanned Reverse Hand-over (MN / NAR)
O'Neill, Corson, Tsirtsis 36
Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000
In this case, we progress as above but because the NAR trusts the MN
it can use the height and OAR information in the RRQ to immediately
trigger the UDU in parallel to the Reverse BU.
8.2.3 Planned Forward Hand-over (MBB or BBM)
As in the case of MIPv6, the MN detects the new link and uses nFA
MAC information or agent advertisement information to send a Forward
BU to the OAR over the old link requesting an EMA hand-over to the
nFA CCoA allocated to the MN. Note that this forward BU and EMA
hand-over request are different from the messages suggested in the
pro-active draft although we plan to revisit this issue later given
the need for network triggered hand-over. The OAR then sends the
FBUack to the NAR as in MIPv6 and includes the height and AAA
information in the forward message. The NAR processes this data as
before and forwards an EMA Hand-over response to the MN over the new
link.
The MN responds by sending a RRQ to nFA with source address of nFA
CCoA, requesting EMA hand-over of existing EMA CCoA. The RRQ is
authenticated by the nFA and matched to the FBUack state which
triggers the UDU and RRP as in 8.2.2. Unmatched state causes the nFA
to resort to unplanned reverse handover. Subsequent failure results
in the progression of the RRQ, somewhat delayed, to the HA.
9. MIPv6 vs MIPv4 in respect to EMA
MIPv6 provides EMA with a number of significant advantages over
MIPv4 that have been highlighted throughout this document. Here we
summarise and highlight the most important benefits.
Fast start-up: IPv6 Routing Advertisements (RAs) provide the MN with
much faster IPv6 address configuration than in IPv4 that needs DHCP.
Easy EMA extension: IPv6 Routing Advertisements (RAs) provide EMA
with an ideal signal for the "single bit EMA flag" needed to
indicate to the MN that should not try to change its CoA while in
the EMA domain.
Simpler interoperability: the fact that MIPv6 does not rely on FAs
and CoAs simplifies the design and the interoperability with non-EMA
domains
Abundance of addresses: EMA requires address allocation to be done
from within the prefix range of the AAR . IPv6's abundance of
addresses makes it so much easier compared to its IPv4 equivalent.
O'Neill, Corson, Tsirtsis 37
Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000
10. Security Considerations
The mechanisms described above can re-use mobile IP and AAA
mechanisms as proposed in [AAAMIP] and [CIP] since the requirements
and level of security required are similar. It is expected that the
EMA Hand-over and AAA options will need to be protected within the
network and over the air interface to prevent a range of attacks,
and IPSEC AH and ESP are to be investigated for this purpose.
10.1 Authenticating users within a domain
Associated with each mobile node (MN) is a unique identifier known
as its Mobile ID (MID). This is taken here to be an IPv6 address
(which may or may not be associated with an interface), but which
may also be a Network Access Identifier (NAI).
On arrival at a NAR, a MN must first either furnish proof of prior
authentication within the domain, or be initially authenticated
before it may send or receive any form of control or data traffic.
Proof of prior authentication may be readily available in the form
of a pre-paid SIM card or from a MN's private authentication key (as
described subsequently).
To perform an authentication check, the MN must present its
credentials (including its MID) to the NAR. The method to conceal
these items over the air interface is not addressed here.
This transmission also advertises its current CCoA (if any) which it
may have auto-generated on arrival at this NAR. Consequently, this
authentication information may be passed to the NAR with a CCoA
(IPv6), or with a NULL source address (IPv4) as is commonly done
with DHCP. In the latter case the NAR (acting as a proxy for the
MN) substitutes its address for the NULL address. The NAR then
forwards the information to the local authentication server with
which it already has a Security Association (SA).
The local authentication server may then contact other servers as
necessary to perform the authentication check. The outcome of the
check (along with the MN's public key) is returned to the NAR. If
successful, the NAR computes a Private Authentication Key (PAK) for
the MN as an MD5 hash of the MN's MID and the domain's private
"network key" known to all domain ARs. The computation of PAK and
PIK herein are based on the PID scheme of [CIP]. The PAK forms a
shared secret known only to the MN and the network, and serves as
proof of MN authentication to other NARs in the domain.
Unsuccessful authentication results in service denial.
After a successful authentication, the NAR checks the MN's CCoA and,
if NULL (IPv4), allocates a new CCoA for the MN. Using the resultant
CCoA, the NAR computes a Private Identification Key (PIK) for the MN
as an MD5 hash of the MN's CCoA and the domain's private "network
key" known to all domain ARs, encrypts the PIK and PAK with the MN's
O'Neill, Corson, Tsirtsis 38
Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000
public key, and sends these to the MN along with the network's
public key and the MN's CCoA. Being keyed to the MN's CCoA, the PIK
is valid as long as the MN uses this CCoA. The PIK can be used to
authenticate (and optionally to encrypt) IP control packets over the
air interface. Authentication is performed by creating a short hash
from the (PIK, timestamp, packet content) triple that is placed into
the transmitted packets. The validity of each packet can be easily
checked by any NAR even immediately after a handoff and without
prior communication with the MN or with the OAR.
In addition to authenticating control packets, the PIK can
optionally also be used to provide security for data packets
transmitted over the wireless link. To this avail, any known,
shared secret-based security mechanism can be used where the PIK
serves as the shared secret.
11. References
[AAAMIP] S. Glass, et al., "Mobile IP Authentication, Authorization,
and Accounting Requirements", Internet-Draft, draft-ietf-mobileip-
aaa-reqs-04.txt (work in progress), June, 2000.
[CIP] A. Campbell, et al., "Cellular IP", Internet-Draft, draft-
ietf-mobileip-cellularip-00.txt (work in progress), January, 2000.
[EMA] A. O'Neill, G. Tsirtsis, S. Corson, "Edge Mobility
Architecture", Internet-Draft, draft-oneill-ema-02.txt (work in
progress), July 2000.
[SEL] R. Draves, "Default Address Selection for IPv6", <draft-ietf-
ipngwg-default-addr-select-00.txt>, work in progress, October 1999.
[MIPv4] C.E. Perkins, Ed., "IP Mobility Support," Internet RFC
2002, Oct 1996.
[MIPv6] D. Johnson, C. Perkins, "Mobility Support in IPv6",
Internet-Draft, draft-ietf-mobileip-ipv6-12.txt (work in progress),
April, 2000.
[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
[TORA] V. Park, M. S. Corson, "Temporally-Ordered Routing Algorithm
(TORA) Version 1 Functional Specification", Internet-Draft, draft-
ietf-manet-tora-spec-02.txt (work in progress), October 1999.
O'Neill, Corson, Tsirtsis 39
Author's Addresses
Alan O'Neill
BT
Phone: +44-20-88260073
Email: alan.w.oneill@bt.com
M. Scott Corson
University of Maryland
Ansible Systems
Phone: +1 301-405-6630
Email: corson@isr.umd.edu
George Tsirtsis
BT
Phone: +44-20-88260073
Email: george.tsirtsis@bt.com
Alternative: gtsirt@hotmail.com
O'Neill, Corson, Tsirtsis 40
Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000
Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into
O'Neill, Corson, Tsirtsis 41
Internet Draft EMA Enhanced Mobile IPv6/v4 July 2000
O'Neill, Corson, Tsirtsis 42
| PAFTECH AB 2003-2026 | 2026-04-24 04:30:14 |