The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] FW: MPLS individual draft submission - MPLS WG - RSVP Hello State machine
Dear MPLS-WG, We are sending the draft which is posted to IETF, seems to me it was not published. we are sending this to MPLS-WG whomever finds it helpful please make use of it, if someone find comments please let us know. Thanks in advance, Best regards, Prabakaran T.S. Arumugam R. Future Software Limited, 480-481, Anna Salai, Chennai - 600035, India. Off Phone: +91-44-24330550 -----Original Message----- From: Prabakaran T Sampath [mailto:prabakarts@future.futsoft.com] Sent: Wednesday, 22 October 2003 10:51 PM To: 'internet-drafts@ietf.org'; 'swallow@cisco.com'; 'loa@pi.se'; 'fenner@research.att.com'; 'zinin@psg.com' Cc: Subject: MPLS individual draft submission - MPLS WG Dear IETF Secretariat, MPLS chairs, We submit an Internet-Draft: Title : RSVP Hello State machine Author(s) : Arumugam R, Prabakaran T.S Filename : draft-aru-praba-rsvpte-hello-state-00.txt Pages : 10 Date : 2003-10-22 Abstract This document proposes a state machine for providing RSVP Hello Extension support. 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 would help in an easy and generic implementation of Hello extension to RSVP-TE. Thanks and regards, Prabakaran T.S. *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. ***************************************************************************
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 proposes a state machine for providing RSVP Hello
Extension support. 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 would help in an
easy and generic implementation of Hello extension to RSVP-TE.
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]
|
|