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 = 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 = 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 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 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]