idnits 2.17.1 draft-ietf-ccamp-lmp-behavior-negotiation-11.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4204, updated by this document, for RFC5378 checks: 2001-07-27) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 8, 2013) is 4067 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Dan Li 2 Internet Draft Huawei 3 Updates: 4204, 4207, 4209, 5818 D. Ceccarelli 4 Category: Standards Track Ericsson 5 Lou Berger 6 LabN 8 Expires: August 2013 February 8, 2013 10 Link Management Protocol Behavior Negotiation and 11 Configuration Modifications 13 draft-ietf-ccamp-lmp-behavior-negotiation-11.txt 15 Abstract 17 The Link Management Protocol (LMP) is used to coordinate the 18 properties, use, and faults of data links in Generalized 19 Multiprotocol Label Switching (GMPLS)-controlled networks. This 20 document defines an extension to LMP to negotiate capabilities and 21 indicate support for LMP extensions. The defined extension is 22 compatible with non-supporting implementations. 24 This document updates RFC 4204, RFC 4207, RFC 4209 and RFC 5818. 26 Status of this Memo 28 This Internet-Draft is submitted to IETF in full conformance with 29 the provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six 37 months and may be updated, replaced, or obsoleted by other documents 38 at any time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html 46 This Internet-Draft will expire on August 5, 2013. 48 Copyright Notice 50 Copyright (c) 2013 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with 58 respect to this document. Code Components extracted from this 59 document must include Simplified BSD License text as described in 60 Section 4.e of the Trust Legal Provisions and are provided without 61 warranty as described in the Simplified BSD License. 63 This document may contain material from IETF Documents or IETF 64 Contributions published or made publicly available before November 65 10, 2008. The person(s) controlling the copyright in some of this 66 material may not have granted the IETF Trust the right to allow 67 modifications of such material outside the IETF Standards Process. 68 Without obtaining an adequate license from the person(s) controlling 69 the copyright in such materials, this document may not be modified 70 outside the IETF Standards Process, and derivative works of it may 71 not be created outside the IETF Standards Process, except to format 72 it for publication as an RFC or to translate it into languages other 73 than English. 75 Conventions used in this document 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in [RFC2119]. 81 Table of Contents 83 1. Introduction ................................................ 3 84 2. LMP Message Modifications.................................... 4 85 2.1. Modified Message Formats................................ 4 86 2.2. Processing ............................................. 5 87 3. LMP Behavior Negotiation..................................... 6 88 3.1. BehaviorConfig C-Type Format............................ 6 89 3.2. Processing ............................................. 7 90 4. Backward Compatibility....................................... 7 91 5. Security Considerations...................................... 8 92 6. IANA Considerations ......................................... 9 93 6.1. New LMP Class Type...................................... 9 94 6.2. New Capabilities Registry............................... 9 95 7. Contributors ............................................... 10 96 8. Acknowledgments ............................................ 10 97 9. References ................................................. 10 98 9.1. Normative References................................... 10 99 10. Authors' Addresses ........................................ 11 101 1. Introduction 103 The Link Management Protocol (LMP) [RFC4204] has been successfully 104 deployed in Generalized Multiprotocol Label Switching (GMPLS)- 105 controlled networks. 107 New LMP behaviors and protocol extensions have been introduced in a 108 number of IETF documents as set out later in this section. It is 109 likely that future extensions will be made to support additional 110 functions. 112 In a network, if one LMP-capable node supports a new behavior or 113 protocol extension but its adjacent node does not, it is beneficial 114 to have a protocol mechanism to discover the capabilities of peer 115 nodes so that the right protocol extensions can be selected and the 116 correct features can be enabled. There are no such procedures 117 defined in the base LMP specification [RFC4204]. [RFC4209] defined a 118 specific mechanism to identify support for the functions specified 119 in that document. This document defines an LMP extension to support 120 the identification of supported LMP functions in a generic fashion, 121 as well as how a node supporting these extensions would communicate 122 with legacy nodes. 124 In [RFC4204], the basic behaviors have been defined around the use 125 of the standard LMP messages, which include Config, Hello, Verify, 126 Test, LinkSummary, and ChannelStatus. Per [RFC4204], these behaviors 127 MUST be supported when LMP is implemented, and the message types 128 from 1 to 20 have been assigned by IANA for these messages. Support 129 for all functions required by [RFC4204] is assumed by this document. 131 In [RFC4207], the SONET/SDH technology-specific behavior and 132 information for LMP is defined. The Trace behavior is added to LMP, 133 and the message types from 21 to 31 were assigned by IANA for the 134 messages that provide the TRACE function. 136 In [RFC4209], extensions to LMP are defined to allow it to be used 137 between a peer node and an adjacent Optical Line System (OLS). The 138 LMP object class type and sub-object class name have been extended 139 to support DWDM behavior. 141 In [RFC5818], the data channel consistency check behavior is defined, 142 and the message types from 32 to 34 have been assigned by IANA for 143 messages that provide this behavior. 145 It is likely that future extensions to LMP for other functions or 146 technologies will require the definition of further LMP messages. 148 This document describes an LMP extension, which is referred to as 149 behavior negotiation, which enables nodes at the ends of a link to 150 identify the LMP messages and functions supported by the adjacent 151 node. The extension makes use of a new CONFIG object. The use of 152 this new object does not preclude the use of existing or yet to be 153 defined CONFIG object. 155 This document also modifies the format of messages that carry CONFIG 156 object to allow for multiple objects. Multiple CONFIG objects allow 157 behavior negotiation concurrent with existing usage of the CONFIG 158 object, i.e., HelloConfig C-Type defined in [RFC4204] and 159 LMP_WDM_CONFIG C-Type defined in [RFC4209]. This document modifies 160 the ConfigAck message to include CONFIG objects so that acceptable 161 parameters are explicitly identified. It also describes how a node 162 which supports the extensions defined in this document interacts 163 with a legacy LMP-capable node. 165 2. LMP Message Modifications 167 LMP Config, ConfigNack and ConfigAck messages are modified by this 168 document to allow for the inclusion of multiple CONFIG objects. The 169 Config and ConfigNack messages were only defined to carry one CONFIG 170 object in [RFC4204]. The ConfigAck message, which was defined 171 without carrying any CONFIG objects in [RFC4204], is modified to 172 enable explicit identification of negotiated configuration 173 parameters. The inclusion of CONFIG objects in ConfigAck messages is 174 triggered by the use of the BehaviorConfig object (defined below) in 175 a received Config message. 177 The message formats in the sections that follow use Backus-Naur Form 178 (BNF) encoding as defined in [RFC5511]. 180 2.1. Modified Message Formats 181 The format of the Config message as updated by this document is as 182 follows: 184 ::= 185 [ ... ] 187 The format of the ConfigAck message as updated by this document is 188 as follows: 190 ::= 191 192 [ ... ] 194 The format of the ConfigNack message as updated by this document is 195 as follows: 197 ::= 198 199 200 [ ... ] 202 2.2. Processing 204 Nodes that support the extensions defined in this document MAY 205 include multiple CONFIG objects when sending a Config, ConfigAck and 206 ConfigNack message. A maximum of a single object of any particular 207 C-type SHALL be included. A node which receives a message with 208 multiple CONFIG objects of the same C-type SHALL process the first 209 object of a particular C-type and ignore any subsequent CONFIG 210 objects of the same C-type. Unless specified as part of the CONFIG 211 object definition, ordering of CONFIG objects with different C-type 212 values is not significant. 214 Nodes that support the extensions defined in this document MUST 215 include a BehaviorConfig type object when sending a Config message 216 to a neighbor whose support for the extensions is either known or 217 unknown. When the neighbor is known to not support the extensions, 218 the object MUST NOT be sent. Inclusion of other CONFIG objects in a 219 Config message is at the discretion of the message sender, and is 220 based on the rules defined as part of CONFIG object definition. 221 Nodes MAY include HelloConfig, LMP_WDM_CONFIG, BehaviorConfig object 222 types in a single message. 224 Inclusion of multiple CONFIG objects in a ConfigNack message is 225 based on the processing of a received Config message. Per [RFC4204] 226 "Parameters where agreement was reached MUST NOT be included in the 227 ConfigNack Message." As such, a ConfigNack message MUST NOT include 228 CONFIG objects which are acceptable and MUST include any CONFIG 229 objects which are not acceptable. When a CONFIG object is included 230 in a ConfigNack message, per [RFC4204], the object is to include 231 "acceptable alternate values for negotiable parameters". 233 When sending a ConfigAck message, nodes supporting the extensions 234 defined in this document MUST include all CONFIG objects received in 235 the corresponding Config message when that message includes a CONFIG 236 object of type BehaviorConfig. 238 3. LMP Behavior Negotiation 240 The Config message is used in the control channel negotiation phase 241 of LMP [RFC4204]. The LMP behavior negotiation procedure is defined 242 in this document as an addition to this phase. 244 The Config message is defined in Section 12.3.1 of [RFC4204] and 245 carries the CONFIG object (class name 6) as defined in Section 13.6 246 of [RFC4204]. 248 Two class types have been defined: 250 - C-Type = 1, HelloConfig, defined in [RFC4204] 252 - C-Type = 2, LMP_WDM_CONFIG, defined in [RFC4209] 254 This document defines a third C-Type to report and negotiate LMP 255 mechanisms and behaviors. Its usage indicates support for the 256 extensions defined in this document. 258 3.1. BehaviorConfig C-Type Format 260 Class = 6 262 - C-Type = (To be assigned by IANA), BehaviorConfig 264 0 1 2 3 265 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 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 |S|D|C| Must Be Zero (MBZ) | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 Flags: 272 S: 1 bit 274 This bit indicates support for the Trace behavior of SONET/SDH 275 technology-specific defined in [RFC4207]. 277 D: 1 bit 279 This bit indicates support for the DWDM behavior defined in 280 [RFC4209]. 282 C: 1 bit 284 This bit indicates support for the data channel consistency check 285 behavior defined in [RFC5818]. 287 Must Be Zero (MBZ): Variable length 289 The remaining bits in the flags field MUST be set to zero (0). 290 This field MUST be sized to ensure 32 bit alignment of the object. 292 Other bits may be defined in future documents, in which case the 293 number of bits in MBZ field is expected to change. 295 3.2. Processing 297 The inclusion of a BehaviorConfig type object in a message is 298 discussed above in Section 2.2. 300 When sending a BehaviorConfig type object, the N-bit (negotiable) in 301 the LMP object header MUST be set (N=1) in the LMP object header. 303 When sending a BehaviorConfig type object in Config and ConfigNack 304 messages, the flags field SHOULD be set based on the supported 305 capabilities of the sending node. When sending a ConfigAck message, 306 the flags field MUST be set to the value received in the 307 corresponding Config message. 309 When receiving a BehaviorConfig type object, the node compares the 310 flags field against its capacities. Any bit set in the MBZ portion 311 of the flags field MUST be interpreted as unacceptable. Processing 312 related to unacceptable values in CONFIG objects is defined in 313 [RFC4204] and is not modified by this document. 315 4. Backward Compatibility 317 The required use of the BehaviorConfig type CONFIG object enables 318 nodes which support the extensions defined in this document to 319 explicitly identify when a neighboring node does not. When a non- 320 supporting node receives a Config message with the BehaviorConfig 321 type CONFIG object or multiple CONFIG objects its behavior is to be 322 one of the following behaviors: 324 a) Reject the Config message because of the unknown BehaviorConfig 325 object type and send a ConfigNack message which includes the 326 unsupported C-type. 328 b) Reject the message because of multiple CONFIG objects and send a 329 ConfigNack message which includes all but one of the CONFIG 330 objects. 332 c) Silently ignore the one or more of the CONFIG object, and respond 333 with a ConfigAck message that does not include any CONFIG objects. 335 d) Treat the message as malformed, and discard it without any 336 response. 338 Behaviors (a) and (b) result in ConfigNack messages with a 339 BehaviorConfig type object whose contents are identical to what was 340 sent in the Config message. Behavior (c) results in a ConfigAck 341 message without a BehaviorConfig type CONFIG object. In each of 342 these cases, the node SHOULD explicitly identify that the LMP 343 neighbor does not support the extensions defined in this document. 345 Behavior (d) results in no response at all. When the node reaches 346 the, [RFC4204]-defined, "retry limit", the node SHOULD infer that 347 the LMP neighbor does not support the extensions defined in this 348 document. 350 Once a node identifies a neighbor as not supporting the extensions 351 defined in this document, the node SHOULD follow previously defined 352 Config message usage. 354 5. Security Considerations 356 [RFC4204] describes how LMP messages between peers can be secured, 357 and these measures are equally applicable to messages carrying the 358 new CONFIG object defined in this document. 360 The procedures described in this document do not of itself 361 constitute a security risk since they do not cause any change in 362 network state. It would be possible, if the messages were 363 intercepted or spoofed to cause bogus alerts in the management plane, 364 or to cause LMP peers to consider that they could or could not 365 operate protocol extensions, and so the use of the LMP security 366 measures are RECOMMENDED. 368 Note, however that [RFC4204] references for security have been 369 updated with [RFC4301] and the current reference for IKEv2 is 370 [RFC5996]. 372 6. IANA Considerations 374 6.1. New LMP Class Type 376 IANA maintains the "Link Management Protocol (LMP)" registry which 377 has a subregistry called "LMP Object Class name space and Class type 378 (C-Type)". 380 IANA is requested to make an assignment from this registry as 381 follows: 383 6 CONFIG [RFC4204] 385 CONFIG Object Class type name space: 387 C-Type Description Reference 388 ------------ --------------------- --------- 389 3(suggested) BehaviorConfig [This.I-D] 391 6.2. New Capabilities Registry 393 IANA is requested to create a new subregistry of the "Link 394 Management Protocol (LMP)" registry to track the Behavior 395 Configuration bits defined in Section 2 of this document. It is 396 suggested that this registry be called "LMP Behavior Configuration 397 Flags". 399 Allocations from this registry are by Standards Action. 401 Bits in this registry are numbered from zero as the most significant 402 bit (transmitted first). The number of bits that can be present is 403 limited by the length field of the CONFIG object which gives rise to 404 (255 x 32)-8 = 8152. IANA is strongly recommended to allocate new 405 bits with the lowest available unused number. 407 The registry is initially populated as follows: 409 Bit | Bit | Meaning | Reference 410 Number | Name | | 411 -------+------+----------------------------------------+---------- 412 0 | S | SONET/SDH Test support | [This.ID] 413 1 | D | DWDM support | [This.ID] 414 2 | C | Data Channel consistency check support | [This.ID] 416 7. Contributors 418 Diego Caviglia 419 Ericsson 420 Via A. Negrone 1/A 16153 421 Genoa Italy 422 Phone: +39 010 600 3736 423 Email: diego.caviglia@ericsson.com 425 8. Acknowledgments 427 Thanks to Adrian Farrel and Richard Graveman for their useful 428 comments. 430 9. References 432 9.1. Normative References 434 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 435 Requirement Levels", BCP 14, RFC 2119, March 1997. 437 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 438 Internet Protocol", RFC 4301, December 2005 440 [RFC5996] C. Kaufman, P. Hoffman, Y. Nir, P. Eronen, "Internet Key 441 Exchange Protocol: IKEv2", RFC 5996, September 2010. 443 [RFC4204] J. Lang, Ed., "Link Management Protocol (LMP)", RFC 4204, 444 October 2005. 446 [RFC4207] J. Lang, Ed., "Synchronous Optical Network (SONET)/ 447 Synchronous Digital Hierarchy (SDH) Encoding for Link 448 Management Protocol (LMP) Test Messages", RFC 4207, 449 October 2005. 451 [RFC4209] A. Fredette, Ed., "Link Management Protocol (LMP) for 452 Dense Wavelength Division Multiplexing (DWDM) Optical Line 453 Systems", RFC 4209, October 2005. 455 [RFC5818] D. Li, Ed., "Data Channel Status Confirmation Extensions 456 for the Link Management Protocol", RFC 5818, April 2010. 458 [RFC5511] Farrel, A., Ed., "Routing Backus-Naur Form (RBNF): A 459 Syntax Used to Form Encoding Rules in Various Routing 460 Protocol Specifications", RFC 5511, April 2009. 462 10. Authors' Addresses 464 Dan Li 465 Huawei Technologies 466 F3-5-B R&D Center, Huawei Industrial Base, 467 Shenzhen 518129 China 468 Phone: +86 755-289-70230 469 Email: huawei.danli@huawei.com 471 Daniele Ceccarelli 472 Ericsson 473 Via A. Negrone 1/A 474 Genova - Sestri Ponente 475 Italy 476 Email: daniele.ceccarelli@ericsson.com 478 Lou Berger 479 LabN Consulting, L.L.C. 480 Email: lberger@labn.net