Network Working Group E. Osborne Internet-Draft Cisco Systems Intended status: Standards Track March 19, 2013 Expires: September 20, 2013 A Liveness Protocol for PSC draft-osborne-mpls-psc-alive-00 Abstract This document adds a liveness protocol to PSC which provides functionality similar to APS's EXER command. It also provides some rules for processing TLVs in PSC messages which apply to all future uses of PSC TLVs. Requirements Language 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 [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on September 20, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Osborne Expires September 20, 2013 [Page 1] Internet-Draft psc-alive March 2013 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Using TLVs in PSC . . . . . . . . . . . . . . . . . . . . . . 2 3. ALIVE: A liveness protocol using PSC TLVs . . . . . . . . . . 3 3.1. The ALIVE function in PSC . . . . . . . . . . . . . . . . 4 3.1.1. The ALIVE State Machine . . . . . . . . . . . . . . . 4 3.1.2. ALIVE Request . . . . . . . . . . . . . . . . . . . . 5 3.1.3. ALIVE Response . . . . . . . . . . . . . . . . . . . 5 3.1.4. Using ALIVE with PSC states . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 6.2. Informative References . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction This document adds a liveness protocol to PSC which provides functionality similar to APS's EXER command. It also provides some rules for processing TLVs in PSC messages which apply to all future uses of PSC TLVs. 2. Using TLVs in PSC RFC6378 provides a TLV space as part of the PSC message. Details on how to use this space are somewhat sparse, so this section sets out some rules about how TLVs may be transmitted and received. This section may be overridden by future documents, but future uses of TLVs MUST either follow the rules in this section or explicitly override them. 1. A given TLV type SHOULD appear only once in a PSC packet. Future uses of TLV MAY send the same TLV type multiple times in a PSC packet, but this is only permissible if the document defining that TLV provides explicit rules about how to handle this case. This rule is also true when there are multiple TLVs in a packet which share not only their Type, but also their Value. 2. The TLV space in a PSC packet is an unordered set. That is, the order of TLVs in a PSC packet MUST not impact the processing of Osborne Expires September 20, 2013 [Page 2] Internet-Draft psc-alive March 2013 those messages. If a future use of PSC TLVs requires that certain data elements be processed in a specific order, packing those elements in a sub-TLV is recommended. 3. If a TLV is unrecognized upon receipt, a node MUST NOT take any action based on that TLV. The exception to this rule is that a node SHOULD alert the operator to the receipt of an unrecognized TLV. This rule also applies if a TLV is recognized (that is, the Type is known) but the Value does not conform to the node's expectations for that Type. 4. By virtue of the packet format, any PSC message which contains a TLV also has the full fixed header. When a message is sent for purposes of TLV transmission, it MUST fully populate all the fixed header fields. The receiver of this message MUST process the fixed header in addition to the TLVs. For example, in steady state PSC sends periodic state refreshes every 5 seconds. If a node decides to send an ALIVE Request 3 seconds into this 5-second interval, it MUST be fully populated on the transmit end and fully processed on the receive side. Whether the transmitting node starts its 5-second timer again from zero after sending the TLV-laden message or whether it keeps the fixed 5 second interval (i.e. sending another PSC message 2 seconds after the one containing the ALIVE TLV) is implementation- dependant. An implementation MUST be able to deal with a fixed header no matter when it is sent. 5. The use of PSC TLVs may increase over time. An implementation SHOULD minimze the number of PSC packets it sends in favor of packing multiple TLVs into a single message. One way to do this is to adjust application timers, e.g. rounding everything to the nearest second so that multiple TLVs are transmitted simultaneously in the same packet rather than in several closely- spaced separate packets. 3. ALIVE: A liveness protocol using PSC TLVs PSC is, by design, similar to APS [insert reference - G.870?]. APS has an Exercise function referred to as EXER. EXER provides an optional keepalive functionality in APS. However, it has a limitation in that it can only be used during non-failure times (NR, DNR). This section provides a liveness function called ALIVE that provides that same keepalive functionality. ALIVE uses PSC TLVs rather than fixed header space to send its messages. The benefit of this approach is that ALIVE messages can be sent and received as long as there is a PSC communication channel, even during most failures. Osborne Expires September 20, 2013 [Page 3] Internet-Draft psc-alive March 2013 3.1. The ALIVE function in PSC ALIVE is a simple protocol. It has two messages - a request and an ACK. The request says 'Please confirm that you are alive'. The response says 'Yes, I am alive'. The request contains a sequence number. The response echoes back that sequence number. Receipt of a Request does not constitute a Response. Requests are sent periodically. If a reply is not received with the expected sequence number within a configurable timeout (default 10sec), the reuqesting node MUST alert the operator. 3.1.1. The ALIVE State Machine ALIVE packets are transmited in PSC TLVs. The ALIVE state machine is independent of the state machine used to control protection switching. As such, ALIVE messages may be sent and replied to at any time (see Section 3.1.4 for details). The ALIVE State Machine has only two states: NoReq and TxReq. The state machine also has two timers: Retry and Timeout. 3.1.1.1. ALIVE Timers The Retry timer is the interval between successive transmissions of the same ALIVE Request. The purpose of the Retry timer is to allow a node to send the same request (that is, with the same sequence number) multiple times to minimize the risk of packet loss. The Retry timer MAY be zero, in which case a given sequence number is sent only once. The default Retry timer is three seconds. The Timeout timer is the amount of time that passes before a node times out on receipt of an ALIVE Response to its most recently transmitted sequence number. The timeout timer MUST be at least equal to the round-trip time between the two nodes plus processing delay, and SHOULD be significantly higher in order to avoid race conditions. The default Timeout is ten seconds. With the default timers, a node will send the same ALIVE Request, with the same sequence number, three times before timing out. 3.1.1.2. NoReq state NoReq is the default ALIVE state. In this state, no ALIVE request has been sent. If an ALIVE Request is received in this state, an ALIVE Response is sent which contains the sequence number received in the most recent ALIVE Request. The node remains in NoReq after sending the ALIVE Response. Osborne Expires September 20, 2013 [Page 4] Internet-Draft psc-alive March 2013 The only trigger to transition out of NoReq is an operator input. This input causes the node to do three things: 1) Start the Retry timer, if it is not set to zero 2) Start the Timeout timer The node then transitions to TxReq state 3.1.1.3. TxReq state A node enters TxReq as a result of an operator input. When a node enters TxReq, it sends an ALIVE Request with the most recent sequence number. There are three possible inputs to the TxReq state: 1) If the Retry timer expires, the node retransmits the most recent ALIVE Request packet 2) If the Timeout timer expires, the node transitions to NoReq state. Expiry of the Timeout timer constitutes a failure of the ALIVE Request/Reply operation. The operator SHOULD be alerted to the failure of the remote node to reply to the ALIVE Request. 3) If the node receives an ALIVE Response, the node transitions to NoReq state. If the reply contains the expected sequence number, the ALIVE operation was successful and the operator SHOULD be alerted thusly. If the reply contains an unexpected sequence number then the ALIVE operation was a failure and the operator SHOULD be notified. When a node exits the TxReq state due to a Timeout or ALIVE Response, the sequence number MUST be incremented. 3.1.2. ALIVE Request The ALIVE Request 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type: ALIVE Request | Length: 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value: Sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.1.3. ALIVE Response The ALIVE Response has the following format: Osborne Expires September 20, 2013 [Page 5] Internet-Draft psc-alive March 2013 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: ALIVE Response | Length: 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value: Sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.1.4. Using ALIVE with PSC states As with all PSC messages, ALIVE messages are only sent over the protection channel. ALIVE messages MUST NOT be sent when there is a failure of the protection channel (SF-P). This includes both local and remote SF-P. ALIVE messages may be sent or received in any other state. 4. IANA Considerations This document requests allocation of two code points from the PSC TLV space. Note to RFC Editor: this section may be removed on publication as an RFC. 5. Acknowledgements Annamaria Fulignoli for the initial text on Point #2 John Drake for the genesis of the EXER replacement idea 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 6.2. Informative References [LS435] , , . Author's Address Osborne Expires September 20, 2013 [Page 6] Internet-Draft psc-alive March 2013 Eric Osborne Cisco Systems Email: eosborne@cisco.com Osborne Expires September 20, 2013 [Page 7]