One document matched: draft-ietf-mobileip-hmipv6-02.txt
Differences from draft-ietf-mobileip-hmipv6-01.txt
IETF Mobile IP Working Group Hesham Soliman, Ericsson
INTERNET-DRAFT Claude Castelluccia, INRIA
Karim El-Malki, Ericsson
Ludovic Bellier, INRIA
February, 2001
Hierarchical MIPv6 mobility management
<draft-ietf-mobileip-hmipv6-02.txt>
Status of this memo
This document is a submission by the mobile-ip Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted
to the MOBILE-IP@STANDARDS.NORTELNETWORKS.COM mailing list.
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
Abstract
This draft introduces some extensions 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 reduce the amount of signalling to CNs and
the HA and may also improve the performance of MIPv6 in terms of
handoff speed. Moreover, HMIPv6 is well-suited to implement access
control and handoffs between different access technologies.
Soliman, Castelluccia, El-Malki, Bellier [Page 1]
INTERNET-DRAFT HMIPv6 ****,2000
TABLE OF CONTENTS
1. Introduction............................................ 3
2. Overview of HMIPv6...................................... 3
3. MIPv6 extension _ BU extensions ........................ 8
4. Neighbour Discovery extension _ MAP option message .... 10
5. MAP Discovery.......................................... 12
5.1 Receiving packets in a foreign network............ 12
5.2 MAP Operation..................................... 12
5.3 MAP Operation..................................... 14
5.4 MAP Operation..................................... 14
6. Basic mode: Supporting MNs with a Regional COA (RCOA).. 15
6.1 MN Operations..................................... 15
6.2 MAP operations ................................... 15
6.3 HA operations .................................... 16
6.4 CN operations .................................... 16
7. Extended mode: Using the MAP COA as an alternate-COA .. 17
7.1 MN Operations..................................... 18
7.2 MAP operations.................................... 19
7.3 HA operations..................................... 19
7.4 CN operations..................................... 20
8. Comparison between the two MAP modes................... 20
9. Load balacing in HMIPv6................................ 21
10. Smooth Handoffs........................................ 21
11. Location Privacy in HMIPv6............................. 21
12. Special optimisations for sending Binding Updates...... 21
13. Notes on MAP selection by the MN....................... 22
14. Security Considerations................................ 23
15. AAA Considerations for IPv6............................ 23
16. Acknowledgements....................................... 24
17. Notice Regarding Intellectual Property Rights.......... 24
Soliman, Castelluccia, El-Malki, Bellier [Page 2]
INTERNET-DRAFT HMIPv6 ****,2000
18. References............................................. 24
19. Appendix A: Future additions........................... 25
20. Authors' addresses..................................... 25
Soliman, Castelluccia, El-Malki, Bellier [Page 3]
INTERNET-DRAFT HMIPv6 ****,2000
1. Introduction
This draft introduces the concept of a Hierarchical Mobile IPv6
network, utilizing a new node called the Mobility Anchor Point (MAP).
In Mobile IPv6 there are no Foreign Agents, but there is still the
need to provide a central point to assist with MIP handoffs. Similar
to MIPv4, Mobile IPv6 can benefit from reduced mobility signalling
with external networks by employing a local 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 including the Access Router (AR).
Unlike FAs in IPv4, a MAP is not required on each subnet. Two
different MAP modes are proposed in this memo. A MN may use a MAP's
address as an alternate-care-of address (COA) (Extended mode) or form
a Regional COA (RCOA) on the MAP's subnet (Basic mode) while roaming
within a MAP domain, where such a domain involves all access routers
advertising that MAP. The two options are described in detail in
chapters 5 and 6.
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 2.
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 draft assumes the generic case of a scaleable multi-level
hierarchy.
2. Overview of HMIPv6
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 [4] 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 a radio interface. Just like MIPv6, this solution is
independent of the underlying access technology, allowing Fast
Handoffs within, or 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.
Soliman, Castelluccia, El-Malki, Bellier [Page 4]
INTERNET-DRAFT HMIPv6 ****,2000
The introduction of the MAP concept will further diminish signalling
generated by MIPv6 over a radio interface. This is due to the fact
that a MN only needs to perform one local BU (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 interact with the AAA protocol to perform key distribution
during handoffs and eliminate the need for re-authentication as
explained in chapter 11.
The MAP will receive all packets on behalf of the MN it is serving
and will encapsulate and forward them directly to the MN's current
address. If the MN changes its current address within a local MAP
domain, it only needs to register the new address with the MAP (since
the global CoA does not change).
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.
When the MN uses a RCoA, a MAP acts essentially as a local Home Agent
(HA) for the MN. A MAP domain's boundaries are defined by the Access
Routers (ARs) advertising the MAP information to the attached Mobile
Nodes. The control of a MAP's mode of operation (as an alternate-CoA
or a local HA) is left to the network administrator's discretion.
The detailed extensions to MIPv6 and operations of the different
nodes will be explained later in this document.
It should be noted that the MAP concept is simply an extension to the
MIPv6 protocol. Hence an HMIPv6-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 network.
Soliman, Castelluccia, El-Malki, Bellier [Page 5]
INTERNET-DRAFT HMIPv6 ****,2000
_______
| HA |
|_______| _______
\ | CN |
\ |_______|
\___ |
\ |
\ ____|
_\___|_
| |
| MAP |
|_______|
/ \
/ \
/ \
/ \
____/____ \_________
| | | |
| AR1/MAP | | AR2/MAP |
|_________| |_________|
| |
| |
__\/____ \/
| |
| MN |
|________|
__________________\
Movement /
Figure 1: Hierarchical MIPv6 domain
In Figure 1, 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. Although a multi-level hierarchy is
not required for a higher performance, it is possible to use multi-
level hierarchies of routers and implement the MAP functionality in
AR1 and AR2 if needed. This would be required in cases where Mobile
Routers are supported as will be explained later in chapter 7. 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 network, 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.
Soliman, Castelluccia, El-Malki, Bellier [Page 6]
INTERNET-DRAFT HMIPv6 ****,2000
A Router advertisement extension is proposed later in this document
for MAP discovery. Router Renumbering [5] is also proposed for MAP
discovery as shown below. 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 in
future. The MAP option in the router advertisement should inform the
MN about the chosen mode of operation for the MAP.
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 HMIPv6-aware then the discovery phase will fail
resulting in the MN using the MIPv6 [1] protocol for its mobility
management. On the other hand, if the MN is HMIPv6-aware it MAY
choose to use its HMIPv6 implementation. If so, the MN will first
need to register with a MAP by sending it a BU containing its Home
Address and on-link address (LCOA). In the case where the MN uses the
MAP as an alternate-COA, the Home address used in the BU is the MNs
Home Address on its home subnet. On the other hand, if the MN is
using a Regional COA (RCOA), the Home address used in the BU is the
RCOA. The MAP MUST store this information in its Binding Cache to be
able to forward packets to their final destination when received from
the different CNs or HAs.
The MN will always need to know the original sender of any received
packets. In the case where the MAP is used as an alternate-COA
(Extended mode), all packets will be tunnelled by the MAP, hence the
MN is not always able to determine whether the packets were
originally tunnelled from the Home Agent(triangular routing) or
received directly from a CN (route optimised). 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, containing its alternate-COA (MAP address or RCOA)
and the MN's Home Address as the final destination, then route
optimisation was used. Otherwise, triangular routing through the HA
was used. This check on the routing header (as opposed to the check
on the source of the tunnelled packets in [1]) can be used for both
modes of operation as well as the standard operation described in
[1].
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 1, if
the CN happens to exist on the same link as the MN, it would be more
Soliman, Castelluccia, El-Malki, Bellier [Page 7]
INTERNET-DRAFT HMIPv6 ****,2000
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 also use its current
on-link address (LCOA) as a COA. The knowledge of whether a CN's
address belongs to the same site or not is outside the scope of this
memo. However, [9] provides a mechanism for gaining this knowledge.
3. MIPv6 extension - Binding Update
This section outlines the extensions proposed to the BU option used
by the MN in MIPv6. A new flag is added: the M flag that indicates
MAP registration. 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.
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|U|L| Prefix Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Options...
+-+-+-+-+-+-+-+-+-+-+-+-
Description of extensions to the BU option:
M If set indicates a MAP registration.
L 1 bit field to request load balancing of packets
destined to the MN.
The L flag MUST NOT be set when the B flag is set. If both flags are
set, the MAP MUST reject the BU with an appropriate error code
3.1 Load Balancing sub-option
Load balancing can be a useful feature in cases where the MN is
connected to different access technologies with different
characteristics. When using the load balancing sub-option below, a MN
would be able to `move' one flow to another AR/interface while
maintaining the reception of other flows on the current interface.
requesting the load balancing service from the MAP can be decided
based on some local policies within the MN and based on the link
characteristics and the types of applications running at the time.
The Load balancing sub-option is included within the BU option. The
sub-option contains information that allows the MAP to identify a
Soliman, Castelluccia, El-Malki, Bellier [Page 8]
INTERNET-DRAFT HMIPv6 ****,2000
traffic flow and route it to a given address. Multiple sub-options
may exist within a BU. These sub-options may contain the same
destination IPv6 address or different addresses. Only one destination
address is allowed in each sub-option.
A traffic flow may be identified by using the flow label or by
combining the destination address and port number. Alternatively, a
MN may simply request per-packet load balancing without identifying a
flow label or a port number.
The message format for the Load balancing sub-option is shown below.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-Option Type| Sub-Option Len|F|P|A| Prot number |r| dest- |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| port | Flow label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sub-Option Type TBD
Sub-Option Len
F When set, indicates that the Flow label
MUST be used to identify a flow
P When set, indicates that the port number
and IP address MUST be used to identify
a flow
A When set, indicates that the destination
address only should be used for load
balancing. This implies that per-packet
load balancing is requested. This flag
MUST NOT be set when the F or P flags
are set.
Prot number A value corresponding to the protocol
number associated with the port numbers.
This field is only relevant when the P
flag is set.
Soliman, Castelluccia, El-Malki, Bellier [Page 9]
INTERNET-DRAFT HMIPv6 ****,2000
It should be noted that per-packet load balancing may have some
negative impacts on TCP congestion avoidance mechanisms as it is
desirable to maintain order between packets belonging to the same TCP
connection. This behaviour is specified in [8]. Other negative
impacts are also foreseen for other types of real time connections
due to the potential variations in RTT between packets.
Hence, a MN SHOULD NOT request per-packet load balancing when TCP
connections are active. However, the MN can still request per-flow
load balancing provided that the entire flow is moved to the new
address. The MN SHOULD be aware of the negative consequences of per-
packet filtering when requesting it.
When requesting load balancing, the MN can set the `flow identifiers'
using the F (flow label) or P (address and port number) flags. If the
A flag is set, per-packet load balancing is requested. Per-packet
load balancing can be done based on local policies in the MAP.
A MN can include several load balancing sub-options within the BU
option. For instance, an MN could move a number of connections to
another interface. In this case the MN would include a number of load
balancing sub-options, each identifying one connection.
The MN MUST NOT include conflicting sub-options. Ie. the MN MUST NOT
mix per-packet load balancing with per-flow load balancing. If a MAP
finds a request for both per-packet and per-flow load balancing, it
MUST reject the Load balancing request with an appropriate error
code.
4. Neighbour Discovery extension - The MAP option message format
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 | Distance | Pref |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Plen |R|M|T| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Global IP Address for MAP +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The alignment requirements for this option is 8n.
Soliman, Castelluccia, El-Malki, Bellier [Page 10]
INTERNET-DRAFT HMIPv6 ****,2000
Fields:
Type Message type. TBA.
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.
Distance An 8 bit unsigned integer showing the distance
from the receiver of the advertisement. It
MUST be set to one in the initial
advertisement, if dynamic MAP discovery is
used. The Distance MUST be set to one if the
MAP is on the same subnet as the MN.
Pref The preference of a MAP. An 8 bit unsigned
integer. A value of 255 means lowest
preference.
Plen The prefix length in this option. The prefix
length in this option. A prefix length value
of 128 indicates that the MAP address should
be used as an alternate-COA. A prefix length
value different from 128 indicates that the MN
should configure its RCoA using the prefix
length and the MAP address.
R Indicates that the MN MUST form a RCOA. If
this flag is set the Plen value MUST be less
than 128.
M Indicates that the MN MUST use the MAP's
Own IP address as an alternate-COA
T Indicates that the on-link prefix is
topologically incorrect. Hence the MN MUST
use the MAP's CoA to be reached. This flag
MUST only be set if the M flag was set.
Global Address One of the MAP's global addresses.
To ensure a secure communication between routers, router
advertisements, sent between routers, containing the MAP option
SHOULD be authenticated by AH. In the case where this authentication
is not possible, a network operator may prefer to manually configure
all the ARs to send the MAP option or use another MAP discovery
mechanism as shown in this document (eg. router renumbering).
Soliman, Castelluccia, El-Malki, Bellier [Page 11]
INTERNET-DRAFT HMIPv6 ****,2000
5. MAP discovery
This section describes how a MN obtains the MAP address and subnet
prefix. Two different methods for MAP discovery are defined below.
Dynamic MAP Discovery is based on propagating the MAP option from the
MAP to the MN through certain (configured) router interfaces within
the hierarchy. This would require manual configuration of the MAP and
the routers receiving the MAP option to allow them to propagate the
option on certain interfaces.
Another method based on Router Renumbering [5] is also shown below.
In this method, no manual configuration is required for routers
within the hierarchy. The MAP option is sent directly from a central
node to all ARs within a MAP domain. This method is best suited to
large networks where manually configuring all routers within a
hierarchy maybe a significantly tedious operation. On the other hand,
when using this method, any changes in the MAP option's parameters
(eg. preference) would require manual intervention.
5.1 Dynamic 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, the MAP's global IP address and
eventually the MAP's subnet prefix.
The ARs can be configured manually or automatically with this
information. In the case of automatic configuration, each MAP in the
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 "Distance" field MUST be set to
a value of one. Upon reception of a router advertisement with the MAP
option and 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 Distance field by one. If the router was also
a MAP, it SHOULD send its own option in the same advertisement.
If a router receives more than one MAP option for the same MAP, from
two different interfaces, it should choose the option with the
smaller distance field.
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.
5.2 Using Router Renumbering for MAP discovery
The Router Renumbering (RR) mechanism described in [5] defines a set
of messages that can be used to renumber certain interfaces on a
Soliman, Castelluccia, El-Malki, Bellier [Page 12]
INTERNET-DRAFT HMIPv6 ****,2000
router without manual configuration of such router. RR messages are
authenticated and protected against replay attacks. The same concept
can be used here to configure a router to propagate the MAP option on
certain interfaces.
To be able to achieve this a new PCO command, PROPAGATE, is defined.
This command is part of the Prefix Code Operation (PCO) and is
included in the Match Prefix part of the message. A PCO message sent
to a router with the PROPAGATE command MUST only contain one or more
MAP options in the Use Prefix part of the message.
Upon reception of this message, a router will propagate the MAP
option on the designated interface, after incrementing the Distance
field's value by one.
This mechanism can be used to configure AR's to advertise one or more
MAP options. This is best suited to large networks or for cases where
third party networks may exist between the MAP and ARs.
5.2.1 Extension to the Match Prefix Part of RR
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OpCode | OpLength | Ordinal | MatchLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MinLen | MaxLen | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ MatchPrefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Extended Fields:
OpCode An unsigned 8-bit field specifying the operation to be
performed when the associated MatchPrefix matches an
interface's prefix or address. Values are:
1 the ADD operation
2 the CHANGE operation
3 the SET-GLOBAL operation
4 the PROPAGATE operation (new code).
Soliman, Castelluccia, El-Malki, Bellier [Page 13]
INTERNET-DRAFT HMIPv6 ****,2000
5.3 MAP Discovery using a new destination option
For more flexibility and simplicity, a new destination option is
designed to allow a MAP to send its parameters directly to the Access
Routers it is serving. This new destination option has to be sent
periodically in order to refresh the state of the
routers. The format of this MAP destination option is described
below. It contains a type, a length and a data fields. The data field
contains the MAP option defined in Section 3.
As a result when a router receives a message with a MAP destination
option, it simply retrieves the data field and insert it in its
router advertisement.
The alignment requirement for this destination option is 8n+2.
5.4 MN Operations
When a HMIPv6-aware MN receives a router advertisement, it should
search for the MAP option. One or more options may be found for
different IP addresses or subnet prefixes.
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
over another depending on the value received in the Distance field,
provided that the preference value is below 255.
If a MN has access to several ARs simultaneously, it SHOULD use a
LCoA on the subnet defined by the AR that advertises its current MAP.
A MN SHOULD store the received option(s) and choose at least one MAP
to register with. 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 [1].
Finally if the M flag is set in the MAP option, the MN MUST register
with the MAP and inform its HA.
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.
5.5 MAP Operation for Dynamic MAP Discovery
When Dynamic MAP Discovery is used, 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
Soliman, Castelluccia, El-Malki, Bellier [Page 14]
INTERNET-DRAFT HMIPv6 ****,2000
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 or load sharing). 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 failures.
The MAP option is propagated down the hierarchy. Each router along
the path to the access router will increment the Distance field by
one. If a 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.
6. Basic Mode: Supporting Mobile Nodes with a Regional COA (RCOA)
This section defines a basic mode of HMIPv6 that is required to
support Mobile Nodes.
In the basic mode, the MN would have two addresses, a RCOA on the
MAP's subnet and an on-link COA (LCOA). This RCOA is formed in a
stateless manner by combining the MAP's subnet prefix received in the
MAP option with the MNs interface identifier.
As illustrated in this section, the basic mode is very simple in the
sense that it only requires special treatment at the Mobile Nodes.
The HA is unchanged. The MAP is merely a "local" HA that maps the
MN's RCoA to an LCoA.
6.1 MN Operations
When a MN moves into a new MAP domain (i.e. its MAP changes), it
needs to get 2 COAs:
A Regional CoA on the MAP's subnet (RCoA) and an on-link one (LCoA).
These addresses maybe formed in a stateless or stateful manner.
After forming the RCOA, the MN sends a BU to the MAP with the M flag
set. The BU specifies its RCoA in the Home Address field. No
alternate CoA sub-option is used. The LCoA is used as the source
address of the BU).
This BU will bind the MN's RCOA (similar to a Home Address) to its
LCOA. The MAP (acting as a HA) will then perform DAD for the MN's
RCOA on its subnet. If successful, the MAP will return a Binding
Acknowledgement (BAck) to the MN indicating a successful
registration. Otherwise, the MAP MUST return a BAck with the
appropriate fault code. No new error codes are needed for this
operation.
The MN MUST also register its new RCoA with its HA by sending a BU
that specifies the binding (RCoA, Home Address) as in MIPv6 (The home
address field of the BU is set to the Home Address. An alternate-CoA
sub-option is used and set to the RCoA). It can also send a similar
BU (i.e. that specifies the binding between the Home Address and the
RCoA) to its current CNs.
Soliman, Castelluccia, El-Malki, Bellier [Page 15]
INTERNET-DRAFT HMIPv6 ****,2000
The MN SHOULD wait for the BAck from the MAP before registering with
its HA. In order to speed up handoff between MAPs, a MN may send a BU
to its previous MAP specifying its new LCoA. Packets in transit that
reach the previous MAP are then forwarded to the new LCoA.
The MAP will receive packets addressed to the MN's RCOA (from the HA
or CNs). Packets will be tunnelled from the MAP to the MN's LCOA. The
MN will decapsulate the packets and process the packet in the normal
manner.
When the MN moves locally (i.e. its MAP does not change), it MUST
only register its new LCoA with its MAP. In this case, the RCoA stays
unchanged.
Note that a MN can send a BU containing its LCoA (instead of its
RCoA) with CNs who share the same link. Packets will then be routed
directly without going through the MAP.
6.2 MAP Operations
In this mode, a MAP acts exactly like a HA. It intercepts all the
packets addressed to the Mobile Nodes it serves and tunnelled them to
the corresponding LCoA.
In this scenario, a MAP would have no knowledge of the MN's Home
address. The MN will send a BU to the MAP with the M, A and D flags
set. The aim of this BU is to inform the MAP that the MN has formed a
RCOA (contained in the BU as a Home address) and request that a MAP
performs DAD on its behalf. This is identical to the HA operation in
[1]. If the operation was successful, the MAP MUST respond with a
BAck to the MN indicating a successful operation. Otherwise a BAck is
sent with the appropriate error code. No new error codes are
introduced for HMIPv6.
The MAP then acts as a proxy between the RCoA and the LCoA.
Packets addressed to the RCOA are then intercepted by the MAP, using
proxy Neighbour Advertisement, encapsulated and routed to the MN
position (LCoA).
6.3 HA Operations
The support of basic mode in HMIPv6 is completely transparent to the
HA operation. Packets addressed to a MN's Home Address will be
forwarded by the HA to its RCoA as described in [1].
6.4 CN Operations
Both HMIPv6 modes are completely transparent to CNs.
Soliman, Castelluccia, El-Malki, Bellier [Page 16]
INTERNET-DRAFT HMIPv6 ****,2000
7. Extended mode: Supporting Mobile Nodes and Mobile Networks
The Extended mode of operation can support both Mobile Nodes and
Mobile networks.
In some mobility scenarios it may not be possible for a MN to get a
RCOA on the MAP's subnet. One example for these scenarios is shown in
this chapter. However, network operators may have other reasons for
choosing this HMIPv6 mode of operation. A comparison between the two
modes of operation will be shown below.
In the case where a MN is also a router to which several MN's may be
connected (eg. a Personal Area Network), it would not be possible for
such router to obtain a new network prefix within a visited network.
Hence, MNs connected to such router will end up with topologically
incorrect addresses. By having the Mobile Router (MR) act as a MAP
within the visited network, MNs connected to it may use its CoA as an
alternate-COA when registering with their HA and other CNs.
Hence, maintaining the IPv6 powerful aggregation of routes within the
backbone, while receiving route-optimised packets sent to the MNs
attached to the Mobile Router (MAP).
In this case the MAP option will be advertised by the MR (being the
AR) that the MN is connected to. The MN MUST send a BU to the HA and
CNs including the MAP's address as an alternate-COA. Hence all
packets addressed to 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 Home Address contained in the MAP registration MUST be the same
Home Address sent in the Home Agent registration. If a MN sends
different BUs for different Home Addresses (in the case it has
multiple Home Addresses), the same process MUST be performed first
for the MAP registrations. This is essential to allow a MAP to
forward packets to the right MN when they are tunnelled from the HA.
The MN SHOULD also have a prefix length of zero in its BUs to the HA.
This would stop the HA from being proxy for other unregistered Home
addresses.
The MAP will need 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 global 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), of which the MAP would have no knowledge, the HA SHOULD add a
routing header to the outer packet. This routing header MUST use one
of the MN's registered 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).
Soliman, Castelluccia, El-Malki, Bellier [Page 17]
INTERNET-DRAFT HMIPv6 ****,2000
7.1 MN Operations
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 flag SHOULD be set and the M flag
(see section 4.5) MUST be set in the BU. The H flag MUST NOT be set
when registering with a MAP. A MN SHOULD 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 its Alternate-COA, to CNs and its HA. The MAP's IP
address or RCOA MUST be included in the Alternate-COA sub-option.
The MN SHOULD send a separate home registration BU for each home
address, with the prefix length value set to zero. 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.
If the MN is connected to a Mobile Router (MR) which also acts as a
MAP. When the MR moves to another AR, it will advertise a new MAP
option (its own) as well as others belonging to higher MAPs in the
hierarchy. To be able to receive route optimised packets, the MN
SHOULD send a BU to the further MAP to bind its Home address to the
MR's (on link MAP) CoA. This would cause all packets sent to the MN
to be forwarded to the MR which in turn will forward them to the MN.
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 HMIPv6's
Extended mode, all packets received from a CN will be tunnelled by
the MAP to the MN regardless of whether they were routed via the HA
or directly to the MAP.
When using the MAP's address as a CoA, packets tunnelled by the HA
to the MAP will be decapsulated and then encapsulated again with the
MAP's address as the source address of the outer header. Therefore a
check on whether the packet was tunnelled by the HA will not be
sufficient to decide whether route optimisation is required.
Hence, 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. It should
be noted that such check is generic and would apply to all use cases
of MIPv6 including the different MAP modes of operation in this memo.
Soliman, Castelluccia, El-Malki, Bellier [Page 18]
INTERNET-DRAFT HMIPv6 ****,2000
Hence, this check need not be an additional implementation for this
mode of operation and can be the only check in an implementation to
determine whether a BU should be sent to CN.
7.2 HA Operations
If the MN uses a MAP address, the Home Agent operations are affected
in a minor way.
The only impact due to this HMIPv6 mode 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 SHOULD 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 Home addresses for
which it received no BUs from the MN.
7.3 MAP Operations
The MAP operation is in many ways similar to the HA operation
described in [1] 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 process the
BU and if successful, add the information to its Binding Cache.
The BU from the MN will contain its LCOA as a source address and its
Home address. A MAP MUST first check if the MN is authorised to use
the MAP in this mode. If so, the MAP SHOULD process the BU in the
normal manner.
If the A flag was set, the MAP MUST send a BAck to the MN.
All packets directed to the MN will be received by the MAP and
tunnelled to the MN. Upon reception of an encapsulated packet, from a
MN's HA, 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 received encapsulated packet contains a routing header, the
MAP MUST process the routing header in the normal way. After
procesing the routing header, the MAP MUST check whether the final
destination corresponds to an entry in its binding cache. If it does,
the MAP MUST tunnel the packet to the MN's current address (LCoA).
When a packet containing a routing header is received (from a CN) the
routing header is processed as usual and the packet is then
encapsulated to the MN.
Soliman, Castelluccia, El-Malki, Bellier [Page 19]
INTERNET-DRAFT HMIPv6 ****,2000
If the MAP is an MR with one or more MNs connected on one interface,
and an AR on the other interface. When changing ARs, the MAP MUST
advertise its own MAP option as well as other MAP options received
from the AR. The MR's MAP option would contain its own LCoA. This
would allow the MNs to obtain a new topologically correct RCoA and
update the higher MAP in the hierarchy.
7.4 CN Operations
In this mode, HMIPv6 is transparent to CNs.
8. Comparison between the HMIPv6 modes of operation
In this memo two different modes of operation are defined for HMIPv6
depending on the MN's choice of its COA when located in a foreign
network. As shown above the selection of the mode of operation is
done based on the information sent in the MAP option. Such
information MUST be configurable by the network administrator. Hence
some administrators may allow a MN to only obtain a RCOA or use the
MAP's address as an alternate-COA. To simplify MN and MAP
implementations, only one mode is used by the MAP at a time.
The use of RCOA is very simple as it is completely independant of the
HA's implementation. intercepted by the MAP (using a HA
implementation) and encapsulated again to the MN. On the other hand,
if the MAP's COA is used, the MAP will decapsulate the packets and
then encapsulate them again to the MN.
Hence, in the latter case, only one additional IPv6 header is needed
as opposed to two headers in the former. If an appropriate header
compression mechanism is used, this may not be an issue. However, if
no header compression is used, it maybe more efficient for the MN to
use the MAP's COA as an alternate-COA.
Another aspect of the comparison, is the Duplicate Address Detection
(DAD) required when performing the initial registration with the MAP.
If a RCOA is used, the MAP MUST perform DAD for that address. On the
other hand, if the MAP address is used as an alternate-COA, there
will be no need to perform DAD as the BU sent to the MAP will bind
the MN's home address to the LCOA. Since no DAD for the LCOA or the
Alternate-COA (being the MAP's address) is required by the MAP, the
registration can be faster when using the MAP address as an
alternate-COA. This aspect of the comparison may not be relevant if
no inter-MAP handoffs are expected when roaming within the visited
network (ie. one MAP domain in the visited network). However, if
inter-MAP handoffs are expected, the time taken to perform DAD by the
MAP may become significant.
In the case where RCOA is used, to avoid DAD delays during inter-MAP
mobility, the MN MAY register its new LCoA with its previous MAP.
Packets will be redirected from the previous MAP to the new LCoA
Soliman, Castelluccia, El-Malki, Bellier [Page 20]
INTERNET-DRAFT HMIPv6 ****,2000
while DAD is performed. In this scenario the time taken to perform
DAD by the MAP in the RCOA mode might be not be an issue.
9. Load balancing in HMIPv6
In some cases, a MN may be connected to more than one link
simultaneously. A MAP domain may cover one or more Access
technologies connected to different ARs. Different links may have
different properties like bandwidth availability, Quality of Service
and reliability. Different applications maybe better suited to
certain types of links. Hence, a MN may prefer to move some
connections to one link while keeping the rest connected to the same
link. To achieve this, the MN needs to send the necessary information
required to identify a connection. This information is included in
the Load-balancing sub-option shown in ch 3.1. Load balancing may be
done on a per-connection or per-packet basis. In the case of load
balancing on per packet basis, the ratio of packets sent to each link
to the total number of packets received by the MN is left to local
policies defined in the MAP. It is important to note that per-packet
load balancing may have some negative effects on some connections,
causing packets to be delivered out of order. Other impacts on TCP
are mentioned earlier in this memo. Hence, generally, per-packet load
balancing in not recommended unless the MN is certain that no
negative impacts on connections will occur.
10. Smooth Handoff
A MAP should be able to handle smooth handoffs. When a mobile host
moves into a new MAP domain, the MN should send a BU to the previous
MAP requesting to forward packets addressed to the MN's new CoA. This
is similar to the smooth handoff mechanism of Mobile IPv6.
11. Location privacy in HMIPv6
HMIPv6 (basic mode) provides users with the ability to hide their
exact location. This is done by providing the users with a `local'
Home address while roaming within a MAP domain. A MN MAY choose to
show the RCoA to the application. By using the provided RCoA, an
application would be able to hide its exact location (subnet) from
other nodes on the Internet.
Providing the RCoA to the application is an implementation dependant
issue and can be provided by API implementors.
When using Extended mode, the MN MUST NOT provide the RCoA (MAP's
address) to the applications.
12. Special optimisations for sending BUs
In some link layers that require some L2 signalling before sending
each frame, it maybe useful for MNs to encapsulate the BU sent to the
HA inside the BU sent to the MAP. The decision on whether this
Soliman, Castelluccia, El-Malki, Bellier [Page 21]
INTERNET-DRAFT HMIPv6 ****,2000
optimisation should be used or not is left up to the implementation,
depending on the type of underlying L2 used for transmission.
It should be noted however, that the use of such encapsulation may
cause extra signalling in case the Home registration was rejected by
the HA (eg. if DAD failed and the MN s required to provide a new Home
address).
13. Notes on MAP selection by the MN
HMIPv6 provides a very flexible mechanism for local mobility
management within a visited network. As explained earlier a MAP can
exist on any level in a hierarchy including the AR. Several MAPs can
be located within a hierarchy independantly of each other. In
addition, overlapping MAP domains are also allowed and recommended.
Both static and dynamic hierarchies are supported for either mode of
operation. Hence the discussion below is independant of the MAP's
mode of operation.
When the MN receives a router Advertisement including a MAP option,
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 SHOULD be:
- "Eager" to perform new bindings
- "Lazy" in releasing existing bindings
The above means that the MN will should register any "new" MAP
advertised by the AR (Eager).
The method by which the MN determines whether the MAP is a "new" MAP
is described above. The MN should not release existing
bindings until it no longer receives its MAP option or the lifetime
of its existing binding expires (Lazy).
This Eager-Lazy approach described above will assist in providing a
fallback mechanism in case one of the MAP routers crash as it would
reduce the time it takes for a MN to inform its CNs and HA about its
new COA.
13.1 MAP selection in a static multi-level hierarchy
For a MN to select one or more MAPs in a static multi-level
hierarchy, in an optimised manner, several factors need to be
considered.
Except for the case of a Mobile network connected via an MR to an AR,
there are no benefits foreseen in selecting more than one MAP and
forcing packets to be sent from the higher MAP down through a
hierarchy of MAPs. This approach may add delays and elimiate the
robustness of IP routing between the highest MAP and the MN. Hence,
allowing more than one MAP (above the AR) within a network should
imply that the MN forces packets to be routed down the hierarchy of
Soliman, Castelluccia, El-Malki, Bellier [Page 22]
INTERNET-DRAFT HMIPv6 ****,2000
MAPs. However, placing more than one MAP above the AR can be used for
redundancy and as an optimisation for the different mobility
scenarios experienced by MNs.
In terms of the Distance based selection in a multi-level hierarchy,
a MN may choose to register with the furthest MAP to avoid frequent
re-registrations. This is particularly important for fast MNs that
will perform frequent handoffs. In this scenario, the choice of a
further MAP would reduce the probability of having to change a MAP
and informing all CNs and the HA.
In the case of Mobile networks, connected via an MR to another
network, MNs should bind their MR's CoA (advertised in the MR's MAP
option) to their Home addresses. For example, in this case the MN may
receive two MAP options, one including the MR's address and another
for a MAP further away in the hierarchy of routers (MAP2). The MN
should then send a BU to MAP2 binding its Home address to the MR.
13.2 MAP selection in a flat mobility management architecture
Network operators may choose a flat architecture in some cases where
a MIP handoff may be considered a rare event. In these scenarios
operators may choose to include the MAP function in ARs only. The
inclusion of the MAP function in ARs can still be quite useful to
reduce the time required to update all CNs and the HA. In this
scenario, a MN may choose a MAP (in the AR) as an anchor point when
performing a handoff. This kind of dynamic hierarchy (or anchor
chaining) is only recommended for cases where inter-AR movement is
not frequent.
14. Security considerations
HMIPv6 does not introduce more security problems than Mobile
IPv6.
A mobile host has to register with its HA and with the Mobility
Anchor Point. All BUs between the MN and the MAP have to be
authenticated as per MIPv6. This means that the mobile host
has to share an authentication key (private or public) with all
MAPs it may visit. These keys can be pre-installed manually or
obtained dynamically via IKE or AAA servers.
The Security association establishment between the MN and the MAP
MUST be based on the Home address when using the extended mode, and
the RCOA when using the basic mode.
15. 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
Soliman, Castelluccia, El-Malki, Bellier [Page 23]
INTERNET-DRAFT HMIPv6 ****,2000
keys only to certain nodes in the network.
One example of the interaction between a MAP and the AAA
infrastructure can be seen when considering the handoff scenario. A
MAP can store the MN's security credentials after the MN is allowed
network access by the AAA infrastructure. During an intra-domain
handoff, the MAP could pass the MN's security credentials to the
"new" AR to avoid performing the AAA process. These credentials
depend on the access enforcement policies in AAAv6 and will not be
covered by this draft. Similarly, the protocol used to transfer such
credentials is outside the scope of this draft.
16. Acknowledgements
The authors would like to thank Conny Larsson (Ericsson) and Mattias
Pettersson (Ericsson) for their valuable input to this draft.
The authors from INRIA would also like to thank the members of the
French RNRT MobiSecV6 project (BULL, France Telecom and INRIA) for
testing our implementation and for their valuable feedback. They
would also like to thank the French Governement for partially funding
this project.
In addition, the authors would like to thank the following members of
the working group in alphabetical order: Samita Chakrabarti (Sun),
Gopal Dommety (Cisco), Eva Gustaffson (Ericsson), Dave Johnson (Rice
University), Annika Jonsson (Ericsson), James Kempf (Sun), Fergal
Ladley, Erik Nordmark (Sun), Basavaraj Patil (Nokia) and Alper Yegin
(Sun) for their comments on the draft.
17. Notice Regarding Intellectual Property Rights
see http://www.ietf.org/ietf/IPR/ERICSSON-General
18. References
[1] D. Johnson and C. Perkins, "Mobility Support in IPv6",
draft-ietf-mobileip-ipv6-12.txt, February 2000.
[2] E. Gustafsson et al, "Mobile IP Regional Tunnel Management",
draft-ietf-mobileip-reg-tunnel-03.txt
(work in progress), March 2000.
[3] K. ElMalki, Editor, "Low latency Handoffs in Mobile IPv4".
draft-ietf-mobileip-lowlatency-handoffs-v4-00.txt, work in
progress.
[4] G. Tsirtsis, Editor, "Fast Handovers for Mobile IPv6", draft-
ietf-mobileip-fast-mipv6-00.txt, work in progress.
[5] M. Crawford _Router Renumbering for IPv6_. RFC 2984.
Soliman, Castelluccia, El-Malki, Bellier [Page 24]
INTERNET-DRAFT HMIPv6 ****,2000
[6] S. Thomson and T. Narten "IPv6 Stateless Address
Autoconfiguration". RFC 2462.
[7] T. Narten, E. Nordmark and W. Simpson _ Neighbour Discovery for
IP version 6 _. RFC 2461.
[8] D. Awduche et al, _Requirements for traffic engineering over
MPLS_. RFC 2702.
[9] E. Nordmark, _Site prefixes in Neigbour Disocvery_.
draft-ietf-ipng-site-prefixes-05.txt. Work in progress.
19. Appendix A: Planned additions to future revisions
In addition to the existing proposal, the following sections are
planned for future revisions:
- quick discovery of MAP failures will be essential for the
reliability of this mechanism. Some suggestions for handling these
scenarios will be included in future revisions.
- Detailed notes for implementors will also be added.
- Add the necessary error codes for the BAck, due to the introduction
of the MAP.
20. Authors' Addresses
The working group can be contacted via the current chairs:
Basavaraj Patil Phil Roberts
Nokia Corporation Motorola M/S M8-540
6000 Connection Drive 1501 West Shure Drive
Irving, TX 75039 Arlington Heights, IL 60004
USA USA
Phone: +1 972-894-6709 Phone: +1 847-632-3148
EMail: Raj.Patil@nokia.com EMail: QA3445@email.mot.com
Fax : +1 972-894-5349
Questions about this memo can also be directed to:
Hesham Soliman
Ericsson Radio Systems AB
Torshamnsgatan 29,
Kista, Stockholm 16480
Sweden
Phone: +46 8 7578162
Fax: +46 8 4043630
Soliman, Castelluccia, El-Malki, Bellier [Page 25]
INTERNET-DRAFT HMIPv6 ****,2000
E-mail: Hesham.Soliman@era.ericsson.se
Claude Castelluccia
INRIA Rhone-Alpes
655 avenue de l'Europe
38330 Montbonnot Saint-Martin
France
email: claude.castelluccia@inria.fr
phone: +33 4 76 61 52 15
fax: +33 4 76 61 52 52
Karim El Malki
Ericsson Radio Systems AB
LM Ericssons Vag. 8
126 25 Stockholm
SWEDEN
Phone: +46 8 7195803
Fax: +46 8 7190170
E-mail: Karim.El-Malki@era.ericsson.se
Ludovic Bellier
INRIA Rhone-Alpes
655 avenue de l'Europe
38330 Montbonnot Saint-Martin
France
email: ludovic.bellier@inria.fr
phone: +33 4 76 61 52 15
fax: +33 4 76 61 52 52
Soliman, Castelluccia, El-Malki, Bellier [Page 26]
| PAFTECH AB 2003-2026 | 2026-04-21 09:39:41 |