Network Working Group K. Kompella
Internet Draft Juniper Networks
Category: Standards Track October 2002
Expires: April 2002
Protocol Liveness Protocol
draft-kompella-rag-plp-00.txt
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.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This document describes a protocol to determine the liveness of
routing protocols such as OSPF and BGP. The basic idea is to have a
single simple mechanism for liveness for all protocols, and thereby
to allow fast detection of failures.
Kompella Standards Track [Page 1]
Internet Draft Protocol Liveness Protocol October 2002
1. Introduction
Most routing protocols have some form of liveness detection built in.
For example, IS-IS [ISIS] and OSPF [OSPF2, OSPF3] have a "hello"
mechanism that lets a router running IS-IS or OSPF know if its
neighbors are still up. Some protocols (such as BGP [BGP4]) use the
underlying transport to determine the liveness of their neighbors (in
BGP's case, TCP keepalives). Some protocols (such as RIP [RIPv2])
have intrinsic liveness mechanisms.
The primary issue with all the above mechanisms is that the time to
detect that one's neighbor is down ranges from seconds to tens or
even hundreds of seconds. However, there are many cases where one
would like to detect that a neighbor is down in a few tenths or even
hundredths of a second. The obvious approach is to allow sub-second
protocol hello timers. For some protocols, this is doable, although
it may require protocol changes. For other protocols, this is not a
feasible approach.
There are two further issues with these liveness mechanisms that
complicate the task of fast detection: (a) each routing protocol has
its own mechanism; (b) hello messages often carry more than just
liveness information, and thus can be fairly large and require some
computational effort to process. (a) means that the approach of
updating each routing protocol to enable fast detection can lead to a
considerable amount of work. (a) and (b) mean that the computational
cost of running fast liveness detection between a pair of neighbors
running multiple protocols can be significant.
This memo proposes a routing protocol independent mechanism for sub-
second liveness detection (more accurately, deadness detection),
called the Protocol Liveness Protocol (PLP). PLP requires no changes
to the packets sent or received by any routing protocol; it does,
however, require some changes in their behavior. It is important to
note that PLP does *not* supercede the existing hello functionality
of routing protocols (if any) -- as mentioned, existing mechanisms
often carry much more information than just liveness, and PLP has no
intention of replacing that. PLP just attempts to speed up deadness
detection.
An ancillary application of PLP is for interface liveness. This is
especially useful for interfaces whose failure detection mechanisms
at the the physical or link layer are slow (such as PPP) or
(presently) non-existent (such as Ethernet).
Kompella Standards Track [Page 2]
Internet Draft Protocol Liveness Protocol October 2002
1.1. Conventions
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 [KEYWORDS].
2. Protocol Liveness Protocol Messages
This section describes PLP messages. (A first-time reader may prefer
to scan just the subsection on "Format of Hello Messages" before
skipping ahead to the next section.)
2.1. PLP Packet Format
PLP packets are IP (v4 or v6) packets with a new protocol ID (TBA by
IANA) (*). Apart from the header, the packet format is identical for
both IPv4 and IPv6. Packets are sent to one or more neighbors; when
the neighbors are directly attached, the source IP address is the
sender's address on that interface (if any; otherwise, the sender's
router ID); the destination IP address is the ALL-PLP-ROUTERS
multicast address (TBA by IANA) or the ALL-ROUTERS multicast address.
When the PLP neighbor is not directly attached, the IP source address
is the sender's router ID, and the destination address is a routable
address belonging to the neighbor. The IP TTL MUST be set to 255.
(*) An alternative to defining a new IP protocol for PLP is to use a
UDP header and a well-defined port for PLP.
All PLP packets contain a single PLP message and are laid out as
follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Common Header |
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message |
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions |
. .
. .
Kompella Standards Track [Page 3]
Internet Draft Protocol Liveness Protocol October 2002
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The total length of the message, i.e., the sum of the lengths of all
sections, is given in the Common Header. Each section is zero-padded
so that its length is a multiple of four octets. The Common Header
has a length of 12 octets. The length of the Message section is
fixed for each Message type. The length of the Extensions section is
inferred as the length of the message minus the lengths of the other
sections.
It is expected that PLP messages will be small enough not to need
fragmentation, although implementations MUST be prepared to deal with
fragmentation and re-assembly.
2.1.1. Common Header Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|r| Version | Message Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The 'r' bit indicates whether the PLP message is being sent to an
directly attached node (r = 0), or to a remote node (r = 1).
The Version field (7 bits) indicates the PLP version number. This
memo describes version 1 of PLP. The Message Type is taken from the
following list.
Type Message
0 Unused
1 Hello
2-255 Reserved for future use
The Length is the combined lengths of the Common Header, Message and
Extensions in octets.
The Router ID is set to the sender's four octet router ID.
PLP messages sent to directly attached neighbors (r = 0) are
associated with an interface. If the interface is numbered, the
Interface Index MAY be set to zero, and the interface identified by
the source IPv4 or IPv6 address in the IP header. Otherwise, the
Kompella Standards Track [Page 4]
Internet Draft Protocol Liveness Protocol October 2002
Interface Index MUST be set to the index allocated by the sending
node for this interface, and the source IP address MUST be an address
identifying the sender.
For PLP messages sent to a node not directly attached (r = 1), the
Interface Index MUST be zero, and the source IPv4 or IPv6 address
MUST be a routable address identifying the sending node.
2.1.2. Extensions
The Extensions section consists of a list of Type-Length-Value
triplets (TLVs). Each TLV has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
. .
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Each message type defines the set of Types it supports, i.e., one
must parse the message before one can interpret the Type. Each Type
defines its own Flags, i.e., one must first parse the Type before one
can interpret the Flags. The Length is the length of the Value field
in octets; the Value field is padded with octets of zero so that the
total length of the TLV is a multiple of four octets.
The Extensions section can have multiple TLVs. If parsing the TLVs
takes one beyond the end of the message (as defined by the Length in
the Common Header), the message has been corrupted and MUST be
discarded.
2.2. PLP Message Formats
2.2.1. Format for Hello Messages
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session | Dead Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
| (64 bits) |
Kompella Standards Track [Page 5]
Internet Draft Protocol Liveness Protocol October 2002
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Registry |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Session can be used to identify several independent PLP sessions
between a pair of routers. Its use will be described in later
revisions.
The Sequence Number is a monotonically increasing 64-bit number with
the first 4-octet word being the higher order word and the second
being the lower order word. A possible implementation of Sequence
Numbers is to use a 32-bit time-of-day (in seconds) for the first
word, and a monotonically increasing counter (that resets to zero
when the time-of-day changes) for the second word. The primary use
of the Sequence Number is to foil replay attacks in the context of
some means of signing PLP messages. (The utility of a Sequence
Number in the Hello message should be re-evaluated when a security
mechanism for PLP is proposed.)
The Dead Interval is specified in microseconds. A router sending a
Hello with a Dead Interval of N tells its PLP neighbor "consider all
the protocols that I'm reporting on dead if you don't hear another
Hello from me in N microseconds".
A Protocol Registry is a 32-bit vector that says for which protocols
liveness reports will be sent in the Hello messages. The semantics
for the bit positions (bit 0 being the Most Significant Bit) of the
Protocol Registry are as follows:
Bit position Protocol
0 BGP
1 IS-IS
2 OSPF v2
3 OSPF v3
4 RIP v1/v2
5 RIP NG
6 PIM
7 DVMRP
8 LDP
9 RSVP
10 LMP
11-30 Reserved (SHOULD be zero)
31 Layer-2
A Protocol Status is a 32-bit vector that parallels the Protocol
Registry. If bit i is set (i.e., is 1), it means that the protocol
Kompella Standards Track [Page 6]
Internet Draft Protocol Liveness Protocol October 2002
represented by bit i is down. Note that bit i in the Protocol Status
vector MUST NOT be set if bit i in the Protocol Registry is not set;
any bit so set SHOULD be ignored by the receiver.
3. PLP Procedures
This section describes the behavior of senders and receivers of PLP
packets.
3.1. Theory of Operation
Suppose routers X and Y are neighbors running (say) IS-IS and RSVP,
and say that X and Y have established an IS-IS adjacency and one or
more RSVP sessions. Both X and Y also are configured with a time
interval (the Dead Interval) in which to send a hello. If X's IS-IS
Dead Interval is 27 seconds, then Y will declare its IS-IS adjacency
with X dead if Y doesn't receive an IS-IS hello from X within 27
seconds of the previous hello. Typically, X will send hellos more
frequently than once every 27 seconds so that even if a hello or two
are lost, the adjacency stays up.
Once X and Y have established various routing protocol "sessions"
between themselves, they can begin exchanging PLP Hellos. A PLP
Hello contains a list of protocols that this Hello is reporting on
(in this case, IS-IS and RSVP), as well as the status of those
protocols (up or down). The Hello message also contains a Dead
Interval. X is essentially saying "If I don't send you a Hello
within the Dead Interval of my previous Hello, declare all protocols
that the last received Hello was reporting on as dead."
Note that the regular IS-IS hellos must also be running. Thus, Y
will declare its IS-IS adjacency with X dead if ANY of the following
occur:
a) no IS-IS hello is received within the IS-IS Dead Interval
of the previous IS-IS hello;
b) a PLP Hello is received, and the Hello states that it is
reporting on IS-IS, AND it states that IS-IS is down;
c) the last received PLP Hello stated that it was reporting on
IS-IS, but no PLP Hello is received in the PLP Dead Interval
following the last Hello.
(Note that if a PLP Hello was never received, (c) doesn't apply.)
Kompella Standards Track [Page 7]
Internet Draft Protocol Liveness Protocol October 2002
3.2. Sender's Processing
An implementation of PLP SHOULD allow configuration of the Dead
Interval and Hello Time (see below), and MUST allow users to turn off
reporting on any given protocol. An implementation MUST also allow
users to turn off running PLP on any given interface or to any given
neighbor.
It is assumed that the PLP module (henceforth called PLPm) can access
the protocol status of the protocols that it has been configured to
report on, as well as report back to the protocols any received
change of state.
Suppose PLPm on node X has been configured to run with neighbor Y
with Dead Interval D (microseconds), Hello Time H (microseconds), and
to report on protocols a, b, ..., z. Note that H is local to a node
-- this value is not transmitted to PLP neighbors. Also, H should be
at most D; typically, however, H would be D/3 or D/4.
If Y is a directly attached neighbor, let X's interface to Y be Z.
0. PLPm first creates an appropriate IP header.
1. PLPm creates a Common Header with:
r = 0 if Y is directly attached, else 1.
Version = 1
Length = 28
Message Type = 1 (Hello)
Interface Index = <index of interface Z or zero>
This Common Header will not change unless the interface index
of Z changes.
2. PLPm creates a Protocol Registry vector R that consists of the
bits corresponding to the configured protocols a ... z set and
the rest unset. PLPm queries each configured protocol for its
status with neighbor Y, and creates a Protocol Status vector S.
Finally, PLPm creates a Hello message with:
Session = 0
Dead Interval = D
Sequence Number = <monotonically increasing number>
Protocol Registry = R
Protocol Status = S
builds an PLP packet with the Common Header and the Hello
message, and sends it to the ALL-PLP-ROUTERS multicast address.
3. PLPm then sets a timer T to expire in H microseconds, and goes
to sleep.
Kompella Standards Track [Page 8]
Internet Draft Protocol Liveness Protocol October 2002
When T expires, PLPm goes back to Step 1. Every time PLPm sends a
Hello, it MUST restart the timer T (with the latest value of H).
3.2.1. Configuration Changes
An implementation MUST limit the number of Hellos sent every Dead
Interval. This requirement overrides any of what follows. Also, an
implementation SHOULD limit how low the Hello Time and Dead Interval
can be set.
If the Hello Time or Dead Interval change, PLPm MAY issue a Hello
before timer T expires. If the protocols to be reported on are
changed such that the new set of protocols to be reported on is a
superset of the old, PLPm MAY issue a Hello before timer T expires.
However, if there is any other change in the protocols to be reported
on, PLPm SHOULD issue a Hello as soon as is reasonable; PLPm SHOULD
send out multiple copies of this Hello to improve the chances of the
neighbors receiving it correctly.
If PLPm can register to be notified by a protocol when the protocol's
status changes, on receiving such a notification with a status
transition from up to down, PLPm SHOULD rebuild the Hello with the
latest values, and send it out as soon as is reasonable. If the
status transition is down to up, PLPm MAY rebuild and send out a
Hello before the timer T expires.
3.3. Receiver's Processing
The PLP module maintains a table of PLP neighbors keyed by
<PLP Session, IP address, Interface Index> that contains:
Field Type Initial Value
Last_Received_Sequence_Number 64-bit integer 0
Last_Received_Protocol_Registry 32-bit vector 0
Last_Received_Protocol_Status 32-bit vector all "down"
Lost_Hellos_Timer timer stopped
When PLPm gets a PLP packet, it may decide based on configuration or
rate-limiting to discard the packet. Otherwise, PLPm does the
following:
0. Sanity-check the packet.
1. Identify the PLP neighbor Y by looking up the key
<Session, Source IP Address, Interface Index> in a table. If no
entry is found, PLP may either discard the packet, or create a
new entry for the key, with initial values as in the table
Kompella Standards Track [Page 9]
Internet Draft Protocol Liveness Protocol October 2002
above.
2. Check that the received Sequence Number is larger than the
Last_Received_Sequence_Number for this key. If not, discard the
packet. Otherwise, update the Last_Received_Sequence_Number;
set New_Registry to the received Protocol Registry; and set
New_Status to the received Protocol Status.
3. If New_Registry == Last_Received_Protocol_Registry, go to Step
4. Otherwise, for each protocol P that is in New_Registry and
not in Last_Received_Protocol_Registry (added protocol):
set Last_Received_Protocol_Status[P] to down;
if (New_Status[P] == up)
call Up(P, Y)
else
call Down(P, Y)
For each protocol P that is in Last_Received_Protocol_Registry
and not in New_Registry (deleted protocol):
set Last_Received_Protocol_Status[P] to down;
call Up(P, Y).
New_Status[P] is status of protocol P in New_Status.
4. If the New_Status != Last_Received_Protocol_Status then
for each changed protocol P,
if (New_Status[P] == up)
call Up(P, Y)
else
call Down(P, Y)
5. Set Last_Received_Sequence_Number = received Sequence Number;
Last_Received_Protocol_Registry = New_Registry.
6. Reset the Lost_Hellos_Timer to fire after the received Dead
Interval.
7. Done processing PLP Hello.
If the Lost_Hello_Timer fires, call Down(P, Y) for each protocol P
that is set in Last_Received_Protocol_Registry for Y, and stop the
timer.
Down(P, Y) invokes protocol P's Down callback (see next section), and
sets Last_Received_Protocol_Status[P] to down.
Up(P, Y) invokes protocol P's Up Callback (see next section). An
implementation SHOULD limit (hold down) the number of times this
callback is actually propagated to the protocol. If Up(P, Y) is sent
Kompella Standards Track [Page 10]
Internet Draft Protocol Liveness Protocol October 2002
to protocol P, then PLPm sets Last_Received_Protocol_Status[P] to up.
3.4. Routing Protocol Changes
Each routing protocol P that supports PLP provides three functions
for PLPm to call: a Status_Check query, an Up callback and a Down
callback. All of these functions take two arguments, the protocol P
and the PLP neighbor Y.
Normally, Status_Check(P, Y) returns "up", regardless of the current
state of P's adjacency with Y. "down" is returned when protocol P is
not configured to run with neighbor Y; or if P is planning to go down
shortly (graceful shutdown). If P doesn't respond in a timely
fashion to the Status_Check() query, PLPm declares the status as
"down".
Down(P, Y) should be treated by P as if its regular hellos (if any)
timed out. Up(P, Y) is generally ignored. The next sections provide
protocol-specific details.
3.4.1. BGP v4
BGP SHOULD treat a PLP Down(BGP, Y) callback just as if the Hold
Timer of the session with neighbor Y had expired (Section 6.5 of
[BGP4]). Following a Down(BGP, Y) call, BGP re-establishes peers as
usual.
BGP ignores PLP Up() callbacks.
3.4.2. IS-IS, OSPF v2 and OSPF v3
IS-IS, OSPF v2 and OSPF v3 SHOULD treat a PLP Down(P, Y) callback
just as they would loss of hellos from neighbor Y. Following a PLP
Down(P, Y) callback, IS-IS, OSPF v2 and v3 re-establish adjacencies
as usual.
IS-IS, OSPF v2 and OSPF v3 ignore PLP Up() callbacks.
3.4.3. RIP v1, v2 and ng
RIP SHOULD respond to a PLP Down(P, Y) callback by immediately
deleting all RIP routes received from Y, as if the "timeout" timer in
Section 3.8 of [RIPv2] (or section 2.3 of [RIPng]) expired for all
those routes.
RIP ignores PLP Up() callbacks.
Kompella Standards Track [Page 11]
Internet Draft Protocol Liveness Protocol October 2002
3.4.4. Other Protocols
The actions of other protocols on receiving Up and Down callbacks
will be described in a future version.
3.5. Interface Liveness
PLP without any protocols registered can act as an interface liveness
protocol for interfaces like Ethernet that don't have layer 2
liveness mechanisms, or others like PPP whose layer 2 liveness
mechanisms may be considered too slow for some purposes.
For PPP interfaces, a Down(Layer-2, Y) callback is ignored unless the
PPP is in state 9 for the interface. If the Down callback is
received while in state 9, the following actions SHOULD be taken:
declare "This-Layer-Down", send a Configure Request, and transition
to state 6 (in the notation of Section 4.1 of [PPP], tld/scr/6).
Up(Layer-2, Y) callbacks are ignored on PPP interfaces.
Ethernet is a bit more complicated as it is a multipoint interface.
A Down(Layer-2, Y) callback SHOULD tell all modules that neighbor Y
is no longer reachable, and appropriate action be taken. An
implementation MAY declare that the Ethernet interface is itself
down; however, this behaviour MUST be configurable.
An Up(Layer-2, Y) callback tells all modules that neighbor Y is again
reachable (or that the Ethernet interface is up).
4. PLP and Graceful Restart
Graceful Restart [BGP-R, G-RSVP, ISIS-R, LDP-R, LDP-FT, OSPF-R], also
known as Hitless Restart allows a protocol to restart while leaving
the forwarding path undisturbed. If a router X and its neighbors are
capable of restarting gracefully, it is not quite as urgent for X's
neighbors to learn when X goes down. However, PLP can pinpoint the
time that X goes down more accurately; this information can be used
for instance to begin restart procedures, or for a more precise
estimate of when to declare that X is beyond recovery.
Kompella Standards Track [Page 12]
Internet Draft Protocol Liveness Protocol October 2002
5. Implementation Notes
Notwithstanding the fact that PLP Hello Dead Intervals are defined in
microseconds, it is suggested that the urge to use Intervals smaller
than 100 miiliseconds be curbed until there is sufficient operational
experience to indicate that smaller intervals are both useful and
scalable.
A useful consequence of running PLP is that the "normal" hellos times
of various routing protocols can be made longer.
Normative References
[BGP4] Rekhter, Y., and T. Li (Editors), "A Border Gateway Protocol 4
(BGP-4)", RFC 1771, March 1995.
[IS-IS] Callon, R.W., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, December 1990.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[OSPF2] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[OSPF3] Coltun, R., D. Ferguson, and J. Moy, "OSPF for IPv6", RFC
2740, December 1999.
[PPP] Simpson, W., (Editor), "The Point-to-Point Protocol (PPP)", STD
51, RFC 1661, July 1994.
[RIPv2] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1998.
[RIPng] Malkin, G., "RIPng for IPv6", RFC 2080, January 1997.
Informative References
[BGP-R] Sangli, S., Y. Rekhter, R. Fernando, J. Scudder and E. Chen,
"Graceful Restart Mechanism for BGP", work in progress.
[G-RSVP] Berger, L., (Editor), "Generalized MPLS Signaling - RSVP-TE
Extensions", RFC-number-in-waiting.
[ISIS-R] Shand, M., "Restart signaling for ISIS", work in progress.
[LDP-R] Leelanivas, M., Y. Rekhter, and R. Aggarwal, "Graceful
Restart Mechanism for LDP", work in progress.
Kompella Standards Track [Page 13]
Internet Draft Protocol Liveness Protocol October 2002
[LDP-FT] Farrel, A. (Editor), "Fault Tolerance for the Label
Distribution Protocol (LDP)", work in progress.
[OSPF-R] Moy, J., P. Pillay-Esnault, and A. Lindem, "Hitless OSPF
Restart", work in progress.
Security Considerations
It is vital that PLP messages be authenticated, as spoofing or
replaying PLP messages may deceive a router about the state of all
its protocol peers. It is not quite as necessary to encrypt the
contents of PLP messages, although that may be required in some
situations.
There is a trade-off to keep in mind here: PLP's essential purpose is
faster hellos, and part of that is achieved by making PLP processing
as cheap as possible. However, strong authentication systems may
impose a severe processing burden.
It is hoped that the output of the RPSec WG provide some help here.
IANA Considerations
Too early to say.
Acknowledgments
Many thanks to Nischal Sheth and Dave Katz, who set my head straight
about IS-IS Hellos. Thanks too to Yakov Rekhter for his comments on
the interaction of PLP and Graceful Restart, and to Mike Davison for
his comments on multicast routing.
Authors' Addresses
Kireeti Kompella
Juniper Networks, Inc.
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
e-mail: kireeti@juniper.net
Kompella Standards Track [Page 14]
Internet Draft Protocol Liveness Protocol October 2002
IPR Notice
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Kompella Standards Track [Page 15]
Internet Draft Protocol Liveness Protocol October 2002
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Kompella Standards Track [Page 16]