INTERNET-DRAFT R. Hott
February 11, 2005 NSWC-DD
Timer Enhancements to Reduce Failover Times for the
Virtual Router Redundancy Protocol for IPv4
<draft-ietf-vrrp-ipv4-timers-00.txt>
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]
