[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

  XXXX Working Group                 H.Sandick, M.Squire, B.Cain
  Internet Draft                     I. Duncan, B.Haberman

  draft-sandiick-flip-00.txt    Nortel Networks

  February 2000
  Expires XXX 2000


                     Fast LIveness Protocol (FLIP)

Status of this Memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.

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.



Abstract

Networks and network applications must be robust and reliable.  For
many applications and services, such as packetized voice, correcting a
failure must be almost instantaneous.  The first step in correcting a
failure is, of course, detecting that it occurred.  IP routing
protocols and signaling protocols as well as many application layer
protocols incorporate their own keepalive mechanisms to detect
failures.  Typically, these protocols detect failures on the order of
seconds or tens of seconds.  While there are some physical and link
layer technologies that inherently supply link outage detection, not
all link layers do this.  In order to provide for fast failure
detection over any type of lower layer, an IP layer fast keepalive
protocol can be used.  This draft describes such a protocol for quickly
detecting when a network layer interface of a peer has failed.

Table Of Contents

1 Terminology ........................................................2
2 Introduction .......................................................3
3 Protocol Overview ..................................................4
4 Neighbor Discovery and Negotiation .................................5
4.1  Neighbor Discovery ..............................................5


Sandick, Squire, Cain, Duncan, Haberman
1
Internet Draft       Fast Link Liveness Protocol      December 7, 1999

4.2  Parameters ......................................................5
4.3  Negotiation Rules ...............................................6
4.4  FLIP Solicitation Protocol Description ..........................7
4.5  FLIP Advertisement Protocol Description .........................7
4.6  Finite State Machine (FSM) for Neighbor Adjacency ...............8
5 FLIP Hello Protocol ...............................................10
5.1  Protocol Description ...........................................10
5.2  Hello Message Contents .........................................11
5.3  Finite state machine for Hello Message Exchange ................11
6 Hello Exchange over NBMA links ....................................13
7 Default Values ....................................................13
7.1  All-FLIP-Peers .................................................13
7.2  HelloInterval ..................................................13
7.3  PeerDeadInterval ...............................................13
7.4  FLIPAdvertisementInterval ......................................14
7.5  FLIPNewAdvertisement ...........................................14
7.6  FLIPAdvertisementDeadInterval ..................................14
7.7  FLIPNewAdvertisementInterval ...................................14
8 Security Considerations ...........................................14
9 Intellectual Property Considerations ..............................14
10  References ......................................................15
A.  Setting the HelloInterval .......................................15
B.  Formats .........................................................16
B.1  FLIP Advertisement Message .....................................16
B.2  FLIP Solicitation Message ......................................18
B.3  FFLIP Hello Message ............................................19



1  Terminology

Adjacency                     see Neighbor Adjacency

Adjacency failure             Communication with a neighbor interfaces
                              is no longer possible

Device                        The logical entity that owns or controls
                              one or more logical IP interfaces. A
                              device can be a host or a router.

GroupID                       Identifies a particular set of peers,
                              e.g. routers.

Neighbor                      A directly connected peer on a shared
                              subnet.








Sandick, Squire, Cain, Duncan, Haberman                              2
Internet Draft       Fast Link Liveness Protocol      December 7, 1999

Interface                     The physical or logical interface(S) used
                              to communicate on a particular IP subnet.
                              The interface is defined by the IP
                              address for the interface on that subnet.
                              Unnumbered interfaces have the IP address
                              "0.0.0.0"

Neighbor Adjacency            Established communication with peer over
                              on a shared IP subnet defined by the
                              respective IP addresses of the local and
                              peer's interfaces. In the case of
                              unnumbered interface, the interface is
                              defined by the interface and has the IP
                              address "0.0.0.0".

Neighbor Interface            The physical or logical interface(S) that
                              a peer uses to communicate on a
                              particular IP subnet.

Peer                          A target device whose IP connectivity is
                              monitored by another device on the same
                              IP link layer or subnet.

Peer failure                  A Peer becomes unreachable over all of
                              its interfaces

PeerID                        An unique identifier for a Peer


2  Introduction

Networks and network applications must be robust and reliable.  For
many applications and services, such as packetized voice, correcting a
failure must be almost instantaneous.  The first step in correcting a
failure is, of course, detecting that it occurred.  IP routing
protocols and signaling protocols as well as many application layer
protocols incorporate their own keepalive mechanisms to detect
failures.  Typically, these protocols detect failures on the order of
seconds or tens of seconds.  While, there are some physical and link
layer technologies that inherently supply link outage detection, not
all link layers do this.  In order to provide for fast failure
detection over any type of lower layer, an IP layer fast keepalive
protocol can be used.  This draft describes such a protocol for quickly
detecting when a network layer interface of a peer has failed.

This document describes a general-purpose peer-to-peer neighbor
adjacency protocol, which is designed to detect failures at the IP
protocol layer over a variety of media.  This protocol uses periodic
hello messages between peers on the same IP subnet to determine "link
aliveness." We feel that a fast IP layer keepalive is necessary to
assist in detecting failures over a variety of lower layer protocols


Sandick, Squire, Cain, Duncan, Haberman                              3
Internet Draft       Fast Link Liveness Protocol      December 7, 1999

that may or may not provide this capability themselves.  A generic fast
hello protocol provides mainly two benefits.  The first is a generic
protocol for neighbor discovery.  The second is support for fast link
failures over any media type.

We present three examples to illustrate the usefulness of our protocol.
Currently, there are many "IP only" Internet service providers.  These
providers must rely on failure notifications from a layer-2 network
operated by another carrier.  In some instances the IP only carrier may
wish to have its own methods and parameters for determining failures.
IP routing protocols (e.g. OSPF or IS-IS Hello) for example may be
used, but they typically have lower frequency thresholds at which they
can operate.  Another scenario that illustrates the usefulness of a
generic approach is IP over WDM.  In this case, the IP layer may handle
all of the signaling and control aspects of the network including
aspects of failure detection.  A third scenario might involve a
synchronization protocol between web servers on the same subnet.

3  Protocol Overview

The FFLIP protocol is designed to be generic, extensible and by
definition, work over any types of media including NBMA and broadcast
subnets.  In order to accommodate these somewhat conflicting
requirements, we divide the protocol into two "sub-protocols".

The first sub-protocol, the FLIP Advertisement protocol, is used for
neighbor discovery and parameter negotiation.  This protocol makes use
of a new type of ICMP message.  These advertisements are multicast at a
low frequency and are used to discover FLIP aware neighbors on a local
subnet.  Once neighbors have been discovered, adjacencies are formed.
Advertisements contain a list of neighbors that have been heard from; a
device considers an adjacency to be formed when the device finds its
address in a neighbor's advertisement.  In the case of unnumbered
interfaces the list can only contain one address, "0.0.0.0".  Once an
adjacency is established, devices use a simple negotiation method to
decide on operating parameters.  This negotiation is simply an
agreement on the lowest common denominator of each parameter between
the parameters sent in their advertisements.

For each adjacency established with the advertisement protocol, a
second sub-protocol, the FLIP Hello protocol is used as a fast
keepalive between two peers.  This protocol is the actual protocol used
for fast link failure detection.  It defines a fixed format hello
message that is exchanged (unicast) between every adjacency.  The FLIP
hello is used to determine the status of a link and therefore operates
at very high frequencies; it may be desirable to implement this
protocol in a hardware implementation.  For example, a device may
include processing for FLIP Hellos in a line card.

In order to provide fast detection for other protocols operating in a
device (e.g. routing protocols), an implementation should treat FFLIP


Sandick, Squire, Cain, Duncan, Haberman                              4
Internet Draft       Fast Link Liveness Protocol      December 7, 1999

detected failures as neighbor adjacency failures.  FFLIP is independent
of other individual hello protocols (e.g. OSPF or IS-IS Hello), and can
be used to signal link failures in a device.


4  Neighbor Discovery and Negotiation

4.1 Neighbor Discovery

In order to discover other FFLIP capable peers on a subnet, the FLIP
Advertisement is used.  The FFLIP Advertisement is similar to the ICMP
Router Advertisement protocol. We define a new message type: FFLIP
Advertisement, which is used by peers to advertise their support of the
protocol and to advertise their configured parameters.

In order to discover all neighbors on a subnet, FFLIP Advertisements
are multicast to the All-FFLIP-Peers address and contain a PeerID.
Devices send these messages periodically over IP interfaces that have
the FLIP protocol enabled.  A neighbor adjacency, i.e. bi-directional
connectivity, is established by listing neighbor interfaces that have
been heard in an advertisement.  Once a FLIP Advertisement is heard
from a neighbor, the neighbor interface is listed in a device's own
FLIP Advertisement for that interface.  In the case of unnumbered
interfaces the address "0.0.0.0" is added to the list. If an
advertisement containing the receiving devices interface has not been
received by a neighbor in [FLIPAdvertisementDeadInterval] seconds, that
neighbor is declared down.

All FLIP messages use ICMP Type field (X).  The FLIP Advertisement is
the only currently defined message with the ICMP Code field set to
zero.


4.2 Parameters

FFLIP Advertisements are also used to advertise the parameters
necessary for the operation of the protocol.  The FLIP Advertisement
contains several parameters: the HelloInterval, the PeerDeadInterval,
the PeerID of the transmitting device, The GroupID and the list of
neighbor interfaces that the transmitting device has heard from.

The HelloInterval and the PeerDeadInterval are used to set the
operational parameters of the FLIP Hello message. The HelloInterval
indicates how often FFLIP Hello messages will be sent and is measured
in milliseconds (ms).  For example, if the value is 3 then the
advertising device would send the Hello message at least every 3 ms.
The PeerDeadInterval indicated how long a device should wait (from the
last Hello) before declaring a neighbor failure.  PeerDeadInterval is
specified in milliseconds. This value MUST be larger than the
HelloInterval and should be at least 3 times the value of the
HelloInterval. (NOTE: Should there be a minimum multiple, say 3 time)


Sandick, Squire, Cain, Duncan, Haberman                              5
Internet Draft       Fast Link Liveness Protocol      December 7, 1999



The PeerID is the globally unique identifier assigned to that device.
A device must use the same PeerID in all FLIP Advertisements.  The
PeerID allows receiving devices to correlate multiple interfaces with
the peer that owns them.

The GroupID identifies the group of peers that this advertisement is
targeted for.

The list of neighbor interfaces is used to establish neighbor
adjacencies.  The list contains the neighbor interfaces that a device
has received advertisements from over a particular IP link layer. In
the case of unnumbered interfaces the list can only contain one
address, "0.0.0.0". If a device receives an advertisement containing
its interface, the device assumes that connectivity to that neighbor
has been established. In the case of an unnumbered interface the IP
address "0.0.0.0" indicates the device's advertisement has been
received.

Note: A device MAY use the HelloInterval and PeerDeadInterval for all
of its interfaces, or it MAY use different ones over different
interfaces.  These parameters MUST be configurable for each device, and
the timer intervals SHOULD be configurable independently on each
interface.  The means by which a device configures the values for its
initial operation are outside this specification.

4.3 Negotiation Rules

It is possible that two neighbors will be configured with different
values for their operating parameters.  Values must be agreed upon
before the hello messaging can begin.  FLIP uses a simple negotiation
scheme that is simply lowest common denominator.  FLIP negotiation is
on a per adjacency basis, NOT a subnet basis.  The rules for
negotiation are:

    (a) If the HelloInterval values are different, then the parameters
         (HelloInterval and PeerDeadInterval) from the neighbor
         associated with the larger HelloInterval are selected to be
         used by both neighbors.
    (b) Otherwise, if the PeerDeadInterval values are different, then
         the parameters associated with the neighbor advertising the
         larger PeerDeadInterval are selected to be used by both
         neighbors.

The larger values are selected (instead of the smaller values) to
accommodate environments where one of the devices cannot operate at the
same parameters as the other device.  In this case, the faster device
must in a sense `slow down' for the slower device.




Sandick, Squire, Cain, Duncan, Haberman                              6
Internet Draft       Fast Link Liveness Protocol      December 7, 1999

After a negotiation is applied, a device does not change the parameters
that are sent in its advertisement.  The parameters sent in an
advertisement are a device's configured parameters and may or may not
be the actual parameters used with a given adjacency.  The actual
parameters used with an adjacency are those which are computed from the
negotiation rules.

Each device SHOULD apply a small jitter factor to the HelloInterval,
rendering the actual parameter to between 75% and 100% of the selected
value.  The same jitter should be applied to the PeerDeadInterval

4.4 FLIP Solicitation Protocol Description

The FLIP protocol is enabled per IP interface; FLIP protocol state is
per interface, per neighbor.  When a FLIP enabled interface first
become enabled it sends a FLIP Solicitation message to the
AllFLIPDevices address.  The address is sent FLIPSolicitationReSend
times FLIPSolicitationInterval apart. When a device receives a FLIP
Solicitation message it unicasts a FLIP Advertisement to the source
address of the Solicitation message.  The Advertisement contains the
source address of the Solicitation in it list of neighbor interfaces.
The FLIP Solicitation message uses the same format as the FLIP
Advertisement but some parameters are set differently.

A valid FLIP Advertisement is one which:
                     1.
                        IP header and ICMP checksums pass
                     2.
                        ICMP Type = X
                     3.
                        ICMP Code = 1
                     4.
                        HelloInterval > 0
                     5.
                        PeerDeadInterval > HelloInterval
                     6.
                        Valid Address Family
                     7.
                        Non-zero PeerID
                     8.
                        Neighbor Interfaces = 0


4.5 FLIP Advertisement Protocol Description

After the FLIP Solicitation message is sent  FLIP Advertisements are
sent every FFLIPAdvertisementSeconds with a small amount of jitter.
When a device receives a FLIP Advertisement from a neighbor, it lists
the neighbor interface in its own FLIP advertisements for that
interface.  If a device receives an advertisement containing its own
interface in one of the neighbor fields and it has listed that neighbor
in its own advertisement, a FLIP adjacency is established.  If an
advertisement containing the receiving device interface has not been
received from a neighbor in FLIPAdvertisementDeadInterval seconds, then
that neighbor is removed from subsequent advertisements (for that
interface) and the adjacency is considered down.

Once a FLIP adjacency is established, a device applies the negotiation
rules in section 4.3 on a per neighbor basis.  They immediately begin


Sandick, Squire, Cain, Duncan, Haberman                              7
Internet Draft       Fast Link Liveness Protocol      December 7, 1999

the FLIP Hello protocol described in section 5.  If there is an
adjacency failure, then the FLIP Hello protocol is ceased for that
neighbor.

When a FLIP Advertisement is received, the source IP address of the
advertisement should be stored with all neighbor state.  This address
is used in the FLIP Hello protocol (see section 5).  In the case of
unnumbered interface the source address is "0.0.0.0".

A valid FLIP Advertisement is one which:

                   1.
                     IP header and ICMP checksums pass
                   2.
                     ICMP Type = X
                   3.
                     ICMP Code = 0
                   4.
                     HelloInterval > 0
                   5.
                     PeerDeadInterval > HelloInterval
                   6.
                     Valid Address Family
                   7.
                     Non-zero PeerID

If a device chooses to modify its FLIP parameters for an interface, it
MUST multicast a FLIP Advertisement with the new parameters at least
FLIPNewAdvertisement times within FLIPNewAdvertisementInterval.  When a
FLIP Advertisement is received from a neighbor, which would cause a
renegotiation, a node  should immediately unicast an advertisement of
its own on the interface to that neighbor.  If a renegotiation occurs,
the new parameters should immediately be applied to the FLIP Hello
protocol.

If a device decides that a particular neighbor has not adjusted its
operating parameters sufficiently, then the device MAY unicast an FLIP
Advertisement to that neighbor.  If the parameters are sufficiently
different, the neighbor's hello protocol will fail and it will have to
re-discover this device and its new operating parameters.



4.6 Finite State Machine (FSM) for Neighbor Adjacency

This FSM formally details how neighbor adjacency state is created,
maintained and deleted.  We adopt the notation of X(y), where X is the
new state transitioned to after action y has been applied.  A "-" means
that no state transition or action is performed.  This FSM is the state
machine for the FLIP adjacency protocol. Behavior global to the
interface such as the periodic sending of FLIP Advertisements are not
part of this FSM.








Sandick, Squire, Cain, Duncan, Haberman                              8
Internet Draft       Fast Link Liveness Protocol      December 7, 1999

                  State
      |         |         |         |
Input |  0      |  1      |  2      |
------+---------+---------+---------+
      |         |         |         |
   A  | -(n)    |  0(n)   | 0(d)    |
------+---------+---------+---------+
      |         |         |         |
      |         |         |         |
   B  | 1(n)    | -(n)    | 1(d)    |
------+---------+---------+---------+
      |         |         |         |
   C  | 2(b)    | 2(b)    | -(a)    |
------+---------+---------+---------+
      |         |         |         |
   D  | NA      | NA      | -(c)    |
------+---------+---------+---------+
      |         |         |         |
   E  | NA      | NA      | 0(e)    |
------+---------+---------+---------+


States
------

Init (0): This is the initial state at which the protocol begins.  In
this state, FLIP Advertisements are sent; No advertisements have been
received for the neighbor.

Half (1): This state is transitioned to after an advertisement is
received from the neighbor. But bi-directional connectivity has not yet
been established, i.e. A FLIP Advertisement containing the receiving
devices interface has not been received.

Full (2): When a receiving device sees its interface in its neighbor's
advertisement then bi-directional connectivity has been established and
this state is established.  In this state, an adjacency is established
and the FLIP Hello protocol should begin operation over this adjacency.

Inputs
------

A  - FLIP Reset
B  - Advertisement from neighbor without receiving device's interface
present
C  - Advertisement from neighbor with receiving device's interface
present
D  - Advertisement received with parameters changed (i.e. re-
negotiation)
E  - FLIPAdvertisementDeadInterval expires

Actions

Sandick, Squire, Cain, Duncan, Haberman                              9
Internet Draft       Fast Link Liveness Protocol      December 7, 1999

-------

a  - Reset FLIPAdvertisementDeadInterval timer
b  - Multicast a FLIPAdvertisement on interface having added the
neighbor interface address to the list of the list of Neighbor
Interfaces; set FLIPAdvertisementDeadInterval timer; reset the
FLIPAdvertisementInterval timer; adjacency established; begin FLIP
Hello protocol
c  - Update operational parameters for FLIP Hello message exchange;
unicast FLIPNewAdvertisements number of FLIP advertisements to
neighbor; reset the FLIPAdvertisementInterval timer; reset
FLIPAdvertisementDeadInterval;
d  - Stop FLIPAdvertisementDeadInterval timer; multicast a
FLIPAdvertisement on interface; reset the FLIPAdvertisementInterval
timer; stop FLIP Hello exchange;
e  - stop FLIP Hello exchange
n  - no op
NA - Not applicable

5  FLIP Hello Protocol

5.1 Protocol Description

The FLIP Hello protocol is used as a fast keepalive protocol for
determining the status of neighbor adjacencies.  This protocol is
designed to operate at high frequencies for quickly detecting link and
device failures.  An implementation may choose to implement this
protocol in hardware in order to achieve the high frequency rates
required to send and receive hello messages.

The FLIP Hello is a simple fixed format message exchanged by devices.
After a neighbor adjacency has been established via the FLIP
Advertisement protocol and parameter negotiations have resolved, a
device sends unicast FLIP Hello messages to the neighbor interface.
The Hellos MUST be sent every HelloInterval.  Each device SHOULD apply
a small jitter factor to the HelloInterval, rendering the actual
parameter to between 75% and 100% of the selected value.  The same
jitter should be applied to the PeerDeadInterval. The jitter should be
calculated once at the beginning of the hello exchange and used until
the neighbor adjacency has failed.

FLIP Hello messages contain a bit for detecting bi-directional
connectivity.  If the device has received a hello message from this
neighbor adjacency within the last PeerDeadInterval, it sets the
HelloHeard bit in the hello messages sent back to that neighbor
interface.  This bit will set as long as a Hello message has been
received from the neighbor interface within the PeerDeadInterval.  If
the received message has the HelloHeard bit set, then there is
successful bi-directional communication with this neighbor, and the
neighbor interface is considered to be active.



Sandick, Squire, Cain, Duncan, Haberman                             10
Internet Draft       Fast Link Liveness Protocol      December 7, 1999

A device must receive a Hello message from a neighbor interface with
the HelloHeard bit set within the PeerDeadInterval or, it considers
that neighbor adjacency to be down.  If connectivity is lost, a FLIP
protocol implementation should signal a neighbor adjacency failure.
How this information is propagated within a device is an implementation
issue and beyond the scope of this document.



5.2 Hello Message Contents

The FLIP Hello message is a fixed format message, designed to be
lightweight and therefore simple enough to be processed in hardware
with minimal effort. Therefore, it carries limited information.

The FLIP Hello message is carried in an IP packet with IP protocol type
X.  The source address in the IP header is the address that the sending
device uses for the interface that it is transmitting on.  The
destination address is the source address from the neighbor's FLIP
Advertisement.  In the case of unnumbered interfaces the source and
destination addresses are both set to "0.0.0.0".  For Differentiated
Service aware networks the DS field will be set in accordance with the
Differentiated Services architecture to CS6, b'110xxx [RFC2476].

The body of the packet contains a 4-byte bit field. The first bit is
the HelloHeard bit, and indicates that the sender has received a hello
message from the this neighbor within the PeerDeadInterval.  All other
bits are reserved at this time. A valid FLIP Hello is one which:
               1.                   IP Protocol Type = X
               2.                   ??

5.3 Finite state machine for Hello Message Exchange

This finite state machine specifies the protocol for a hello exchange
with one neighbor interface.


















Sandick, Squire, Cain, Duncan, Haberman                             11
Internet Draft       Fast Link Liveness Protocol      December 7, 1999


               State
      |      |      |      |      |
Input |  0   |  1   |  2   |  3   |
------+------+------+------+------+
      |      |      |      |      |
      |      |      |      |      |
   A  | 1(a )| -(n )| -(n )| -(n )|
------+------+------+------+------+
      |      |      |      |      |
      |      |      |      |      |
   B  | -(n )|  3(c)|  3(c)|  -(f)|
------+------+------+------+------+
      |      |      |      |  2(d)|
      |      |      |      | -or- |
   C  | -(n )|  2(n)|  -(n)| -(n )|
------+------+------+------+------+
      |      |      |      |      |
      |      |      |      |      |
   D  |   NA |   NA |   NA |  1(e)|
------+------+------+------+------+
      |      |      |      |      |
      |      |      |      |      |
   E  | -(n )| 0(g )|  0(g)|  0(e)|
------+------+------+------+------+
      |      |      |      |      |
      |      |      |      |      |
   F  |   NA | -(a )| -(b )|  -(b)|
------+------+------+------+------+



States
--------

0 -  Reset
1 -  Neighbor Adjacency established
2 -  Hello received with HelloHeard bit Off
3 -  Hello received with HelloHeard bit On:
     Bi-directional connectivity established


Inputs
------

A _ Neighbor Adjacency established
B - Hello HelloHeard bit On
C - Hello HelloHeard bit Off
D - PeerDeadInterval Pops
E _ Neighbor Adjacency failed
F - HelloInterval pops


Sandick, Squire, Cain, Duncan, Haberman                             12
Internet Draft       Fast Link Liveness Protocol      December 7, 1999

Actions
-------

a - Send hello with HelloHeard bit off; reset HelloInterval timer
b - Send hello with HelloHeard bit on; reset HelloInterval timer
c - Indicate two-way connectivity has been  established;
    reset PeerDeadInterval timer
d - Indicate two-way connectivity has been
    lost; stop PeerDeadInterval timer
e - Indicate two-way connectivity has been
    lost. Stop PeerDeadInterval timer
    timer;  stop HelloInterval timer
f - Reset PeerDeadInterval timer
g - Stop HelloInterval timer
f - Reset PeerDeadInterval timer
n - Do nothing
NA- Not applicable



6  Hello Exchange over NBMA links

TDB

7  Default Values

The following describes the values and ranges of the variables and
timers used in the FLIP protocol.


7.1 All-FLIP-Peers

The All-FLIP-Peers multicast address has the following possible values:

           o  IPv4 _ 224.0.0.12
           o  IPv6 _ FF02:0:0:0:0:0:0:C







7.2 HelloInterval

The HelloInterval indicates how often FLIP Hello Messages are
transmitted on an interface.  The lower bound on the HelloInterval is 1
ms.  Default value: 3 ms.


7.3 PeerDeadInterval


Sandick, Squire, Cain, Duncan, Haberman                             13
Internet Draft       Fast Link Liveness Protocol      December 7, 1999

The PeerDeadInterval specifies the amount of time a device should wait,
since the last Hello message, before declaring a neighbor down.  The
PeerDeadInterval has a lower bound of 3*HelloInterval and an upper
bound of 2^32 ms.  Default value: 12 ms.


7.4 FLIPAdvertisementInterval

The FLIPAdvertisementInterval controls how often FLIP Advertisements
are sent.  The lower bound on the interval is 3 seconds.  The upper
bound is 1800 seconds.  Default value: 600 seconds.


7.5 FLIPNewAdvertisement

The FLIPNewAdvertisement variable specifies how many advertisements
must be sent upon the activation of an IP interface.  The lower bound
is 2 and the upper bound is 10.  This variable should be tuned to
correspond to the loss characteristics of the media.  All devices on an
IP subnet should have this variable configured the same.  Default
value: 3.


7.6 FLIPAdvertisementDeadInterval

The FLIPAdvertisementDeadInterval is the amount time that can elapse
without an advertisement being received with the receiving devices IP
address in the list of neighbors.  The lower bound is
[FLIPAdvertismentInterval].  Default value:
2*FLIPAdvertisementInterval.


7.7 FLIPNewAdvertisementInterval


The FLIPNewAdvertisementInterval specifies the timeframe in which the
[FLIPNewAdvertisement] advertisements must be sent.  Default value:
[FLIPNewAdvertisment] seconds.


8  Security Considerations

TBD.

9  Intellectual Property Considerations

Nortel Networks may seek patent or other intellectual property
protection for some or all of the technologies disclosed in this
document.  If any standards arising from this document are or become
protected by one or more patents assigned to Nortel Networks, Nortel
intends to disclose those patents and license them on reasonable and
non-discriminatory terms.

Sandick, Squire, Cain, Duncan, Haberman                             14
Internet Draft       Fast Link Liveness Protocol      December 7, 1999


10 References

[RFC1256]           Deering, S., "ICMP Router Discovery Messages", RFC
                    1256, September 1991.

[IANAAFN]           IANA Address Family Number, http://www.isi.edu/in-
                    notes/iana/assignments/address-family-numbers.
[RFC2474]           Nichols, K., Blake, S., Baker, F. and D. Black,
                    "Definition of the Differentiated Services Field
                    (DS Field) in the IPv4 and IPv6 Headers", RFC 2474,
                    December 1998.





Appendices

A.
  Setting the HelloInterval



There are three factors that affect the bandwidth utilization of FFLIP
Hello messages.  First, is the HelloInterval or the frequency with
which the messages are sent.  The second factor is the speed of the
link.  The third factor is how many neighbor adjacencies are maintained
over one link (for multi-access links only).   Let t represent the
number of milliseconds between hello packets, m represent the Mbps
available to L2 data over that link, p represent the size of the hello
packet in bits at Layer 2, and n represent the number of devices
sharing the bandwidth over that link.  The general formula to determine
the percentage of the Layer 2 bandwidth used by the hello messages
between the n peers over that link:

                           pn(n-1)
    Bandwidth percentage = --------
                             10tm

For full duplex links, this percentage should be divided by two.

The following table shows how much bandwidth a 64-byte Hello message
uses over various media speeds and hello intervals.  Full duplex
communication is assumed for a single pair of neighbors.  Note: 64-byte
size packet is selected because it is the minimum size on Ethernet
subnets.







Sandick, Squire, Cain, Duncan, Haberman                             15
Internet Draft       Fast Link Liveness Protocol      December 7, 1999

millisecond  = ms

        Percentage of link for 64-byte packet
        transmitted every time period

                  10Mb       100Mb       1Gigb
         +------+--------+----------+----------+
 3ms     | 64 B |   1.7& |  .17%    |  .017%   |
         +------+--------+----------+----------+
 6ms     | 64 B |   .85% |  .085%   |  .0085%  |
         +------+--------+----------+----------+
 9ms     | 64 B |   .57% |   .057%  |  .0057%  |
         +------+--------+----------+----------+
12ms     | 64 B |   .43% |   .043%  |  .0043%  |
         +------+--------+----------+----------+
         |               .                     |
         |               .                     |
         |               .                     |


These numbers must be multiplied for each neighbor adjacency maintained
over an interface.  So for example if there are 10 peers over a 100 Mb
interface sending hellos every 9ms would use .57% over switched full
duplex and 1.1 % over switched half duplex and 12.54% over a shared
media.

There are several factors to consider when setting the HelloInterval
and the PeerDeadInterval: speed of the link, quality of the link, timer
precision, number of neighbors, etc.  Additionally, if there is a self
healing subnet technology in the middle of the subnet, the timers may
set with a large enough interval to allow the subnet to fix the link
fault before FFLIP events determine a neighbor adjacency failure to be
down.

B.
  Formats

B.1    FLIP Advertisement Message
















Sandick, Squire, Cain, Duncan, Haberman                             16
Internet Draft       Fast Link Liveness Protocol      December 7, 1999


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            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Hello Interval                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       PeerDeadInterval                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  GroupID      |  Reserved     |    Address Family Number      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            PeerID                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Neighbor Interface #1                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             . . .                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Neighbor Interface #X                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


IP Fields:

     Source Address           An IP address belonging to the interface
                              from which this message is sent.

     Destination Address      The configured multicast Advertisement
                              Address or the IP address of a
                              neighboring host.

     Time-to-Live             1


ICMP Fields:

     Type                     X

     Code                     0 {FLIP Advertisement)

     Checksum                 The 16-bit one's complement of the one's
                              complement sum of the ICMP message,
                              starting with the ICMP Type.  For
                              computing the checksum, the checksum
                              field is set to 0.

     HI                       HelloInterval _ This interval is the time
                              period between successive FLIP Hello
                              messages. Measured in milliseconds




Sandick, Squire, Cain, Duncan, Haberman                             17
Internet Draft       Fast Link Liveness Protocol      December 7, 1999

     PDI                      PeerDeadInterval _ If this device does
                              not receive a FFLIP Hello message from
                              the neighbor interface within this time
                              period, it will consider the link to be
                              down.  Measured in milliseconds.

     GroupID                  Identifies a particular set of peers,
                              e.g. routers.

     Reserved                 must be all zeros


     Address Family Number    0    Reserved
                                   1    IP (IP version 4)
                                           2    IP6 (IP version 6)


     PeerID                   The sending peer's globally unique IP
                              identifier.
                              Length is per Address Family.

     Neighbor Interface X     A list of all source IP addresses of all
                              FLIP Advertisements that have been heard
                              on this interface.  Length of each
                              address is per Address Family.

  B.2  FLIP Solicitation Message

The message is the same format as the FLIP Advertisement.  The fields
are set the same with the following exceptions:

IP Fields:

     Destination Address      The configured multicast Advertisement


ICMP Fields:

     Type                     X

     Code                     1 {FLIP Solicitation)


     Neighbor Interface X     A list of all source IP addresses of all
                              FLIP Advertisements that have been heard
                              on this interface.  The field should be
                              empty and MUST be ignored by the
                              receiving device





Sandick, Squire, Cain, Duncan, Haberman                             18
Internet Draft       Fast Link Liveness Protocol      December 7, 1999

  B.3  FFLIP Hello 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                           IP Header                           |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|H|                          Reserved                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

IP Fields:

DSCP  This is the Differential Services Code Point.  If supported set
to CS6, b'110xxx
     Source Address           An IP address belonging to the interface
                              from which this message is sent.

     Destination Address      The IP address of a neighboring host.

     Time-to-Live             1

     IP Protocol Type         FFLIP Protocol (type X)



   Hello Fields:

     H Bit                    HelloHeard bit. The transmitting device
                              has received a hello message from the
                              target of this message.

     Reserved                 set to all zeros


Authors' Addresses

Hal Sandick
Nortel Networks
4309 Emperor Blvd
Suite 200
Durham, NC 27703
email: hsandick@nortelnetworks.com

 Matt Squire
Nortel Networks
4309 Emperor Blvd
Suite 200
Durham, NC 27703

Sandick, Squire, Cain, Duncan, Haberman                             19
Internet Draft       Fast Link Liveness Protocol      December 7, 1999

email: msquire@nortelnetworks.com

Brad Cain
Nortel Networks
600 Technology Park
Billerica, MA 01821
Email: bcain@nortelnetworks.com

Brian Haberman
Nortel Networks
4309 Emperor Blvd
Suite 200
Durham, NC 27703
email: haberman@nortelnetworks.com

Ian Duncan
Nortel Networks
130 COLONNADE ROAD
NEPEAN, ONTARIO K2E 1B6
email: iduncan@nortelnetworks.com



































Sandick, Squire, Cain, Duncan, Haberman                             20


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/