Internet DRAFT - draft-osborne-mpls-psc-alive
draft-osborne-mpls-psc-alive
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] , , <https://datatracker.ietf.org/documents/LIAISON/
liaison-2012-10-03-itu-t-sg-15-mpls-recommendation-
itu-t-g8131y1382-revision-linear-protection-switching-for-
mpls-tp-networks-attachment-1.docx>.
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]
