NEMO Working Group J. Ryu Internet-Draft N. Choi Expires: January 9, 2006 Seoul National University E. Paik KT T. Kwon Seoul National University M. Nam KT July 8, 2005 Failover for Multiple Mobile Routers in a Mobile Network draft-ryu-nemo-mr-failover-00.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 January 9, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This draft proposed the use of multiple mobile routers in a single NEMO. Failed mobile router is replaced by another mobile router Ryu, et al. Expires January 9, 2006 [Page 1] Internet-Draft Failover for Multiple Mobile Routers July 2005 using "prefix peer" relationship among mobile routers in a NEMO. "prefix peer" relationship enables a mobile router's prefix to be handled by another mobile router. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Peer Multiple Care-of Addresses Registration . . . . . . . . . 4 3.1 Binding Cache Structure and Management . . . . . . . . . . 4 3.2 Binding Update Structure and Management . . . . . . . . . 4 3.3 Operation . . . . . . . . . . . . . . . . . . . . . . . . 5 3.4 Messages Format Changes . . . . . . . . . . . . . . . . . 5 3.4.1 Binding Unique Identifier sub-option . . . . . . . . . 5 3.4.2 Binding Update . . . . . . . . . . . . . . . . . . . . 5 3.4.3 Binding Update Acknowledgment . . . . . . . . . . . . 6 4. Multiple Mobile Routers Failover . . . . . . . . . . . . . . . 7 4.1 HA Operation . . . . . . . . . . . . . . . . . . . . . . . 7 4.1.1 Interface Failure and Recovery . . . . . . . . . . . . 7 4.1.2 MR Failure and Recovery . . . . . . . . . . . . . . . 7 4.2 MR Operation . . . . . . . . . . . . . . . . . . . . . . . 8 4.2.1 Interface Failure and Recovery . . . . . . . . . . . . 8 4.2.2 MR Failure and Recovery . . . . . . . . . . . . . . . 8 4.3 Message Format . . . . . . . . . . . . . . . . . . . . . . 8 4.3.1 ICMP Mobile Router Failure Notify . . . . . . . . . . 9 4.3.2 ICMP Mobile Router Failure Notify Acknowledgment . . . 10 4.3.3 ICMP Mobile Router Recovery Notify . . . . . . . . . . 11 4.3.4 ICMP Mobile Router Recovery Notify Acknowledgment . . 13 5. Security Consideration . . . . . . . . . . . . . . . . . . . . 14 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15 A. Appendices . . . . . . . . . . . . . . . . . . . . . . . . . . 16 A.1 Operation Example . . . . . . . . . . . . . . . . . . . . 16 A.1.1 Interface Failure . . . . . . . . . . . . . . . . . . 17 A.1.2 MR Failure . . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . 21 Ryu, et al. Expires January 9, 2006 [Page 2] Internet-Draft Failover for Multiple Mobile Routers July 2005 1. Introduction In mobile IPv6 [1], if a host has multiple network interfaces, it can register CoAs for individual interfaces with its home agent (HA) [2]. One of the CoAs is called a primary CoAs, while other CoAs are called alternative CoAs. In this draft, we extend this concept of multiple CoAs registration of a single mobile host to the case of multiple mobile routers (MR) in mobile neworks (NEMO) environments [3] for the purposes of failover and load balancing. To provide a failover service, we propose to add a new "backup" flag in binding cache entries to maintain multiple CoAs of multiple MRs of a NEMO. To deal with an MR with multiple interfaces, we also adopt the binding unique identifier (BID) proposed in [2]. Moreover, we propose to make a "prefix peer" relationship among the MRs in a multi-homed NEMO [4], which is realized by introducing a prefix peer binding update (PPBU) message. The PPBU message enables mobile routers using a "prefix peer" relationship to register their CoAs with the HA of the failed MR, so that when the MR fails, other MRs using a "prefix peer" relationship can provide Internet service instead of the MR that cannot provide Internet service during IP handoff. 2. Terminology Terms used in this draft are defined in [1], [5] and [6]. We define or redefine the following ones: Original Mobile Router An original mobile router is a MR that advertises its own mobile network prefix (MNP). Failed Mobile Router A failed mobile router is a MR which has an egress (ingress) interface failure or fails itself. Peer Mobile Router A peer mobile router is a MR capable of providing proxy services to neighboring MR(s). A peer MR (PMR) should be first authenticated by a 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. Ryu, et al. Expires January 9, 2006 [Page 3] Internet-Draft Failover for Multiple Mobile Routers July 2005 Prefix Peer Binding Update Prefix peer binding update means this binding update message is sent by PMRs. Prefix peer binding update (PPBU) has different meaning 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 a CoA in binding cache of a HA. 3. Peer Multiple Care-of Addresses Registration Peer multiple CoAs registration is an extended version of multiple CoAs registration mechanism for mobile IPv6 [2]. In this draft, a MR can register not only its CoA but also its PMR's CoA as one of multple peer CoAs. An MR carries out prefix binding update to support a multi-homed NEMO consisting of multiple MRs. One of the registered CoAs of PMRs is used to provide seamless connection service when an original MR fails. Registered CoAs in binding cache of a HA is classified into active CoAs and 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. 3.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 the CoA is CoA of a peer MR. The value MUST be zero if the CoA is not a peer MR's CoA but the original MR's CoA. 3.2 Binding Update Structure and Management Additional flags are required in the binding update structure, which are: - Prefix peer flag: MUST be set if the binding update is sent by a peer MR. - Backup flag: MUST be set if the CoA is a peer CoA. Ryu, et al. Expires January 9, 2006 [Page 4] Internet-Draft Failover for Multiple Mobile Routers July 2005 3.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 bit 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 entry has an active field set to 0 and a peer field set to 1. 3.4 Messages Format Changes 3.4.1 Binding Unique Identifier sub-option A new flag (B) is included in the binding unique identifier sub- option to indicate to the HA whether the CoA in the binding update is a peer CoA or not. The rest of the Binding Unique Identifier sub- option format remains the same as defined in [2] 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 CoA is an active CoA. For descriptions of the other fields in the message, see [2] 3.4.2 Binding Update A new flag (P) is included in the binding update to indicate to the HA whether this binding update is sent by its PMR or original MR. The rest of the binding update format remains the same as defined in [2]. Ryu, et al. Expires January 9, 2006 [Page 5] Internet-Draft Failover for Multiple Mobile Routers July 2005 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. 3.4.3 Binding Update Acknowledgment A new flag (P) is included in the binding update to indicate that the HA that processed the corresponding binding update support peer multiple CoAs registration. The flag is set to 1 only if the corresponding binding update have the prefix peer flag (P) set to 1. The rest of the binding acknowledgment format remains the same as defined in [3]. 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 . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ryu, et al. Expires January 9, 2006 [Page 6] Internet-Draft Failover for Multiple Mobile Routers July 2005 Prefix peer Flag (P) The prefix peer flag is set to indicate that the HA that processed the corresponding binding update support backup multiple CoAs registration. It is set to 1 only if the corresponding binding update had the prefix peer flag set to 1. For descriptions of the other fields in the message, see [3] 4. Multiple Mobile Routers Failover In this section, the detailed mechanism of MR failover is described. Generally, an MR uses the wireless channel as an access channel for mobility support. Because this wireless channel has unreliability due to channel error, blackout, or handover, kinds of failures may occur. Among all types of failures, this document is concentrated only on an egress or ingress interface failure and an MR failure. After a HA authenticates and registers a PMR successfully, the PMR should support other failed mobile routers. 4.1 HA Operation 4.1.1 Interface Failure and Recovery When a HA 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 this CoA in a PPBU message is set to 1, the HA regards that an original MR fails. If the HA does not have any entry corresponding to this CoA, it silently discards this message. Every peer CoA in binding cache which active field set to 1 cannot be used because of original MR failure, thus its active field is set to 0. An active field corresponding to this CoA in a PPBU message is set to 1. When the HA receives a PPBU message with the unset backup flag in the Binding Update Identifier sub-option and both active and peer fields corresponding to this CoA in a PPBU message are set to 0, the HA regards that the original MR recovers from failure. If the HA does not have any entry corresponding to this CoA in a PPBU message, it silently discards this message. The recovery notify messages are sent to all PMRs by checking active field currently set to 1. Every peer CoA in binding cache which active field set to 1 need not to be activated because of the failed MR recovery, thus its active field is set to 0. An active field corresponding to this CoA in a BU message is set to 1. 4.1.2 MR Failure and Recovery This operation is identical to interface failure and recovery in the Ryu, et al. Expires January 9, 2006 [Page 7] Internet-Draft Failover for Multiple Mobile Routers July 2005 section 4.1.1. 4.2 MR Operation 4.2.1 Interface Failure and Recovery Any PMR detects an egress (ingress) interface failure of an original MR by receiving a failure notify 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 PPBU ACK, this PMR replies a Failure Notify Acknowledgement to the failed MR. The PMR starts to advertise MNP of the failed MR. The PMR can provide Internet service for fixed and mobile nodes instead of the failed MR. Therefore, if the PMR receives a packet from fixed or mobile nodes belonging to MNPs of the failed MR, it can forward the packet through an appropriate tunnel for seamless connectivity. If an egress (ingress) interface failure is recovered, the original MR sends BU message to its HA. When the PMR receives a Recovery Notify message including MNP of original MR from the HA of the original MR, it stops advertising the MNP of the failed MR. Finally, the PMR replies a Recovery Notify Acknowledge message to the HA of the failed MR. Then, the original MR restarts to advertise its MNP. 4.2.2 MR Failure and Recovery When the original MR fails, the failed MR cannot send a failure notify message to inform its PMRs of the MRr failure and the HA address of the failed MR to perform PPBU. Therefore, any PMR detects failure of the original MR, it first performs a dynamic home agent address discovery (DHAAD) [1] to know 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, it advertises the MNP of the failed MR. Other operations are the same as that of the interface failure in the section 4.2.1. 4.3 Message Format Ryu, et al. Expires January 9, 2006 [Page 8] Internet-Draft Failover for Multiple Mobile Routers July 2005 4.3.1 ICMP Mobile Router Failure Notify The ICMP Mobile Router Failure Notify message is sent by the failed MR to its PMR. By this message, a PMR can know the 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 . . . + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IP Fields: Source Address Home address of the failed MR. Destination Address Home address of the PMR. ICMP Fields: Type 154 Code 0 Cheksum Ryu, et al. Expires January 9, 2006 [Page 9] Internet-Draft Failover for Multiple Mobile Routers July 2005 The ICMP checksum [9]. Identifier An identifier to aid in matching MR failure notify acknowledgment 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. 4.3.2 ICMP Mobile Router Failure Notify Acknowledgment The ICMP Mobile Router Failure Notify Acknowledgment message is used by a PMR to respond to the failed MR that sends an ICMP Mobile Router Failure 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + . . . HA Address . . . + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IP Fields: Source Address Home address of the PMR. Ryu, et al. Expires January 9, 2006 [Page 10] Internet-Draft Failover for Multiple Mobile Routers July 2005 Destination Address Home address of the failed MR. ICMP Fields: Type 155 Code 0 Cheksum 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. HA address HA address of the failed MR. 4.3.3 ICMP Mobile Router Recovery Notify 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, a PMR can know the MNP of the failed MR to stop advertising the MNP of the MR recovered from failure. Ryu, et al. Expires January 9, 2006 [Page 11] Internet-Draft Failover for Multiple Mobile Routers July 2005 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 Cheksum The ICMP checksum [9]. Identifier An identifier to aid in matching MR recovery notify acknowledgment messages to this MR failure recovery message. Ryu, et al. Expires January 9, 2006 [Page 12] Internet-Draft Failover for Multiple Mobile Routers July 2005 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. 4.3.4 ICMP Mobile Router Recovery Notify Acknowledgment The ICMP Mobile Router Failure Recovery Acknowledgment 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: Ryu, et al. Expires January 9, 2006 [Page 13] Internet-Draft Failover for Multiple Mobile Routers July 2005 Type 157 Code 0 Cheksum 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. 5. Security Consideration We do not consider any security issues in this draft. 6. References [1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [2] Wakikawa, R., "Multiple Care-of Addresses Registration", draft-wakikawa-mobileip-multiplecoa-04 (work in progress), June 2005. [3] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. [4] Ernst, T., "Analysis of Multihoming in Network Mobility Support", draft-ietf-nemo-multihoming-issues-02 (work in progress), February 2005. [5] Manner, J. and M. Kojo, "Mobility Related Terminology", Ryu, et al. Expires January 9, 2006 [Page 14] Internet-Draft Failover for Multiple Mobile Routers July 2005 RFC 3753, June 2004. [6] Ernst, T. and H. Lach, "Network Mobility Support Terminology", draft-ietf-nemo-terminology-03 (work in progress), February 2005. [7] Choi, S., "Neighbor MR Authentication and Registration 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. 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/ Ryu, et al. Expires January 9, 2006 [Page 15] Internet-Draft Failover for Multiple Mobile Routers July 2005 Eunkyoung Paik KT Portable Internet Team, Convergence Lab., KT 17 Woomyeon-dong, Seocho-gu Seoul 137-792 Korea Phone: +82-2-526-5233 Fax: +82-2-526-5200 Email: euna@kt.co.kr URI: http://mmlab.snu.ac.kr/~eun/ 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/ Minji Nam KT Portable Internet Team, Convergence Lab., KT 17 Woomyeon-dong, Seocho-gu Seoul 137-792 Korea Phone: +82-2-526-6121 Fax: +82-2-526-5200 Email: mjnam@kt.co.kr URI: http://mmlab.snu.ac.kr/~mjnam/ Appendix A. Appendices A.1 Operation Example Ryu, et al. Expires January 9, 2006 [Page 16] Internet-Draft Failover for Multiple Mobile Routers July 2005 +-----+ +-----+ | HA1 | | HA2 | +--+--+ +--+--+ | | | | +---+----------+----+ MR1 +-----+ | Internet |------| MR1 | +---+----------+----+ CoA1+--+--+ | |MNP1 MR2|CoA2 | +-----+ | | MR2 | | +--+--+ | |MNP2 | | | +--+--------------+--+ | NEMO | +--------------------+ Figure 1. Multi-homed NEMO A.1.1 Interface Failure Suppose that an egress (ingress) interface of MR1 fails in a multi- homed NEMO consisting of MR1 and MR2 as a PMR of MR1. MR1 sends a failure notify message including the HA address of MR1 through an ingress (egress) interface to inform MR2. MR2 sends a PPBU message with an unset backup flag if MR2 has the intention to provide proxy services to MR1 in consideration of its policy and load. The snapshots of binding cache at HA1 after PPBU with the backup flag set and that unset are given as follows. After backup MCoA PPBU w/ backup option HoA: MR1 HoA, CoA: MR1 CoA, BID: 0, Active: -, Peer: - Prefix: MNP1, CoA: MR1 CoA, BID: 0, Active: 1, Peer: 0 Prefix: MNP1, CoA: MR2 CoA, BID: 0, Active: 0, Peer: 1 Figure 2. Binding Cache in HA1 After backup MCoA PPBU w/o backup option HoA: MR1 HoA, CoA: MR1 CoA, BID: 0, Active: -, Peer: - Prefix: MNP1, CoA: MR1 CoA, BID: 0, Active: 0, Peer: 0 Prefix: MNP1, CoA: MR2 CoA, BID: 0, Active: 1, Peer: 1 Ryu, et al. Expires January 9, 2006 [Page 17] Internet-Draft Failover for Multiple Mobile Routers July 2005 Figure 3. Binding Cache in HA1 HA1 MR1 MR2 HA2 | | | | | TUNNEL TID1 | | TUNNEL TID2 | |==============| |==============| | |<- Interface | | | | Failure | | | | FN | | | |------------->| | | PPBU(MR1 Prefix, MR2 CoA) | | |<----------------------------| | | PPBU ACK | | |---------------------------->| | | | FN ACK | | | |<-------------| | | TUNNEL TID3 | | |=============================| | | | | | | | | | Figure 4. Interface Failure Operation After receiving PPBU ACK, MR2 sends RA messages for the MNP1 to a NEMO instead of MR1. Additionally, MR2 should forward outgoing packets 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 HoA, CoA: MR1 CoA, BID: 0, Active: -, Peer: - Prefix: MNP1, CoA: MR1 CoA, BID: 0, Active: 1, Peer: 0 Prefix: MNP1, CoA: MR2 CoA, BID: 0, Active: 0, Peer: 1 Figure 5. Binding Cache in HA1 Now, MR1 sends RA messages again and MR2 stops RA messages for the MNP1. Ryu, et al. Expires January 9, 2006 [Page 18] Internet-Draft Failover for Multiple Mobile Routers July 2005 HA1 MR1 MR2 HA2 | | | | | |<- Recovery | | | BU(MR1 Prefix, MR1 CoA) | | |<-------------| | | | BU ACK | | | |------------->| | | |Re-TUNNEL TID1| | | |==============| | | | RN (MR1 Prefix) | | |---------------------------->| | | RN ACK | | |<----------------------------| | | | RA | | | |------------->| | Fiture 6. Failure Recovery Operation A.1.2 MR Failure When a MR1 itself fails, MR2 detects it and performs DHAAD to know 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 can send a PPBU message with an unset backup flag to HA1. The recovery of the failed MR1 is the same as that of an egress (ingress) interface failure. Ryu, et al. Expires January 9, 2006 [Page 19] Internet-Draft Failover for Multiple Mobile Routers July 2005 HA1 MR1 MR2 HA2 | | | | | TUNNEL TID1 | | TUNNEL TID2 | |==============| |==============| | |<-MR1 Failure | | | | | | | | No RA | | | |- - - - ->| | | ICMP HAAD Request | | |<----------------------------| | | ICMP HAAD Replay(HA1 ADDR) | | |---------------------------->| | | PPBU(MR1 Prefix, MR2 CoA) | | |<----------------------------| | | PPBU ACK | | |---------------------------->| | | TUNNEL TID3 | | |=============================| | | | | | | | | | Figure 7. MR Failure Operation Ryu, et al. Expires January 9, 2006 [Page 20] Internet-Draft Failover for Multiple Mobile Routers July 2005 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 (2005). 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 January 9, 2006 [Page 21]