INTERNET DRAFT Arumugam R Expiration Date: April 2004 Prabakaran T.S Future Software RSVP Hello State machine draft-aru-praba-rsvpte-hello-state-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. Abstract This document provides a state machine table for RSVP Hello Extension. In the current RSVP-TE Specification[RSVP-TE], there is no state machine specified for processing Hello messages. We believe that defining a common state machine helps interoperability between different Hello implementations. 1. Introduction The RSVP Hello extension[RSVP-TE], provides a mechanism for node to node failure detection. This mechanism is used when notification of link layer failures is not available and unnumbered links are not used, or the failure detection mechanisms provided by the link layer are not sufficient for timely node failure detection. Though the RSVP Hello extension is an optional mechanism, RSVP-TE Fast Reroute[RSVP-TE-FRR] needs this support to detect a Node or Link failure. To simplify and to make the RSVP Hello implementation generic, a state machine has been proposed in this draft. Arumugam & Prabakaran April 2004 [Page 1] INTERNET DRAFT RSVP Hello State machine October 2003 This State machine has been defined as a set of States, Events, New States and State Transition Actions. The set of possible States are STATUS_UNKNOWN, HELLO_NOT_SUPPORTED, HELLO_SUPPORTED and HELLO_SUPPORT_RESET. The set of events that impact the state machine is based on the Incoming Hello Request/Ack messages and Hello Timer/Internal events. 2. Terminology The key words "MUST", "SHOULD", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [RFC-WORDS]. 3. State Machine for RSVP Hello 3.1 States This section describes the various states that are used in the state machine for RSVP Hello. -- STATUS_UNKNOWN This is the initial Hello State when the Neighbor is created and Hello is enabled. Any other state MAY transform to this state when the "Neighbor deletion" or "Hello disable" event occurs. In this state a node periodically sends Hello messages for the configured number of Hello retries. -- HELLO_NOT_SUPPORTED This state means that the neighbor does not support Hello. In this state a back off timer MAY be started for later Hello retries. -- HELLO_SUPPORTED This state means that the neighbor supports Hello. In this state the node periodically sends Hello Request message and expects a Hello Ack message within the time to die interval (3.5 times the Hello Interval) [RSVP-TE]. Arumugam & Prabakaran April 2004 [Page 2] INTERNET DRAFT RSVP Hello State machine October 2003 -- HELLO_SUPPORT_RESET This state means that the neighbor that previously supported Hello, does not support it currently. In this state a node MAY start a exponential back off timer for Hello retries. During Hello retries, the Src_Instance value MUST be different from the previously advertised value[RSVP-TE]. 3.2 Events 3.2.1 Internal Events The set of possible Internal events are Hello Timer timeout events and neighbor creation or deletion events. 3.2.2 External Events The set of possible External events are the receipt of Hello Request Messages and Hello Ack Messages. 3.3 State Transitions The following diagram describes briefly the Hello state transitions. +--------------------------+ +-- | | 1a, 1b, | | HELLO_NOT_SUPPORTED | 1d +-->| |---+ +--------------------------+ | | ^ | 1c 1e, 1f | 2e | | | | | v | | +--------------------------+ | +--| | | 1a, 1b, 2a, | | STATUS_UNKNOWN |---|--+ 2b, 2d, 2f, +->| |<--|--|-----+ 2g +--------------------------+ | | 1c, | ^ | | 2c | 3k | | | | | | | | +--------------------------+ | | | +--| |<--+ | | 3a, 3b, 3e, | | HELLO_SUPPORTED |<-----+ | 3f, 3h, 3j, +->| | | 3d +--------------------------+ | Arumugam & Prabakaran April 2004 [Page 3] INTERNET DRAFT RSVP Hello State machine October 2003 | ^ | 3c, 3g, 3i | 4a, 4c | | | | | v | | +--------------------------+ | +--| | 4h | 4b, 4d, 4e, | | HELLO_SUPPORT_RESET |------------+ 4f, 4g +->| | +--------------------------+ 3.4 State Machine 3.4.1 Hello Request Message Processing 3.4.1.1 State - "STATUS_UNKNOWN/HELLO_NOT_SUPPORTED" State: STATUS_UNKNOWN/HELLO_NOT_SUPPORTED Event: 1a : Neighbor_Src_Instance is zero (0) and Src_Instance field is non-zero. New State: STATUS_UNKNOWN/HELLO_NOT_SUPPORTED Actions: The Neighbor_Src_Instance is updated with the new value. State: STATUS_UNKNOWN/HELLO_NOT_SUPPORTED Event: 1b : Neighbor_Src_Instance is zero (0) and Src_Instance field is zero (0), New State: STATUS_UNKNOWN/HELLO_NOT_SUPPORTED Actions: Ignore. State: STATUS_UNKNOWN/HELLO_NOT_SUPPORTED Event: 1c : Neighbor_Src_Instance non-zero New State: HELLO_SUPPORTED Actions: Send Hello Ack message with destination instance field updated with the neighbor source instance value. 3.4.1.2 State - "HELLO_SUPPORTED" State: HELLO_SUPPORTED Event: 3a : Neighbor_Src_Instance is equal to Dst_Instance field and received Dst_Instance is equal to Src_Instance field. New State: HELLO_SUPPORTED Actions: Send Hello Ack message. State: HELLO_SUPPORTED Event: 3b : Neighbor continues to advertise a wrong non-zero value within the configured number of intervals. New State: HELLO_SUPPORTED Actions: Ignore. Arumugam & Prabakaran April 2004 [Page 4] INTERNET DRAFT RSVP Hello State machine October 2003 State: HELLO_SUPPORTED Event: 3c : Neighbor continues to advertise a wrong non-zero value after the configured number of intervals. New State: HELLO_SUPPORT_RESET Actions: Generate Node failure indication. State: HELLO_SUPPORTED Event: 3d : Neighbor continues to advertise a Hello Request object within the prior Hello interval. New State: HELLO_SUPPORTED Actions: Suppress the generation of Hello Request message. 3.4.1.3 State - "HELLO_SUPPORT_RESET" State: HELLO_SUPPORT_RESET Event: 4a : Neighbor_Src_Instance field non-zero, received Dst_Instance field zero(0). New State: HELLO_SUPPORTED Actions: Send Hello Ack message. State: HELLO_SUPPORT_RESET Event: 4b : Neighbor_Src_Instance is zero(0) and Src_Instance field is non-zero. New State: HELLO_SUPPORT_RESET Actions: Update Neighbor_Src_Instance field with a new value. 3.4.2 Hello Ack Message Processing 3.4.2.1 State - "STATUS_UNKNOWN" State: STATUS_UNKNOWN Event: 2a : Neighbor_Src_Instance is zero (0) and Src_Instance field is non-zero. New State: STATUS_UNKNOWN Actions: The Neighbor_Src_Instance is updated with the new value. State: STATUS_UNKNOWN Event: 2b : Received Dst_Instance field is not equal to Src_Instance field. New State: STATUS_UNKNOWN Actions: Ignore, continue to send Hello Request message. State: STATUS_UNKNOWN Event: 2c : Received Dst_Instance field is equal to Src_Instance field. Arumugam & Prabakaran April 2004 [Page 5] INTERNET DRAFT RSVP Hello State machine October 2003 New State: HELLO_SUPPORTED Actions: Update the Dst_Instance field with the Neighbor_Src_Instance value and continue to send Hello Request message. 3.4.2.2 State - "HELLO_SUPPORTED" State: HELLO_SUPPORTED Event: 3e : Neighbor_Src_Instance is equal to Dst_Instance field and received Dst_Instance is equal to Src_Instance field. New State: HELLO_SUPPORTED Actions: Ignore, continue to send Hello Request message. State: HELLO_SUPPORTED Event: 3f : Neighbor_Src_Instance field is zero(0), and the Src_Instance field is non-zero. New State: HELLO_SUPPORTED Actions: Update Neighbor_Src_Instance field with the new value, continue to send Hello Request message. State: HELLO_SUPPORTED Event: 3g : Neighbor advertises a wrong non-zero value. New State: HELLO_SUPPORT_RESET Actions: Generate Node failure indication. 3.4.2.3 State - "HELLO_SUPPORT_RESET" State: HELLO_SUPPORT_RESET Event: 4c : Received Dst_Instance is equal to Src_Instance field. New State: HELLO_SUPPORTED Actions: Update the Dst_Instance field with the Neighbor_Src_Instance value and continue sending Hello Request message. State: HELLO_SUPPORT_RESET Event: 4d : Received Dst_Instance is not equal to Src_Instance field. New State: HELLO_SUPPORT_RESET Actions: Ignore, continue sending Hello Request message. State: HELLO_SUPPORT_RESET Event: 4e : Neighbor_Src_Instance is zero(0). New State: HELLO_SUPPORT_RESET Actions: Update Neighbor_Src_Instance field with a new value and continue sending Hello Request message. Arumugam & Prabakaran April 2004 [Page 6] INTERNET DRAFT RSVP Hello State machine October 2003 3.4.3 Hello Timer/Internal Events processing 3.4.3.1 State - "STATUS_UNKNOWN" State: STATUS_UNKNOWN Event: 2d : Hello Timer time out event and Hello retry limit does not exceed. New State: STATUS_UNKNOWN Actions: Send Hello Request message. State: STATUS_UNKNOWN Event: 2e : Hello Timer time out event and Hello retry limit exceeds. New State: HELLO_NOT_SUPPORTED Actions: Ignore, stop sending Hello Request message. State: STATUS_UNKNOWN Event: 2f : Neighbor creation event. or Hello enable event. New State: STATUS_UNKNOWN Actions: Send Hello Request message. State: STATUS_UNKNOWN Event: 2g : Neighbor deletion event or Hello disable event. New State: STATUS_UNKNOWN Actions: Stop sending Hello Request message and stop Hello timers. 3.4.3.2 State - "HELLO_NOT_SUPPORTED" State: HELLO_NOT_SUPPORTED Event: 1d : Hello Timer time out event and Hello back off timer limit does not exceed. New State: HELLO_NOT_SUPPORTED Actions: Ignore. State: HELLO_NOT_SUPPORTED Event: 1e : Hello Timer time out event and Hello back off timer limit exceeds. New State: STATUS_UNKNOWN Actions: Send Hello Request message with a new Src_Instance value. State: HELLO_NOT_SUPPORTED Event: 1f : Neighbor deletion event or Hello disable event. New State: STATUS_UNKNOWN Actions: Stop Hello timers. Arumugam & Prabakaran April 2004 [Page 7] INTERNET DRAFT RSVP Hello State machine October 2003 3.4.3.3 State - "HELLO_SUPPORTED" State: HELLO_SUPPORTED Event: 3h : Hello Timer time out event and Hello time to die does not expire. New State: HELLO_SUPPORTED Actions: Send Hello Request message. State: HELLO_SUPPORTED Event: 3i : Hello Timer time out event and Hello time to die expired in case of uni-link or Hello message has not been received in any other link of the multi-link consideration. New State: HELLO_SUPPORT_RESET Actions: Generate node failure indication. State: HELLO_SUPPORTED Event: 3j : Hello Timer time out event and Hello time to die expired, Hello message has been received on any other link of a multi-link consideration. New State: HELLO_SUPPORTED Actions: Ignore. State: HELLO_SUPPORTED Event: 3k : Neighbor deletion event or Hello disable event. New State: STATUS_UNKNOWN Actions: Stop Hello timers. 3.4.3.4 State - "HELLO_SUPPORT_RESET" State: HELLO_SUPPORT_RESET Event: 4f : Hello Timer time out event and Hello back off timer limit does not exceed. New State: HELLO_SUPPORT_RESET Actions: Ignore. State: HELLO_SUPPORT_RESET Event: 4g : Hello Timer time out event and Hello back off timer limit exceeds. New State: HELLO_SUPPORT_RESET Actions: Send Hello Request message with a new Src_Instance value. State: HELLO_SUPPORT_RESET Event: 4h : Neighbor deletion event or Hello disable event. New State: STATUS_UNKNOWN Actions: Stop Hello timers. Arumugam & Prabakaran April 2004 [Page 8] INTERNET DRAFT RSVP Hello State machine October 2003 4. Limitations All other events that are not captured in this RSVP Hello state machine SHOULD be ignored and the current state SHOULD prevail. 5. Security Considerations This document is provided as an informational extension of the RSVP-TE specification[RSVP-TE]. The State machine proposed in this draft is intended to simplify the implementation of Hello Extension defined in the RSVP-TE specification, and does not supplement or override the definitions and procedures provided there. Implementation of a state machine may be vulnerable to spurious events generated by any external source. In this document, these specific events fall into two categories: Internal events and External events triggered by the receipt of RSVP messages. Security considerations relating to generation of spurious internal events are not addressed in this document. RSVP Hello messages MAY be protected using mechanisms described in the RSVP-TE specification. See "Security Considerations" in the RSVP-TE specification[RSVP-TE]. 6. Acknowledgements The mechanism described in this document has been inspired by prior work about MPLS traffic engineering mechanisms. Specifically the drafts authored by Daniel O. Awduche, Lou Berger, Der-Hwa Gan, Tony Li, Vijay Srinivasan, and George Swallow have provided the motivation to come up with this contribution. We also wish to place on record the suggestions and review comments given by Manikantan Srinivasan and Anton Basil R for this work. The support given by other well wishers and friends during this work is recalled with gratitude. Arumugam & Prabakaran April 2004 [Page 9] INTERNET DRAFT RSVP Hello State machine October 2003 7. Authors' Address Arumugam R. Future Software Limited, 480-481 Anna Salai, Nandanam, Chennai - 600 035, India Phone : +91-44-24330550 Email : arumugamr@future.futsoft.com Prabakaran T.S. Future Software Limited, 480-481 Anna Salai, Nandanam, Chennai - 600 035, India Phone : +91-44-24330550 Email : prabakarts@future.futsoft.com 8. References [RSVP-TE] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, G. Swallow, " RSVP-TE: Extensions to RSVP for LSP Tunnels ", RFC 3209, December 2001. [RSVP-TE-FRR] Ping Pan, Der-Hwa Gan, George Swallow, Jean Philippe Vasseur, Dave Cooper, Alia Atlas, Markus Jork, " Fast Reroute Extensions to RSVP-TE for LSP Tunnels ", draft-ietf-mpls-rsvp-lsp- fastreroute-03.txt, Expires: December 2003. [RFC-WORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC-IANA] T. Narten and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434. Arumugam & Prabakaran April 2004 [Page 10]