[Search] [pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
Network Working Group                           Hesham Soliman, Ericsson
INTERNET-DRAFT                                 Claude Castellucia, INRIA
Expires: February 2001                          Karim El-Malki, Ericsson
                                                  Ludovic Bellier, INRIA
                                                         September, 2000






                 Hierarchical MIPv6 mobility management
                  <draft-soliman-mobileip-hmipv6-01.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.
   Distribution of this memo is unlimited.
   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, Casteluccia, El-Malki, Bellier                         [Page 1]


INTERNET-DRAFT                   HMIPv6                        ****,2000



   TABLE OF CONTENTS


      1.   Introduction.............................................3

      3.   Hierarchical Mobility Management using MIPv6.............5

      4.   Overview of the MIPv6 Hierarchical Mobility Management...6

      5.   Neighbour Discovery extension - MAP discovery............9

      6.   MIPV6 extensions - Sending Binding Updates..............10

      7.   MN Operation............................................11
      7.1  MAP Discovery...........................................11
      7.2  Sending Binding Updates.................................12
      7.3  Receiving packets in a foreign network..................12
      7.4  Fast Handoff scenario...................................13

      8.   MAP Operation...........................................14
      8.1  MAP Discovery..................................._.......14
      8.2  Receiving and forwarding Packets for a MN...............14
      8.3  Fast handoff scenario...................................15

      9.   HA Operation............................................15

      10.  AAA Considerations for IPv6.............................16

      11.  Acknowledgements........................................16

      12.  Notice Regarding Intellectual Property Rights...........16

      13.  References..............................................17

      14.  Authors' addresses......................................17


















Soliman, Casteluccia, El-Malki, Bellier                         [Page 2]


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.
   Similarly to MIPv4, 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 including the Access
   Router (AR). Unlike FAs in IPv4, a MAP is not required on each
   subnet. Two different options are proposed in this memo for the use
   of a MAP. A MN may use the MAP as an alternate-care-of address (COA)
   or form a Regional COA (RCOA) on the MAP's subnet while roaming
   within a hierarchical (MAP) domain, where such a domain involves all
   access routers advertising that MAP. The two options are described in
   detail in chapters 4.1 and 4.2.

   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 3.

   This draft assumes the generic case of scaleable multi-level
   Hierarchical Mobile IP (HMIP) networks and is therefore applicable to
   HMIP networks in general. Hierarchical MIPv6 (HMIPv6)can assist with
   speeding up MIP Handoffs, hence offering advantages which are
   especially important for the support of real-time services.

3. 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 [5] 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




Soliman, Casteluccia, El-Malki, Bellier                         [Page 3]


INTERNET-DRAFT                   HMIPv6                        ****,2000


   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.

   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 interact with the AAA protocol to perform
   key distribution during handoffs and eliminate the need for re-
   authentication as explained in ch 10.


4. 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 may be used by a MN as an alternate-COA [1] while roaming
   within a certain MAP domain. Alternatively, the MN MAY choose to use
   a Regional Care of Address (RCOA) on the MAP's subnet as its own COA
   while roaming within a MAP's domain. In the latter case, 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.

   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
   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 explained in [5].

   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



Soliman, Casteluccia, El-Malki, Bellier                         [Page 4]


INTERNET-DRAFT                   HMIPv6                        ****,2000


   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   |
                \          |_______|
                 \___          |
                     \         |
                      \    ____|
                      _\___|_
                     |       |
                     |  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. 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.



Soliman, Casteluccia, El-Malki, Bellier                         [Page 5]


INTERNET-DRAFT                   HMIPv6                        ****,2000


   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 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 MAP-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 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. 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
   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. 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, containng 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.

   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
   efficient to use the first hop MAP (in this case assume it is AR1)



Soliman, Casteluccia, El-Malki, Bellier                         [Page 6]


INTERNET-DRAFT                   HMIPv6                        ****,2000


   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.


4.1 Using a MAP's address as a COA

   Using a MAP as an alternate-COA may be a useful tool for some
   mobility scenarios. 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
   act as a MAP within the visited network, MNs connected to it may use
   it as an alternate-COA when registering with their HA and other CNs.
   Hence, maintaining the IPv6 powerful aggregation of routes witihn the
   backbone.

   In this case the MAP option will be advertised by the AR that the MN
   is connected to. The MN SHOULD 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 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 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 MUST 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).

4.2 Using a Regional COA (RCOA) on a MAP's subnet





Soliman, Casteluccia, El-Malki, Bellier                         [Page 7]


INTERNET-DRAFT                   HMIPv6                        ****,2000


   In this scenario, 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.

   After forming the RCOA, the MN sends a BU to the MAP. The BU will
   bind the RCOA (similar to a Home Address) to its LCOA. The BU MUST
   have both the A and D flags set. 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 Acknowlegement (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 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.

5. Neighbour Discovery extension - 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 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
   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, 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. 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     |  Distance     |  Pref         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Plen      |R|M|              Reserved                     |



Soliman, Casteluccia, El-Malki, Bellier                         [Page 8]


INTERNET-DRAFT                   HMIPv6                        ****,2000


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Valid Lifetime                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +           Prefix / Global IP Address for MAP                  +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The alignment requirements for this option is 8n.

      Fields:

          Type            Message type. To be assigned.

          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.

          Pref            The preference of this MAP. An 8 bit unsigned
                          integer. A value of 255 means lowest
                          preference.

          Plen            The prefix length in this option. A prefix
                          length value of 128 indicates that the MAP
                          option contians the MAP's IP address.

          R               Indicates that the MN MUST form a RCOA

          M               Indicates that the MN MUST use the MAP's
                          Own IP address as an alternate-COA

          Global Address  One of the MAP's global addresses.

   To ensure a secure communication between routers, router
   advertisements 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.




Soliman, Casteluccia, El-Malki, Bellier                         [Page 9]


INTERNET-DRAFT                   HMIPv6                        ****,2000




6. MIPV6 extensions - Sending Binding Updates

   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| Res | Prefix Length |        Sequence Number        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            Lifetime                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Sub-Options...
    +-+-+-+-+-+-+-+-+-+-+-+-

    Description of extensions to the BU option:

        M              If set indicates a MAP registration.

        Res            3 bit reserved field


7. 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 [1] applies.

7.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 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
   than another depending on the value received in the Distance field,
   as long as the preference value is below 255.

   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.



Soliman, Casteluccia, El-Malki, Bellier                        [Page 10]


INTERNET-DRAFT                   HMIPv6                        ****,2000



   If no MAP options are found in the router advertisement, the MN MUST
   use the MIPv6 protocol as specified in [1]. If the MN receives a
   duplicated MAP option ( having the same IP address or prefix) with
   different preference values or Distance values, the MAP IP address
   SHOULD not be used as an Alternate-COA in any BU's sent by the MN.

   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.

7.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 regional registration by sending a BU
   to the MAP with the appropriate flags set. The contents of the BU
   will depend on the MAP's mode of operation.
   When registering with a MAP, the A flag SHOULD be set and the M flag
   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 or a RCOA from the MAP's
   subnet as an alternate COA in its BUs.

   After successfully performing registration with a MAP, a MN can start
   sending BUs, with it's  Alternate-COA,to CNs and its HA. The MAP's IP
   address or RCOA MUST be included in the Alternate-COA sub-option.

   If the MN uses a MAP's address as an alternate-COA, then 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.

7.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 HMIPv6,
   all packets received from a CN will be tunnelled by the MAP to the
   MN.

   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.



Soliman, Casteluccia, El-Malki, Bellier                        [Page 11]


INTERNET-DRAFT                   HMIPv6                        ****,2000



   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 generic 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 work for all
   the various use cases of MIPv6 including the different MAP modes of
   operation in this memo.

8. MAP Operation

8.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 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. 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.

8.2 Receiving and forwarding Packets for a MN

   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 MAP will need to determine how it should act based on the
   information given in the BU. Two different modes of operation are
   described below.


8.2.1 Using a MAP's address as a COA





Soliman, Casteluccia, El-Malki, Bellier                        [Page 12]


INTERNET-DRAFT                   HMIPv6                        ****,2000


   In this scenario, 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 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.

8.2.2 Using a RCOA on the MAP's subnet

   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.

8.3 The MAP as a Mobile Router (MR)

   In the case where a Mobile Router (MR) is located in a foreign
   network, the MR will not be able to obtain a new network prefix for
   the MNs attached to it. Hence, the MR MUST act as a MAP and advertise
   the MAP option to the MNs attached to it. The MAP option MUST have
   the M flag set to ensure that the MNs register with it. This will
   allow the MNs to be reachable without advertising host specific
   routes to other routers within the network. This approach maintains
   IPv6 route aggregation and ensures that no additional routing table
   entries are required due to the MR's network mobility.

9. HA Operation

   The Home Agent operations are affected in a minor way by the
   introduction of the MAP. The only impact due to HMIPv6 on the HA
   implementation is that when tunnelling packets to the MN with
   destination addresses other than the addresses registered by the MN



Soliman, Casteluccia, El-Malki, Bellier                        [Page 13]


INTERNET-DRAFT                   HMIPv6                        ****,2000


   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.


10. 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.

   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 secrity 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.

11. Acknowledgements

   The authors would like to thank Conny Larsson (Ericsson) and Mattias
   Pettersson (Ericsson) for their valuable input to this draft.
   In addition, the authors would like to thank the following members of
   the working group in alphabetical order: Eva Gustaffson (Ericsson),
   Dave Johnson (Rice University), Annika Jonsson (Ericsson), Fergal
   Ladley (Ericsson) and Erik Nordmark (Sun) for their comments on the
   draft.

12. 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 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.

13. References

   [1]   D. Johnson and C. Perkins, "Mobility Support in IPv6",
         draft-ietf-mobileip-ipv6-12.txt, February 2000.




Soliman, Casteluccia, El-Malki, Bellier                        [Page 14]


INTERNET-DRAFT                   HMIPv6                        ****,2000


   [2]   E. Gustafsson, A. Jonsson and C. Perkins, " Mobile IP Regional
         Tunnel Management ", draft-ietf-mobileip-reg-tunnel-02.txt
         (work in progress), March 2000.

   [3]   C. Perkins, Editor. "IP Mobility Support", RFC 2002, October
         1996.

   [4]   K. El Malki and H. Soliman " Fast Handoffs in Mobile IPv4".
         (work in progress)

   [5]   K. El Malki and H. Soliman " Fast Handoffs in Mobile IPv6".
         draft-elmalki-handoffsv6-00.txt (work in progress)

14. Appendix A: Planned additions to future revisions

   In addition to the existing proposal, the following sections are
   planned for future revisions:

   - MAP discovery. Other ways for dynamic MAP discovery are being
   investigated. The reuse of Router renumbering has been suggested and
   if suited, it may be included in the next revision.

   - 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.

15. 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 Australia
         61 Rigall St., Broadmeadows
         Melbourne, Victoria 3047
         AUSTRALIA



Soliman, Casteluccia, El-Malki, Bellier                        [Page 15]


INTERNET-DRAFT                   HMIPv6                        ****,2000



         Phone:  +61 3 93012049
         Fax:    +61 3 93014280
         E-mail: Hesham.Soliman@ericsson.com.au

         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
         Access Networks Research
         SE-164 80 Stockholm
         SWEDEN

         Phone:  +46 8 7573561
         Fax:    +46 8 7575720
         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, Casteluccia, El-Malki, Bellier                        [Page 16]