NEMO Working Group J. Ryu
Internet-Draft N. Choi
Expires: April 25, 2007 Seoul National University
E. Paik
KT
T. Kwon
C. Park
Seoul National University
October 22, 2006
Failover for Multiple Mobile Routers in a Mobile Network
draft-ryu-nemo-mr-failover-02.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
This Internet-Draft will expire on April 25, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This draft proposed the use of multiple mobile routers in a single
NEMO. A failed mobile router is taken over by another mobile router
using "prefix peer" relationship among mobile routers in a NEMO.
Ryu, et al. Expires April 25, 2007 [Page 1]
Internet-Draft Failover for Multiple Mobile Routers October 2006
"prefix peer" relationship enables a mobile router's prefix to be
handled by another mobile router.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5
4. Failure Classification for Multiple Mobile Routers . . . . . . 5
4.1. Egress Interface Failure . . . . . . . . . . . . . . . . . 5
4.2. Ingress Interface Failure . . . . . . . . . . . . . . . . 6
4.3. MR itself Failure . . . . . . . . . . . . . . . . . . . . 6
5. Peer Multiple Care-of Address Registration . . . . . . . . . . 7
5.1. Binding Cache Structure and Management . . . . . . . . . . 7
5.2. Binding Update message Structure and Management . . . . . 8
5.3. Operation . . . . . . . . . . . . . . . . . . . . . . . . 8
5.4. Messages Format Changes . . . . . . . . . . . . . . . . . 8
5.4.1. Binding Unique Identifier sub-option . . . . . . . . . 8
5.4.2. Binding Update . . . . . . . . . . . . . . . . . . . . 9
5.4.3. Binding Acknowledgement . . . . . . . . . . . . . . . 9
6. Multiple Mobile Router Failover . . . . . . . . . . . . . . . 10
6.1. HA Operation . . . . . . . . . . . . . . . . . . . . . . . 10
6.1.1. Interface Failure and Recovery . . . . . . . . . . . . 10
6.1.2. MR Failure and Recovery . . . . . . . . . . . . . . . 11
6.2. MR Operation . . . . . . . . . . . . . . . . . . . . . . . 11
6.2.1. Interface Failure and Recovery . . . . . . . . . . . . 11
6.2.2. MR Failure and Recovery . . . . . . . . . . . . . . . 12
6.3. Message Format . . . . . . . . . . . . . . . . . . . . . . 12
6.3.1. ICMP Mobile Router Failure Notify (FN) . . . . . . . . 12
6.3.2. ICMP Mobile Router Failure Notify Acknowledgement
(FN ACK) . . . . . . . . . . . . . . . . . . . . . . . 13
6.3.3. ICMP Mobile Router Recovery Notify (RN) . . . . . . . 14
6.3.4. ICMP Mobile Router Recovery Notify Acknowledgement
(RN ACK) . . . . . . . . . . . . . . . . . . . . . . . 16
7. Implementation . . . . . . . . . . . . . . . . . . . . . . . . 17
7.1. Machine Setting . . . . . . . . . . . . . . . . . . . . . 19
7.2. Test Scenario . . . . . . . . . . . . . . . . . . . . . . 19
8. Security Consideration . . . . . . . . . . . . . . . . . . . . 19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Ryu, et al. Expires April 25, 2007 [Page 2]
Internet-Draft Failover for Multiple Mobile Routers October 2006
Appendix A. Operation Example . . . . . . . . . . . . . . . . . . 20
A.1. Interface Failure . . . . . . . . . . . . . . . . . . . . 20
A.2. MR Failure . . . . . . . . . . . . . . . . . . . . . . . . 22
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . . . . . 27
Ryu, et al. Expires April 25, 2007 [Page 3]
Internet-Draft Failover for Multiple Mobile Routers October 2006
1. Introduction
Recently, the NEMO working group is investigating the multihoming
issues [1] for a NEMO, but the NEMO Basic Support protocol [2] has no
specific mechanism to support multihoming yet. In mobile IPv6 [3], a
multihoming mechanism [4] is proposed so that a multihomed host can
register multiple CoAs with its home agent (HA). In this document,
we propose to extend the concept of multiple CoA registration of a
single mobile host to the case of multiple mobile routers (MR) in
mobile network (NEMO) environments for the purposes of failover.
2. Terminology
Terms used in this draft are defined in [3], [5] and [6]. We define
or redefine the following ones:
Original Mobile Router
An original mobile router is an MR that advertises its own mobile
network prefix (MNP).
Failed Mobile Router
A failed mobile router is an MR which i) fails on its egress
interface and/or ingress interface. ii) fails itself. Here,
"failure" means an MR loses the connectivity due to mobility,
fading and so on.
Peer Mobile Router
A peer mobile router is an MR capable of providing Internet
services instead of a failed MR. A peer MR (PMR) should be first
authenticated by an MR or its HA in the same NEMO to prevent
malicious nodes from spoofing. An MR hearing router advertisement
(RA) messages from neighboring MRs initiates a PMR authentication
depending on its policy. Also, the technique proposed in [7] can
be also used for the PMR authentication.
Prefix Peer Binding Update (PPBU)
Prefix peer binding update means this binding update message is
sent by PMRs. PPBU has different meanings depending on the backup
flag in Binding Unique Identifier sub-option. If the backup flag
is set to 1, it means that a PMR sends this binding update message
for PMR registration. Otherwise, this binding update message is
sent by a PMR to change the active CoA of the MNP in binding cache
of a HA.
Ryu, et al. Expires April 25, 2007 [Page 4]
Internet-Draft Failover for Multiple Mobile Routers October 2006
Active CoA
An active CoA is a CoA that is currently used in the NEMO. The
active field in binding cache entry of the HA corresponding to the
CoA is set to 1.
Peer CoA
A peer CoA is a CoA that is assigned to the egress interface of a
PMR. This CoA will be used to provide Internet service instead of
a failed mobile router.
FN
The ICMP Mobile Router Failure Notify message is sent by the
failed MR to its PMR. By this message, the PMR can know the
failure of the original MR and HA address of the failed MR to
perform PPBU.
RN
The ICMP Mobile Router Recovery Notify message is sent by the HA
to its MR's PMR when the original MR recovers from failure. By
this message, the PMR can know the original MR's recovery and the
MNP of the original MR to stop advertising.
3. Protocol Overview
To provide a failover service, we propose to make a "prefix peer"
relationship among the MRs in a multi-homed NEMO [1], which is
realized by introducing a prefix peer binding update (PPBU) message.
The PPBU message enables mobile routers to establish a "prefix peer"
relationship by registering their CoAs with the HA of an MR, so that
when the MR fails, one of the other MRs that have a "prefix peer"
relationship can provide Internet service instead of the MR that
cannot provide Internet service.
4. Failure Classification for Multiple Mobile Routers
We classify MR's failure conditions as follows.
4.1. Egress Interface Failure
Ryu, et al. Expires April 25, 2007 [Page 5]
Internet-Draft Failover for Multiple Mobile Routers October 2006
+---+----------+----+MR1's +-----+
| Internet |------| MR2 |
+---+----------+----+ CoA +--+--+
|
|
(Failure) |
+-----+ |MNP2(+ MNP1)
| MR1 | |
+--+--+ |
| |
| |
+--+--------------+--+
| NEMO |
+--------------------+
Figure 1. Egress Interface Failure
An egress interface failure condition make the MR cannot send any
packet to outside(AR,HA or Internet). In this case, the failed MR
should stop advertising its RA and a PMR may back up the failed MR.
4.2. Ingress Interface Failure
+---+----------+----+MR1's +-----+
| Internet |------| MR2 |
+---+----------+----+ CoA +--+--+
| |
| |
MR2's|CoA |
+-----+ |MNP2(+ MNP1)
| MR1 | |
+--+--+ |
(Failure) |
|
+--+--------------+--+
| NEMO |
+--------------------+
Figure 2. Ingress Interface Failure
In an ingress interface failure condition, the MR cannot send RA
message to MNs. Here, a PMR may send RA message with an MNP of the
failed MR instead of the failed MR for backup.
4.3. MR itself Failure
Ryu, et al. Expires April 25, 2007 [Page 6]
Internet-Draft Failover for Multiple Mobile Routers October 2006
+---+----------+----+MR1's +-----+
| Internet |------| MR2 |
+---+----------+----+ CoA +--+--+
x |
x |
x |
+-----+ |MNP2(+ MNP1)
failed | MR1 | |
+--+--+ |
x |
x |
+--+--------------+--+
| NEMO |
+--------------------+
Figure 3. MR itself Failure
This situation is union of ingress/egress interface failure or system
failure. In this case, a PMR need a way to detect the failure of the
original MR and may back up the failed MR.
5. Peer Multiple Care-of Address Registration
Peer multiple CoAs registration is an extended version of multiple
CoAs registration mechanism for mobile IPv6 [4]. In this draft, an
MR can register not only its CoA but also delegate its PMR to
register the PMR's CoA as one of multiple peer CoAs. An MR sends a
prefix peer binding update message to support a multi-homed NEMO
consisting of multiple MRs. One of the registered CoAs of PMRs is
used to provide seamless Internet service when an original MR fails.
For each MNP in binding cache of a HA there are one active CoA and
multiple peer CoAs. An active CoA means incoming packets to the NEMO
are being forwarded to this CoA. A peer CoA means that it is one of
the PMRs' CoAs and maintained for backup purposes.
5.1. Binding Cache Structure and Management
To support a multi-homed NEMO consisting of multiple MRs, additional
fields are required in the binding cache structure, which are:
- Active of the binding cache entry. Active means the CoA is now in
use. The value MUST be zero if the CoA is not active.
- Peer of the binding cache entry. Peer means this CoA is a PMR's
one. The value MUST be zero if the CoA is not a PMR's CoA but the
original MR's CoA.
Ryu, et al. Expires April 25, 2007 [Page 7]
Internet-Draft Failover for Multiple Mobile Routers October 2006
5.2. Binding Update message Structure and Management
Additional flags are required in the binding update structure, which
are:
- Prefix peer flag: MUST be set to 1 if the binding update is sent by
a peer MR.
- Backup flag: MUST be set to 1 if the CoA is the peer CoA.
5.3. Operation
After the successful PMR authentication, an MR sends a PPBU message
to its HA for peer MR registration. This PPBU message includes the
CoA of a PMR and backup flag set to 1 in Binding Update Identifier
sub-option. If the HA that receives this PPBU message does not have
this CoA entry in its binding cache, it adds an entry corresponding
to this CoA as a peer CoA. The binding cache entry has an active
field set to 0 and a peer field set to 1.
5.4. Messages Format Changes
5.4.1. Binding Unique Identifier sub-option
A new backup flag (B) is included in the binding unique identifier
sub-option to notify the HA of whether the CoA in the binding update
message is a peer CoA or not. The rest of the Binding Unique
Identifier sub-option format remains the same as defined in [4].
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 = TBD | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Binding Unique ID (BID) |P|B| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+
Backup Flag (B)
The backup flag is set to indicate to the HA whether the CoA in
the binding update is a peer CoA or not. If the flag is set to 0,
the active field of this CoA should be set.
For descriptions of the other fields in the message, see [4].
Ryu, et al. Expires April 25, 2007 [Page 8]
Internet-Draft Failover for Multiple Mobile Routers October 2006
5.4.2. Binding Update
A new prefix peer flag (P) is included in the binding update message
to indicate to the HA whether this binding update message is sent by
its PMR or original MR. The rest of the binding update message
format remains the same as defined in [4].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|B|P| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prefix Peer Flag (P)
The prefix peer flag is set to indicate to the HA whether this
binding update is sent by the PMR or the original MR.
5.4.3. Binding Acknowledgement
A new prefix peer flag (P) is included in the binding acknowledgement
message to indicate that the HA that received the corresponding
binding update supports peer multiple CoAs registration. If the
corresponding binding update has the prefix peer flag (P) set to 1,
the flag should be set to 1. The rest of the binding acknowledgement
message format remains the same as defined in [2].
Ryu, et al. Expires April 25, 2007 [Page 9]
Internet-Draft Failover for Multiple Mobile Routers October 2006
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K|R|P|Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prefix peer Flag (P)
The prefix peer flag is set to indicate that the HA that processed
the corresponding binding update support peer multiple CoAs
registration. If the corresponding binding update had the prefix
peer flag set to 1, the flag should be set to 1.
For descriptions of the other fields in the message, see [2].
6. Multiple Mobile Router Failover
In this section, the detailed mechanism of MR failover is described.
In general, an MR uses the wireless channel as an egress interface
for NEMO support. Because this wireless channel is subject to
disconnectivity due to channel error, blackout, or handover, some
link failures may occur. With respect to failures, this draft is
concentrated only on an egress or ingress interface failure and an MR
itself failure. After the HA of an original MR authenticates and
registers a PMR successfully, the PMR should be able to take over if
the original MR fails.
6.1. HA Operation
6.1.1. Interface Failure and Recovery
When a HA of an original MR receives a PPBU message with the unset
backup flag in the Binding Update Identifier sub-option but the peer
field in binding cache entry of this HA corresponding to the CoA in
the PPBU message is set to 1, the HA assumes that the original MR
fails. If the HA does not have any entry corresponding to this CoA,
it silently discards this message. The CoA of the original MR in
binding cache whose active field set to 1 cannot be used because of
original MR failure. Thus its active field is set to 0. An active
Ryu, et al. Expires April 25, 2007 [Page 10]
Internet-Draft Failover for Multiple Mobile Routers October 2006
field corresponding to the CoA in a PPBU message is set to 1. When
the HA receives a BU message with the unset backup flag in the
Binding Update Identifier sub-option and both active and peer fields
corresponding to the CoA in the BU message are set to 0, the HA
assumes that the original MR recovers from failure. If the HA does
not have any entry corresponding to the CoA in the BU message, it
silently discards this message. A new ICMP Mobile Router Recovery
Notify messages (6.3.3) are sent to all PMRs whose active field
currently set to 1. Every peer CoA in binding cache whose active
field is set to 1 need to be deactivated because the failed MR
recovers. Thus its active field is set to 0. An active field
corresponding to the CoA in the BU message is set to 1. After
receiving the PPBU or the BU message, the HA must replay with a
Binding Acknowledgement.
6.1.2. MR Failure and Recovery
This operation is identical to interface failure and recovery in the
section 4.1.1.
6.2. MR Operation
6.2.1. Interface Failure and Recovery
If an MR detects its ingress (or egress) interface failure, it should
immediately stop advertising its prefix and send a new ICMP Mobile
Router Failure Notify message (6.3.1) to the PMR. Any PMR detects an
egress (or ingress) interface failure of the original MR by receiving
a FN message from the failed MR, the PMR sends a PPBU message to the
HA of the failed MR. The backup flag of the Binding Update
Identifier sub-option in this PPBU message is set to 0. After
receiving the PPBU ACK message, this PMR replies a new ICMP Mobile
Router Failure Notify Acknowledgement (6.3.2) to the failed MR. The
PMR starts advertising the MNP of the failed MR in addition to its
own MNP. The PMR can provide Internet service for fixed and mobile
nodes instead of the failed MR. That is, if the PMR receives a
packet from fixed or mobile nodes belonging to the MNP of the failed
MR, it can forward the packet through an appropriate tunnel between
the HA of the failed MR and itself for seamless connectivity. If an
egress (or ingress) interface failure is recovered, the original MR
sends a BU message to its HA. When the PMR receives an ICMP Mobile
Router Recovery Notify message including the MNP of the original MR
from the HA of the original MR, it stops advertising the MNP of the
failed MR. Finally, the PMR replies a new ICMP Mobile Router
Recovery Notify Acknowledgement message (6.3.2) to the HA of the
failed MR. Meanwhile, the original MR restarts advertising its MNP.
Ryu, et al. Expires April 25, 2007 [Page 11]
Internet-Draft Failover for Multiple Mobile Routers October 2006
6.2.2. MR Failure and Recovery
When the original MR fails (a system failure), the failed MR cannot
send an ICMP Mobile Router Failure Notify message to inform its PMRs
of the MR failure and the HA address of the failed MR to send PPBU
message. Therefore, any PMR detects failure of the original MR, it
first performs a dynamic home agent address discovery (DHAAD) [3] to
obtain the HA address of the failed MR. The PMR sends an ICMP home
agent address discovery request message to the mobile IPv6 home-
agents anycast address [8] for the home subnet prefix of the failed
MR. The HA of the failed MR receiving the request message returns an
ICMP home agent address discovery reply message with the HA address
as the source address to the PMR. After the PMR receives the reply
message, it will send a PPBU message to the HA of the failed MR. The
backup flag of the Binding Update Identifier sub-option in this PPBU
message is set to 0. After receiving a PPBU ACK message, it
advertises the MNP of the failed MR. Other operations are the same
as that of the interface failure in section 4.2.1.
6.3. Message Format
6.3.1. ICMP Mobile Router Failure Notify (FN)
The ICMP Mobile Router Failure Notify message is sent by the failed
MR to its PMR. By this message, the PMR can know the failure of the
original MR and HA address of the failed MR to perform PPBU.
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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
. .
. HA Address .
. .
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ryu, et al. Expires April 25, 2007 [Page 12]
Internet-Draft Failover for Multiple Mobile Routers October 2006
IP Fields:
Source Address
Home address of the failed MR.
Destination Address
Home address of the PMR.
ICMP Fields:
Type
154
Code
0
Checksum
The ICMP checksum [9].
Identifier
An identifier to aid in matching MR failure notify acknowledgement
messages to this MR failure notify message.
Reserved
This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
HA address
HA address of the failed MR.
6.3.2. ICMP Mobile Router Failure Notify Acknowledgement (FN ACK)
The ICMP Mobile Router Failure Notify Acknowledgement message is used
by a PMR to respond to the failed MR that sends an ICMP Mobile Router
Failure Notify Message.
Ryu, et al. Expires April 25, 2007 [Page 13]
Internet-Draft Failover for Multiple Mobile Routers October 2006
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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP Fields:
Source Address
Home address of the PMR.
Destination Address
Home address of the failed MR.
ICMP Fields:
Type
155
Code
0
Checksum
The ICMP checksum [9].
Identifier
The identifier from the invoking MR failure notify message.
Reserved
This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
6.3.3. ICMP Mobile Router Recovery Notify (RN)
The ICMP Mobile Router Recovery Notify message is sent by the HA to
its MR's PMR when the original MR recovers from failure. By this
message, the PMR can know the original MR's recovery and the MNP of
the original MR to stop advertising.
Ryu, et al. Expires April 25, 2007 [Page 14]
Internet-Draft Failover for Multiple Mobile Routers October 2006
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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
. .
. Mobile Network Prefix Option .
. .
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP Fields:
Source Address
Home agent address of the original MR.
Destination Address
Home address of the PMR.
ICMP Fields:
Type
156
Code
0
Checksum
The ICMP checksum [9].
Identifier
An identifier to aid in matching MR recovery notify
acknowledgement messages to this MR failure recovery message.
Ryu, et al. Expires April 25, 2007 [Page 15]
Internet-Draft Failover for Multiple Mobile Routers October 2006
Reserved
This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
Mobile Network Prefix Option
MNP of the original MR recovered from failure.
6.3.4. ICMP Mobile Router Recovery Notify Acknowledgement (RN ACK)
The ICMP Mobile Router Failure Recovery Acknowledgement message is
used by a PMR to reply to the HA in Mobile Router Recovery Notify
message.
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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
. .
. Mobile Network Prefix Option .
. .
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP Fields:
Source Address
Home address of the PMR.
Destination Address
HA address of the original MR.
ICMP Fields:
Type
Ryu, et al. Expires April 25, 2007 [Page 16]
Internet-Draft Failover for Multiple Mobile Routers October 2006
157
Code
0
Checksum
The ICMP checksum [9].
Identifier
The identifier from the invoking MR recovery notify message.
Reserved
This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
Mobile Network Prefix Option
MNP of the original MR recovered from failure.
7. Implementation
We implemented our protocol at the linux machines. Our test-bed is
consits of 9 linux machines; 2 MRs (MR1 & 2), 2 HAs (HA1 & 2), 2 MNs
(MN1 & 2), 1 CN, 1 Internet router (IR), and 1 dynamic switch (DS).
Logically, the testbed is organized as follow:
Ryu, et al. Expires April 25, 2007 [Page 17]
Internet-Draft Failover for Multiple Mobile Routers October 2006
+-------- ~ ------+
| |
+--+-+ |
+-----| IR |----+ |
~ +----+ ~ +----+
| | | CN |
+-----+ +-----+ +----+
| HA1 | | HA2 |
+-----+ +-----+
| |
| |
| |
+-----+ +-----+
| MR1 | | MR2 |
+-----+ +-----+
| |
| |
+-----+ +-----+
| MN1 | | MN2 |
+-----+ +-----+
Figure 4. Logical organization of Testbed
However, we use a Linux Dynamic Switch [10] to emulate the link state
for simlicity. Thus, physical setting of testbed is as follow:
+-----+ +-----+ +-----+ +----+
| HA1 | | MR1 | | MN1 | | IR |
+-----+ +-----+ +-----+ +----+
| | | |
+----------+---||||---+----------+
++++++
| DS |
++++++
+---------+----||||---+----------+
| | | |
+-----+ +-----+ +-----+ +----+
| HA2 | | MR2 | | MN2 | | CN |
+-----+ +-----+ +-----+ +----+
Figure 5. Physical organization of Testbed
We modify the NEPL [11] by adding new ICMP messages, PPBU messages,
and several routines to handle these new messages. We use a
radvd.conf for new RA which includes PMR's MNP. An ingress filtering
Ryu, et al. Expires April 25, 2007 [Page 18]
Internet-Draft Failover for Multiple Mobile Routers October 2006
at both HA1 and HA2 is setted by using ip6tables.
7.1. Machine Setting
Our all machines has Intel Pentiun4 2.8Ghz CPU, 512MB RAM. They use
Fedora core 4 as its operating system except the DS. To use NEPL,
HAs and MRs are upgraded its kernel version to 2.6.15. Other
machines uses kernel version 2.6.9. The DS uses Red hat 7.0 as its
operation system, and it has two 4 port ethernet cards to conneect
other 8 machines. Both MR1 and MR2 have two ethernet interfaces for
egress and ingress.
7.2. Test Scenario
We use a mozila firefox browser to test the IPv6. When MN1 downloads
some files from CN through firefox, a failure happens at MR1 like in
appendix scenario. However, according to our protocol, there are no
problem that MN1 downlaods all files completely.
8. Security Consideration
We do not consider any security issues in this draft.
9. References
[1] Ng, C., "Analysis of Multihoming in Network Mobility Support",
draft-ietf-nemo-multihoming-issues-05 (work in progress),
February 2006.
[2] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005.
[3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[4] Wakikawa, R., "Multiple Care-of Addresses Registration",
draft-wakikawa-mobileip-multiplecoa-04 (work in progress),
June 2005.
[5] Manner, J. and M. Kojo, "Mobility Related Terminology",
RFC 3753, June 2004.
[6] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
draft-ietf-nemo-terminology-05 (work in progress), March 2006.
[7] Choi, S., "Neighbor MR Authentication and Registration
Ryu, et al. Expires April 25, 2007 [Page 19]
Internet-Draft Failover for Multiple Mobile Routers October 2006
Mechanism in Multihomed Mobile Networks",
draft-cho-nemo-mr-registration-00 (work in progress),
April 2004.
[8] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast
Addresses", RFC 2526, March 1999.
[9] Conta, A. and S. Deering, "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification", RFC 2463, December 1998.
[10] "http://sourceforge.net/projects/dynamic-switch", Linux
Dynamic Switch (IP/MAC Killer).
[11] "http://software.nautilus6.org/NEPL/index.php", NEMO Platform
for Linux.
Appendix A. Operation Example
+-----+ +-----+
| HA1 | | HA2 |
+--+--+ +--+--+
| |
| |
+---+----------+----+MR1's +-----+
| Internet |------| MR1 |
+---+----------+----+ CoA +--+--+
| |MNP1
MR2's|CoA |
+-----+ |
| MR2 | |
+--+--+ |
|MNP2 |
| |
+--+--------------+--+
| NEMO |
+--------------------+
Figure 6. Multi-homed NEMO
A.1. Interface Failure
Suppose that there is a multi-homed NEMO that has two MRs: MR1 and
MR2. In the following scenario MR1 is to fail and MR2 will act as a
PMR of MR1. When the egress (or ingress) interface of MR1 fails, MR1
Ryu, et al. Expires April 25, 2007 [Page 20]
Internet-Draft Failover for Multiple Mobile Routers October 2006
sends an FN message including the HA address of MR1 through an
ingress (or egress) interface to inform MR2. MR2 sends a PPBU
message with an unset backup flag if MR2 has the intention to provide
Internet services instead of MR1 in consideration of its policy and
load. The snapshots of binding cache at HA1 before and after PPBU
with the unset backup flag are given as follows.
After PPBU with set backup flag
HoA: MR1's HoA, CoA: MR1's CoA, BID: 1, Active: -, Peer: -
Prefix: MNP1, CoA: MR1's CoA, BID: 1, Active: 1, Peer: 0
Prefix: MNP1, CoA: MR2's CoA, BID: 1, Active: 0, Peer: 1
Figure 7. Binding Cache for MR1 in HA1
After PPBU with unset backup flag
HoA: MR1's HoA, CoA: MR1's CoA, BID: 1, Active: -, Peer: -
Prefix: MNP1, CoA: MR1's CoA, BID: 1, Active: 0, Peer: 0
Prefix: MNP1, CoA: MR2's CoA, BID: 1, Active: 1, Peer: 1
Figure 8. Binding Cache for MR1 in HA1
HA1 MR1 MR2 HA2
| | | |
| TUNNEL TID1 | | TUNNEL TID2 |
|==============| |==============|
| |<- Interface | |
| | Failure | |
| | | |
| | FN | |
| |------------->| |
| PPBU(MR1 Prefix, MR2's CoA) | |
|<----------------------------| |
| PPBU ACK | |
|---------------------------->| |
| | FN ACK | |
| |<-------------| |
| TUNNEL TID3 | |
|=============================| |
| | | |
| | | |
Figure 9. Interface Failure Operation
After receiving PPBU ACK, MR2 sends RA messages with MNP1 to a NEMO
instead of MR1. Additionally, MR2 should forward outgoing packets
Ryu, et al. Expires April 25, 2007 [Page 21]
Internet-Draft Failover for Multiple Mobile Routers October 2006
from fixed or mobile nodes in the NEMO through an appropriate tunnel
based on the prefix of a source address of the packets. When the
failed egress (ingress) interface of MR1 is repaired, MR1 sends a BU
message to HA1. The snapshot of binding cache at HA1 is updated as
follows.
HoA: MR1's HoA, CoA: MR1's CoA, BID: 1, Active: -, Peer: -
Prefix: MNP1, CoA: MR1's CoA, BID: 1, Active: 1, Peer: 0
Prefix: MNP1, CoA: MR2's CoA, BID: 1, Active: 0, Peer: 1
Figure 10. Binding Cache for MR1 in HA1
Now, MR1 resumes broadcast RA messages again and MR2 stops
broadcasting RA messages for the MNP1.
HA1 MR1 MR2 HA2
| | | |
| |<- Recovery | |
| BU(MR1 Prefix, MR1's CoA) | |
|<-------------| | |
| BU ACK | | |
|------------->| | |
|Re-TUNNEL TID1| | |
|==============| | |
| RN (MNP1) | |
|---------------------------->| |
| RN ACK | |
|<----------------------------| |
| | RA | |
| |------------->| |
Figure 11. Failure Recovery Operation
A.2. MR Failure
When MR1 itself fails, MR2 detects it (We only consider the case that
an MR and a PMR share same IP subnet so they can here their own RA
each other. After all, if MR2 does not hear a predetermined number
of consecutive RA messages of MR1, MR2 concludes that MR1 itself
failed.) and performs DHAAD to obtain the HA address of MR1. MR2
sends an ICMP home agent address discovery message to the mobile IPv6
home-agents anycast address for the home subnet prefix of MR1. HA1
receiving the request message returns an ICMP home agent address
discovery reply message including the HA1 address as a source address
to MR2. After MR2 receives the reply message, MR2 sends a PPBU
message with an unset backup flag to HA1. The recovery of the failed
MR1 is the same as that of an egress (or ingress) interface failure.
Ryu, et al. Expires April 25, 2007 [Page 22]
Internet-Draft Failover for Multiple Mobile Routers October 2006
HA1 MR1 MR2 HA2
| | | |
| TUNNEL TID1 | | TUNNEL TID2 |
|==============| |==============|
| |<-MR1 Failure | |
| | | |
| | | |
| | No RA (n times) |
| |- - - - ->| |
| ICMP HAAD Request | |
|<----------------------------| |
| ICMP HAAD Replay(HA1 ADDR) | |
|---------------------------->| |
| PPBU(MR1 Prefix, MR2 CoA) | |
|<----------------------------| |
| PPBU ACK | |
|---------------------------->| |
| TUNNEL TID3 | |
|=============================| |
| | | |
| | | |
Figure 12. MR Failure Operation
Appendix B. Change Log
This draft is an update of draft-ryu-nemo-mr-failover-01.txt
Changes from draft-ryu-nemo-mr-failover-01 to -02:
* Added new Section 7: "Implementation"
Changes from draft-ryu-nemo-mr-failover-00 to -01:
* Various expressions are revised
* Modifications to Section 1:
+ A part of section 1 moved to a new section 3.
* Modifications to Section 2:
+ Added 'Active CoA' and 'Peer CoA' terms
Ryu, et al. Expires April 25, 2007 [Page 23]
Internet-Draft Failover for Multiple Mobile Routers October 2006
+ Added 'FN' and 'RN' terms
* Added new Section 3: "Protocol Overview"
* Added new Section 4: "Failure Classification for Multiple Mobile
Routers"
Ryu, et al. Expires April 25, 2007 [Page 24]
Internet-Draft Failover for Multiple Mobile Routers October 2006
Authors' Addresses
Jiho Ryu
Seoul National University
Multimedia Communications Lab., Seoul National Univ.
Shillim-dong, Kwanak-gu
Seoul 151-744
Korea
Phone: +82-2-876-7170
Fax: +82-2-876-7170
Email: jhryu@mmlab.snu.ac.kr
URI: http://mmlab.snu.ac.kr/~jhryu/
Nakjung Choi
Seoul National University
Multimedia Communications Lab., Seoul National Univ.
Shillim-dong, Kwanak-gu
Seoul 151-744
Korea
Phone: +82-2-876-7170
Fax: +82-2-876-7170
Email: fomula@mmlab.snu.ac.kr
URI: http://mmlab.snu.ac.kr/~fomula/
Eunkyoung Paik
KT
Advanced Technology Lab. KT
17 Woomyeon-dong, Seocho-gu
Seoul 137-792
Korea
Phone: +82-2-526-5233
Fax: +82-2-526-5759
Email: euna@kt.co.kr
URI: http://mmlab.snu.ac.kr/~eun/
Ryu, et al. Expires April 25, 2007 [Page 25]
Internet-Draft Failover for Multiple Mobile Routers October 2006
Taekyoung Kwon
Seoul National University
Multimedia Communications Lab., Seoul National Univ.
Shillim-dong, Kwanak-gu
Seoul 151-744
Korea
Phone: +82-2-880-9105
Fax: +82-2-872-2045
Email: tk@mmlab.snu.ac.kr
URI: http://mmlab.snu.ac.kr/~tk/
Chulhyun Park
Seoul National University
Multimedia Communications Lab., Seoul National Univ.
Shillim-dong, Kwanak-gu
Seoul 151-744
Korea
Phone: +82-2-876-7170
Fax: +82-2-876-7170
Email: chpark@mmlab.snu.ac.kr
URI: http://mmlab.snu.ac.kr/~chpark/
Ryu, et al. Expires April 25, 2007 [Page 26]
Internet-Draft Failover for Multiple Mobile Routers October 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Ryu, et al. Expires April 25, 2007 [Page 27]