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]