Subject: [MOBILE-IP] New I-D: draft-yegin-mobileip-nrouting-00.txt

From: Alper Yegin <[email-masked]>
Date: Tue, 26 Sep 2000 10:57:53 -0700

Hello,

We submitted a new draft to IETF yesterday. Before it goes through the IETF
editors queue, here's a copy.

   Title        : Mobile IPv6 Neighborhood Routing for Fast Handoff
   Authors      : A. Yegin, M. Parthasarathy, C. Williams
   Filename     : draft-yegin-mobileip-nrouting-00.txt
   Pages        : 15
   Date         : September 25, 2000

Abstract

   The Mobile IP working group is currently examining proposals to
   assist in minimizing the latency and packet loss due to handoffs
   when a Mobile IPv6 node moves from one point of attachment to
   another.  One of the desires to reduce this latency and packet loss
   is a result of the strict requirements of real-time network
   services.  This proposal specifies a solution whereby the mobile
   node sends a binding update with multiple care-of-addresses which
   match the current link and other links that the mobile node may
   possibly visit next. After receiving such a binding update, the
   correspondent nodes and home agent use a new routing header
   extension to route the packet that will be received by the mobile
   node at one of the possible care-of-addresses. Thus, the
   correspondent nodes and home agent can still communicate with
   the mobile node despite not knowing its exact location while the
   mobile node moves across links. The proposal presents no new
   networking entities and the resulting architecture describes a
   natural extension to the Mobile IPv6 protocol.

Alper Yegin
Internet Engineering
Sun Microsystems, Inc.

Mobile IP Working Group                                 Alper E. Yegin
Internet Draft                                     Mohan Parthasarathy
Category: Standards Track                                Carl Williams
Expires: March, 2001                                  Sun Microsystems
                                                       September, 2000

         Mobile IPv6 Neighborhood Routing for Fast Handoff
                draft-yegin-mobileip-nrouting-00.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   The Mobile IP working group is currently examining proposals to
   assist in minimizing the latency and packet loss due to handoffs
   when a Mobile IPv6 node moves from one point of attachment to
   another.  One of the desires to reduce this latency and packet loss
   is a result of the strict requirements of real-time network
   services.  This proposal specifies a solution whereby the mobile
   node sends a binding update with multiple care-of-addresses which
   match the current link and other links that the mobile node may
   possibly visit next. After receiving such a binding update, the
   correspondent nodes and home agent use a new routing header
   extension to route the packet that will be received by the mobile
   node at one of the possible care-of-addresses. Thus, the
   correspondent nodes and home agent can still communicate with
   the mobile node despite not knowing its exact location while the
   mobile node moves across links. The proposal presents no new
   networking entities and the resulting architecture describes a
   natural extension to the Mobile IPv6 protocol.

Yegin, Parthasarathy, Williams     Expires 25 March 2001        Page 1

Internet Draft          Neighborhood Routing         25 September 2000

Contents

   Status of this Memo                                          1

   Abstract                                                     1

   1. Introduction                                              3

   2. Terminology                                               3

   3. Protocol Operation                                        4
       3.1. Access Router Sending Router Advertisements  . . .  4
       3.2. MN Processing  . . . . . . . . . . . . . . . . . .  5
       3.3. CN Processing  . . . . . . . . . . . . . . . . . .  5
       3.4. Access Router Processing Data Packets  . . . . . .  6
       3.5. Home Agent Processing  . . . . . . . . . . . . . .  6
       3.6. Other Details  . . . . . . . . . . . . . . . . . .  6

   4. New Requirements for IPv6 Nodes                           7
       4.1. Access Routers . . . . . . . . . . . . . . . . . .  7
       4.2. Mobile Node  . . . . . . . . . . . . . . . . . . .  7
       4.3. Correspondent Nodes  . . . . . . . . . . . . . . .  8
       4.4. Home Agent . . . . . . . . . . . . . . . . . . . .  8

   5. Protocol Extensions                                       9
       5.1. Router Advertisement . . . . . . . . . . . . . . .  9
       5.2. Binding Update . . . . . . . . . . . . . . . . . . 10
       5.3. New Routing Header . . . . . . . . . . . . . . . . 10

   6. Security Considerations                                  14

   7. Conclusion                                               14

   References                                                  15

   Author's Addresses                                          15

Yegin, Parthasarathy, Williams     Expires 25 March 2001        Page 2

Internet Draft          Neighborhood Routing         25 September 2000

1. Introduction

   MIPv6 draft [1] describes how a MN should send a BU after moving to
   a new link. When MN is attached to a new link, it configures a new
   CoA and sends BUs to CNs and HA. Although this would establish
   "connectivity" as soon as BUs are received by CNs and HA, this
   method doesn't produce acceptable results for communications that
   require certain characteristics, such as minimum latency and packet
   loss . During the time between when MN detaches from old link and
   the time when BUs are received, MN is "unreachable". All the packets
   in flight during this period end up at the old link and get dropped.

   The unreachability problem is due to the lack of knowledge at the
   CNs and HA about the possible movement of the MN. By the time
   binding update reaches the CNs and HA, all packets that were sent to
   the old location of the mobile node are lost. If the MN had provided
   the information about its neighborhood and if the packet can be
   routed in that neighborhood, then MN will always be reachable. The
   "neighborhood" is an area in which the MN may visit in the immediate
   future. It consists of the known current link and a number of
   possible other links that the MN might move to next. With this
   information the CNs and HA will send packets to the "neighborhood"
   for the MN. Since the MN will be in the "neighborhood" even after
   detaching from the old link, packets will be delivered successfully.

   Layer 2 (L2) of access router (AR) can figure out a list of possible
   next links that MN might visit in the immediate future, by using the
   layout of ARs in the domain and measurements (e.g. direction of MN),
   and applying some heuristics. When AR communicates this information
   to MN, MN can send an extended BU to CNs and HA, telling them about
   its neighborhood. So with this extended information CNs and HA can
   send packets to this neighborhood, which tries to reach the MN at
   the known current link first, and then at the other links in the
   neighborhood. Packets can be routed to multiple links using a new
   routing header described later in this document.

   In this manner, MN can notify CNs and HA where it is now and where
   else it might be in the immediate future. Instead of "reactively"
   updating the system to establish connectivity as soon as MN moves,
   this protocol "proactively" informs CNs and HA to cover MN's
   possible movements, and refine in time. And although no other entity
   keeps track of instant movements of MN, it stays reachable.

2. Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [2].

   Basic Mobile IPv6 terminology is used as defined in [1].

Yegin, Parthasarathy, Williams     Expires 25 March 2001        Page 3

Internet Draft          Neighborhood Routing         25 September 2000

   Additionally, the following terminology is used in this draft:

   Access Router (AR)
        The closest router to the mobile node in the visited domain
        that the mobile node uses to access the network [3].

   Neighborhood
        The ordered list of links which includes the link that MN is
        currently attached to and a number of other links that MN may
        visit in the immediate future. Since MN may visit links that
        are more than one hop away, other links in the neighborhood
        don't have to be adjacent to current link of attachment.
        Neighborhood is determined by the L2 of access router MN is
        currently attached to.

   Current Care-of-Address
        Care-of-Address configured using the prefix of the link that
        MN is currently attached to.

   Possible Next Link (pn-link)
        Any of the links in a neighborhood other than the one that MN
        is currently attached to.

   Possible Next Prefix (pn-prefix)
        Prefix of one of the pn-links.

   Possible Next Care-of-Address (pn-CoA)
        Care-of-Address configured using one of the pn-prefixes.

3. Protocol Operation

   This section describes how this proposed protocol works. It uses an
   example where MN is moving through a series of links: link1, link2,
   link3, etc. link1 is attached to AR1, and uses the prefix prefix1.
   Care-of-Address configured by using prefix1 is CoA1. Similarly,
   link2 is attached to AR2, uses prefix2, and MN configures CoA2 by
   using prefix2.

3.1. Access Router Sending Router Advertisements

   Layer 2 of the AR comes up with a list of links that an attached MN
   might be visiting in the immediate future, by using the layout of
   ARs in the domain and measurements (e.g. direction of MN), and
   applying some heuristics. This list would be the "neighborhood of
   MN". Neighborhood is conveyed to layer 3 in the form of a list of
   links (e.g. "link1, link2, link3"). Current access router, AR1,
   needs to map these links to prefixes advertised on each link. One
   possible way of implementing this mapping could be in the form of a
   table. This table can be a local one or a centrally maintained one.
   Note that even without this extension to the protocol, AR1 uses such

Yegin, Parthasarathy, Williams     Expires 25 March 2001        Page 4

Internet Draft          Neighborhood Routing         25 September 2000

   a table to advertise its own prefixes on various links. That table
   can be extended to include other links a MN may visit in this
   domain.

   AR1 comes up with a list of prefixes, prefix1, prefix2, etc. after a
   successful lookup. The first prefix is the one for the link MN is
   physically attached to. The rest are the prefixes for possible next
   links in the order of descending possibility. Note that this list is
   per MN, and its elements and their order can change in time.

   Now AR1 can send a router advertisement (RA) to MN. This RA includes
   a prefix information option to carry prefix1 as current prefix, and
   a number of others to carry pn-prefixes (see section 5.1

3.2. MN Processing

   When MN receives an RA with pn-prefixes, it can configure one CoA
   for each prefix. CoA1 will be current CoA, and others pn-CoAs. All
   the pn-CoAs are marked as deprecated, so that they are not used as
   source addresses in outgoing packets. Now MN can receive packets
   that are sent to any of its CoAs.

   Next, MN sends a new BU to CNs and HA. This BU, in addition to
   current CoA, contains one pn-CoA destination option sub-option for
   all pn-CoAs (see section 5.2).

3.3. CN Processing

   After receiving a BU with pn-CoAs, whenever CN wants to send a
   packet to MN, it includes a routing header extension in the packet.
   CN uses new routing header type 1 (instead of type 0) that includes
   all CoAs as intermediate hops (see section 5.3). The destination of
   the packet is CoA1, and the routing header is initialized to contain
   CoA2, CoA3, ..., home address of MN as the route segments. The
   routing infrastructure makes a best effort to route packet through
   intermediate hops. But, if a router on the same link as next hop
   (such as AR1) determines that host at next hop (such as MN at CoA1)
   is not reachable, it can simply skip this hop, update the routing
   header, and forward the packet to the following hop (MN at CoA2).

   If MN is not attached to any of the links, last AR forwards the
   packet to the home link to be intercepted by HA since the last route
   segment in the routing header is the home address of the MN (see
   section 3.5 for more on this).

Yegin, Parthasarathy, Williams     Expires 25 March 2001        Page 5

Internet Draft          Neighborhood Routing         25 September 2000

3.4. Access Router Processing Data Packets

   When a packet with type 1 routing header arrives, AR1 will forward
   it to MN for a successful delivery if MN is still attached to link1.
   It's assumed that L2 of AR can determine whether a MN is attached or
   not, and convey this information to L3.

   If MN had already moved to link2 before the packet arrives at AR1,
   then AR1 would know that MN at CoA1 is no longer attached to link1.
   AR1 would process the routing header, so that CoA1 is skipped, and
   the packet is forwarded to next hop, CoA2. This time AR2, seeing
   that MN at CoA2 is attached to link2, forwards the packet to MN.
   Although sender of the packet didn't know the exact location of MN,
   the packet is delivered successfully by using the information about
   where else MN might be located currently.

3.5. Home Agent Processing

   As stated in [1], HA intercepts packets from various CNs and tunnels
   them to MN. Additionally, if HA has the knowledge of pn-CoAs, it
   puts a routing header type 1 in the encapsulating packet's header.
   The destination of this packet is CoA1, and the routing header is
   initialized to contain CoA2, CoA3, ... as the route segments. This
   way, tunneled packet will be delivered to MN at one of the CoAs.
   Note that since home address of MN is not included in the routing
   header (unlike CN processing, see section 3.3), this packet will
   never be forwarded back to the home link.

   One special case MAY need to be handled by HA. When a packet from CN
   with routing header type 1 is not delivered at any of CoAs, it ends
   up at the HA to be intercepted. If HA blindly processes, the
   tunneled packet could traverse the same ARs as the original packet
   and get dropped at the last AR. In order to prevent an extra
   transmission, HA MAY implement an optional check. HA MAY compare its
   knowledge of CoAs with the one derived from the routing header of
   the intercepted packet. If they are same, HA MUST discard the
   packet. This shows CN already tried the possibilities that HA would
   try. Sending the packet again won't deliver the packet. This can be
   the case when MN moved to a different domain, and neither CN nor HA
   has received the most current BU yet.

3.6. Other Details

   The neighborhood of MN changes as MN moves within and across links.
   When MN moves within the same link, current CoA stays the same but
   pn-CoAs may change. Current CoA changes only when MN moves to
   another link. Furthermore, each CoA has an associated lifetime and
   they are removed when their lifetime expires. Each of such changes
   to the list of CoAs can trigger a new BU transmission. MN
   proactively makes sure each CN and HA has enough information to

Yegin, Parthasarathy, Williams     Expires 25 March 2001        Page 6

Internet Draft          Neighborhood Routing         25 September 2000

   deliver packets wherever it might move next by refining its list of
   CoAs.

   In this protocol, if AR doesn't send np-prefixes, or MN doesn't
   recognize np-prefixes, or MN doesn't send np-CoA sub-options, or CN
   and HA don't recognize np-CoA sub-options, then this protocol
   automatically converges to the one in draft [1]. None of the
   entities need to detect whether new protocol is recognized at
   others or not.

   Whenever L2 determines that MN will be staying at the current link
   for an extended period of time (due to low speed, very large cell,
   etc.), system can use only one CoA as in [1]. System can use the new
   protocol to configure pn-CoAs as soon as a possible move to another
   link is detected.

   Definition of "immediate future", the heuristic used to come up with
   a list of next possible links, and maximum number of CoAs to
   configure on MN are system wide tuning parameters.

4. New Requirements for IPv6 Nodes

   This protocol extension requires modification to the Access Routers,
   the Mobile Node, the Correspondent Nodes, and the Home Agent.

   The proposed MIPv6 extensions are optional to basic Mobile IPv6;
   networking elements can function with support of the new option
   independent to any other networking entity providing support. If the
   extensions are not supported by AR, MN, CN, and HA, the operation
   will default to the base protocol as defined in [1].

4.1. Access Routers

   L3 of AR MUST be capable of interfacing with L2 to obtain a list of
   links that the MN may be visiting next. The actual interface is
   beyond the scope of this document. The AR MUST be able to map each
   link to the prefix information and also be capable of sending router
   advertisements with the N bit set for these prefixes.  Additionally,
   L3 MUST be capable of determining if a MN is attached to its link or
   not. The AR MUST be able to process data packets containing the
   type 1 routing header extension.

4.2. Mobile Node

   The MN MUST recognize the use of the prefix information option with
   N bit set so that the extended protocol can be used. The MN MUST be
   able to configure one CoA for each prefix it receives. The MN MAY
   perform further processing on the list of prefixes it receives from
   the AR. This processing MAY include the reordering or reducing the

Yegin, Parthasarathy, Williams     Expires 25 March 2001        Page 7

Internet Draft          Neighborhood Routing         25 September 2000

   list of prefixes via some heuristic. The mobile node MUST be able to
   send a BU with pn-CoA sub-option.  The MN MUST be able to process
   type 1 routing header extensions.

4.3. Correspondent Nodes

   The CN MUST be able to recognize a BU with pn-CoA sub-option. The CN
   MUST be capable of maintaining binding cache entries based on the BU
   with pn-CoA sub-option.  The CN MUST be able to send a type 1
   routing header extension whenever sending packets to the MN.

4.4. Home Agent

   The HA MUST be able to recognize BU with pn-CoA sub-option. The HA
   MUST be capable of maintaining a binding cache entries based on the
   neighborhood binding updates. The HA MUST be able to send a router
   header extension of type 1 for all the intercepted packets that are
   tunneled. The HA MAY also check the router headers in the
   intercepted packets to handle the case specified in section 3.5.

Yegin, Parthasarathy, Williams     Expires 25 March 2001        Page 8

Internet Draft          Neighborhood Routing         25 September 2000

5. Protocol Extensions

5.1. Router Advertisement

   This section defines a new bit as part of the prefix information
   that is sent as part of the router advertisement [4]. Access routers
   set this bit to indicate that the prefix contained in this option is
   a pn-prefix (see section 3.1). MN can use this information to
   configure the additional care of addresses and also use it in the
   binding updates to indicate its neighborhood.

     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     | Prefix Length |L|A|R|N|Resvd1 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         Valid Lifetime                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Preferred Lifetime                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                           Reserved2                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    |                                                               |
    +                            Prefix                             +
    |                                                               |
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 1: Prefix Information Option

     N : This indicates that the contained prefix belongs to a
         router where the MN could possibly be visiting in in the
         near future.

   All other fields has the same meaning as that of [4].

   If the N bit is not understood by the mobile node, it MUST skip the
   prefix contained in the option. Thus, this mechanism provides
   backward compatibility to mobile nodes that does not understand the
   bit and hence falls back to the old scheme mentioned in the
   draft [1].

Yegin, Parthasarathy, Williams     Expires 25 March 2001        Page 9

Internet Draft          Neighborhood Routing         25 September 2000

5.2. Binding Update

   This section defines a new destination option sub-option for the
   binding update that lists the possible next care of addresses to be
   used by the HA or CNs in routing header type 1.

     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
                                    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                    |       8       |       len     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    |                                                               |
    +                  Care-of Address 1                            +
    |                                                               |
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .                                                               .
    .                                                               .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    |                                                               |
    +                  Care-of Address n                            +
    |                                                               |
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 2: Possible Next Care-of-Address Sub-Option
                      (alignment requirement: 8n+6)

        len : n * 16 where n is the number of care of addresses.

   The source address of the BUs will be the current CoA. If this
   sub-option is not understood by the CN or HA, it MUST be skipped as
   mentioned in the draft [1].  Thus, this mechanism provides backward
   compatibility to nodes that does not understand the new sub-option
   and hence falls back to the old scheme mentioned in the draft [1].

5.3. New Routing Header

   This proposal defines a new routing header type 1 which is used by
   CNs and HA when sending packets to MN. This MUST be sent only if CN
   and HA received a binding update with the new possible next

Yegin, Parthasarathy, Williams     Expires 25 March 2001       Page 10

Internet Draft          Neighborhood Routing         25 September 2000

   care-of-address sub-option defined in section 5.2.

   The Routing header is used by an IPv6 source to list one or more
   intermediate nodes to be "visited" on the way to a packet's
   destination. The Routing header is identified by a Next Header
   value of 43 in the immediately preceding header, and has the
   following format:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Next Header  |  Hdr Ext Len  |  Routing Type | Segments Left |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .                                                               .
    .                       type-specific data                      .
    .                                                               .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 3: Routing Header Extension

   All the fields of the routing header remain the same as in type 0
   [5] except that the Routing Type is 1.

Yegin, Parthasarathy, Williams     Expires 25 March 2001       Page 11

Internet Draft          Neighborhood Routing         25 September 2000

   The Type 1 Routing header has the following format:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Next Header  |  Hdr Ext Len  | Routing Type=1| Segments Left |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            Reserved                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    |                                                               |
    +                           Address[1]                          +
    |                                                               |
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    |                                                               |
    +                           Address[2]                          +
    |                                                               |
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .                               .                               .
    .                               .                               .
    .                               .                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    |                                                               |
    +                           Address[n]                          +
    |                                                               |
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 4: Type 1 Routing Header Extension

   The processing of Routing header type 1 is almost the same except
   for the difference noted below.

   A Routing header type 0 is not examined or processed until it
   reaches the node identified in the Destination Address field of the
   IPv6 header. But in the case of routing header type 1, the last hop
   router that forwards the packet to the node identified by the
   Destination Address of the IPv6 header also processes the packet if
   the packet can't be delivered. If it knows readily that the node
   identified by the destination address is reachable, it sends the

Yegin, Parthasarathy, Williams     Expires 25 March 2001       Page 12

Internet Draft          Neighborhood Routing         25 September 2000

   packet. If it is not reachable, it swaps the destination addresses
   with the next hop address contained in the route specific data, as
   it does with routing header type 0 and forwards the packet to the
   new destination address.

   The router that determines that the packet being forwarded is
   on-link, checks to see whether the destination is reachable or not.
   It checks for a routing header type 1 and processes it only if the
   destination is not reachable. The processing is as follows :

        If (packet being forwarded is on-link) {
                if (destination is reachable) {
                        Send the packet(*)
                } else if (routing header type 1 present) {
                        Process the routing header type 1 similar to
                        routing header type 0. Swap the IPv6 destination
                        address with the next hop address in the option
                        and forward the packet to the new destination.
                } else {
                        drop the packet.
                }
        } else {
                forward the packet using the default IPv6 rules.
        }

   (*)If the destination is reachable and the packet was sent to the
   destination connected on-link, the node receiving the packet would
   see one of the care of addresses (it sent in the binding update) in
   the destination field of the IPv6 header, depending on which link it
   receives the packet. It processes the packet in the following way:

        if (Segments Left == 0) {
                Send an ICMP Parameter Problem, Code 0, message
                to the Source Address, pointing to the Hdr Ext
                Len field, and discard the packet
        } else {
                Swap the Destination address with the next hop address
                and feed the packet for transmission.
                As all the addresses belongs to this node, this will
                eventually stop when the last hop address is
                processed.
        }

Yegin, Parthasarathy, Williams     Expires 25 March 2001       Page 13

Internet Draft          Neighborhood Routing         25 September 2000

6. Security Considerations

   Binding updates MUST be protected by IPsec Authentication header.
   When Routing header type 1 is used and IPsec is also used, routing
   header should be protected by IPsec. The processing of routing
   header type 1 is the same as routing header type 0 in the context
   of IPsec.

7. Conclusion

   Standard routing expects a host to be reachable at a certain link.
   New protocol extends this to reaching a host at one of the possible
   links it might be attached at that time. All the traffic can be
   delivered to MN at any of those links by MN knowing which other
   links it might be moving to and informing CNs and HA about them.
   AR determines this link information using L2 knowledge and sends it
   to MN.

   This new protocol is a natural extension to the one in MIPv6 draft
   [1]. It doesn't define new networking entities. The data flow is the
   same as specified in the MIPv6 draft [1]: MN configures CoAs by
   using the prefixes in RAs, MN informs CNs and HA by use of BUs, CNs
   use routing header to deliver packets to MN, and HA intercepts
   packets from CNs and tunnels them. The new protocol shows up as
   extensions to router advertisement, binding update, and routing
   header. These extensions are ignored when they are not recognized by
   any of the networking entities, and the system automatically
   converges to regular MIPv6.

   As soon as MN moves to a new link, it can start sending and
   receiving packets without anyone else keeping track of instant
   movements of MN.

   This protocol allows the MIPv6 infrastructure to dynamically adapt
   itself to changing conditions and different deployment scenarios.
   If handoffs are happening frequently (fast MN movement, too small
   cells, etc.), MN sends more CoAs in its BUs.  If no handoff is
   expected for a while, none of the new extensions are used, therefore
   only one CoA is sent and the system becomes what's described in [1].

Yegin, Parthasarathy, Williams     Expires 25 March 2001       Page 14

Internet Draft          Neighborhood Routing         25 September 2000

References

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

   [2] S. Bradner. "Key words for use in RFCs to Indicate Requirement
       Levels", Request for Comments (Best Current Practice) 2119,
       March 1997.

   [3] J. Malinen and C. Perkins. "Mobile IPv6 Regional Registrations",
       draft-malinen-mobileip-regreg6-00.txt, July 2000.

   [4] T. Narten, E. Nordmark, and W. Simpson. "Neighbor Discovery for
       IP Version 6 (IPv6)", Request for Comments (Draft Standard) 2461,
       December 1998.

   [5] S. Deering and R. Hinden. "Internet Protocol, Version 6 (IPv6)",
       Request for Comments (Draft Standard) 2460, December 1998.

Author's Addresses

        Alper E. Yegin
        Sun Microsystems, Inc.
        901 San Antonio Road
        Palo Alto, CA 94303
        USA
        phone: +1 650 786 4013
        fax:   +1 650 786 5896
        email: [email-masked]

        Mohan Parthasarathy
        Sun Microsystems, Inc.
        901 San Antonio Road
        Palo Alto, CA 94303
        USA
        phone: +1 650 786 8885
        fax:   +1 650 786 5896
        email: [email-masked]

        Carl Williams
        Sun Microsystems, Inc.
        901 San Antonio Road
        Palo Alto, CA 94303
        USA
        phone: +1 650 786 5186
        fax:   +1 650 786 5896
        email: [email-masked]

Yegin, Parthasarathy, Williams     Expires 25 March 2001       Page 15

---

From: Thi Nguyen <[email-masked]>
Date: Wed, 27 Sep 2000 16:15:45 -0500

Hi All,

This is my first time to post here, and I am a beginner in MIP. Please
forgive me if my inexperience show. Pardon me if what I am saying below has
been discussed and ignored.

I don't understand why we do not put the soft-handoff or fast-handoff
function in the MN. This is done in CDMA network. The mobile device (MN) can
sense that it is drifting into another cell (link) other than it current
cell (link). This is done by the signal strength measurement in the mobile
device. The mobile device then initiate a soft-handoff (BU), where it can
receive signals from both the current cell and the cell it is about to go
into.

I don't see why this concept can not be repeated for MIPv6.

Regards,
Thi Nguyen

-----Original Message-----
From: Alper Yegin [mailto:[email-masked]]
Sent: Tuesday, September 26, 2000 12:58 PM
To: [email-masked]
Subject: [MOBILE-IP] New I-D: draft-yegin-mobileip-nrouting-00.txt

Hello,

Abstract

Alper Yegin
Internet Engineering
Sun Microsystems, Inc.

---

From: Alper Yegin <[email-masked]>
Date: Wed, 27 Sep 2000 16:42:22 -0700

> I don't see why this concept can not be repeated for MIPv6.

Hi Thi,

You are talking about MN being data connected at both the previous link and the
new link simultanesouly, right? You are right, if that was the case, it'd be
easier: if MN has enough time in the overlapped area to get the latest BUs to
CNs/HA and receive the last packet sent to old CoA, then things are fine.

But I think when this was discussed, people said not all the technologies
provide this "be connected at both links" feature, it may require two receivers
...

Also, if the overlap area is too small, MN may get out of it before the last
packet sent to old CoA is received.

alper

>    natural extension to the Mobile IPv6 protocol.

alper

---

From: Alper Yegin <[email-masked]>
Date: Fri, 29 Sep 2000 10:31:13 -0700

> In this draft, AR has to specify possible prefix candidates and MN provide
> COAs. But the moving of MN may be fast from one zone to another zone.
> So I doubt that the prediction of AR and MN is reasonable??

This is why the "neighborhood" can consist of more than one link.

One case is MN is not moving, or it's moving but will be in the same link for a
while (due to big cell, slow speed MN), then neighborhood is only the current
link (link1).

For other cases, there needs to be more links in the neighborhood. Like in your
example, if there's a possiblity that MN might be in link2, and even link3 (MN
moving through link1, link2, and link3), then neighborhood will be "link1,
link2, link3".

alper