One document matched: draft-yegin-mobileip-nrouting-00.txt
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: Alper.Yegin@eng.sun.com
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: Mohan.Parthasarathy@eng.sun.com
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: Carl.Williams@eng.sun.com
Yegin, Parthasarathy, Williams Expires 25 March 2001 Page 15
| PAFTECH AB 2003-2026 | 2026-04-22 04:54:35 |