idnits 2.17.1 draft-ietf-ccamp-gmpls-oam-requirements-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 565. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 536. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 543. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 549. 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 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group T. Nadeau 2 INTERNET-DRAFT BT 3 Intended Status: Informational T. Otani 4 Created: October 22, 2007 KDDI R&D Labs 5 Expires: April 22, 2008 D. Brungard 6 at&t 7 A. Farrel 8 Old Dog Consulting 10 OAM Requirements for Generalized Multi-Protocol Label Switching 11 (GMPLS) Networks 13 draft-ietf-ccamp-gmpls-oam-requirements-00.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Abstract 39 This document describes requirements for operations and management 40 (OAM) for Generalized Multi-Protocol Label Switching (GMPLS) 41 networks, as well as for applications of GMPLS. 43 Table of Contents 45 1. Introduction .................................................. 3 46 2. Terminology ................................................... 3 47 2.1 Conventions Used in this Document ............................ 3 48 2.2 Key Terms .................................................... 3 49 2.3 Acronyms ..................................................... 3 50 3. Motivations ................................................... 4 51 4. General Requirements .......................................... 4 52 4.1 GMPLS Control Plane and Communications Channel ............... 7 53 4.2 Interaction Between the Management and Control Planes ........ 7 54 4.2.1 Signaling .................................................. 7 55 4.2.2 Routing .................................................... 7 56 4.2.3 Link Management ............................................ 9 57 4.3 Interaction Between the GMPLS Control Plane and Data Plane ... 9 58 4.4 Detection of Label Switch Path Defects ....................... 9 59 4.5 Diagnosis of a Broken Label Switch Path ..................... 10 60 4.6 Path Characterization ....................................... 61 4.7 Service Level Agreement Measurement ......................... 62 4.8 Frequency of OAM Execution .................................. 63 4.9 Alarm Suppression, Aggregation, and Layer Coordination ...... 64 4.10 Support for OAM Interworking for Fault Notification ........ 65 4.11 Error Detection and Recovery ............................... 66 4.12 Standard Management Interfaces ............................. 67 4.13 Detection of Denial of Service Attacks .................... 68 4.14 Per-LSP Accounting Requirements ............................ 69 5. Security Consideration ....................................... 70 6. IANA Considerations .......................................... 71 7. References ................................................... 72 7.1 Normative References ........................................ 73 7.2 Informative References ...................................... 74 8. Acknowledgments .............................................. 75 9. Author's Address ............................................. 76 10. Intellectual Property Statement ............................. 77 11. Copyright Statement ......................................... 79 1. Introduction 81 This document describes requirements for control plane operations and 82 management (OAM) for Generalized Multi-Protocol Label Switching 83 (GMPLS) networks. It also describes OAM requirements associated with 84 the interaction between the GMPLS Control Plane and Data Plane OAM. 85 The OAM requirements specified in this document apply to GMPLS 86 networks as well as to applications of GMPLS functions such as 87 dynamic bandwidth broker applications. 89 [RFC3945] describes how GMPLS extends Multi-Protocol Label Switching 90 (MPLS) to support a variety of data plane technologies. The 91 requirements set out in this document apply to all forms of GMPLS 92 LSPs. 94 Note that the requirements for OAM for GMPLS networks are built on 95 the foundation requirements for OAM for MPLS networks [RFC4377], as 96 well as the existing OAM techniques available in non-packet networks 97 that may be controlled by GMPLS. These existing requirements are not 98 repeated in this document except to illustrate new requirements. 100 2. Terminology 102 2.1 Conventions Used in this Document 104 Although this is not a protocol specification, the key words "MUST", 105 "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 106 "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 107 interpreted as described in RFC-2119 [RFC2119] for clarity of 108 presentation of requirements. 110 2.2 Key Terms 112 Definitions of key terms for MPLS OAM and GMPLS are found in 113 [RFC3945] and [RFC4377], and the reader is assumed to be familiar 114 with those definitions which are not repeated here. 116 The reader may also find it helpful to be familiar with at least the 117 terminology sections of the SONET/SDH and OTN architectures [G.709] 118 and [G.784]. 120 2.3 Acronyms 122 GMPLS: Generalized Multi-Protocol Label Switching 123 CE: Customer Edge 124 DoS: Denial of Service 125 ECMP: Equal Cost Multipath 126 LDP: Label Distribution Protocol 127 LSP: Label Switched Path 128 LSR: Label Switching Router 129 OAM: Operations and Management 130 OA&M: Operations, Administration and Maintenance. 131 RSVP: Resource reSerVation Protocol 132 SP: Service Provider 133 TE: Traffic Engineering 134 SONET: Synchronous Optical Network 135 SDH: Synchronous Digital Hierarchy 136 TDM: Time Division Multiplexing 138 3. Motivations 140 OAM for MPLS networks has been established as a fundamental 141 requirement both through operational experience and through its 142 documentation in numerous Requests For Comment. Early MPLS OAM 143 documents developed specific solutions to individual issues or to 144 problems encountered in MPLS deployments. Coordination of the full 145 OAM requirements for MPLS was achieved in [RFC4377] and [RFC3609] in 146 recognition of the fact that the previous piecemeal approach could 147 lead to inconsistent and inefficient applicability of OAM techniques 148 across the MPLS architecture, and might require significant 149 modifications to operational procedures and systems in order to 150 provide consistent and useful OAM functionality. 152 Similarly, operational requirements for OAM have been established for 153 SONET/SDH/TDM networks. However, no requirements documents exist for 154 GMPLS networks which provide a comprehensive set of OAM requirements 155 which take into consideration both the GMPLS control plane protocols 156 and the underlying data planes. Since GMPLS networks pose some unique 157 configurations and problems for OAM not covered by existing 158 requirements or solutions documents, this document sets out the 159 requirements that need to be satisfied to fill this gap. 161 4. General Requirements 163 The general requirements described in this section are inspired by 164 those described for point-to-point MPLS in [RFC4377], and where the 165 GMPLS network is a packet network it is expected that the solutions 166 will be identical or very similar. The subsections below do not 167 repeat material from [RFC4377], but simply give references to that 168 document. 170 However, where the requirements for GMPLS OAM differ from or are more 171 extensive than those expressed in [RFC4377], additional text is 172 supplied. 174 Moreover, these requirements should be commonly applied to not only a 175 single domain network but also an inter-domain network [RFC4726]. 177 4.1 GMPLS Control Plane and Communications Channel 179 The GMPLS control plane SHOULD provide a health check function 180 between GMPLS control entities. 182 The control plane MUST provide a health check on the connectivity of 183 the control channel, and this SHOULD be configurable for both on- 184 demand operation and continual monitoring. This requirement applies 185 both to in-band and out-of-band control channel support. 187 If multiple control channels exist between two LSRs, the health check 188 SHOULD be supported for each control channel. 190 These functions MUST be independent of the underlying technology of 191 the control plane or data plane. 193 4.2 Interaction Between the Management and Control Planes 195 4.2.1 Signaling 197 It MUST be possible to monitor and manage the information about an 198 LSP (including session name, attributes, source/destination pair, and 199 route) created by the GMPLS control plane. Such management SHOULD be 200 provided through MIB modules. 202 It SHOULD be possible to monitor and distinguish the LSPs traversing 203 any TE link in the network. In the event of any data plane event that 204 affects any TE link, it MUST be possible for the management plane to 205 correlate the data plane faults to the individual control plane LSPs. 207 The control plane MUST allow the management plane administrative 208 privileges, e.g., changing the operational status of an LSP for pre- 209 planned maintenance and recovery-related operations. To support a 210 pre-planned maintenance activity or during a control plane failure, 211 it SHOULD be possible for selected LSPs to be manually switched from 212 their primary route to their secondary route though the management 213 plane. 215 The management plane SHOULD have the ability to change the recovery 216 type of active LSPs (for example, from unprotected to 1+1 protected, 217 or from full LSP rerouting to pre-planned LSP rerouting) without 218 disrupting traffic on the LSPs. 220 It SHOULD also be possible for the management plane to change other 221 properties of LSPs without impacting data plane operations. These 222 properties include, but are not limited to: 224 - LSP recovery type 225 - recovery priorities 226 - reversion support 227 - TBD List to be completed 229 The management plane SHOULD provide a mechanism to force the switch- 230 over to a different route or to a rcovery LSP. 232 4.2.2 Routing 234 It MUST be possible to manage and monitor the GMPLS routing 235 information exchanged in the control plane and to manage and monitor 236 the process by which the informaiton is exchanged. Such management 237 SHOULD be provided through MIB modules. 239 Management SHOULD have access to at least the following GMPLS 240 properties of TE links: 242 - bandwidth 243 - switching type 244 - source/destination address pair 246 Mechanisms SHOULD be provided in the management plane to verify the 247 consistency of the connectivity information distributed by routing 248 mechanisms in the control plane with the physical connectivity in the 249 data plane. 251 4.2.3 Link Management 253 The management plane MUST be able to monitor and manage the status 254 of TE links, and status changes of TE links MUST be notified to the 255 management plane. This SHOULD be provided through MIB modules. 257 Link verification mechanisms using the data plane and the control 258 plane should be supported interactively without configuring each 259 plane independently. 261 4.3 Interaction Between the GMPLS Control Plane and Data Plane 263 The GMPLS control plane supports operational separation from the data 264 plane. Various applications (e.g., ASON Call support [RFC4974], and 265 GMPLS recovery mechanisms [RFC4872], [RFC4873]) require the control 266 plane to be aware of the data plane operational status. The 267 operational state of the data plane SHOULD be automatically reported 268 to the control plane. On the other hand, the operational state of the 269 GMPLS control plane MUST NOT impact the operaitonal state of the data 270 plane. 272 4.4 Detection of Label Switch Path Defects 274 GMPLS decouples the data plane and the control plane. If the route of 275 an LSP is traced in the control plane, the route information SHOULD 276 include information about the data plane resources utilized by the 277 LSP so that an operator can check the validity of the data plane by 278 examining the data plane state directly. Mechanisms MAY be provided 279 to automate this correlation functionality. 281 4.5 Diagnosis of a Broken Label Switch Path 283 LMP [RFC4204] and LMP-WDM [RFC4209] are defined for use in GMPLS 284 networks manage TE links. The functions provided include fault 285 detection and fault isolation. The management plane SHOULD be able 286 to access this informaiton to make correlations between broken data 287 links and the implied status of both the TE links that the data links 288 support and the LSPs that traverse the data links. 290 Additionally, LSPs may be used as data links to support TE links 291 [RFC4206]. In this case, the management plane SHOULD be able to 292 access LSP status information to make correlations between failed 293 LSPs and the TE links that the LSPs support. 295 4.6 Path Characterization 297 Path characterization function is the ability to indicate the detail 298 of created LSPs. 300 The control plane MUST provide mechanisms to gather path 301 characterization information. The informaiton collected by the 302 control plane MUST be accessible to the management plane, and this 303 access SHOULD be through a MIB module. 305 4.7 Service Level Agreement Measurement 307 Existing data planes already provide various mechanisms to measure 308 the level of service being provided. These mechanisms are technology- 309 specific and include bit interleaved parity (BIP)-8 in SONET/SDH 310 overhead, and error counts in forward error correction (FEC) function 311 on OTN interfaces. These mechanisms operate distinct from the control 312 plane. 314 Mechanisms MUST be provided in the management to control the use of 315 these mechanisms and to gather the recorded information. It MUST be 316 possible to correlate the infromation gathered to the LSPs and the 317 services that the LSPs support. 319 Mechanisms MAY be provided thrugh the control plane to control the 320 use of these mechanisms and to distribute the information recorded. 322 4.8 Frequency of OAM Execution 324 This requirement is the same as for the MPLS OAM requirements. See 325 [RFC4377] section 4.5. 327 4.9 Alarm Suppression, Aggregation, and Layer Coordination 329 Alarm suppression function is required for in order to support link 330 maintenance. The GMPLS control plane MUST provide the ability to 331 control whether data plane components on the path of an LSP do or do 332 not generate alarms in the case of data plane faults. 334 To avoid a stream of alarms, alarm aggregation may be implemented by 335 LSRs and this may be achieved by determining the main cause and by 336 prioritizing the alarms. This function MAY be managed through the 337 control plane for data plane components on the path of an LSP. 339 Considering multi-layer GMPLS networks, such as a TDM switch capable 340 network over a lambda switch capable network, the generated alarms 341 MAY be correlated between layers by using the linkage information 342 between control planes of different layers. 344 4.10 Support for OAM Interworking for Fault Notification 346 MPLS OAM and GMPLS OAM SHOULD be interwork to support the operation 347 of an MPLS-TE network over a GMPLS network [MPLS/GMPLS]. 349 The operator SHOULD be able to control OAM function separately in 350 each network, but SHOULD be able to coordinate the OAM funciton. For 351 example, in the case of a data link failure in the GMPLS network, the 352 it SHOULD be possible to configure the GMPLS OAM to apply priorities 353 to the following actions: 355 - report the data link failure to the management plane of the GMPLS 356 network 358 - report the data link failure to the management plane of the MPLS 359 network 361 - trigger recovery operations within the GMPLS network 363 - trigger recovery operations within the MPLS network 365 4.11 Error Detection and Recovery 367 Error detection and recovery SHOULD be applicable not only to a 368 single domain network, but also an inter-domain network. Those 369 operations SHOULD be automated through the control plane and the data 370 plane. 372 4.12 Standard Management Interfaces 374 Common interfaces for the control and the management of the GMPLS 375 network are desired to facilitate wide deployment GMPLS networks. 377 Some GMPLS MIB modules have been standardized in [RFC4631], 378 [RFC4802], and [RFC4803] building on [RFC3811], [RFC3812], and 379 [RFC3813]. [RFC4220] provides a MIB module for managing and 380 monitoring TE links. 382 Since only those MIB modules do not cover all the OAM requirements 383 set out in this document, additional MIB modules SHOULD be developed 384 such as [TED-MIB]. 386 4.13 Detection of Denial of Service Attacks 388 This requirement is the same as for the MPLS OAM requirements. See 389 [RFC4377] section 4.10. 391 4.14 Per-LSP Accounting Requirements 393 A GMPLS LSP may support MPLS LSPs hierarchically. By pointing out the 394 GMPLS LSP, those MPLS LSPs over it SHOULD be managed and accounted. 396 5. Security Considerations 398 This document introduces no new security issues beyond those detailed 399 in the MPLS OAM requirements. See [RFC4377] section 5. 401 6. IANA Considerations 403 This informational document makes no requests for IANA action. 405 7. References 407 7.1 Normative References 409 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 410 Requirement Levels", BCP 14, RFC 2119, March 1997. 412 [RFC3945] E. Mannie, "Generalized Multi-Protocol Label 413 Switching Architecture", RFC 3945, October, 2004. 415 [RFC4377] T. Nadeau, et al., "OAM Requirements for MPLS 416 Network" RFC 4377, February 2006. 418 7.2 Informative References 420 [RFC3609] Bonica, R., Kompella, K., and Meyer, D., "Tracing 421 Requirements for Generic Tunnels", RFC 3609, September 422 2003. 424 [RFC3811] Nadeau, T., and Cucchiara, J., "Definitions of Textual 425 Conventions (TCs) for Multiprotocol Label Switching 426 (MPLS) Management", RFC 3811, June 2004. 428 [RFC3812] Srinivasan, C., Viswanathan, A., and Nadeau, T., 429 "Multiprotocol Label Switching (MPLS) Traffic 430 Engineering (TE) Management Information Base (MIB)", 431 RFC 3812, June 2004. 433 [RFC3813] Srinivasan, C., Viswanathan, A., and Nadeau, T., 434 "Multiprotocol Label Switching (MPLS) Label Switching 435 Router (LSR) Management Information Base (MIB)", 436 RFC 3813, June 2004. 438 [RFC4204] J. P. Lang, "Link Management Protocol(LMP)", RFC4204, 439 October 2005. 441 [RFC4206] Kompella, K. and Rekhter, Y., "Label Switched Paths 442 (LSP) Hierarchy with Generalized Multi-Protocol Label 443 Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, 444 October 2005. 446 [RFC4209] A. Fredette, "Link Management Protocol (LMP) for 447 Dense Wavelength Division Multiplexing (DWDM) Optical 448 Line Systems", RFC4209, October 2005. 450 [RFC4220] Dubuc, M., Nadeau, T., and Lang, J., "Traffic 451 Engineering Link Management Information Base", 452 RFC 4220, November 2005. 454 [RFC4631] M. Dubuc, et al, "Link Management Protocol (LMP) 455 Management Information Base (MIB)", RFC4631, September 456 2006. 458 [RFC4726] A. Farrel, et al, "A Framework for Inter-Domain MPLS 459 Traffic Engineering", RFC4726, November 2006. 461 [RFC4802] T. Nadeau, et al, "Generalized Multiprotocol Label 462 Switching (GMPLS) Traffic Engineering Management 463 Information Base", RFC4802, February 2007. 465 [RFC4803] T. Nadeau, et al, "Generalized Multiprotocol Label 466 Switching (GMPLS) Label Switching Router (LSR) 467 Management Information Base", RFC4803, Feb., 2007. 469 [RFC4872] Lang, J., Rekhter, Y., and Papadimitriou, D., "RSVP-TE 470 Extensions in Support of End-to-End Generalized Multi- 471 Protocol Label Switching (GMPLS) Recovery", RFC 4872, 472 May 2007. 474 [RFC4873] L. Berger, "GMPLS Based Segment Recovery", RFC 4873, 475 May 2007. 477 [RFC4974] Papadimitriou, D. and Farrel, A., "Generalized MPLS 478 (GMPLS) RSVP-TE Signaling Extensions in Support of 479 Calls", RFC 4974, August 2007. 481 [G.709] "Interfaces for the optical transport network (OTN)", 482 ITU-T G.709, February 2001. 484 [G.784] "Synchronous Digital Hierarchy (SDH) management", 485 ITU-T G.784, June 1999. 487 [MPLS/GMPLS] K. Kumaki, "Interworking Requirements to Support 488 operation of MPLS-TE over GMPLS networks", draft-ietf- 489 ccamp-mpls-gmpls-interwork-reqts, work in progress. 491 [TED-MIB] Miyazawa, M., Otani, T., Nadeaud, T., and Kumaki, K., 492 "Traffic Engineering Database Management Information 493 Base in support of GMPLS", draft-ietf-ccamp-gmpls-ted- 494 mib, work in progress. 496 8. Acknowledgments 498 The authors wish to acknowledge and thank Masanori Miyazawa, Don 499 O'Connor, and Tom Petch for their valuable comments on this document. 501 9. Author's Address 503 Tomohiro Otani 504 KDDI R&D Laboratories, Inc. 505 2-1-15 Ohara Fujimino 506 Saitama, 356-8502. Japan 507 Phone: +81-49-278-7357 508 Email: otani@kddilabs.jp 510 Thomas D. Nadeau 511 British Telecom 512 BT Centre 513 81 Newgate Street 514 EC1A 7AJ 515 London 516 Email: tom.nadeau@bt.com 518 Deborah Brungard (AT&T) 519 Rm. D1-3C22-200 S. Laurel Ave. 520 Middletown, NJ 07748, USA 521 Email: dbrungard@att.com 523 Adrian Farrel 524 Old Dog Consulting 525 Email: adrian@olddog.co.uk 527 10. Intellectual Property Statement 529 The IETF takes no position regarding the validity or scope of any 530 Intellectual Property Rights or other rights that might be claimed to 531 pertain to the implementation or use of the technology described in 532 this document or the extent to which any license under such rights 533 might or might not be available; nor does it represent that it has 534 made any independent effort to identify any such rights. Information 535 on the procedures with respect to rights in RFC documents can be 536 found in BCP 78 and BCP 79. 538 Copies of IPR disclosures made to the IETF Secretariat and any 539 assurances of licenses to be made available, or the result of an 540 attempt made to obtain a general license or permission for the use of 541 such proprietary rights by implementers or users of this 542 specification can be obtained from the IETF on-line IPR repository at 543 http://www.ietf.org/ipr. 545 The IETF invites any interested party to bring to its attention any 546 copyrights, patents or patent applications, or other proprietary 547 rights that may cover technology that may be required to implement 548 this standard. Please address the information to the IETF at ietf- 549 ipr@ietf.org. 551 11. Copyright Statement 553 Copyright (C) The IETF Trust (2007). 555 This document is subject to the rights, licenses and restrictions 556 contained in BCP 78, and except as set forth therein, the authors 557 retain all their rights. 559 This document and the information contained herein are provided on an 560 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 561 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 562 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 563 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 564 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 565 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.