Internet DRAFT - draft-elmalki-soliman-hmipv4v6
draft-elmalki-soliman-hmipv4v6
MOBILE-IP Working Group Karim El Malki, Ericsson
INTERNET-DRAFT Hesham Soliman, Ericsson
Expires: September 2000 March 10, 2000
Hierarchical Mobile IPv4/v6 and Fast Handoffs
<draft-elmalki-soliman-hmipv4v6-00.txt>
Status of this memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This document is an individual submission to the IETF. Comments
should be directed to the authors.
Abstract
This draft provides a number of extensions to the Hierarchical MIPv4
model in [1] as well as a new Hierarchical MIPv6 model. A number of
additions are made to Regional Tunnel Management in terms of Fast
Handoffs and the avoidance of triangle routing within the hierarchical
domain. A few extensions were also made for MIPv6 and neighbour
discovery to allow for the introduction of a hierarchical MIPv6 mobility
management model. The proposed hierarchical mobility management for
MIPv6 will improve the performance of MIPv6 in terms of handoff speed
and is well-suited to implement access control and handoffs between
different access technologies.
Karim El Malki and Hesham Soliman [Page 1]
INTERNET-DRAFT HMIPv4/v6 and Fast Handoffs Mar 10, 2000
TABLE OF CONTENTS
1. Introduction.................................................3
2. Hierarchical Mobile IPV4 Network.............................4
3. Traffic Routing in Mobile IPv4 Hierarchies...................5
4. Fast Handoffs................................................7
4.1 Initiating Fast Handoffs through the "previous" FA...........10
5. Regional Deregistration for Fast Handoffs....................11
6. Smooth Handoffs between Hierarchies (GFAs)...................12
7. Hierarchical Mobility Management using MIPv6.................13
8. Overview of the MIPv6 Hierarchical Mobility Management.......13
9. Neighbour Discovery extension - MAP discovery................16
10. MIPV6 extensions - Sending Binding Updates...................18
11. MN Operation.................................................18
11.1 MAP Discovery................................................19
11.2 Sending Binding Updates......................................19
11.3 Receiving packets in a foreign network.......................20
11.4 Fast Handoff scenario........................................20
12. MAP Operation................................................21
12.1 MAP Discovery................................................21
12.2 Receiving and forwarding Packets for a MN....................22
12.3 Fast handoff scenario........................................22
13. HA Operation.................................................23
14. AAA Considerations for IPv6..................................23
15. Acknowledgements.............................................23
16. Notice Regarding Intellectual Property Rights................23
17. References...................................................24
18. Authors' addresses...........................................24
Karim El Malki and Hesham Soliman Expires 10 September 2000 [Page 2]
INTERNET-DRAFT HMIPv4/v6 and Fast Handoffs Mar 10, 2000
1. Introduction
The Hierarchical Mobile IPv4 scheme introduced in Regional Tunnel
Management [1] allows a Mobile Node to perform registrations locally
in order to reduce the number of signalling messages to the home
network. This achieves a reduction in the signalling delay when a
Mobile Node moves between Foreign Agents and therefore improves the
performance of such handoffs. This draft provides for a number of
additions to Regional Tunnel Management in terms of Fast Handoffs and
the avoidance of triangle routing within the hierarchical domain.
This draft also introduces the concept of a Hierarchical Mobile IPv6
network which makes use of similar features, utilizing a new node
called the Mobility Anchor Point (MAP).
Fast Handoffs anticipate the movement of Mobile Nodes by utilizing
simultaneous bindings at Regional Foreign Agents or MAPs in order to
"multicast" traffic to potential Mobile Node movement locations. Fast
Handoffs coupled to layer 2 mobility can help in achieving seamless
handoffs between Foreign Agents by eliminating even the delay period
required to perform the Regional Registration following a Mobile IP
handoff. As for Mobile IPv4, hierarchical networks utilizing Regional
Tunnel management will suffer from triangle routing. The worst case
will involve communication between Mobile Nodes connected to the same
Foreign Agent, or to any other Foreign Agent within the same
hierarchy, since packets will be routed through the respective home
networks. In this draft, triangle routing between nodes within the
hierarchical domain is eliminated by direct routing through Regional
Foreign Agents or alternatively reduced by routing through the
Gateway Foreign Agent (GFA).
In Mobile IPv6 there are no Foreign Agents, but there is still the
need to provide a central point of access control and, similarly to
Mobile IPv4, Mobile IPv6 can benefit from reduced mobility
signalling with external networks by employing a regional
hierarchical structure. For this reason a new Mobile IPv6 node,
called the Mobility Anchor Point (MAP), is used and can be located at
any level in a hierarchical Mobile IPv6 network. Unlike FAs in IPv4,
a MAP is not required on each subnet. The MAP is used by a MN as an
alternate-care-of address (COA) while roaming within a hierarchical
(MAP) domain, where such a domain involves all access routers
advertising that MAP. The MAP will limit the amount of Mobile IPv6
signalling outside the domain and will support Fast Handoffs to
help Mobile Nodes in achieving seamless mobility. Other advantages of
the introduction of the MAP functionality are covered in chapter 7.
This draft assumes the generic case of scaleable multi-level
Hierarchical Mobile IP (HMIP) networks and is therefore applicable to
HMIP networks in general. HMIP networks utilizing Regional Tunnel
Management (HMIPv4) or Hierarchical MIPv6 (HMIPv6), Fast Handoffs
and local routing optimizations offer advantages which are especially
Karim El Malki and Hesham Soliman Expires 10 September 2000 [Page 3]
INTERNET-DRAFT HMIPv4/v6 and Fast Handoffs Mar 10, 2000
important for the support of real-time services.
2. Hierarchical Mobile IPV4 Network
The Regional Tunnel Management draft [1] describes a two-level Mobile
IPv4 hierarchy (i.e. GFA and one level of FAs). In [1] Annex A briefly
describes the possibility of having multiple FA levels. In the generic
case, there may be multiple levels of FAs but only a single "root" GFA
within an administrative domain. The procedures described in this
draft do not limit the number of hierarchical levels of FAs. In
addition, a MN may be attached directly to any FA within the hierarchy
and may move between FAs from different levels in the hierarchy. The
following figure describes the Hierarchical MIPv4 network.
________
| |
| GFA |
|________|
/ | \
... ... ...
____|___
| |
| FA3 |
|________|
______/_ _\______
| | | |
| FA2 | | FA1 |
|________| |________|
____|___ ____|___
| | | |
|AP/RAN 2| |AP/RAN 1|
|________| |________|
| ____|___
| |
CN | MN |
|________|
Figure 1: Multi-level Hierarchical MIPv4 domain.
In the above figure, Access Points (APs) or Radio Access Networks
(RANs) consisting of multiple access points, are used to provide a
MN with L2 access. It is important to note that there may be
multiple paths between a MN and the GFA (Gateway Foreign Agent).
FA1 and FA2 will be referred to as the lowest level regional FAs in
the hierarchy. Also, the "common route" regional FA is defined as
the first regional FA in common for the route of communication
between hosts connected to regional FAs. In Figure 1, FA3 is the
"common route" regional FA for communication between a host connected
Karim El Malki and Hesham Soliman Expires 10 September 2000 [Page 4]
INTERNET-DRAFT HMIPv4/v6 and Fast Handoffs Mar 10, 2000
to FA2 (i.e. CN) and a host connected to FA1 (i.e. MN). A regional FA
found in a hierarchical level between the GFA and the lowest level
FAs will be referred to as an intermediate regional FA.
As described in [1], a regional FA announces itself and its GFA in
the Agent Advertisement; in the first and last address in the
care-of address field in the Mobility Agent Advertisement extension
[2]. If there is a hierarchy of foreign agents between the GFA and
the announcing foreign agent, the foreign agent MAY include the
corresponding addresses in order between its own address (first) and
the GFA address (last). For example, in Figure 1, FA1 MAY advertise
in the order: FA1, FA3 .. GFA.
This draft supplements [1] with the following for MIPv4:
- limitation of triangle routing for communication between hosts
within the administrative domain
- Fast Handoffs within the administrative domain
- Considerations on Regional Deregistration
Regional Tunnel Management allows Regional Registrations within an
administrative domain in order to avoid always having to perform
registrations through the Home Agent, which is often distant from the
Mobile Node's current location. However, it is also part of Regional
Tunnel Management that the Mobile Node's registration with the Home
Agent be renewed before its expiry. Therefore it is assumed that the
MN will send one or more Registrations (using the GFA address as
care-of address) to the Home Agent before the MN's Registration
lifetime with the Home Agent expires. As specified in Regional
Tunnel Management, the GFA's address always appears to the Home
Agent as the Mobile Node's care-of address. In this way, some of the
Home Agent's functionality is performed locally in the GFA. It is
assumed in this draft and in [1] that regional FAs and the GFA share
a common security association.
3. Traffic Routing in Mobile IPv4 Hierarchies
The GFA and intermediate regional FAs will hold a binding for a
registered MN to the "next" FA in the hierarchical branch towards
the MN. The Regional Registration Requests (and Regional Registration
Replies if the MN includes the Hierarchical Foreign Agent extension
in its Regional Registration Request) containing the Hierarchical
Foreign Agent extension [1] will allow a hop-by-hop route along this
branch to be created within the hierarchy for the MN. This procedure
is specified in [1]. The complete order of FAs in the branch MAY be
advertised to the MN in the Mobility Agent Advertisement extension.
In this case the Hierarchical Foreign Agent extension MAY be present
also in the Regional Registration Reply received by the intermediate
Karim El Malki and Hesham Soliman Expires 10 September 2000 [Page 5]
INTERNET-DRAFT HMIPv4/v6 and Fast Handoffs Mar 10, 2000
regional FAs in the branch and the MN, although the order of the
addresses is inverted with respect to that in the Regional
Registration Request.
If the packets for the MN are tunnelled from the HA, then the GFA
should change the source and destination IP address of the
encapsulating header to the "next" FA towards the MN. The "next" FA
may be the lowest level FA. The same procedure will be performed by
intermediate regional FAs if any are present. When packets reach the
lowest level FA they will be detunnelled and sent to the MN.
Otherwise, if the regional FAs or GFA receive packets for MNs which
are not tunnelled (i.e. sent by other hosts within the hierarchy),
then routing between MNs in the same hierarchy (or between any host
in the hierarchy and a MN in the same hierarchy) may be performed:
- through the Home Agent
- through the GFA
- through any regional FA (including the GFA)
In order to reduce triangle routing and the associated unnecessary
latency and tunnelling overhead for communication between hosts
within the same administrative domain, it is preferred to route using
the last two options, namely through the GFA or through any regional
FA. As an example of routing through any regional FA, in Figure 1 the
path of communication between the CN and the MN would go through FA2,
FA3 and FA1.
The most efficient routing is using the shortest path through any
regional FA. However the decision on which option to adopt depends on
the particular implementation and deployment. These two methods will
be described in the following sections.
I. Routing between nodes only through the GFA
Routing between MNs (or between a fixed host and a MN) in the same
hierarchy may be performed through the GFA. The GFA does this by
tunnelling packets for a MN to the appropriate "next" FA using the
information it has for the MN in its Regional binding. Therefore,
packets generated within the hierarchical domain and directed to
the MN's home address reach the GFA and are tunnelled by the GFA
to the "next" regional FA. Following this, the same hierarchical
routing procedure described previously for traffic coming from the
HA applies.
II. Routing between the nodes through any regional FA (shortest path)
Routing between MNs (or between a fixed host and a MN) in the same
hierarchy may be performed through any regional FA in the hierarchy.
Any number of levels of regional FAs may be present in the hierarchy.
Karim El Malki and Hesham Soliman Expires 10 September 2000 [Page 6]
INTERNET-DRAFT HMIPv4/v6 and Fast Handoffs Mar 10, 2000
Packets sent between MNs in the same hierarchy will be routed through
the shortest path of connected FAs in the hierarchy. This shortest
path goes through the closest regional FA that is able to
interconnect the nodes: the "common route" regional FA. In Figure 1,
this is FA3. It is possible that the closest regional FA able to
interconnect the nodes is the GFA.
If the regional FAs or GFA receives packets for the MN which are not
tunnelled (i.e. sent by other hosts within the hierarchy) then routing
will be performed using any existing active regional bindings by
tunnelling packets to the "next" regional FA towards the MN. Following
this, the same hierarchical routing procedure described previously for
traffic coming from the HA applies.
4. Fast Handoffs
Fast Handoffs address the need to achieve seamless Mobile IP
Handoffs when the MN moves between FAs. This is done by "bicasting"
traffic to the "previous" FA and "new" FA while the MN is moving
between them. The anticipation of the MN's movement is achieved by
tight coupling with Layer 2 functionality which is dependent on the
type of access technology used. "Bicasting" is achieved through
simultaneous bindings, where the MN activates the "S" bit in the
Registration Request. When a Regional Registration Request has the
"S" bit set, the receiving FA or GFA which has an existing binding
with the MN will add the relevant new binding for the MN but will
also maintain any other existing bindings it had for the MN.
When the MN has multiple active bindings with FAs, it may or may not
receive multiple copies of the same traffic directed to it. The use
of simultaneous bindings does not necessarily mean that the MN is
receiving packets contemporarily from multiple sources. This depends
on the characteristics of the access (L2) technology. The "bicasting"
of packets is used to anticipate the MN's movement and speed up
handoffs by sending a copy of the data to the FA which the MN is
moving to. Until the MN actually completes the L2 handoff to the new
FA, the data "copy" reaching this FA may be discarded. In this way
the total handoff delay is limited to the time needed to perform the
L2 handoff. Thus, Fast Handoffs coupled to the L2 access potentially
result in loss-less IP-layer mobility. As described in 4.1, depending
on the L2 characteristics, it is also possible for an MN to initiate
a Fast Handoff through the "previous" FA without having direct access
to the "new" FA.
When there is a hierarchy of foreign agents between the GFA and the
announcing foreign agent, the announcing foreign agent MAY include
the corresponding addresses in order between its own address (first)
and the GFA address (last) in the Mobility Agent Advertisement
extension of its Agent Advertisements. If there are only two
Karim El Malki and Hesham Soliman Expires 10 September 2000 [Page 7]
INTERNET-DRAFT HMIPv4/v6 and Fast Handoffs Mar 10, 2000
hierarchical levels, a foreign agent announces itself and a GFA in
the Agent Advertisement; in the first and last address in the
care-of address field in the Mobility Agent Advertisement extension.
There must be at least one care-of address in the Mobility Agent
Advertisement extension. If there is only one care-of address it
is the address of the GFA, and the MN is connected directly to it.
When the MN receives an Agent Advertisement with a Mobility Agent
extension and the "I" bit set, as specified in [1], it should perform
actions according to the following movement detection mechanisms. In
a Hierarchical Mobile IP network such as the one described in this
draft, the MN MUST be:
- "Eager" to perform new bindings
- "Lazy" in releasing existing bindings
The above means that the MN will perform Regional Registrations with
any "new" FA from which it receives an advertisement (Eager). The
method by which the MN determines whether the FA is a "new" FA is
described in [2] and may make use of an FA-NAI extension. However
the MN should not release existing bindings until it no longer
receives advertisement from the relative FA and the lifetime of
its existing binding expires (Lazy).
It should be noted that the MN may add a Hierarchical FA extension
to Registration Requests in order to identify the exact FA path to
be followed by the Registration Request. This extension must not be
removed by regional FAs.
If the MN has at least one existing binding with an FA, additional
simultaneous regional registrations will be performed requesting a
short lifetime. This is done in order to limit the lifetime of
bindings which the MN only needs temporarily and therefore limit
bandwidth usage. This is the case when the MN is moving between FAs
and uses Fast Handoffs to achieve loss-less IP mobility. The
lifetime of additional "auxiliary" bindings needed for Fast Handoffs
is thus limited.
The remaining issue is the choice of the appropriate HA address in
the Regional Registration Request when the MN has at least an
existing active regional binding. Two options follow:
1) Mobility Agent extension advertises FA and GFA address only
In this case it is assumed that there is always a single path from
the MN to the GFA. The MN will always perform Regional Registrations
using the GFA address as HA address and the advertising FA as
care-of address. As the Regional Registration Request is relayed
towards the GFA, each FA receiving it will check whether it has an
Karim El Malki and Hesham Soliman Expires 10 September 2000 [Page 8]
INTERNET-DRAFT HMIPv4/v6 and Fast Handoffs Mar 10, 2000
existing binding with the MN and whether the Regional Registration
has the "S" bit set to request for simultaneous bindings. If this is
true and the Regional Registration is validated by the GFA, these FAs
will activate the simultaneous binding upon receiving the (successful)
Regional Registration Reply from the GFA. Therefore it is not
necessary to advertise to the MN all of the FA addresses in the
hierarchical branch, thus reducing bandwidth usage over wireless.
2) Mobility Agent Advertisement extension advertises complete order
of FAs in the branch
In specific cases where multiple regional FA levels and multiple
paths from the MN to the GFA are present and are advertised, it
may be necessary for the MN to identify the "common route" FA
using the complete list of FAs in the hierarchical branch. It is
assumed that the GFA advertises only one care-of address on all its
interfaces towards the MN.
The MN must cache the Mobility Agent Advertisement extensions for
its active bindings. When it receives an advertisement from a "new"
FA which has a different Mobility Agent Adv. extension, it will be
eager to perform a new binding. The MN compares the IP addresses in
the new Mobility Agent Adv. extension with the ones it has cached
for its active binding(s). If there is an IP address in common
between these extensions, named "common route" FA or GFA, the MN
will use that IP address as HA address and destination address of its
Regional Registration Request in which the "S" bit will be set. The
care-of address is the advertising FA's address. The MN may add a
Hierarchical FA extension to the Regional Registration Request, in
order to identify the regional FA path to be followed by the Request
up the hierarchy. A Regional FA receiving a Regional Registration
Request with it's own address as HA address may return a Regional
Registration Reply to the MN.
If there is no IP address in common between the extensions, then the
MN must have moved into a new hierarchy and the GFA advertised in the
new extension must be different from the one in the previously cached
extension(s). When the MN moves between administrative domains (i.e.
changes GFA) then the MN should use the new GFA's IP address as
care-of address in its new Registration Request to the HA and may add
the Hierarchical FA extension as described previously. If the MN has
at least one existing active binding when it moves to the new GFA, it
may perform a smooth handoff as explained in section 6.
The MN is able to perform this option to implement Fast Handoffs only
if its binding lifetime with the GFA or HA does not expire during the
period needed by the MN to complete its handoff. Intermediate
regional FAs are able to accept the MN's regional registration
Karim El Malki and Hesham Soliman Expires 10 September 2000 [Page 9]
INTERNET-DRAFT HMIPv4/v6 and Fast Handoffs Mar 10, 2000
(simultaneous binding) only if the intermediate regional FA has an
existing active binding for the MN. The resulting simultaneous
binding may therefore have a maximum possible lifetime equal to the
lifetime remaining in its previously existing active binding. Once
the registration lifetime with the GFA or HA is about to expire, the
MN must perform a new Mobile IP registration with the HA.
4.1 Initiating Fast Handoffs through the "previous" FA
In the case in which the wireless L2 technology allows the MN to
be data-connected to multiple wireless access points simultaneously,
the MN may solicit advertisements from FAs before handoffs.
Some existing wireless L2 technologies and their implementations do
not allow a MN to be data-connected to multiple wireless access
points simultaneously. Thus, in order to perform a Fast Handoff it
is necessary for some form of interworking between layers 2 and 3.
It should be noted that the method by which an FA determines when a
MN has initiated an L2 handoff is outside the scope of this draft.
A Fast Handoff in this case requires the MN to receive "new" agent
advertisements through the "old" wireless access points, and to
perform a (regional) registration with the "new" FA through the "old"
wireless access point. Two ways of performing this follow.
I. Inter-FA Solicitation
This solution assumes that the FA with which the MN is currently
registered is aware of the IP address of the "new" FA which the MN is
moving to. The method by which the current FA is informed of this may
depend on interaction with L2 and is outside the scope of this draft.
Once the current FA is aware of the address of the FA which the MN
will move to, it will send the "new" FA an agent solicitation
message. The "new" FA will reply to the current FA by sending it an
agent advertisement with appropriate extensions. The current FA will
then send the agent advertisement to the MN's address. As a
consequence, the MN, being eager to perform new registrations, will
send a regional registration request to the "new" FA through the
"old" wireless access point served by the current FA.
II. Piggy-backing Advertisements on L2 messaging
Let us take Figure 1 as an example, where a MN initiates an L2
handoff from AP/RAN1 to AP/RAN2 (Note that it may not be the MN which
takes decisions on handoffs). It is assumed that when an L2 handoff
is initiated, AP/RAN1 and AP/RAN2 perform L2 messaging procedures to
Karim El Malki and Hesham Soliman Expires 10 September 2000 [Page 10]
INTERNET-DRAFT HMIPv4/v6 and Fast Handoffs Mar 10, 2000
negotiate the L2 handoff. Since the MN is not attached to AP/RAN2
yet, FA2 is unaware of the IP address of the MN and cannot send an
advertisement to it. Therefore it is necessary for the L2 procedures
to interwork with Mobile IP.
Once a L2 handoff is initiated, such that AP/RAN2 and AP/RAN1 are in
communication, it is possible for AP/RAN2 to solicit an advertisement
from FA2 and transfer it to AP/RAN1. Once this is received by the MN,
the MN can perform a regional registration directed to FA2 even
though the MN has no data-connection to AP/RAN2 yet.
The precise definition of such L2 procedures is outside the scope of
Mobile IP.
5. Regional Deregistration for Fast Handoffs
Regional deregistration is described in [1]. In this draft we apply
the deregistration procedure to Fast Handoffs. When the MN performs
a regional registration with a "new" regional FA, then a regional
deregistration must be performed with the MN's old location,
which may include all the FAs in its old regional branch. This is
necessary to avoid incorrect routing of packets (see section 3) by
the "previous" FA(s) in the old regional branch during the interval
in which the MN has moved but the "previous" FA(s)'s regional binding
lifetime for the MN has not yet expired. As stated in [1] it is also
a problem since, if old locations are not deregistered, it is
possible that tunnels are not correctly redirected when a mobile node
moves back to a previous regional foreign agent.
The regional deregistration is performed by a regional FA upon the
first time it receives a valid Regional Registration Request, without
the "S" bit set, from a MN which had previously set the "S" bit in
its regional registration(s). This regional FA may respond with
a Registration reply and may perform the Regional deregistration by
sending a Binding Update with zero lifetime to the "next" regional FA
in the MN's old regional branch, setting the Binding Update's care-of
address to the the previous care-of address it had registered for the
MN (i.e. the "previous" lowest level FA). The Binding Update is
relayed down towards the previous care-of address, and each regional
foreign agent in the hierarchy receiving this notification removes
its binding for the MN. In this way, the MN updates all the Regional
FAs in the "old" hierarchical branch between the "common route" FA
and the "old" lowest level FA.
In this draft there is no assumption that the GFA shares its GFA-MN
security association with the regional FAs. Therefore the MN will be
able to perform regional deregistrations through intermediate
Karim El Malki and Hesham Soliman Expires 10 September 2000 [Page 11]
INTERNET-DRAFT HMIPv4/v6 and Fast Handoffs Mar 10, 2000
regional FAs only for the duration of its registration lifetime with
the GFA or HA. Otherwise the regional deregistration will be performed
by the GFA.
6. Smooth Handoffs between Hierarchies (GFAs)
When the MN moves between domains it receives Mobility Agent
extensions containing a new GFA IP address. The MN registers with its
HA using the new GFA IP address as care-of address. In order to
improve inter-domain handoffs it may use the Previous Foreign Agent
extension in the Regional Registration Request [3]. This results in a
smooth handoff between the domains.
A new flag is required in the Binding Update message to perform a
smooth handoff while maintaining the existing binding in the
"previous" FA. This is the "S" bit for the simultaneous binding. This
simultaneous binding is necessary in the case in which the MN only
momentarily moves "forward" to the new domain, then returns back to
the "previous" FA (domain) before its "previous" binding expires. In
this case the binding for the MN with the "previous" FA must be
maintained. Following is the new Binding Update message with the "S"
flag added which replaces one bit of the Reserved space.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |A|I|M|G|S| Rsv | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node Home Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Care-of Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
Karim El Malki and Hesham Soliman Expires 10 September 2000 [Page 12]
INTERNET-DRAFT HMIPv4/v6 and Fast Handoffs Mar 10, 2000
7. Hierarchical Mobility Management using MIPv6
The aim of introducing the hierarchical mobility management model in
MIPv6 is to enhance the network performance while minimising the
impact on MIPv6 or other IPv6 protocols. This is achieved by using
the MIPv6 protocol combined with layer 2 features to manage both IP
micro and macro mobility, leading to rationalisation and less complex
implementations in the MN and other network nodes. This hierarchical
MIPv6 scheme introduces a new function, the Mobility Anchor Point
(MAP), and minor extensions to the MN and the Home Agent operations.
The CN operation will not be affected.
The introduction of the MAP concept minimises the latency due to
handoffs between access routers. Furthermore, the addition of
bicasting to a MAP allows for Fast Handoffs which will minimise the
packet losses due to handoffs and consequently improve the throughput
of best effort services and performance of real time data services
over the radio interface. Just like MIPv6, this solution is
independent of the underlying access technology, allowing Fast
Handoffs between different types of access networks. Furthermore, a
smooth architectural migration can be achieved from Hierarchical
MIPv4 networks, since a dual operation of IPv4 and IPv6 Hierarchies
will be possible making use of the similarity in architecture.
The introduction of the MAP concept will further diminish signalling
generated by MIPv6 over the radio interface. This is due to the fact
that a MN only needs to perform one regional update (MAP) when
changing its layer 3 access point within the MAP domain. The
advantage can be easily seen when compared to other scenarios (no
MAP) where at least two BUs (Binding Updates) will be sent (to one CN
and HA). A MAP may also be used as a point of access control and key
distribution for the AAA protocol in IPv6.
8. Overview of the MIPv6 Hierarchical Mobility Management
In order to introduce hierarchical mobility management in MIPv6, the
protocol is extended with a new function. The proposed new
functionality is the Mobility Anchor Point (MAP). It simply provides
an optional mobility management function that can be located at any
level in the hierarchy starting from the access router upwards.
The MAP is used by a MN as an alternate-COA while roaming within a
certain MAP domain. A MAP domain's boundaries are defined by the
Access Routers (ARs) advertising the MAP information to the attached
Mobile Nodes.
When the MAP is used as an alternate COA, the MAP will receive all
packets on behalf of the MN and will encapsulate and forward them
directly to the MN's current address. If the MN changes its current
Karim El Malki and Hesham Soliman Expires 10 September 2000 [Page 13]
INTERNET-DRAFT HMIPv4/v6 and Fast Handoffs Mar 10, 2000
address within a regional MAP domain, it needs to register the new
address with the MAP. This makes the MN's mobility transparent to the
CNs it is communicating with. The MAP can also be used to execute a
Fast Handoff between ARs as will be explained later.
The detailed extensions to MIPv6 and operations of the different
nodes will be explained later in this document.
Although the proposed method is independent of the network topology,
it is best suited to a hierarchical network or one with multi-access
technologies. It should be noted that the MAP concept is simply an
extension to the MIPv6 protocol. Hence a MAP-aware MN with an
implementation of MIPv6 MAY choose to use the MAP or simply use the
standard MIPv6 implementation as it sees fit. Furthermore, a MN can
at any time stop using the MAP. This provides great flexibility, both
from a MN or a network operations point of view.
The network architecture shown below illustrates an example of the
use of the MAP in a foreign domain.
_______
| HA |
|_______| _______
\ | CN |
\ |_______|
\___ |
\ |
PATH A \ ____| PATH B
_\___|_
| |
| MAP |
|_______|
/ \
/ \
PATH C / \ PATH D
/ \
____/____ \_________
| | | |
| AR1 | | AR2 |
|_________| |_________|
| |
| |
__\/____ \/
| |
| MN |
|________|
__________________\
Movement /
Figure 2: Hierarchical MIPv6 domain
Karim El Malki and Hesham Soliman Expires 10 September 2000 [Page 14]
INTERNET-DRAFT HMIPv4/v6 and Fast Handoffs Mar 10, 2000
In Figure 2, the MAP can help in providing seamless mobility for the
MN as it moves from Access Router 1 (AR1) to Access Router 2 (AR2),
while communicating with the CN. It is possible to use multi-level
hierarchies of routers and implement MAP functionality in AR1 and AR2
if needed. It should be noted that AR1 and AR2 could be two points of
attachment in the same RAN (Radio Access Network) or in different
RANs.
Upon arrival in a foreign domain, the MN will discover the global
address of the MAP. This address is stored in the Access Routers
and communicated to the MN via Router Advertisements. The discovery
phase will also inform the MN of the distance of the MAP from the MN.
For example, the MAP could also be implemented in AR1 and AR2, in
which case the MN can choose the first hop MAP, second hop MAP, or
both.
A Router advertisement extension is proposed later in this document
for MAP discovery. Other service discovery methods may also be used
for the same purpose. If a router advertisement is used for MAP
discovery, as described in this document, all ARs belonging to the
MAP domain MUST advertise the MAP's IP address. The same concept
should be used if other methods of MAP discovery are introduced.
The process of MAP discovery continues as the MN moves from one
subnet to the next. As the MN roams within a MAP's domain, the same
information announcing the MAP should be received. If a change in the
advertised MAP's address is received, the MN should act on the change
by sending the necessary Binding Updates to its HA and CNs.
If the MN is not MAP-aware then the discovery phase will fail
resulting in the MN using the MIPv6 protocol for its mobility
management. On the other hand, if the MN is MAP-aware it MAY choose
to use the MAP implementation. If so, the MN will first need to
register with a MAP by sending it a BU containing its Home Address
and current address. The MAP MUST store this information to be able
to forward packets to their final destination when received from the
different CNs or HAs.
The Home Address contained in the MAP registration MUST be the same
Home Address sent in the Home Agent registration. If a MN sends
different BU's for different Home Addresses (in the case it has
multiple Home Addresses), the same process MUST be performed for the
MAP registrations. This is essential to allow a MAP to forward
packets to the right COA when they are tunnelled from the HA. The MN
should also have a prefix length of 128 in its BUs to the HA. This
would stop the HA from being proxy for other unregistered Home
addresses.
The MN will then need to update all CNs and its HA with its new COA.
The new COA in this case SHOULD be the MAP's global IP address
received earlier in the discovery phase. Hence all packets meant for
Karim El Malki and Hesham Soliman Expires 10 September 2000 [Page 15]
INTERNET-DRAFT HMIPv4/v6 and Fast Handoffs Mar 10, 2000
the MN will be sent through the MAP's address as specified by the MN
in its BU. The MAP will (acting like a HA) tunnel the packets
addressed to the MN to its current address. The details of the MAP
operation will be given later in this document.
The MN will always need to know the original sender of any received
packets. Since all packets will be tunnelled by the MAP, the MN is
not always able to determine whether the packets were originally
tunnelled from the Home Agent or received directly from a CN. This
knowledge is needed by the MN to decide whether a BU needs to be sent
to a CN in order to initiate route optimisation. For this purpose a
check needs to be performed on the internal packet's routing header
to find out whether the packet was tunnelled by the HA or originated
from a CN using route optimisation instead. If a routing header
exists in the internal packet, having the MN's Home Address as the
final destination, then route optimisation was used. Otherwise,
triangular routing through the HA was used.
The MAP also needs to know how the final destination in the packet
corresponds to the registered address of a MN. This should be obvious
when the packets are sent from a CN to the Home Address of the MN or
to the COA with a routing header. However, if the HA tunnels packets
with addresses other than the MN's Home Address (eg. Site-local,
organisation-local or multicast), of which the MAP would have no
knowledge, the HA MUST add a routing header to the outer packet. This
routing header must use one of the MN's Home Addresses as the final
destination. This will enable the MAP to tunnel the packet to the
correct destination (i.e. the MN's current address).
To use the network bandwidth in a more efficient manner, a MN may
decide to register with more than one MAP simultaneously and use each
MAP address for a specific group of CNs. For example, in Fig 2, if
the CN happens to exist on the same link as the MN, it would be more
efficient to use the first hop MAP (in this case assume it is AR1)
for communication between them. This will avoid sending all packets
via the "highest" MAP in the hierarchy and hence result in a more
efficient usage of network bandwidth. The MN can use its current
address as a COA as well.
9. Neighbour Discovery extension - MAP discovery
The process of MAP discovery can be performed in many different ways.
In this document, router advertisements are used for the discovery
phase by introducing a new option. The access router is required to
send the MAP option in all router advertisements. This option
includes the distance from the MN in terms of number of hops, the
preference for this particular MAP and the MAP's global IP address.
The ARs can be configured manually or automatically with this
information. In the case of automatic configuration, each MAP in the
Karim El Malki and Hesham Soliman Expires 10 September 2000 [Page 16]
INTERNET-DRAFT HMIPv4/v6 and Fast Handoffs Mar 10, 2000
network needs to be configured with a default preference, the right
interfaces to send this option on and, if necessary, the IP address
to be sent. The initial value of the "HOPS" field MUST be set to a
value of one. Upon reception of a router advertisement with the MAP
option, given that a router is configured to resend this option on
certain interfaces, the router MUST copy the option and resend it
after incrementing the HOPS field by one. If the router was also a
MAP, it SHOULD send its own option in the same advertisement. In this
manner information about a MAP at a certain level in a hierarchy can
be dynamically passed to a MN. Furthermore, by performing the
discovery phase in this way, different MAP nodes are able to change
their preferences dynamically based on the local policies, node
overload or other load sharing protocols being used.
The following figure illustrates the new MAP option.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | HOPS | Pref |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Global IP Address for MAP +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The alignment requirements for this option is 8n.
Fields:
Type 6
Length 8-bit unsigned integer. The length of the option
(including the type and length fields) in units
of 8 octets. The value 0 is invalid. Nodes
MUST silently discard an ND packet that contains
an option with length zero.
HOPS An 8 bit unsigned integer showing the number of
hops away from the receiver of the
advertisement. It MUST be set to one in the
initial advertisement.
Pref The preference of this MAP. An 8 bit unsigned
integer. A value of 255 means lowest preference.
Karim El Malki and Hesham Soliman Expires 10 September 2000 [Page 17]
INTERNET-DRAFT HMIPv4/v6 and Fast Handoffs Mar 10, 2000
Global Address One of the MAP's global addresses.
10. MIPV6 extensions - Sending Binding Updates
This section outlines the extensions proposed to the BU option used
by the MN in MIPv6. Two new flags were added: the M flag that
indicates MAP registration and the B flag that indicates a request
for bicasting. When a MN registers with the MAP, the M flag MUST be
set to distinguish this registration from a Home Registration or a BU
being sent to a CN. The B flag is used during handoffs and signifies
a request that a MAP bicast all received packets to the MN's current
address (source Address on the packet) and the Alternate-COA specified
in the sub-option.
A MN MAY choose to use this flag to achieve a Fast Handoff, described
in section 11.4. If the MN sends a BU with the B flag set, it MUST
include an Alternate- care-of address sub-option, otherwise the BU
MUST be rejected by the MAP. The B flag is only valid in BUs to a MAP.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|R|D|M|B|Res| Prefix Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Options...
+-+-+-+-+-+-+-+-+-+-+-+-
Description of extensions to the BU option:
M If set indicates a MAP registration.
B A request to bicast all received packets to the
source address and the alternate COA given.
Res 2 bit reserved field
11. MN OPERATION
This section is concerned with the extensions to the MN's operation
in a foreign network due to the introduction of the MAP. Unless
otherwise specified, the normal MN operation in [4] applies.
Karim El Malki and Hesham Soliman Expires 10 September 2000 [Page 18]
INTERNET-DRAFT HMIPv4/v6 and Fast Handoffs Mar 10, 2000
11.1 MAP discovery
When a MAP-aware MN receives a router advertisement, it should search
for the MAP option. One or more options may be found for different IP
addresses.
A MN SHOULD register with the MAP having the lowest preference value.
A MAP with a preference value of 255 SHOULD not be used in the MAP
registration. A MN MAY however choose to register with one MAP rather
than another depending on the value received in the HOPS field, as
long as the preference value is below 255.
A MN SHOULD store the received option(s) and choose at least one MAP
IP address to register as its COA. Storing the options is essential
as they will be compared to other options received later for the
purpose of the move detection algorithm.
If no MAP options are found in the router advertisement, the MN MUST
use the MIPv6 protocol as specified in [4]. If the MN receives a
duplicated MAP option with different preference values or HOPS
values, the MAP IP address MUST not be used as an Alternate-COA in
any BU's sent by the MN.
A MN MAY choose to register with more than one MAP simultaneously or
use both MAP address and its own address as COAs simultaneously with
different CNs.
11.2 Registration with the MAP - Sending Binding Updates
After MAP discovery has taken place, a MN can register with one or
more MAPs. The MN performs this local registration by sending a BU
to the MAP with the appropriate flags set. When registering with a
MAP, the A and M flags MUST be set in the BU. The H flag MUST not
be set when registering with a MAP. A MN MUST wait for a BAck
(Binding Acknowledgement) from the MAP before using the MAP address
as an alternate COA in its BUs.
After successfully performing registration with a MAP, a MN can
start sending BUs, with the MAP's IP address as an Alternate-COA,
to CNs and its HA. The MAP's IP address MUST be included in the
Alternate-COA sub-option.
For each home address registration sent to the HA with a MAP's
address as the COA, a BU MUST be sent to the same MAP using the same
home address. The MN SHOULD send a separate home registration BU for
each home address, with the prefix length value set to 128. This
stops the HA from forming home addresses for that MN on each link
that the HA is connected to, thus ensuring consistency in the Binding
Caches of both the MAP and HA for the MN.
Karim El Malki and Hesham Soliman Expires 10 September 2000 [Page 19]
INTERNET-DRAFT HMIPv4/v6 and Fast Handoffs Mar 10, 2000
11.3 Receiving packets in a foreign network
When in a foreign network, a MN needs to know which path a packet has
taken from the CN to the MN. That is, whether triangular routing was
used via the HA or route optimisation was used. When using the MAP as
an alternate-COA, all packets received from a CN will be tunnelled by
the MAP to the MN. If a HA tunnels a packet to the MAP, it will be
decapsulated and then encapsulated again with the MAP's address as
the source address. Therefore a check on whether the packet was
tunnelled by the HA will not be sufficient to decide whether route
optimisation is required. However, a check for the existence of a
routing header in the encapsulated packet (i.e. with CN as source
address), where the MN's home address is the final address, will be
sufficient to determine whether the path was route optimised or not.
If the routing header does not exist, the MN SHOULD send a BU with
the appropriate information to initiate route optimisation.
11.4 Fast Handoff scenario
In this section, a mechanism is explained for the execution of a Fast
Handoff between two access routers within a MAP domain. A Fast
Handoff using this mechanism can be achieved independently of the
underlying access technology, provided the appropriate movement
detection algorithm is being used.
One way of achieving a Fast Handoff is by sending the next access
point's router advertisement to the MN via the current access point.
The router advertisement must be sent unicast to the MN concerned.
This can be achieved by treating the advertisement as a solicited
one, hence having the MN's global IP address in the destination field
of the router advertisement. Possible mechanisms to achieve this are
described in section 4.1 for MIPv4, although easily applicable to
this case. It should be noted that it may be more suitable
(depending on the access technology) for a MN to solicit such
advertisement. The decision on the method of receiving such
advertisement is dependent on the access technology and will not be
covered in this document.
Upon reception of the new router advertisement, a MN should check
whether it is still within the same MAP domain. If it is, a BU SHOULD
be sent to the MAP containing the following information:
- M flag MUST be set indicating a MAP registration
- The B flag SHOULD be set to indicate that bicasting is required
- If the B flag is set, the lifetime should not be more than 5
seconds
- The A flag SHOULD be set.
- The MN's future COA formed from the new prefix in the router
advertisement. This new COA MUST be included in the alternate-COA
Karim El Malki and Hesham Soliman Expires 10 September 2000 [Page 20]
INTERNET-DRAFT HMIPv4/v6 and Fast Handoffs Mar 10, 2000
sub-option.
- The source address in the packet MUST be the MN's current address.
This BU enables the MAP to send all packets for the MN to both
addresses until a deregistration is made for the old COA. It should
be noted that the addition of the "B" flag in the BU does not imply
that a MN is required to receive packets from both ARs
simultaneously. Sending of packets over the air interface need only
be done by the AR to which the MN is currently attached.
After the Handoff is executed, the MN SHOULD deregister its old COA
from the MAP to stop the bicasting. This is done by sending a BU to
the MAP with only the M and A flags set, which would cause the MAP to
remove previous entries for the MN in its Binding Cache.
The new router advertisement received by the MN during handoff may
also include a new MAP option on top of the existing one. Depending
on its level in the hierarchy and its preference value, the MN MAY
register with the new MAP as well without informing all CNs during
the handoff. This may be useful since the current MAP may disappear
during the following handoff.
If the MN receives a new MAP option during handoff, and finds that
its current MAP will disappear, it MUST register with the new MAP as
explained earlier in MAP discovery. The MN MUST then update all the
CNs and HA if necessary. The MN MUST also deregister with its
previous MAP. This is done by sending a BU with the current COA and a
lifetime of zero. Alternatively, a MN can simply send another BU with
its new COA to the MAP. This BU should contain a short lifetime as it
is a way of forwarding to the new COA those packets still being sent
to the old COA. The deregistration method may depend on roaming
agreements between the two domains.
12. MAP Operation
12.1 MAP Discovery
As mentioned previously, the MAP discovery is done via router
advertisements having the new MAP option added. A MAP will be
configured to send its option or relay other MAPs' options on certain
interfaces. The choice of interfaces is done by the network operator
and depends on the network architecture. A default preference value
should be assigned to each MAP. It should be noted that a MAP can
change its preference value at any time due to various reasons (e.g.
node overload, load sharing etc.). A preference value of 255 means
that the MAP SHOULD not be chosen by a MN. This value could be
reached in cases of node overload or node failure.
The MAP option is propagated down the hierarchy. Each router along
the path to the access router will increment the HOPS field. If a
Karim El Malki and Hesham Soliman Expires 10 September 2000 [Page 21]
INTERNET-DRAFT HMIPv4/v6 and Fast Handoffs Mar 10, 2000
router that is also a MAP receives advertisements from other MAPs, it
SHOULD add its own MAP option and propagate both options to the next
level in the hierarchy.
12.2 Receiving and forwarding Packets for a MN
The MAP operation is in many ways similar to the HA operation
described in [4] with some modifications. Upon reception of a BU from
a MN with the M flag set, and provided it is allowed to accept this
message (i.e. no local policy restrictions) the MAP MUST store the
MN's current address and its Home Address in its Binding Cache. The
MAP MUST also update its routing table accordingly. If the A flag was
set in the BU, the MAP MUST then reply to the MN with a BAck (Binding
Acknowledgement) having the format specified in [4].
If both the M and H flags are set in a BU, the MAP MUST reject the
Binding Update by sending a BAck with the appropriate error code.
Upon reception of an encapsulated packet with no routing header in
the outer packet, the packet is decapsulated in the normal way. If
the inside packet contains a destination address that doesn't belong
to the MAP, the MAP should check its Binding Cache to see if the
address belongs to any of its registered MN's. If it does, the packet
MUST be tunnelled to the MN's current address. Otherwise, the packet
is processed in the normal way.
If the encapsulated packet contains a routing header in the outer
packet containing the MN's home address as the next destination, the
MAP MUST process the routing header in the normal way, then tunnel
the packet to the MN's current address.
12.3 Fast handoff scenario
When a MAP receives a BU from a MN with the B flag set it SHOULD
check for the following:
- The M flag MUST be set.
- An Alternate-COA sub-option exists.
- The MN's new address is not the same as the old one.
If any of the checks above fail, the MAP SHOULD reject the BU with
the appropriate error code.
If the registration lifetime for the "bicast" BU is greater than that
specified by the local network's policy, the lifetime stored SHOULD
be reduced to the maximum allowed time. The new lifetime SHOULD then
be sent in the BAck. If the A flag is set, the MAP MUST reply with a
BAck to the MN's current address.
Karim El Malki and Hesham Soliman Expires 10 September 2000 [Page 22]
INTERNET-DRAFT HMIPv4/v6 and Fast Handoffs Mar 10, 2000
If the packet passes all of the checks above, the MAP should add a
new entry in its Binding Cache for the MN's home address. All packets
that are to be tunnelled to the MN after this point MUST be tunnelled
to both entries in the Binding Cache.
If the new entry (with the B flag set) times out, the MAP MUST remove
only that entry. After the handoff is executed, the MN SHOULD send a
BU to the MAP with its new COA (the previous alternate-COA used in
the bicast request) with only the M and A flags set. The MAP should
replace both entries in the Binding cache with the new BU information,
resulting in the termination of the bicast.
13. HA Operation
The Home Agent operations are affected in a minor way by the
introduction of the MAP. The only change foreseen on the HA
implementation is that when tunnelling packets to the MN with
destination addresses other than the addresses registered by the MN
in its Home Registration, the HA MUST include a routing header in the
outer packet with the MN's registered home address as the final
destination. This is done to enable the MAP to find the right routing
entry for the MN, since it has no knowledge of a non-unicast global
home address for the MN.
14. AAA Considerations for IPv6
The MAP can be utilised to perform access control on MNs and may
interact with the protocol which will be defined for AAA in IPv6. The
MAP can speed up a handoff by having the MN's security credentials
which will allow it to verify whether a certain node is allowed
access to the network. This allows greater efficiency in distributing
keys only to certain nodes in the network.
15. Acknowledgements
The authors would like to thank Conny Larsson (Ericsson) and Mattias
Pettersson (Ericsson) for their valuable input to this draft. Since
this draft is in part a successor to the previous draft on Fast
Handoffs (draft-elmalki-mobileip-fast-handoffs-01) we also thank
N. A. Fikouras and S. Cvetkovic.
16. Notice Regarding Intellectual Property Rights
Ericsson may seek patent or other intellectual property protection
for some or all of the technologies disclosed in this document. If any
standards arising from this disclosure are or become protected by one
Karim El Malki and Hesham Soliman Expires 10 September 2000 [Page 23]
INTERNET-DRAFT HMIPv4/v6 and Fast Handoffs Mar 10, 2000
or more patents assigned to Ericsson, Ericsson intends to disclose
those patents and license them on reasonable and non-discriminatory
terms. Future revisions of this draft may contain additional
information regarding specific intellectual property protection sought
or received.
17. References
[1] E. Gustafsson, A. Jonsson and C. Perkins, " Mobile IP Regional
Tunnel Management ", draft-ietf-mobileip-reg-tunnel-02.txt
(work in progress), March 2000.
[2] C. Perkins, Editor. "IP Mobility Support", RFC 2002, October
1996.
[3] C. Perkins and D. Johnson, "Route Optimization in Mobile IP",
draft-ietf-mobileip-optim-09.txt (work in progress), February
2000.
[4] D. Johnson and C. Perkins, "Mobility Support in IPv6",
draft-ietf-mobileip-ipv6-10.txt, February 2000.
18. Authors' Addresses
Questions about this memo can be directed to:
Karim El Malki
Ericsson Radio Systems AB
Access Networks Research
SE-164 80 Stockholm
SWEDEN
Phone: +46 8 7573561
Fax: +46 8 7575720
E-mail: Karim.El-Malki@era.ericsson.se
Hesham Soliman
Ericsson Australia
61 Rigall St., Broadmeadows
Melbourne, Victoria 3047
AUSTRALIA
Phone: +61 3 93012049
Fax: +61 3 93014280
E-mail: Hesham.Soliman@ericsson.com.au
This Internet-Draft expires in September 2000.
Karim El Malki and Hesham Soliman Expires 10 September 2000 [Page 24]
