idnits 2.17.1 draft-or-psc-cap-mode-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 67 has weird spacing: '.... When to se...' -- The document date (October 21, 2013) is 3833 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Osborne 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Experimental JD. Ryoo 5 Expires: April 24, 2014 ETRI 6 H. van Helvoort 7 Huawei Technologies 8 A. D'Alessandro 9 Telecom Italia 10 T. Cheung 11 ETRI 12 October 21, 2013 14 Capabilities and Modes in PSC 15 draft-or-psc-cap-mode-01 17 Abstract 19 This document introduces capabilites and modes to PSC. A capability 20 is an individual behavior, and a node's set of capabilities are 21 signalled using the method given in this draft. A mode is a 22 particular combination of capabilities. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119 [RFC2119]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on April 24, 2014. 47 Copyright Notice 48 Copyright (c) 2013 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Capabilities . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2.1. Sending the Capabilities TLV . . . . . . . . . . . . . . 3 66 2.1.1. What to send . . . . . . . . . . . . . . . . . . . . 3 67 2.1.2. When to send it . . . . . . . . . . . . . . . . . . 4 68 2.2. Receiving the Capabilities TLV . . . . . . . . . . . . . 4 69 2.2.1. Comparing Capabilties TLVs . . . . . . . . . . . . . 4 70 2.2.2. Handling a missing TLV . . . . . . . . . . . . . . . 4 71 2.3. Handling errors . . . . . . . . . . . . . . . . . . . . . 4 72 2.3.1. TLV Timeout . . . . . . . . . . . . . . . . . . . . . 4 73 2.3.2. TLV Mismatch . . . . . . . . . . . . . . . . . . . . 5 74 2.3.3. Handling an error . . . . . . . . . . . . . . . . . . 5 75 3. Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 3.1. PSC Mode . . . . . . . . . . . . . . . . . . . . . . . . 5 77 3.2. APS Mode . . . . . . . . . . . . . . . . . . . . . . . . 6 78 3.2.1. SF-P and FS priority swap . . . . . . . . . . . . . . 6 79 3.2.2. Modified non-revertive behavior and MS-W . . . . . . 6 80 3.2.3. Signal degrade . . . . . . . . . . . . . . . . . . . 6 81 3.2.4. Exercise . . . . . . . . . . . . . . . . . . . . . . 6 82 4. Backward compatability . . . . . . . . . . . . . . . . . . . 6 83 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 85 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 86 8. Normative References . . . . . . . . . . . . . . . . . . . . 7 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 89 1. Introduction 91 This document brings two things to PSC - Capabilies, and Modes. A 92 Capability is an individual behavior whose use is signalled in a 93 Capabilities TLV inside PSC, and a Mode is a predefined set of 94 Capabilities. 96 2. Capabilities 98 A Capability is an individual behavior whose use is signalled in a 99 Capabilities TLV inside PSC. The format of the Capabilities TLV is: 101 0 1 2 3 102 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 103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 104 | Type=Capabilities | Length | 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 106 | Options Value | 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 The Length is the length of the Options Value, and is in octets. The 110 value for the Type field is TBD pending IANA allocation. 112 2.1. Sending the Capabilities TLV 114 There are two things to consider when sending a capabilities TLV - 115 what to send, and when to send it. 117 2.1.1. What to send 119 The Value of the Capabilities TLV can be any length, as long as it is 120 a multiple of 4 octets. An implementation MUST send only as long a 121 Value as it needs to. Other parts of this document discuss five 122 capabilities that are signalled using the 5 least significant bits; 123 if a node wishes to signal these five, it MUST send an Options Value 124 of 4 octets. A node would only send an Options Value of >4 octets if 125 it had more than 32 Capabilities to indicate. All unused bits MUST 126 be set to zero. 128 If the bit defined for an individual capabilitiy is set to 1, that 129 indicates the sending node's intent to use that capability in the 130 protection domain. If a bit is set to 0, the sending node does not 131 intend to use the indicated capability in the protection domain. 132 Note that it is not possible to distinguish between the intent not to 133 use a capability and a node's complete non-support (i.e. lack of 134 implemntation) of a given capabilty. 136 2.1.2. When to send it 138 PSC sends messages for two reasons - messages in response to external 139 inputs, and periodic retransmission of current status. It is not 140 necessary to send the Capabilties TLV with every PSC packet. Indeed, 141 it may be expensive to send and to parse an Capabilities TLV attached 142 to a packet intended to trigger a protection switch or other real- 143 time behavior. However, it is also true that if a node does not 144 periodically send its Capabilities TLV, the receiving node cannot 145 tell the difference between a deliberate omission of the Capabilities 146 TLV for performance reasons versus an accidental omission due to an 147 implementation issue. To guard against this, a node MUST send its 148 Capabilities TLV in every periodic retransmission of current status, 149 and MAY send its Capabilities TLV more frequently than that. 151 2.2. Receiving the Capabilities TLV 153 A node MUST establish a receive timer for the Capabilities TLV. By 154 default this MUST be three times the periodic retransmission timer of 155 five seconds - so, fifteen seconds. Both the periodic retranmission 156 time and the timout SHOULD be configurable by the operator. When a 157 node receives a Capabilties TLV it resets the timer to fifteen 158 seconds. If the timer expires, the node behaves as in Section 2.3. 160 2.2.1. Comparing Capabilties TLVs 162 When a node receives a Capabilites TLV it MUST compare it to its most 163 recent transmitted Capabilites TLV. If the two are equal, the 164 protection domain is said to be running in the mode indicated by that 165 set of capabilites (see Section 3). 167 2.2.2. Handling a missing TLV 169 As mentioned in section 2.1.2, a node may not send the Capabilties 170 TLV with every PSC message. However, a node MUST send the 171 Capabilities TLV as part of its periodic state retransmission. 173 2.3. Handling errors 175 This section covers the two possible errors - a TLV timeout and a TLV 176 mismatch - and the error handling procedures in both cases. 178 2.3.1. TLV Timeout 180 If the Capabilities TLV receive timer expires, a node is said to have 181 timed out. Whe this happens, the node MUST alert the operator and 182 MUST behave as in Section 2.3.4, "Handling an error". 184 2.3.2. TLV Mismatch 186 If the sent and received Capabilties TLVs are not equal, this 187 indicates a capabilities mismatch. For timer and timeout purposes, a 188 capabilities mismatch is treated as a missed TLV. That is, the 189 received TLV is not taken as an input to the receive timer for 190 Capabilties TLV refresh purposes. A node MAY retain the received TLV 191 for logging, alert or debug purposes. 193 2.3.3. Handling an error 195 If a node decides that it is in an error state in respect to the 196 Capabilities TLV, it MUST do two things: 198 1) Indicate the detected mismatch to the operator by the usual alert 199 mechanisms (e.g. syslog). 201 2) Not make any state transitions based on the contents of any PSC 202 messages 204 To expand on point 2 - assume node A is receiving NR(0,0) from its 205 PSC peer Z and is also receiving a mismatched set of capabilities 206 (e.g. received 0x4, transmitted 0x5). If Z detects a local SF-W and 207 wants to initiate a protection switch (that is, by sending SF(1,1)), 208 Node A MUST NOT react to this input by changing its state. A node 209 MAY increase the severity or urgency of its alarms to the operator, 210 but until the operator resolves the mismatch in the Capabilites TLV 211 the protection domain will likely operate in an inconsistent state. 213 3. Modes 215 A Mode is a given set of Capabilities. Modes are shorthand; 216 referring to a set of capabilites by their individual values or by 217 the name of their mode does not change the protocol behavior. This 218 document defines two modes - PSC and APS. 220 << are those the right names? TBD. >> 222 << how to define future modes. TBD. >> 224 3.1. PSC Mode 226 PSC Mode is defined as the lack of any Capabilities - that is, a 227 Capabilities set of 0x0. It is the behavior specified in RFC6378. 228 There are two ways to declare PSC Mode. A node can send a 229 Capabilities TLV of 0x0, or it can send no Capabilities TLV at all. 230 This is further explored in section 4. 232 3.2. APS Mode 234 APS Mode is defined as the use of five specific capabilties. These 235 capabilites are defined in other documents, but are repeated here in 236 order to define the mode. They are listed below. APS Mode is 237 indicated with a Capabilites TLV of 0x1F. 239 3.2.1. SF-P and FS priority swap 241 This feature is defined in draft-rhd-mpls-tp-psc-priority and is 242 assigned bit 0x1. 244 3.2.2. Modified non-revertive behavior and MS-W 246 These are both defined in draft-cdh-mpls-tp-psc-non-revertive but are 247 negotiated seperately.. Modified NR behavior is assigne bit 0x2 and 248 MS-W is assigned bit 0x4. 250 3.2.3. Signal degrade 252 This feature is defined in draft-rhd-mpls-tp-psc-sd. It is assigned 253 bit 0x8. 255 3.2.4. Exercise 257 This feature is defined in draft-dj-mpls-tp-exer-psc. It is assigned 258 bit 0x10. 260 4. Backward compatability 262 As defined in Section 3, PSC Mode is indicated either with a 263 Capabilties TLV of 0x0 or the lack of any Capabilities TLV. This is 264 to allow backward compatability between two nodes - one which can 265 send the Capabilities TLV, and one which cannot. 267 RFC6378 does not define how to handle an unrecognized TLV. There may 268 be some implementations that silently discard an unrecognized TLV, 269 and some that take more drastic steps like refusing to allow PSC to 270 operate. Thus, a node which has the ability to send and receive the 271 PSC Mode Capabilities TLV MUST be able to both send the PSC Mode 272 Capabilties TLV and send no Capabilities TLV at all. An 273 implementation MUST be configurable between these two choices. 275 One question that arises from this dual definition of PSC Mode is, 276 what happens if a node which was sending a non-null Capabilities TLV 277 (e.g. APS Mode) sends PSC packets without any Capabilites TLV? This 278 case is handled as follows: 280 If a node has never, during the life of a PSC session, received a 281 Capabilites TLV from a neighbor, the lack of a Capabilites TLV is 282 treated as receipt of a PSC Capabilites TLV. This allows for interop 283 between nodes which support the PSC Mode TLV and nodes which do not, 284 and are thus implicitly operating in PSC Mode. 286 If a node has received a non-null Capabilites TLV (e.g. APS Mode) 287 during the life of a PSC session and then receives a PSC packet with 288 no Capabilites TLV, the receiving node MUST treat the lack of 289 Capabilites TLV as simply a lack of refresh. That is, the receipt of 290 a PSC packet with no Capabilites TLV simply does not reset the 291 receive timer defined in Section 2.2 293 5. IANA Considerations 295 - A value for the Cap TLV 297 - A registry for the capabilities inside the Cap TLV 299 6. Security Considerations 301 None. 303 7. Acknowledgements 305 8. Normative References 307 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 308 Requirement Levels", BCP 14, RFC 2119, March 1997. 310 Authors' Addresses 312 Eric Osborne 313 Cisco Systems, Inc. 315 Email: eosborne@cisco.com 317 Jeong-Dong Ryoo 318 ETRI 320 Huub van Helvoort 321 Huawei Technologies 323 Email: Huub.van.Helvoort@huawei.com 324 Alessandro D'Alessandro 325 Telecom Italia 327 Email: alessandro.dalessandro@telecomitalia.it 329 Taesik Cheung 330 ETRI 332 Email: cts@etri.re.kr