idnits 2.17.1 draft-li-ccamp-lmp-behavior-negotiation-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 : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 28, 2010) is 5082 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) == Missing Reference: 'RCF4204' is mentioned on line 97, but not defined == Missing Reference: 'RC4204' is mentioned on line 122, but not defined == Outdated reference: A later version (-04) exists of draft-ceccarelli-ccamp-gmpls-g709-lmp-test-02 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). 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: RFC4204 D. Ceccarelli 4 Category: Standards Track Ericsson 6 Expires: November 2010 May 28, 2010 8 Behavior Negotiation in Link Management Protocol 10 draft-li-ccamp-lmp-behavior-negotiation-01.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with 15 the provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This Internet-Draft will expire on November 27, 2010. 35 Copyright Notice 37 Copyright (c) 2010 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with 45 respect to this document. Code Components extracted from this 46 document must include Simplified BSD License text as described in 47 Section 4.e of the Trust Legal Provisions and are provided without 48 warranty as described in the Simplified BSD License. 50 Abstract 52 The Link Management Protocol (LMP) is used to coordinate the 53 properties, use, and faults of data links in Generalized 54 Multiprotocol Label Switching (GMPLS) networks. Various proposals 55 have been advanced to provide extensions to the base LMP 56 specification. This document provides a generic procedure for LMP 57 implementations that do not recognize or do not support any one of 58 these extensions. 60 Conventions used in this document 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 63 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 64 document are to be interpreted as described in [RFC2119]. 66 Table of Contents 68 1. Introduction.................................................2 69 2. LMP Behavior Negotiation Procedure...........................3 70 3. Security Considerations......................................6 71 4. IANA Considerations..........................................6 72 5. Contributors.................................................6 73 6. Acknowledgments..............................................7 74 7. References...................................................7 75 7.1. Normative References....................................7 76 7.2. Informative References..................................7 77 8. Authors' Address.............................................8 79 1. Introduction 81 The Link Management Protocol (LMP) [RFC4204] is being successfully 82 deployed in Generalized Multiprotocol Label Switching (GMPLS) 83 networks in the field. New LMP behaviors and protocol extensions are 84 being introduced in a number of IETF documents. 86 In the network, if one GMPLS Label Switching Router (LSR) supports a 87 new behavior or protocol extension, but its peer LSR does not, it is 88 necessary to have a protocol mechanism for resolving issues that may 89 arise. It is also beneficial to have a protocol mechanism to 90 discover the capabilities of peer LSRs. There is no such procedure 91 defined in the base LMP specification [RFC4204], so this document 92 defines how to handle LMP extensions both at legacy LSRs and at 93 upgraded LSRs that communicate with legacy LSRs. 95 In [RFC4204], the basic behaviors have been defined around the use 96 of the standard LMP message, which includes Config, Hello, Verify, 97 Test, LinkSummary, ChannelStatus. Per [RCF4204], these behaviors 98 MUST be supported when the LMP is implemented, and the message types 99 from 1 to 20 are used for these behaviors. 101 In [RFC4207], the SONET/SDH technology-specific information for LMP 102 is defined. The TRACE behavior is added to LMP, and the message 103 types from 21 to 31 were defined for the TRACE function. The TRACE 104 function has been extended for the support of OTNs (Optical 105 Transport Networks) in [LMP TEST]. 107 In [RFC4209], extensions to LMP are defined to allow it to be used 108 between a peer node and an adjacent optical line system (OLS). The 109 LMP object class type and sub-object class name have been extended 110 to support DWDM behavior. 112 In [RFC5818], the data channel consistency check behavior is defined, 113 the message types from 32 to 34 are used for this behavior. 115 This document describes the behavior negotiation procedure to make 116 sure both LSRs of each link understand the LMP messages being 117 exchanged between peers. 119 2. LMP Behavior Negotiation Procedure 121 The Config message is used in the control channel negotiation phase 122 of LMP [RC4204]. The LMP behavior negotiation procedure is defined 123 in this document as an addition at this phase. 125 The Config message is defined in Section 12.3.1 of [RFC4204] and 126 carries the object (class name 6) as defined in Section 127 13.6 of [RFC4204]. Multiple objects (each with a different 128 Class Type) MAY be present on a Config message in which case all of 129 the objects MUST be processed. 131 Two class types have been defined: 133 - C-Type = 1, HelloConfig, defined in [RFC4204] 135 - C-Type = 2, LMP_WDM_CONFIG, defined in [RFC4209] 136 This document defines a third C-Type with value 3 (TBD by IANA) to 137 report and negotiate new and future LMP extensions and behaviors. 139 - C-Type = 3, ENHANCED_BEHAVIOR_CONFIG 141 Two different types of flag are defined in this object: Architecture 142 Flags and Capability Flags. The first set of flags indicates the 143 network architecture supported by the node (e.g. OTN, SDH/SONET, 144 DWDM), while the second one all the optional capabilities supported 145 by the protocol implementation (e.g. Link Verification, Fault 146 Management). The existing RFCs define the following capabilities: 148 - Control Channel Management (Mandatory) 150 - Link Property Correlation (Mandatory) 152 - Link Verification (Optional) 154 - Fault Management (Optional) 156 - Trace Monitoring (Optional) 158 - Data Channel Status Confirmation (Optional) 160 Due to the fact that Control Channel Management and Link Property 161 Correlation are mandatory capabilities, no capability flag is 162 defined for their configuration. When an architecture flag is set, 163 automatically these two capabilities are implicitly supported. With 164 respect to the other ones, a flag for each of them is defined. 166 The format of the new type of CONFIG Class is defined as follows: 168 0 1 2 3 169 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 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | Reserved |M|O|W|S| Reserved |D|T|F|V| 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 |<----- Architecture Flags ---->|<----- Capability Flags ----->| 175 Architecture Flags: 177 S: 1 bit 179 This bit indicates support for the SONET/SDH. 181 W: 1 bit 182 This bit indicates support for WDM. 184 O: 1 bit 186 This bit indicates support for OTN. 188 M: 1 bit 190 This bit indicates support for MPLS-TP 192 Capability Flags: 194 V: 1 bit 196 This bit indicates support for the Link Verification capability 197 defined in [RFC4204]. 199 F: 1 bit 201 This bit indicates support for the Fault Management capability 202 defined in [RFC4204]. 204 T: 1 bit 206 This bit indicates support for the Trace Monitoring defined in 207 [RFC4204], [RFC4207] and [LMP TEST]. 209 D: 1 bit 211 This bit indicates support for the Data Channel Status Confirmation 212 messages defined in [RFC5818]. 214 Further bits may be defined in future documents. 216 The Reserved field MUST be sent as zero and MUST NOT be ignored on 217 receipt. This allows the detection of supported/unsupported LMP 218 behaviors. 220 Upon receiving a bit set related to a non supported behavior, a 221 ConfigNack message MUST be sent with a object representing 222 the supported LMP behaviors. 224 An LSR that receives a Config message containing a object 225 with a C-Type that it does not recognize MUST respond with a 226 ConfigNack message as described in [RFC4204]. Thus, legacy LMP nodes 227 that do not support the ENHANCED_BEHAVIOR_CONFIG C-Type defined in 228 this document will respond with a ConfigNack message. 230 3. Security Considerations 232 [RFC4204] describes how LMP messages between peers can be secured, 233 and these measures are equally applicable to messages carrying the 234 new object defined in this document. 236 The operation of the procedures described in this document does not 237 of itself constitute a security risk since they do not cause any 238 change in network state. It would be possible, if the messages were 239 intercepted or spoofed to cause bogus alerts in the management plane, 240 or to cause LMP peers to consider that they could or could not 241 operate protocol extensions, and so the use of the LMP security 242 measures are RECOMMENDED. 244 4. IANA Considerations 246 IANA maintains the "Link Management Protocol (LMP)" registry which 247 has a subregistry called "LMP Object Class name space and Class type 248 (C-Type)". 250 IANA is requested to make an assignment from this registry as 251 follows: 253 6 CONFIG [RFC4204] 255 CONFIG Object Class type name space: 257 C-Type Description Reference 258 ------ ------------------------ --------- 259 3 ENHANCED_BEHAVIOR_CONFIG [This.I-D] 261 5. Contributors 263 Diego Caviglia 264 Ericsson 265 Via A. Negrone 1/A 16153 266 Genoa Italy 267 Phone: +39 010 600 3736 268 Email: diego.caviglia@ericsson.com 270 6. Acknowledgments 272 Thanks to Adrian Farrel and Lou Berger for their useful comments. 274 7. References 276 7.1. Normative References 278 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 279 Requirement Levels", BCP 14, RFC 2119, March 1997. 281 [RFC4204] J. Lang, Ed., "Link Management Protocol (LMP)", RFC 4204, 282 October 2005. 284 [RFC4207] J. Lang, Ed., "Synchronous Optical Network (SONET)/ 285 Synchronous Digital Hierarchy (SDH) Encoding for Link 286 Management Protocol (LMP) Test Messages", RFC 4207, 287 October 2005. 289 [RFC4209] A. Fredette, Ed., "Link Management Protocol (LMP) for 290 Dense Wavelength Division Multiplexing (DWDM) Optical Line 291 Systems", RFC 4209, October 2005. 293 [RFC5818] D. Li, Ed., "Data Channel Status Confirmation Extensions 294 for the Link Management Protocol", RFC 5818, April 2010. 296 7.2. Informative References 298 [LMP TEST] D. Ceccarelli, Ed., "Link Management Protocol (LMP) Test 299 Messages Extensions for Evolutive Optical Transport 300 Networks (OTN)" draft-ceccarelli-ccamp-gmpls-g709-lmp- 301 test-02.txt, May, 2010. 303 8. Authors' Address 305 Dan Li 306 Huawei Technologies 307 F3-5-B R&D Center, Huawei Industrial Base, 308 Shenzhen 518129 China 309 Phone: +86 755-289-70230 310 Email: danli@huawei.com 312 Daniele Ceccarelli 313 Ericsson 314 Via A. Negrone 1/A 315 Genova - Sestri Ponente 316 Italy 317 Email: daniele.ceccarelli@ericsson.com