[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02                                                      
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]