idnits 2.17.1 draft-gray-mpls-tp-nm-req-02.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 -- 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.) -- The document date (January 16, 2009) is 5579 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'LM' on line 391 -- Looks like a reference, but probably isn't: 'DM' on line 391 Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Hing-Kam Lam 3 Internet Draft Alcatel-Lucent 4 Expires: April, 2009 Scott Mansfield 5 Intended Status: Informational Eric Gray 6 Ericsson 7 January 16, 2009 9 MPLS TP Network Management Requirements 10 draft-gray-mpls-tp-nm-req-02.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance 15 with the provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet 18 Engineering Task Force (IETF), its areas, and its working 19 groups. Note that other groups may also distribute working 20 documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet- 25 Drafts as reference material or to cite them other than as "work 26 in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on July 16, 2009. 36 Abstract 38 This document specifies the requirements necessary to manage the 39 elements and networks that support an MPLS Transport Profile 40 (MPLS-TP). This document is a product of a joint International 41 Telecommunications Union - Telecommunications Standardization 42 Sector (ITU-T) and Internet Engineering Task Force (IETF) effort 43 to include a MPLS Transport Profile within the IETF MPLS 44 architecture. The requirements are driven by the management 45 functionality needs defined by ITU-T for packet transport 46 networks. 48 Table of Contents 50 1. Introduction................................................3 51 1.1. Terminology............................................3 52 2. Management Interface Requirements...........................4 53 3. Management Communication Channel (MCC) Requirements.........4 54 4. Management Communication Network (MCN) Requirements.........5 55 5. Fault Management Requirements...............................5 56 5.1. Supervision Function...................................5 57 5.2. Validation Function....................................6 58 5.3. Alarm Handling Function................................7 59 5.3.1. Alarm Severity Assignment.........................7 60 5.3.2. Alarm Suppression.................................8 61 5.3.3. Alarm Reporting Control...........................8 62 5.3.4. Alarm Reporting...................................8 63 6. Configuration Management Requirements.......................9 64 6.1. Hardware/Software Configuration........................9 65 6.2. Path Configuration.....................................9 66 6.3. OAM Configuration......................................9 67 7. Performance Management Requirements........................10 68 7.1. Path Characterization Performance Metrics.............10 69 7.2. Performance Collection Instrumentation................11 70 7.2.1. Collection Frequency.............................11 71 7.2.2. Collection Granularity...........................11 72 8. Security Management Requirements...........................12 73 8.1. Management Communication Channel Security.............12 74 8.1.1. In-Band management security......................12 75 8.1.2. Out-of-Band management security..................12 76 8.2. Signaling Communication Channel Security..............13 77 8.3. Distributed Denial of Service.........................13 78 9. Security Considerations....................................13 79 10. IANA Considerations.......................................13 80 11. Acknowledgments...........................................14 81 12. References................................................14 82 12.1. Normative References.................................14 83 12.2. Informative References...............................14 84 13. Author's Addresses........................................15 85 Intellectual Property Statement...............................15 86 Disclaimer of Validity........................................16 87 Copyright Statement...........................................16 88 Acknowledgment................................................16 90 1. Introduction 92 This document describes the requirements necessary to manage the 93 elements and networks that support an MPLS Transport Profile 94 (MPLS-TP). It leverages on the management requirements 95 specified in ITU-T G.7710/Y.1701 [1] and RFC 4377 [2]. ITU-T 96 G.7710/Y.1701 [1] specifies generic management requirements for 97 transport (including packet-based and circuit-based) networks. 98 RFC 4377 specifies the OAM requirements, including OAM-related 99 network management requirements, for MPLS networks. This 100 document expands on the requirements in [1] and [2] to cover 101 fault, configuration, performance, and security management for 102 MPLS-TP networks. 104 1.1. Terminology 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 107 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 108 "OPTIONAL" in this document are to be interpreted as described 109 in RFC 2119 [6]. 111 Editor's Note: Do we need the bulk of this section, since it 112 will be in the NM-FRAME document? Should we have the acronyms 113 spelled out in both documents? 115 MPLS-TP NE: a network element (NE) that supports MPLS-TP 116 functions 118 MPLS-TP network: a network in which MPLS-TP NEs are deployed 120 Data Communication Network (DCN): a network that supports Layer 121 1 (physical layer), Layer 2 (data-link layer), and Layer 3 122 (network layer) functionality for distributed management 123 communications related to the management plane, for distributed 124 signaling communications related to the control plane, and other 125 operations communications (e.g., order-wire/voice 126 communications, software downloads, etc.). 128 Management Communication Network (MCN): A DCN supporting 129 management plane communication is referred to as a Management 130 Communication Network (MCN). 132 Signaling Communication Network (SCN): A DCN supporting control 133 plane communication is referred to as a Signaling Communication 134 Network (SCN). 136 Embedded Communication Channel (ECC): a logical channel between 137 network elements (NEs) that can be used - e.g. - for management 138 plane application or control plane applications. The physical 139 channel supporting the ECC is technology specific. An example of 140 physical channels supporting the ECC is a DCC channel within 141 SDH. 143 Management Communication Channel (MCC): an ECC dedicated for 144 management plane communications. 146 Signaling Communication Channel (SCC): an ECC dedicated for 147 control plane communications. The SCC MAY be used for GMPLS/ASON 148 signaling and/or other control plane messages like e.g., routing 149 messages. 151 2.Management Interface Requirements 153 This document does not specify which management interface 154 protocol should be the standard protocol for managing MPLS-TP 155 networks. Managing an end-to-end connection across multiple 156 operator domains where one domain is managed (for example) via 157 NETCONF/XML or SNMP/SMI, and another domain via CORBA/IDL, is 158 allowed. 160 For the management interface to the management system, an MPLS- 161 TP NE is not expected to actively support more than one 162 management protocol in any given deployment. The protocol to be 163 supported is at the discretion of the operator. 165 3. Management Communication Channel (MCC) Requirements 167 The MPLS-TP management network SHOULD support seamless management 168 connectivity with remote MPLS-TP domains and NEs as specified 169 generically in ITU-T G.8601 [8] as well as with termination points 170 located in NEs under control by a third party network operator as 171 specified in G.8601. 173 For management purpose, every MPLS-TP NE MUST connect to an OS 174 either directly or indirectly via another MPLS-TP NE. When an 175 MPLS-TP NE is connected indirectly to an OS, an MCC MUST be 176 supported between the MPLS-TP NE and the other MPLS-TP NE. 178 4.Management Communication Network (MCN) Requirements 180 Entities of the MPLS-TP management plane communicate via the 181 DCN, or more specifically via the MCN. The MCN connects MPLS-TP 182 NEs with management systems, NEs with NEs, and management 183 systems with management systems. Transport DCN architecture and 184 requirements are specified in ITU-T G.7712/Y.1703 [7], including 185 network layer protocols and their interworking. 187 In order to have the MCN operate properly, a number of 188 management functions for the MCN are required: 190 . Retrieval of DCN network parameters to ensure compatible 191 functioning, e.g. packet size, timeouts, quality of 192 service, window size, etc.; 194 . Establishment of message routing between DCN nodes; 196 . Management of DCN network addresses; 198 . Retrieval of operational status of the DCN at a given node; 200 . Capability to enable/disable access to the DCN. 202 5.Fault Management Requirements 204 The Fault Management functions within an MPLS-TP NE enable the 205 supervision, detection, validation, isolation, correction, and 206 reporting of abnormal operation of the MPLS-TP network and its 207 environment. 209 5.1. Supervision Function 211 The supervision function analyses the actual occurrence of a 212 disturbance or fault for the purpose of providing an appropriate 213 indication of performance and/or detected fault condition to 214 maintenance personnel and operations systems. 216 The MPLS-TP NE MUST support the following transmission 217 supervision functions: 219 . Supervision of continuity check functions used to detect a 220 broken connection; 222 . Supervision of connectivity check functions used to detect 223 misconnection; 225 . Supervision of looping check functions used to detect 226 unintended self-replication; 228 . Supervision of Alarms based on native OAM, e.g., AIS (Alarm 229 Indication Signal) and FDI (Forward Defect Indication) 231 . Supervision of Lock indication; 233 . Supervision of Packet loss measurement in both directions 234 of the bidirectional connection; 236 . Supervision of Misinsertion check function used to detect 237 misinserted packet in the connection 239 . Supervision of Diagnostic test; 241 . Supervision of Route tracing; 243 . Supervision of Remote defect indication; 245 . Supervision of the detection of failure in the sequence of 246 a protocol exchange (e.g. automatic protection switching 247 protocol); 249 The MPLS-TP NE transmission-related supervision mechanisms MUST 250 support the flexibility to be configured to perform on-demand or 251 proactively. 253 The MPLS-TP NE MUST support supervision for software processing 254 e.g., processing fault, storage capacity problem, version 255 mismatch, Corrupted data, Out of memory, etc. 257 The MPLS-TP NE MUST support hardware-related supervision for 258 interchangeable and non-interchangeable units, cable, and power 259 problem. 261 The MPLS-TP NE SHOULD support environment-related supervision 262 for temperature, humidity, etc. 264 The MPLS-TP NE MUST support supervision of the OAM mechanisms 265 that are deployed for supporting the OAM requirements defined in 266 [3]. 268 5.2. Validation Function 270 Validation is concerned with the integration of Fault Causes 271 into Failures. A Fault Cause indicates a limited interruption of 272 the required transport function. A Fault Cause is not reported 273 to maintenance personnel because it could exist only for a very 274 short time. Note that some of these events however are summed up 275 in the Performance Monitoring process, and when this sum exceeds 276 a certain value, a Threshold Report can be generated. 278 When the Fault Cause lasts long enough, an inability to perform 279 the required transport function arises. This Failure condition 280 is subject to reporting to maintenance personnel and/or OS 281 because corrective action might be required. Conversely, when 282 the Fault Cause ceases after a certain time, clearing of the 283 Failure condition also subject to reporting. 285 The MPLS-TP NE MUST perform persistency check on fault causes 286 before it declares a fault cause a failure. 288 A transmission failure SHALL be declared if the fault cause 289 persists continuously for a configurable time (Time-D). The 290 failure SHALL be cleared if the fault cause is absent 291 continuously for a configurable time (Time-C). Typically the 292 default time values would be as follows: 294 Time-D = 2.5 +/- 0.5 seconds 296 Time-C = 10 +/- 0.5 seconds 298 These time values are as defined in G.7710 [1]. 300 The failure declaration and clearing MUST be time stamped. The 301 time-stamp SHALL indicate the time at which the fault cause is 302 activated at the input of the fault cause persistency (i.e. 303 defect-to-failure integration) function, and the time at which 304 the fault cause is deactivated at the input of the fault cause 305 persistency function. 307 5.3. Alarm Handling Function 309 5.3.1. Alarm Severity Assignment 311 Failures might be categorized to indicate the severity or 312 urgency of the fault. 314 An MPLS-TP NE SHOULD support the flexibility of assignment of 315 severity (e.g., Critical, Major, Minor, Warning) by the 316 management system. 318 See G.7710 [1] for more description about alarm severity 319 assignment. 321 5.3.2. Alarm Suppression 323 An MPLS-TP NE MUST provide alarm suppression functionality that 324 prevents the generation of a superfluous generation of alarms. 326 Examples of alarm suppression mechanism include simply 327 discarding the alarms (or not generating them in the first 328 place), or aggregating the alarms together, thereby greatly 329 reducing the number of alarm notifications to be emitted. 331 An MPLS-TP NE supporting the inter-working of one or more 332 networking technologies (e.g., Ethernet, SDH/SONET, OTN, MPLS) 333 with MPLS-TP MUST be able to translate an MPLS-TP defect into 334 the native technology's error condition. 336 See RFC 4377 [2] for more description. 338 5.3.3. Alarm Reporting Control 340 Alarm Reporting Control (ARC) supports an automatic in-service 341 provisioning capability. Alarm reporting MAY be turned off on a 342 per-managed entity (e.g., LSP) basis to allow sufficient time 343 for customer service testing and other maintenance activities in 344 an "alarm free" state. Once a managed entity is ready, alarm 345 reporting is automatically turned on. 347 An MPLS-TP NE SHOULD support the Alarm Reporting Control 348 function for controlling the reporting of alarm conditions. 350 See G.7710 [1] and RFC 3878 [1] for more description of ARC. 352 5.3.4. Alarm Reporting 354 Alarm Reporting is concerned with the reporting of relevant 355 events and conditions, which occur in the network (including the 356 NE, incoming signal, and external environment). 358 Local reporting is concerned with automatic alarming by means of 359 audible and visual indicators near the failed equipment. 361 An MPLS-TP NE MUST support local reporting of alarms. 363 The MPLS-TP NE MUST support reporting of alarms to an OS. These 364 reports are either autonomous reports (notifications) or reports 365 on request by maintenance personnel. The MPLS-TP ME SHOULD 366 report local (environmental) alarms to a network management 367 system. 369 6. Configuration Management Requirements 371 Configuration Management provides functions to identify, collect 372 data from, provide data to and control NEs. Specific 373 configuration tasks requiring network management support include 374 hardware and software configuration, configuration of NEs to 375 support transport paths (including required working and 376 protection paths), and configuration of required path 377 integrity/connectivity and performance monitoring (i.e. - OAM). 379 6.1. Hardware/Software Configuration 381 The MPLS-TP NE MUST support the configuration requirements 382 specified in G.7710 [1] for hardware, software, and date/time. 384 6.2. Path Configuration 386 The MPLS-TP NE MUST support the capability of configuring 387 required working and/or protection paths. 389 The MPLS-TP NE MUST support the capability of configuring 390 required path performance characteristic thresholds (e.g. - Loss 391 Measurement [LM], Delay Measurement [DM] thresholds). 393 The MPLS-TP NE MUST support the capability of configuring 394 required path protection as follows: 396 . configure some paths as working and others as protection; 397 . retrieve the status of these paths; 398 . configure the wait to restore time; 399 . operate/release manual protection switching; 400 . operate/release force protection switching; 401 . operate/release protection lockout; 402 . request/set automatic protection switching (APS) 403 parameters. 405 6.3. OAM Configuration 407 The MPLS-TP NE MUST provide the capability of configuring the 408 OAM functions specified in [3]. 410 The MPLS-TP NE MUST support the capability to choose which OAM 411 functions to use and which maintenance entity to apply them. 413 The MPLS-TP NE MUST support the capability of configuring the 414 OAM functions as part of connectivity management, including 415 bidirectional point-to-point connection, uni-directional point- 416 to-point connection, and uni-directional point-to-multipoint 417 connection. 419 The MPLS-TP NE MUST support the configuration of maintenance 420 entity identifiers (e.g. MEP ID and MIP ID) for the purpose of 421 connection connectivity checking. 423 The MPLS-TP NE MUST have the flexibility to configure OAM 424 parameters to meet their specific operational requirements, such 425 as whether (1) one-time on-demand immediately or (2) one-time 426 on-demand pre-scheduled or (3) on-demand periodically based on a 427 specified schedule or (4) proactive on-going. 429 The MPLS-TP NE MUST support the enabling/disabling of the 430 connectivity check processing. The connectivity check process of 431 the MPLS-TP NE MUST support provisioning of the identifiers to 432 be transmitted and the expected identifiers. 434 7. Performance Management Requirements 436 Performance Management provides functions to evaluate and report 437 upon the behavior of the equipment, NE, and network for the 438 purpose of Maintenance, Bring-into-service, Quality of service, 439 and Performance monitoring for signal degradation. ITU-T 440 Recommendation G.7710 [1] provides transport performance 441 monitoring requirements for packet-switched and circuit-switched 442 transport networks with the objective of providing coherent and 443 consistent interpretation of the network behavior, in particular 444 for hybrid network which consists of multiple transport 445 technologies. The performance management requirements specified 446 in this document are driven by such an objective. 448 7.1. Path Characterization Performance Metrics 450 The MPLS-TP NE MUST support collection of loss measurement (LM) 451 so that they can be used to detect performance degradation. 453 The MPLS-TP NE MUST support collection of delay measurement (DM) 454 so that they can be used to detect performance degradation. 456 The MPLS-TP NE MUST support reporting of Performance degradation 457 via fault management for corrective actions (e.g. protection 458 switching). 460 The MPLS-TP NE MUST support collection of loss ratio measurement 461 so that they can be used to determine Severely Errored Second 462 (SES). 464 A SES is declared for a one second interval when the ratio of 465 lost packets to total transmitted packets in that one second 466 interval exceeds a predetermined threshold. 468 The packet lost threshold for declaring SES MUST be 469 configurable. 471 The number of SESs MUST be collected per configurable intervals 472 (e.g. 15-minute and 24-hour). 474 The MPLS-TP NE MUST support collection of SES measurement so 475 that they can be used to determine service unavailable time. 477 A period of unavailable time (UAT) begins at the onset of 10 478 consecutive SES events. These 10 seconds are considered to be 479 part of unavailable time. A new period of available time begins 480 at the onset of 10 consecutive non-SES events. These 10 seconds 481 are considered to be part of available time. 483 The MPLS-TP NE MUST support collection of UAS so that they can 484 be used to determine service availability. 486 The number of unavailable time in seconds (UAS) MUST be 487 collected per configurable intervals (e.g. 15-minute and 24- 488 hour). 490 7.2.Performance Collection Instrumentation 492 7.2.1. Collection Frequency 494 The performance collection mechanisms MUST support the 495 flexibility to be configured to operate on-demand or proactively 496 (i.e. continuously). 498 7.2.2. Collection Granularity 500 On Packet loss measurement: 502 - For bidirectional (P2P) connection, collection of on-demand 503 single-ended packet loss measurement is required. 505 - For bidirectional (P2P) connection, collection of proactive 506 packet loss measurements for both directions is required. 508 - For unidirectional (P2P and P2MP) connection, collection of 509 proactive packet loss measurement is required. 511 On Delay measurement: 513 - For unidirectional (P2P and P2MP) connection, collection of 514 on-demand delay measurement is required. 516 - For bidirectional (P2P) connection, collection of on-demand 517 one-way and two-way delay measurement is required. 519 8. Security Management Requirements 521 The MPLS-TP NE MUST be able to secure the transport plane and 522 control plane. 524 8.1. Management Communication Channel Security 526 Secure channels MUST be provided for all network traffic and 527 protocols used to support management functions. This MUST 528 include, at least, protocols used for configuration, monitoring, 529 configuration backup, logging, time synchronization, 530 authentication, and routing. The MCC MUST support application 531 protocols that provide confidentiality and data integrity 532 protection. 534 8.1.1. In-Band management security 536 If in-band management is provided, the MCC MUST support the 537 following: 539 - Use of open cryptographic algorithms (See RFC 3871 [5] 540 section 4.5) 542 - Authentication 544 - Allow management connectivity only from authorized IP 545 addresses or MAC Addresses. 547 8.1.2. Out-of-Band management security 549 The MPLS TP NE MUST support an out-of-band management console 550 port. The management traffic MUST remain separate from the data 551 and control plane traffic (no routing or forwarding between the 552 management plane and the data/control plane). 554 8.2. Signaling Communication Channel Security 556 Secure control plane protocols MAY be used in place of their 557 insecure counterparts. If an insecure protocol is used, the 558 transport layer protocol MAY be used to secure the SCC. 560 8.3. Distributed Denial of Service 562 Denial of Service (DoS) attack is an attack which tries to 563 prevent a target from performing an assigned task, or providing 564 its intended service(s), through any means. A Distributed DoS 565 (DDoS) can multiply attack severity (possibly by an arbitrary 566 amount) by using multiple (potentially compromised) systems to 567 act as topologically (and potentially geographically) 568 distributed attack sources. It is possible to lessen the impact 569 and potential for DDOS by using secure protocols, turning off 570 unnecessary processes, logging and monitoring, and ingress 571 filtering. RFC 4732 [4] provides background on DOS in the 572 context of the Internet. 574 9. Security Considerations 576 Section 8 lists a set of security requirements that apply to 577 MPLS-TP network management. 579 Provisions to any of the network mechanisms designed to satisfy 580 the requirements described herein are required to prevent their 581 unauthorized use. Likewise, these network mechanisms MUST 582 provide a means by which an operator can prevent denial of 583 service attacks if those network mechanisms are used in such an 584 attack. 586 Solutions MUST provide mechanisms to prevent this private 587 information from being accessed by unauthorized eavesdropping, 588 or being directly obtained by an unauthenticated network 589 element, system or user. 591 Performance of diagnostic functions and path characterization 592 involves extracting a significant amount of information about 593 network construction that the network operator MAY consider 594 private. 596 10. IANA Considerations 598