Internet DRAFT - draft-or-psc-cap-mode
draft-or-psc-cap-mode
Network Working Group E. Osborne
Internet-Draft Cisco Systems, Inc.
Intended status: Experimental JD. Ryoo
Expires: April 24, 2014 ETRI
H. van Helvoort
Huawei Technologies
A. D'Alessandro
Telecom Italia
T. Cheung
ETRI
October 21, 2013
Capabilities and Modes in PSC
draft-or-psc-cap-mode-01
Abstract
This document introduces capabilites and modes to PSC. A capability
is an individual behavior, and a node's set of capabilities are
signalled using the method given in this draft. A mode is a
particular combination of capabilities.
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 April 24, 2014.
Copyright Notice
Osborne, et al. Expires April 24, 2014 [Page 1]
Internet-Draft psc-cap-mode October 2013
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
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. Capabilities . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Sending the Capabilities TLV . . . . . . . . . . . . . . 3
2.1.1. What to send . . . . . . . . . . . . . . . . . . . . 3
2.1.2. When to send it . . . . . . . . . . . . . . . . . . 4
2.2. Receiving the Capabilities TLV . . . . . . . . . . . . . 4
2.2.1. Comparing Capabilties TLVs . . . . . . . . . . . . . 4
2.2.2. Handling a missing TLV . . . . . . . . . . . . . . . 4
2.3. Handling errors . . . . . . . . . . . . . . . . . . . . . 4
2.3.1. TLV Timeout . . . . . . . . . . . . . . . . . . . . . 4
2.3.2. TLV Mismatch . . . . . . . . . . . . . . . . . . . . 5
2.3.3. Handling an error . . . . . . . . . . . . . . . . . . 5
3. Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. PSC Mode . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. APS Mode . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2.1. SF-P and FS priority swap . . . . . . . . . . . . . . 6
3.2.2. Modified non-revertive behavior and MS-W . . . . . . 6
3.2.3. Signal degrade . . . . . . . . . . . . . . . . . . . 6
3.2.4. Exercise . . . . . . . . . . . . . . . . . . . . . . 6
4. Backward compatability . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
8. Normative References . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
This document brings two things to PSC - Capabilies, and Modes. A
Capability is an individual behavior whose use is signalled in a
Capabilities TLV inside PSC, and a Mode is a predefined set of
Capabilities.
Osborne, et al. Expires April 24, 2014 [Page 2]
Internet-Draft psc-cap-mode October 2013
2. Capabilities
A Capability is an individual behavior whose use is signalled in a
Capabilities TLV inside PSC. The format of the Capabilities TLV is:
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=Capabilities | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Length is the length of the Options Value, and is in octets. The
value for the Type field is TBD pending IANA allocation.
2.1. Sending the Capabilities TLV
There are two things to consider when sending a capabilities TLV -
what to send, and when to send it.
2.1.1. What to send
The Value of the Capabilities TLV can be any length, as long as it is
a multiple of 4 octets. An implementation MUST send only as long a
Value as it needs to. Other parts of this document discuss five
capabilities that are signalled using the 5 least significant bits;
if a node wishes to signal these five, it MUST send an Options Value
of 4 octets. A node would only send an Options Value of >4 octets if
it had more than 32 Capabilities to indicate. All unused bits MUST
be set to zero.
If the bit defined for an individual capabilitiy is set to 1, that
indicates the sending node's intent to use that capability in the
protection domain. If a bit is set to 0, the sending node does not
intend to use the indicated capability in the protection domain.
Note that it is not possible to distinguish between the intent not to
use a capability and a node's complete non-support (i.e. lack of
implemntation) of a given capabilty.
Osborne, et al. Expires April 24, 2014 [Page 3]
Internet-Draft psc-cap-mode October 2013
2.1.2. When to send it
PSC sends messages for two reasons - messages in response to external
inputs, and periodic retransmission of current status. It is not
necessary to send the Capabilties TLV with every PSC packet. Indeed,
it may be expensive to send and to parse an Capabilities TLV attached
to a packet intended to trigger a protection switch or other real-
time behavior. However, it is also true that if a node does not
periodically send its Capabilities TLV, the receiving node cannot
tell the difference between a deliberate omission of the Capabilities
TLV for performance reasons versus an accidental omission due to an
implementation issue. To guard against this, a node MUST send its
Capabilities TLV in every periodic retransmission of current status,
and MAY send its Capabilities TLV more frequently than that.
2.2. Receiving the Capabilities TLV
A node MUST establish a receive timer for the Capabilities TLV. By
default this MUST be three times the periodic retransmission timer of
five seconds - so, fifteen seconds. Both the periodic retranmission
time and the timout SHOULD be configurable by the operator. When a
node receives a Capabilties TLV it resets the timer to fifteen
seconds. If the timer expires, the node behaves as in Section 2.3.
2.2.1. Comparing Capabilties TLVs
When a node receives a Capabilites TLV it MUST compare it to its most
recent transmitted Capabilites TLV. If the two are equal, the
protection domain is said to be running in the mode indicated by that
set of capabilites (see Section 3).
2.2.2. Handling a missing TLV
As mentioned in section 2.1.2, a node may not send the Capabilties
TLV with every PSC message. However, a node MUST send the
Capabilities TLV as part of its periodic state retransmission.
2.3. Handling errors
This section covers the two possible errors - a TLV timeout and a TLV
mismatch - and the error handling procedures in both cases.
2.3.1. TLV Timeout
If the Capabilities TLV receive timer expires, a node is said to have
timed out. Whe this happens, the node MUST alert the operator and
MUST behave as in Section 2.3.4, "Handling an error".
Osborne, et al. Expires April 24, 2014 [Page 4]
Internet-Draft psc-cap-mode October 2013
2.3.2. TLV Mismatch
If the sent and received Capabilties TLVs are not equal, this
indicates a capabilities mismatch. For timer and timeout purposes, a
capabilities mismatch is treated as a missed TLV. That is, the
received TLV is not taken as an input to the receive timer for
Capabilties TLV refresh purposes. A node MAY retain the received TLV
for logging, alert or debug purposes.
2.3.3. Handling an error
If a node decides that it is in an error state in respect to the
Capabilities TLV, it MUST do two things:
1) Indicate the detected mismatch to the operator by the usual alert
mechanisms (e.g. syslog).
2) Not make any state transitions based on the contents of any PSC
messages
To expand on point 2 - assume node A is receiving NR(0,0) from its
PSC peer Z and is also receiving a mismatched set of capabilities
(e.g. received 0x4, transmitted 0x5). If Z detects a local SF-W and
wants to initiate a protection switch (that is, by sending SF(1,1)),
Node A MUST NOT react to this input by changing its state. A node
MAY increase the severity or urgency of its alarms to the operator,
but until the operator resolves the mismatch in the Capabilites TLV
the protection domain will likely operate in an inconsistent state.
3. Modes
A Mode is a given set of Capabilities. Modes are shorthand;
referring to a set of capabilites by their individual values or by
the name of their mode does not change the protocol behavior. This
document defines two modes - PSC and APS.
<< are those the right names? TBD. >>
<< how to define future modes. TBD. >>
3.1. PSC Mode
PSC Mode is defined as the lack of any Capabilities - that is, a
Capabilities set of 0x0. It is the behavior specified in RFC6378.
There are two ways to declare PSC Mode. A node can send a
Capabilities TLV of 0x0, or it can send no Capabilities TLV at all.
This is further explored in section 4.
Osborne, et al. Expires April 24, 2014 [Page 5]
Internet-Draft psc-cap-mode October 2013
3.2. APS Mode
APS Mode is defined as the use of five specific capabilties. These
capabilites are defined in other documents, but are repeated here in
order to define the mode. They are listed below. APS Mode is
indicated with a Capabilites TLV of 0x1F.
3.2.1. SF-P and FS priority swap
This feature is defined in draft-rhd-mpls-tp-psc-priority and is
assigned bit 0x1.
3.2.2. Modified non-revertive behavior and MS-W
These are both defined in draft-cdh-mpls-tp-psc-non-revertive but are
negotiated seperately.. Modified NR behavior is assigne bit 0x2 and
MS-W is assigned bit 0x4.
3.2.3. Signal degrade
This feature is defined in draft-rhd-mpls-tp-psc-sd. It is assigned
bit 0x8.
3.2.4. Exercise
This feature is defined in draft-dj-mpls-tp-exer-psc. It is assigned
bit 0x10.
4. Backward compatability
As defined in Section 3, PSC Mode is indicated either with a
Capabilties TLV of 0x0 or the lack of any Capabilities TLV. This is
to allow backward compatability between two nodes - one which can
send the Capabilities TLV, and one which cannot.
RFC6378 does not define how to handle an unrecognized TLV. There may
be some implementations that silently discard an unrecognized TLV,
and some that take more drastic steps like refusing to allow PSC to
operate. Thus, a node which has the ability to send and receive the
PSC Mode Capabilities TLV MUST be able to both send the PSC Mode
Capabilties TLV and send no Capabilities TLV at all. An
implementation MUST be configurable between these two choices.
One question that arises from this dual definition of PSC Mode is,
what happens if a node which was sending a non-null Capabilities TLV
(e.g. APS Mode) sends PSC packets without any Capabilites TLV? This
case is handled as follows:
Osborne, et al. Expires April 24, 2014 [Page 6]
Internet-Draft psc-cap-mode October 2013
If a node has never, during the life of a PSC session, received a
Capabilites TLV from a neighbor, the lack of a Capabilites TLV is
treated as receipt of a PSC Capabilites TLV. This allows for interop
between nodes which support the PSC Mode TLV and nodes which do not,
and are thus implicitly operating in PSC Mode.
If a node has received a non-null Capabilites TLV (e.g. APS Mode)
during the life of a PSC session and then receives a PSC packet with
no Capabilites TLV, the receiving node MUST treat the lack of
Capabilites TLV as simply a lack of refresh. That is, the receipt of
a PSC packet with no Capabilites TLV simply does not reset the
receive timer defined in Section 2.2
5. IANA Considerations
- A value for the Cap TLV
- A registry for the capabilities inside the Cap TLV
6. Security Considerations
None.
7. Acknowledgements
8. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Authors' Addresses
Eric Osborne
Cisco Systems, Inc.
Email: eosborne@cisco.com
Jeong-Dong Ryoo
ETRI
Huub van Helvoort
Huawei Technologies
Email: Huub.van.Helvoort@huawei.com
Osborne, et al. Expires April 24, 2014 [Page 7]
Internet-Draft psc-cap-mode October 2013
Alessandro D'Alessandro
Telecom Italia
Email: alessandro.dalessandro@telecomitalia.it
Taesik Cheung
ETRI
Email: cts@etri.re.kr
Osborne, et al. Expires April 24, 2014 [Page 8]
