INTERNET-DRAFT R. Hott February 11, 2005 NSWC-DD Timer Enhancements to Reduce Failover Times for the Virtual Router Redundancy Protocol for IPv4 Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. 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 expires on August 11, 2005. Abstract This memo identifies a new requirement for the Virtual Router Redundancy Protocol (VRRP) for IPv4 and proposes candidate implementation approaches to address this requirement. VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IP address(es) associated with a virtual router is called the Master, and forwards packets sent to these IP addresses. The election process draft-ietf-vrrp-ipv4-timers-00.txt [Page 1] INTERNET-DRAFT VRRP IPv4 Timers February 2005 provides dynamic fail over in the forwarding responsibility should the Master become unavailable. The new requirement is for VRRP for IPv4 to support sub-second fail over from the Master. draft-ietf-vrrp-ipv4-timers-00.txt [Page 2] INTERNET-DRAFT VRRP IPv4 Timers February 2005 Table of Contents 1. Introduction...............................................4 2. Required Capability........................................5 3. VRRP Fail Over Overview....................................5 4. Candidate Implementation Approaches........................7 4.1 Advertisement Interval.................................7 4.2 Timer Adjustments......................................9 5. Operational Issues........................................10 6. Security Considerations...................................10 7. Intellectual Property.....................................10 8. Acknowledgments...........................................11 9. IANA Considerations.......................................11 10. Normative References......................................11 11. Informative References....................................11 12. Authors' Address..........................................11 13. Disclaimer of Validity....................................12 14. Copyright Statement.......................................12 draft-ietf-vrrp-ipv4-timers-00.txt [Page 3] INTERNET-DRAFT VRRP IPv4 Timers February 2005 1. Introduction VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IP address(es) associated with a virtual router is called the Master, and forwards packets sent to these IP addresses. The election process provides dynamic fail over in the forwarding responsibility should the Master become unavailable. The new requirement is for VRRP for IPv4 to support sub-second fail over from the Master. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. 1.1 Scope The remainder of this document provides a description of the sub-second fail over requirement, a discussion of the factors that impact the fail over time period, and candidate implementation approaches for VRRP for IPv4. 1.2 Definitions VRRP Router A router running the Virtual Router Redundancy Protocol. It may participate in one or more virtual routers. Virtual Router An abstract object managed by VRRP that acts as a default router for hosts on a shared LAN. It consists of a Virtual Router Identifier and an a set of associated IP address(es) across a common LAN. A VRRP Router may backup one or more virtual routers. IP Address Owner The VRRP router that has the virtual router's IP address(es) as real interface address(es). This is the router that, when up, will respond to packets addressed to one of these IP addresses for ICMP pings, TCP connections, etc. draft-ietf-vrrp-ipv4-timers-00.txt [Page 4] INTERNET-DRAFT VRRP IPv4 Timers February 2005 Primary IP Address An IP address selected from the set of real interface addresses. One possible selection algorithm is to always select the first address. VRRP advertisements are always sent using the primary IP address as the source of the IP packet. Virtual Router Master The VRRP router that is assuming the responsibility of forwarding packets sent to the IP address(es) associated with the virtual router, and answering ARP requests for these IP addresses. Note that if the IP address owner is available, then it will always become the Master. Virtual Router Backup The set of VRRP routers available to assume forwarding responsibility for a virtual router should the current Master fail. 2. Required Capability This section outlines the new feature that is required for VRRP for IPv4 implementations. That feature is the support for sub-second fail over from the Master. Within the U.S. Navy, and other commercial sectors, there exists special purpose computing environments with survivability requirements which cannot tolerate prolonged service outages. These environments are controlled local area networks interconnecting mission critical computing resources. VRRP for IPv4 is a standards based protocol that could help to address the survivability aspect of the default router. At present, proprietary alternatives to VRRP are used in these environments that require sub-second fail over. The current work in progress for VRRP for IPv6 is addressing the need for sub-second fail over. This capability is also needed for IPv4. 3. VRRP Fail Over Overview Within the current standard for VRRP for IPv4, RFC 3768, there are two user configurable variables that can affect fail over time from the Virtual Router Master. draft-ietf-vrrp-ipv4-timers-00.txt [Page 5] INTERNET-DRAFT VRRP IPv4 Timers February 2005 The first variable is the Advertisement Interval. Its value has a direct impact on fail over time. The Advertisement Interval is the time interval between ADVERTISEMENTS. This variable is an eight bit field in the VRRP for IPv4 packet and its value is specified in seconds. The default value for this variable is one second. The second variable is the Priority. It specifies the sending VRRP router's priority for the virtual router. This variable is an eight bit unsigned integer field in the VRRP for IPv4 packet. The higher the value the higher the priority. Its impact on the fail over time is in the calculation of a Skew_Time, discussed below. Within the VRRP for IPv4 protocol state machine, for each Virtual Router, in addition to Advertisement Interval and Priority, the following parameters impact the fail over time: Skew_Time Time to skew Master_Down_Interval in seconds. Calculated as: ( (256 - Priority) / 256 ) Master_Down_Interval Time interval for Backup to declare Master down (seconds). Calculated as: (3 * Advertisement_Interval) + Skew_time There are two timers used by the state machines and they are based upon the variables and parameters above. The timers are: Master_Down_Timer Timer that fires when ADVERTISEMENT has not been heard for Master_Down_Interval. Adver_Timer Timer that fires to trigger sending of ADVERTISEMENT based on Advertisement_Interval. Based upon the configurable variables for VRRP for IPv4, the minimum fail over time for VRRP, as specified in RFC 3768, is approximately three seconds. This assumes that the Advertisement Interval is set to one second and the Priority set to 254. The use of ADVERTISEMENTs from the Virtual Router Master and the algorithm for calculating the Master_Down_Timer results in a Virtual Router Backup taking over as the Virtual Router Master when three ADVERTISEMENTs are missed. draft-ietf-vrrp-ipv4-timers-00.txt [Page 6] INTERNET-DRAFT VRRP IPv4 Timers February 2005 4. Candidate Implementation Approaches To achieve sub-second fail over from the Virtual Router Master two areas of the VRRP for IPv4 must be addressed. They are (1) the specification and granularity of the Advertisement Interval and (2) the calculation of the timers used in the Virtual Router Backups. 4.1 Advertisement Interval As stated above, the Advertisement Interval directly impacts the fail over time for VRRP. To achieve sub-second fail over, the Advertisement Interval must be set to less than one second. This section discusses two options for specifying a sub-second Advertisement Interval within the VRRP for IPv4 packet. The first option is to introduce an optional flag that specifies the resolution for the Advertisement Interval. A second option is to align the specification of the Advertisement Interval with the current work in progress for the VRRP for IPv6. For either approach, it is proposed that the resolution used for the Advertisement Interval, to provide the sub-second fail over capability, match the resolution for VRRP for IPv6. The Advertisement Interval is specified in centiseconds. The following two sub-sections provide a discussion of options for specifying a sub-second Advertisement Interval within VRRP for IPv4. 4.1.1 Support for an Advertisement Interval Flag The current standard for VRRP for IPv4, RFC 3768, eliminated the use of the Authenication Type. The standard did not re-allocate the space in the packet inorder to maintain backwards compatibility. Only two bits, from the possible 8 bits, were allocated in the previous version of the standard, RFC 2338, for Authentication Type. This alternative proposes to split the original Authentication Type field into four 1-bit "flags" fields and a shortened 4-bit Authentication Type field. The first flag field, the "C" Flag, would be used to indicate the clock resolution for the Advertisement Interval. When set to zero, the clock resolution would be set to seconds, to maintain backwards compatibility. When set to one (1), the clock resolution would be set to centiseconds. The next three 1-bit flag fields MUST be set to zero and would be reserved for future use. This proposal does change the interpretation of several fields within the VRRP for IPv4 packet, but it still maintains backward compatibility. To support the centisecond capability, a new variable would have to be introduced to indicate the setting for the clock draft-ietf-vrrp-ipv4-timers-00.txt [Page 7] INTERNET-DRAFT VRRP IPv4 Timers February 2005 resolution. This might be used for clock purposes and possibly to differentiate the Skew_Time calculation differences that exist between RFC 3768 and the current working draft for VRRP for IPv6. The revised packet format could look like the following: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Type | Virtual Rtr ID| Priority | Count IP Addrs| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C|R|R|R|Au Type| Adver Int | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Address (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Address (n) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.1.2 Re-defining Advertisement Interval The current work in progress to provide VRRP support for IPv6 has recognized the requirement for sub-second fail over. The result is a draft that has changed the resolution of the Advertisement Interval from seconds to centiseconds and a change to the VRRP packet which expands the size of the Advertisement Interval from 8 bits to 12 bits. Since RFC 3768 removed the authentication methods from VRRP, this option proposes the reclaiming of that portion of the VRRP packet and the alignment of the Advertisement Interval with the VRRP for IPv6 efforts. This change would alter the packet format and would thus require a revision change for VRRP for IPv4. With this change, the Advertisement Interval would be specified in centiseconds, with a default value of 100 centiseconds (1 second) and the revised packet format would be as follows: draft-ietf-vrrp-ipv4-timers-00.txt [Page 8] INTERNET-DRAFT VRRP IPv4 Timers February 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Type | Virtual Rtr ID| Priority | Count IP Addrs| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |(Rsvd) | Adver Int | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Address (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Address (n) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The two fields created or changed are the Rsvd and Advertisement Interval (Adver Int). The Rsvd field MUST be set to zero on transmission and ignored on reception. The Advertisement Interval is a 12-bit field that indicates the time interval (in centiseconds) between ADVERTISEMENTS. The default is 100 centiseconds (1 second). 4.2 Timer Adjustments The primary adjustment that must be made is the change from seconds to centiseconds. If the alternative that maintains backward compatibility is selected, a variable may be required to deal with the differences in clock resolution. It is suggested that the implementation of sub-second timers be consistent with the ongoing work for VRRP for IPv6. Of the variables and timers discussed in Section 3 (VRRP Fail Over Overview), above, all of the variables are defined the same, with the exception of the Skew_Time. RFC 3768 states that Skew_Time is calculated as: ( (256 - Priority) / 256 ). The current work for standardizing VRRP for IPv6 states that Skew_Time is calculated as: ( ( (256 - priority) * Advertisement_Interval ) / 256 ). If the approach is to use FLAGs to indicate the clock resolution, then the variable discribed above could be used to determine which calculation should be used. If the decision is to change the clock resolution, and revise VRRP for IPv4, then it is recommended that the Skew_Time be calculated the same way for both IPv4 and IPv6 implementations. draft-ietf-vrrp-ipv4-timers-00.txt [Page 9] INTERNET-DRAFT VRRP IPv4 Timers February 2005 5. Operational Issues The changes proposed to VRRP for IPv4 are intended to provide additional capabilities to address specific operational requirements, specifically, sub-second fail over from the Master. The use of sub-second timers is not recommended for general purpose networking environments. Missed ADVERTISEMENTS can lead to fail overs. Reducing the time period for fail over, the MASTER_DOWN_TIMER, increases to potential for missed ADVERTISEMENTS, due to network congestion and denial of service attacks. One area for possible future activity for VRRP is in mechanisms that prevent VRRP flapping. This can occur regardless of the Advertisement Interval setting. 6. Security Considerations This draft does not address the security issues relating to VRRP that have been identified in RFC 3768. 7. Intellectual Property 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. draft-ietf-vrrp-ipv4-timers-00.txt [Page 10] INTERNET-DRAFT VRRP IPv4 Timers February 2005 8. Acknowledgments The work presented in this document is based upon the VRRP specification in RFC3768 and the current work in progress for VRRP for IPv6. The authors and contributors of these works are R. Hinden, P. Higginson, R. Hinden, P. Hunt, S. Knight, A. Lindem, D. Mitzel, M. Shand, D. Weaver, and D. Whipple. The author of this document would also like to thank Karen O'Donoghue, Leon Sangroniz, and Changming Liu for their helpful suggestions. 9. IANA Considerations This document has no actions for IANA. 10. Normative References [RFC3768] Hinden, R., Ed., "Virtual Router Redundancy Protocol (VRRP)", RFC 3768, April 2004. 11. Informative References [RFC2338] Knight, S., et. al., "Virtual Router Redundancy Protocol", RFC2338, April 1998. [VRRP-IPv6] Hinden, R., "Virtual Router Redundancy Protocol for IPv6", draft-ietf-vrrp-ipv6-spec-07 (work in progress), September 2004. 12. Author's Address Robert W. Hott Naval Surface Warfare Center Dahlgren Division Code B35 17320 Dahlgren Road Dahlgren, VA 22448-5100 USA Phone: +1 540 653-1497 EMail: robert.hott@navy.mil draft-ietf-vrrp-ipv4-timers-00.txt [Page 11] INTERNET-DRAFT VRRP IPv4 Timers February 2005 13. 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. 14. Copyright Statement Copyright (C) The Internet Society (2004). 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. draft-ietf-vrrp-ipv4-timers-00.txt [Page 12]