idnits 2.17.1 draft-ietf-mpls-tp-nm-req-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 date (October 21, 2009) is 5302 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Downref: Normative reference to an Informational RFC: RFC 4377 (ref. '2') ** Downref: Normative reference to an Informational RFC: RFC 3871 (ref. '4') -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Downref: Normative reference to an Informational draft: draft-ietf-mpls-tp-framework (ref. '8') ** Downref: Normative reference to an Informational draft: draft-ietf-mpls-tp-nm-framework (ref. '9') Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 3 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: March, 2010 Scott Mansfield 5 Intended Status: Standards Track Eric Gray 6 Ericsson 7 October 21, 2009 9 MPLS TP Network Management Requirements 10 draft-ietf-mpls-tp-nm-req-06.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 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 April 21, 2010. 36 Abstract 38 This document specifies the requirements for the management of 39 equipment used in networks supporting an MPLS Transport Profile 40 (MPLS-TP). The requirements are defined for specification of 41 network management aspects of protocol mechanisms and procedures 42 that constitute the building blocks out of which the MPLS 43 transport profile is constructed. That is, these requirements 44 indicate what management capabilities need to be available in 45 MPLS for use in managing the MPLS-TP. This document is intended 46 to identify essential network management capabilities, not to 47 specify what functions any particular MPLS implementation 48 supports. 50 Table of Contents 52 1. Introduction................................................3 53 1.1. Terminology............................................4 54 2. Management Interface Requirements...........................6 55 3. Management Communication Channel (MCC) Requirements.........6 56 4. Management Communication Network (MCN) Requirements.........7 57 5. Fault Management Requirements...............................8 58 5.1. Supervision Function...................................8 59 5.2. Validation Function....................................9 60 5.3. Alarm Handling Function...............................10 61 5.3.1. Alarm Severity Assignment........................10 62 5.3.2. Alarm Suppression................................11 63 5.3.3. Alarm Reporting..................................11 64 5.3.4. Alarm Reporting Control..........................11 65 6. Configuration Management Requirements......................12 66 6.1. System Configuration..................................12 67 6.2. Control Plane Configuration...........................12 68 6.3. Path Configuration....................................12 69 6.4. Protection Configuration..............................13 70 6.5. OAM Configuration.....................................14 71 7. Performance Management Requirements........................14 72 7.1. Path Characterization Performance Metrics.............15 73 7.2. Performance Measurement Instrumentation...............16 74 7.2.1. Measurement Frequency............................16 75 7.2.2. Measurement Scope................................16 76 8. Security Management Requirements...........................17 77 8.1. Management Communication Channel Security.............17 78 8.2. Signaling Communication Channel Security..............17 79 8.3. Distributed Denial of Service.........................18 80 9. Security Considerations....................................18 81 10. IANA Considerations.......................................19 82 11. Acknowledgments...........................................19 83 12. References................................................19 84 12.1. Normative References.................................19 85 12.2. Informative References...............................20 86 Author's Addresses............................................21 87 Copyright Statement...........................................22 88 Acknowledgment................................................22 89 Appendix A - Communication Channel (CCh) Examples.............23 91 1. Introduction 93 This document specifies the requirements for the management of 94 equipment used in networks supporting an MPLS Transport Profile 95 (MPLS-TP). The requirements are defined for specification of 96 network management aspects of protocol mechanisms and procedures 97 that constitute the building blocks out of which the MPLS 98 transport profile is constructed. That is, these requirements 99 indicate what management capabilities need to be available in 100 MPLS for use in managing the MPLS-TP. This document is intended 101 to identify essential network management capabilities, not to 102 specify what functions any particular MPLS implementation 103 supports. 105 This document also leverages management requirements specified in 106 ITU-T G.7710/Y.1701 [1] and RFC 4377 [2], and attempts to comply 107 with best common practice as defined in [15]. 109 ITU-T G.7710/Y.1701 defines generic management requirements for 110 transport networks. RFC 4377 specifies the OAM requirements, 111 including OAM-related network management requirements, for MPLS 112 networks. 114 This document is a product of a joint ITU-T and IETF effort to 115 include an MPLS Transport Profile (MPLS-TP) within the IETF MPLS 116 and PWE3 architectures to support capabilities and functionality 117 of a transport network as defined by ITU-T. 119 The requirements in this document derive from two sources: 121 1) MPLS and PWE3 architectures as defined by IETF, and 123 2) packet transport networks as defined by ITU-T. 125 Requirements for management of equipment in MPLS-TP networks are 126 defined herein. Related functions of MPLS and PWE3 are defined 127 elsewhere (and are out of scope in this document). 129 This document expands on the requirements in [1] and [2] to cover 130 fault, configuration, performance, and security management for 131 MPLS-TP networks, and the requirements for object and information 132 models needed to manage MPLS-TP Networks and Network Elements. 134 In writing this document, the authors assume the reader is 135 familiar with references [8] and [9]. 137 1.1. Terminology 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 140 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 141 "OPTIONAL" in this document are to be interpreted as described in 142 RFC 2119 [5]. Although this document is not a protocol 143 specification, the use of this language clarifies the 144 instructions to protocol designers producing solutions that 145 satisfy the requirements set out in this document. 147 Anomaly: The smallest discrepancy which can be observed between 148 actual and desired characteristics of an item. The occurrence of 149 a single anomaly does not constitute an interruption in ability 150 to perform a required function. Anomalies are used as the input 151 for the Performance Monitoring (PM) process and for detection of 152 defects (from [21], 3.7). 154 Communication Channel (CCh): A logical channel between network 155 elements (NEs) that can be used - e.g. - for management or 156 control plane applications. The physical channel supporting the 157 CCh is technology specific. See Appendix A. 159 Data Communication Network (DCN): A network that supports Layer 1 160 (physical layer), Layer 2 (data-link layer), and Layer 3 (network 161 layer) functionality for distributed management communications 162 related to the management plane, for distributed signaling 163 communications related to the control plane, and other operations 164 communications (e.g., order-wire/voice communications, software 165 downloads, etc.). 167 Defect: The density of anomalies has reached a level where the 168 ability to perform a required function has been interrupted. 169 Defects are used as input for performance monitoring, the control 170 of consequent actions, and the determination of fault cause (from 171 [21], 3.24). 173 Failure: The fault cause persisted long enough to consider the 174 ability of an item to perform a required function to be 175 terminated. The item may be considered as failed; a fault has now 176 been detected (from [21], 3.25). 178 Fault: A fault is the inability of a function to perform a 179 required action. This does not include an inability due to 180 preventive maintenance, lack of external resources, or planned 181 actions (from [21], 3.26). 183 Fault Cause: A single disturbance or fault may lead to the 184 detection of multiple defects. A fault cause is the result of a 185 correlation process which is intended to identify the defect that 186 is representative of the disturbance or fault that is causing the 187 problem (from [21], 3.27). 189 Fault Cause Indication (FCI): An indication of a fault cause. 191 Management Communication Channel (MCC): A CCh dedicated for 192 management plane communications. 194 Management Communication Network (MCN): A DCN supporting 195 management plane communication is referred to as a Management 196 Communication Network (MCN). 198 MPLS-TP NE: A network element (NE) that supports the functions of 199 MPLS necessary to participate in an MPLS-TP based transport 200 service. See [7] for further information on functionality 201 required to support MPLS-TP. 203 MPLS-TP network: a network in which MPLS-TP NEs are deployed. 205 OAM, On-Demand and Proactive: One feature of OAM that is largely 206 a management issue is control of OAM; on-demand and proactive are 207 modes of OAM mechanism operation defined - for example - in 208 Y.1731 ([22] - 3.45 and 3.44 respectively) as: 210 . On-demand OAM - OAM actions which are initiated via manual 211 intervention for a limited time to carry out diagnostics. 212 On-demand OAM can result in singular or periodic OAM actions 213 during the diagnostic time interval. 215 . Proactive OAM - OAM actions which are carried on 216 continuously to permit timely reporting of fault and/or 217 performance status. 219 (Note that it is possible for specific OAM mechanisms to only 220 have a sensible use in either on-demand or proactive mode.) 222 Operations System (OS): A system that performs the functions that 223 support processing of information related to operations, 224 administration, maintenance, and provisioning (OAM&P) for the 225 networks, including surveillance and testing functions to support 226 customer access maintenance. 228 Signaling Communication Channel (SCC): A CCh dedicated for 229 control plane communications. The SCC can be used for GMPLS/ASON 230 signaling and/or other control plane messages (e.g., routing 231 messages). 233 Signaling Communication Network (SCN): A DCN supporting control 234 plane communication is referred to as a Signaling Communication 235 Network (SCN). 237 2. Management Interface Requirements 239 This document does not specify a preferred management interface 240 protocol to be used as the standard protocol for managing MPLS-TP 241 networks. Managing an end-to-end connection across multiple 242 operator domains where one domain is managed (for example) via 243 NETCONF ([16]) or SNMP ([17]), and another domain via CORBA 244 ([18]), is allowed. 246 1) For the management interface to the management system, an 247 MPLS-TP NE MAY actively support more than one management 248 protocol in any given deployment. 250 For example, an operator can use one protocol for configuration 251 of an MPLS-TP NE and another for monitoring. The protocols to be 252 supported are at the discretion of the operator. 254 3. Management Communication Channel (MCC) Requirements 256 1) Specifications SHOULD define support for management 257 connectivity with remote MPLS-TP domains and NEs, as well as 258 with termination points located in NEs under the control of 259 a third party network operator. See ITU-T G.8601 [23] for 260 example scenarios in multi-carrier multi-transport- 261 technology environments. 263 2) For management purpose, every MPLS-TP NE MUST connect to an 264 OS. The connection MAY be direct (e.g. - via a software, 265 hardware or proprietary protocol connection) or indirect 266 (via another MPLS-TP NE). In this document, any management 267 connection that is not via another MPLS-TP NE is a direct 268 management connection. When an MPLS-TP NE is connected 269 indirectly to an OS, an MCC MUST be supported between that 270 MPLS-TP NE and any MPLS-TP NE(s) used to provide the 271 connection to an OS. 273 4. Management Communication Network (MCN) Requirements 275 Entities of the MPLS-TP management plane communicate via a DCN, 276 or more specifically via the MCN. The MCN connects management 277 systems with management systems, management systems with MPLS-TP 278 NEs, and (in the indirect connectivity case discussed in section 279 3) MPLS-TP NEs with MPLS-TP NEs. 281 RFC 5586 [14] defines a Generic Associated Channel (G-ACh) to 282 enable the realization of a communication channel (CCh) between 283 adjacent MPLS-TP NEs for management and control. Reference [10] 284 describes how the G-ACh can be used to provide infrastructure 285 that forms part of the MCN and SCN. It also explains how MCN and 286 SCN messages are encapsulated, carried on the G-ACh, and 287 decapsulated for delivery to management or signaling/routing 288 control plane components on a label switching router (LSR). 290 ITU-T G.7712/Y.1703 [6], section 7, describes the transport DCN 291 architecture and requirements. 293 1) The MPLS-TP MCN MUST support the requirements (in reference 294 [6]) for: 296 a) CCh access functions specified in section 7.1.1; 298 b) MPLS-TP SCC data-link layer termination functions 299 specified in section 7.1.2.3; 301 c) MPLS-TP MCC data-link layer termination functions 302 specified in section 7.1.2.4; 304 d) Network layer PDU into CCh data-link frame encapsulation 305 functions specified in section 7.1.3; 307 e) Network layer PDU forwarding (7.1.6), interworking (7.1.7) 308 and encapsulation (7.1.8) functions, as well as tunneling 309 (7.1.9) and routing (7.1.10) functions specified in [6]. 311 As a practical matter, MCN connections will typically have 312 addresses. See the section on Identifiers in [8] for further 313 information. 315 In order to have the MCN operate properly, a number of management 316 functions for the MCN are needed, including: 318 . Retrieval of DCN network parameters to ensure compatible 319 functioning, e.g. packet size, timeouts, quality of service, 320 window size, etc.; 322 . Establishment of message routing between DCN nodes; 324 . Management of DCN network addresses; 326 . Retrieval of operational status of the DCN at a given node; 328 . Capability to enable/disable access by an NE to the DCN. 329 Note that this is to allow isolating a malfunctioning NE 330 from impacting the rest of the network. 332 5. Fault Management Requirements 334 The Fault Management functions within an MPLS-TP NE enable the 335 supervision, detection, validation, isolation, correction, and 336 reporting of abnormal operation of the MPLS-TP network and its 337 environment. 339 5.1. Supervision Function 341 The supervision function analyses the actual occurrence of a 342 disturbance or fault for the purpose of providing an appropriate 343 indication of performance and/or detected fault condition to 344 maintenance personnel and operations systems. 346 1) The MPLS-TP NE MUST support supervision of the OAM 347 mechanisms that are deployed for supporting the OAM 348 requirements defined in [3]. 350 2) The MPLS-TP NE MUST support the following data-plane 351 forwarding path supervision functions: 353 a) Supervision of loop-checking functions used to detect 354 loops in the data-plane forwarding path (which result in 355 non-delivery of traffic, wasting of forwarding resources 356 and unintended self-replication of traffic); 358 b) Supervision of failure detection; 360 3) The MPLS-TP NE MUST support the capability to configure 361 data-plane forwarding path related supervision mechanisms to 362 perform on-demand or proactively. 364 4) The MPLS-TP NE MUST support supervision for software 365 processing - e.g., processing faults, storage capacity, 366 version mismatch, corrupted data and out of memory problems, 367 etc. 369 5) The MPLS-TP NE MUST support hardware-related supervision for 370 interchangeable and non-interchangeable unit, cable, and 371 power problems. 373 6) The MPLS-TP NE SHOULD support environment-related 374 supervision for temperature, humidity, etc. 376 5.2. Validation Function 378 Validation is the process of integrating Fault Cause indications 379 into Failures. A Fault Cause Indication (FCI) indicates a limited 380 interruption of the required transport function. A Fault Cause is 381 not reported to maintenance personnel because it might exist only 382 for a very short time. Note that some of these events are summed 383 up in the Performance Monitoring process (see section 7), and 384 when this sum exceeds a configured value, a threshold crossing 385 alert (report) can be generated. 387 When the Fault Cause lasts long enough, an inability to perform 388 the required transport function arises. This failure condition is 389 subject to reporting to maintenance personnel and/or an OS 390 because corrective action might be required. Conversely, when the 391 Fault Cause ceases after a certain time, clearing of the Failure 392 condition is also subject to reporting. 394 1) The MPLS-TP NE MUST perform persistency checks on fault 395 causes before it declares a fault cause a failure. 397 2) The MPLS-TP NE SHOULD provide a configuration capability for 398 control parameters associated with performing the 399 persistency checks described above. 401 3) An MPLS-TP NE MAY provide configuration parameters to 402 control reporting, and clearing, of failure conditions. 404 4) A data-plane forwarding path failure MUST be declared if the 405 fault cause persists continuously for a configurable time 406 (Time-D). The failure MUST be cleared if the fault cause is 407 absent continuously for a configurable time (Time-C). 409 Note: As an example, the default time values might be as follows: 411 Time-D = 2.5 +/- 0.5 seconds 413 Time-C = 10 +/- 0.5 seconds 415 These time values are as defined in G.7710 [1]. 417 5) MIBs - or other object management semantics specifications - 418 defined to enable configuration of these timers SHOULD 419 explicitly provide default values and MAY provide guidelines 420 on ranges and value determination methods for scenarios 421 where the default value chosen might be inadequate. In 422 addition, such specifications SHOULD define the level of 423 granularity at which tables of these values are to be 424 defined. 426 6) Implementations MUST provide the ability to configure the 427 preceding set of timers, and SHOULD provide default values 428 to enable rapid configuration. Suitable default values, 429 timer ranges, and level of granularity are out of scope in 430 this document and form part of the specification of fault 431 management details. Timers SHOULD be configurable per NE for 432 broad categories (for example, defects and/or fault causes), 433 and MAY be configurable per-interface on an NE and/or per 434 individual defect/fault cause. 436 7) The failure declaration and clearing MUST be time stamped. 437 The time-stamp MUST indicate the time at which the fault 438 cause is activated at the input of the fault cause 439 persistency (i.e. defect-to-failure integration) function, 440 and the time at which the fault cause is deactivated at the 441 input of the fault cause persistency function. 443 5.3. Alarm Handling Function 445 5.3.1. Alarm Severity Assignment 447 Failures can be categorized to indicate the severity or urgency 448 of the fault. 450 1) An MPLS-TP NE SHOULD support the ability to assign severity 451 (e.g., Critical, Major, Minor, Warning) to alarm conditions 452 via configuration. 454 See G.7710 [1], section 7.2.2 for more detail on alarm severity 455 assignment. For additional discussion of Alarm Severity 456 management, see discussion of alarm severity in RFC 3877 [11]. 458 5.3.2. Alarm Suppression 460 Alarms can be generated from many sources, including OAM, device 461 status, etc. 463 1) An MPLS-TP NE MUST support suppression of alarms based on 464 configuration. 466 5.3.3. Alarm Reporting 468 Alarm Reporting is concerned with the reporting of relevant 469 events and conditions, which occur in the network (including the 470 NE, incoming signal, and external environment). 472 Local reporting is concerned with automatic alarming by means of 473 audible and visual indicators near the failed equipment. 475 1) An MPLS-TP NE MUST support local reporting of alarms. 477 2) The MPLS-TP NE MUST support reporting of alarms to an OS. 478 These reports are either autonomous reports (notifications) 479 or reports on request by maintenance personnel. The MPLS-TP 480 NE SHOULD report local (environmental) alarms to a network 481 management system. 483 3) An MPLS-TP NE supporting one or more other networking 484 technologies (e.g. - Ethernet, SDH/SONET, MPLS) over MPLS-TP 485 MUST be capable of translating an MPLS-TP defects into 486 failure conditions that are meaningful to the client layer, 487 as described in RFC 4377 [2], section 4.7. 489 5.3.4. Alarm Reporting Control 491 Alarm Reporting Control (ARC) supports an automatic in-service 492 provisioning capability. Alarm reporting can be turned off on a 493 per-managed entity (e.g., LSP) basis to allow sufficient time for 494 customer service testing and other maintenance activities in an 495 "alarm free" state. Once a managed entity is ready, alarm 496 reporting is automatically turned on. 498 1) An MPLS-TP NE SHOULD support the Alarm Reporting Control 499 function for controlling the reporting of alarm conditions. 501 See G.7710 [1] (section 7.1.3.2) and RFC 3878 [24] for more 502 information about ARC. 504 6. Configuration Management Requirements 506 Configuration Management provides functions to identify, collect 507 data from, provide data to and control NEs. Specific 508 configuration tasks requiring network management support include 509 hardware and software configuration, configuration of NEs to 510 support transport paths (including required working and 511 protection paths), and configuration of required path 512 integrity/connectivity and performance monitoring (i.e. - OAM). 514 6.1. System Configuration 516 1) The MPLS-TP NE MUST support the configuration requirements 517 specified in G.7710 [1] section 8.1 for hardware. 519 2) The MPLS-TP NE MUST support the configuration requirements 520 specified in G.7710 [1] section 8.2 for software. 522 3) The MPLS-TP NE MUST support the configuration requirements 523 specified in G.7710 [1] section 8.13.2.1 for local real time 524 clock functions. 526 4) The MPLS-TP NE MUST support the configuration requirements 527 specified in G.7710 [1] section 8.13.2.2 for local real time 528 clock alignment with external time reference. 530 5) The MPLS-TP NE MUST support the configuration requirements 531 specified in G.7710 [1] section 8.13.2.3 for performance 532 monitoring of the clock function. 534 6.2. Control Plane Configuration 536 1) If a control plane is supported in an implementation of 537 MPLS-TP, the MPLS-TP NE MUST support the configuration of 538 MPLS-TP control plane functions by the management plane. 539 Further detailed requirements will be provided along with 540 progress in defining the MPLS-TP control plane in 541 appropriate specifications. 543 6.3. Path Configuration 545 1) In addition to the requirement to support static 546 provisioning of transport paths (defined in [7], section 2.1 547 - General Requirements - requirement 18), an MPLS-TP NE MUST 548 support the configuration of required path performance 549 characteristic thresholds (e.g. - Loss Measurement , 550 Delay Measurement thresholds) necessary to support 551 performance monitoring of the MPLS-TP service(s). 553 2) In order to accomplish this, an MPLS-TP NE MUST support 554 configuration of LSP information (such as an LSP identifier 555 of some kind) and/or any other information needed to 556 retrieve LSP status information, performance attributes, 557 etc. 559 3) If a control plane is supported, and that control plane 560 includes support for control-plane/management-plane hand-off 561 for LSP setup/maintenance, the MPLS-TP NE MUST support 562 management of the hand-off of Path control. See, for 563 example, references [19] and [20]. 565 4) Further detailed requirements SHALL be provided along with 566 progress in defining the MPLS-TP control plane in 567 appropriate specifications. 569 5) If MPLS-TP transport paths cannot be statically provisioned 570 using MPLS LSP and pseudo-wire management tools (either 571 already defined in standards or under development), further 572 management specifications MUST be provided as needed. 574 6.4. Protection Configuration 576 1) The MPLS-TP NE MUST support configuration of required path 577 protection information as follows: 579 . designate specifically identified LSPs as working or 580 protecting LSPs; 582 . define associations of working and protecting paths; 584 . operate/release manual protection switching; 586 . operate/release force protection switching; 588 . operate/release protection lockout; 590 . set/retrieve Automatic Protection Switching (APS) 591 parameters, including - 593 o Wait to Restore time, 595 o Protection Switching threshold information. 597 6.5. OAM Configuration 599 1) The MPLS-TP NE MUST support configuration of the OAM 600 entities and functions specified in [3]. 602 2) The MPLS-TP NE MUST support the capability to choose which 603 OAM functions are enabled. 605 3) For enabled OAM functions, the MPLS-TP NE MUST support the 606 ability to associate OAM functions with specific maintenance 607 entities. 609 4) The MPLS-TP NE MUST support the capability to configure the 610 OAM entities/functions as part of LSP setup and tear-down, 611 including co-routed bidirectional point-to-point, associated 612 bidirectional point-to-point, and uni-directional (both 613 point-to-point and point-to-multipoint) connections. 615 5) The MPLS-TP NE MUST support the configuration of maintenance 616 entity identifiers (e.g. MEP ID and MIP ID) for the purpose 617 of LSP connectivity checking. 619 6) The MPLS-TP NE MUST support configuration of OAM parameters 620 to meet their specific operational requirements, such as 621 whether - 623 a) one-time on-demand immediately or 625 b) one-time on-demand pre-scheduled or 627 c) on-demand periodically based on a specified schedule or 629 d) proactive on-going. 631 7) The MPLS-TP NE MUST support the enabling/disabling of the 632 connectivity check processing. The connectivity check 633 process of the MPLS-TP NE MUST support provisioning of the 634 identifiers to be transmitted and the expected identifiers. 636 7. Performance Management Requirements 638 Performance Management provides functions for the purpose of 639 Maintenance, Bring-into-service, Quality of service, and 640 statistics gathering. 642 This information could be used, for example, to compare behavior 643 of the equipment, MPLS-TP NE or network at different moments in 644 time to evaluate changes in network performance. 646 ITU-T Recommendation G.7710 [1] provides transport performance 647 monitoring requirements for packet-switched and circuit-switched 648 transport networks with the objective of providing coherent and 649 consistent interpretation of the network behavior in a multi- 650 technology environment. The performance management requirements 651 specified in this document are driven by such an objective. 653 7.1. Path Characterization Performance Metrics 655 1) It MUST be possible to determine when an MPLS-TP based 656 transport service is available and when it is unavailable. 658 From a performance perspective, a service is unavailable if there 659 is an indication that performance has degraded to the extent that 660 a configurable performance threshold has been crossed and the 661 degradation persists long enough (i.e. - the indication persists 662 for some amount of time - which is either configurable, or well- 663 known) to be certain it is not a measurement anomaly. 665 Methods, mechanisms and algorithms for exactly how unavailability 666 is to be determined - based on collection of raw performance data 667 - are out of scope for this document. 669 2) The MPLS-TP NE MUST support collection and reporting of raw 670 performance data that MAY be used in determining the 671 unavailability of a transport service. 673 3) MPLS-TP MUST support the determination of the unavailability 674 of the transport service. The result of this determination 675 MUST be available via the MPLS-TP NE (at service termination 676 points), and determination of unavailability MAY be 677 supported by the MPLS-TP NE directly. To support this 678 requirement, the MPLS-TP NE management information model 679 MUST include objects corresponding to availability-state of 680 services. 682 Transport network unavailability is based on Severely Errored 683 Seconds (SES) and Unavailable Seconds (UAS). ITU-T is 684 establishing definitions of unavailability generically applicable 685 to packet transport technologies, including MPLS-TP, based on SES 686 and UAS. Note that SES and UAS are already defined for Ethernet 687 transport networks in ITU-T Recommendation Y.1563 [25]. 689 4) The MPLS-TP NE MUST support collection of loss measurement 690 (LM) statistics. 692 5) The MPLS-TP NE MUST support collection of delay measurement 693 (DM) statistics. 695 6) The MPLS-TP NE MUST support reporting of Performance 696 degradation via fault management for corrective actions. 698 "Reporting" in this context could mean: 700 . reporting to an autonomous protection component to 701 trigger protection switching, 703 . reporting via a craft interface to allow replacement of a 704 faulty component (or similar manual intervention), 706 . etc. 708 7) The MPLS-TP NE MUST support reporting of performance 709 statistics on request from a management system. 711 7.2. Performance Measurement Instrumentation 713 7.2.1. Measurement Frequency 715 1) For performance measurement mechanisms that support both 716 proactive and on-demand modes, the MPLS-TP NE MUST support 717 the capability to be configured to operate on-demand or 718 proactively. 720 7.2.2. Measurement Scope 722 On measurement of packet loss and loss ratio: 724 1) For bidirectional (both co-routed and associated) P2P 725 connections - 727 a) on-demand measurement of single-ended packet loss, and 728 loss ratio, measurement is REQUIRED; 730 b) proactive measurement of packet loss, and loss ratio, 731 measurement for each direction is REQUIRED. 733 2) For unidirectional (P2P and P2MP) connection, proactive 734 measurement of packet loss, and loss ratio, is REQUIRED. 736 On Delay measurement: 738 3) For unidirectional (P2P and P2MP) connection, on-demand 739 measurement of delay measurement is REQUIRED. 741 4) For co-routed bidirectional (P2P) connection, on-demand 742 measurement of one-way and two-way delay is REQUIRED. 744 5) For associated bidirectional (P2P) connection, on-demand 745 measurement of one-way delay is REQUIRED. 747 8. Security Management Requirements 749 1) The MPLS-TP NE MUST support secure management and control 750 planes. 752 8.1. Management Communication Channel Security 754 1) Secure communication channels MUST be supported for all 755 network traffic and protocols used to support management 756 functions. This MUST include, at least, protocols used for 757 configuration, monitoring, configuration backup, logging, 758 time synchronization, authentication, and routing. 760 2) The MCC MUST support application protocols that provide 761 confidentiality and data integrity protection. 763 3) The MPLS-TP NE MUST support the following: 765 a) Use of open cryptographic algorithms (See RFC 3871 [4]) 767 b) Authentication - allow management connectivity only from 768 authenticated entities. 770 c) Authorization - allow management activity originated by an 771 authorized entity, using (for example) an Access Control 772 List (ACL). 774 d) Port Access Control - allow management activity received 775 on an authorized (management) port. 777 8.2. Signaling Communication Channel Security 779 Security requirements for the SCC are driven by considerations 780 similar to MCC requirements described in section 8.1. 782 Security Requirements for the control plane are out of scope for 783 this document and are expected to be defined in the appropriate 784 control plane specifications. 786 1) Management of control plane security MUST be defined in the 787 appropriate control plane specifications.. 789 8.3. Distributed Denial of Service 791 A Denial of Service (DoS) attack is an attack that tries to 792 prevent a target from performing an assigned task, or providing 793 its intended service(s), through any means. A Distributed DoS 794 (DDoS) can multiply attack severity (possibly by an arbitrary 795 amount) by using multiple (potentially compromised) systems to 796 act as topologically (and potentially geographically) distributed 797 attack sources. It is possible to lessen the impact and potential 798 for DoS and DDoS by using secure protocols, turning off 799 unnecessary processes, logging and monitoring, and ingress 800 filtering. RFC 4732 [26] provides background on DoS in the 801 context of the Internet. 803 1) An MPLS-TP NE MUST support secure management protocols and 804 SHOULD do so in a manner that reduces potential impact of a 805 DoS attack. 807 2) An MPLS-TP NE SHOULD support additional mechanisms that 808 mitigate a DoS (or DDoS) attack against the management 809 component while allowing the NE to continue to meet its 810 primary functions. 812 9. Security Considerations 814 Section 8 includes a set of security requirements that apply to 815 MPLS-TP network management. 817 1) Solutions MUST provide mechanisms to prevent unauthorized 818 and/or unauthenticated access to management capabilities and 819 private information by network elements, systems or users. 821 Performance of diagnostic functions and path characterization 822 involves extracting a significant amount of information about 823 network construction that the network operator might consider 824 private. 826 10. IANA Considerations 828 There are no IANA actions associated with this document. 830 11. Acknowledgments 832 The authors/editors gratefully acknowledge the thoughtful review, 833 comments and explanations provided by Adrian Farrel, Alexander 834 Vainshtein, Andrea Maria Mazzini, Ben Niven-Jenkins, Bernd 835 Zeuner, Dan Romascanu, Daniele Ceccarelli, Diego Caviglia, Dieter 836 Beller, He Jia, Leo Xiao, Maarten Vissers, Neil Harrison, Rolf 837 Winter, Yoav Cohen and Yu Liang. 839 12. References 841 12.1. Normative References 843 [1] ITU-T Recommendation G.7710/Y.1701, "Common equipment 844 management function requirements", July, 2007. 846 [2] Nadeau, T., et al, "Operations and Management (OAM) 847 Requirements for Multi-Protocol Label Switched (MPLS) 848 Networks", RFC 4377, February 2006. 850 [3] Vigoureux, M., et al, "Requirements for OAM in MPLS 851 Transport Networks", draft-ietf-mpls-tp-oam-requirements, 852 work in progress. 854 [4] Jones, G., "Operational Security Requirements for Large 855 Internet Service Provider (ISP) IP Network Infrastructure", 856 RFC 3871, September 2004. 858 [5] Bradner, S., "Key words for use in RFCs to Indicate 859 Requirement Levels", RFC 2119, March 1997. 861 [6] ITU-T Recommendation G.7712/Y.1703, "Architecture and 862 specification of data communication network", June 2008. 864 [7] Niven-Jenkins, B. et al, "MPLS-TP Requirements", draft- 865 ietf-mpls-tp-requirements, work in progress. 867 [8] Bocci, M. et al, "A Framework for MPLS in Transport 868 Networks", draft-ietf-mpls-tp-framework, work in progress. 870 [9] Mansfield, S. et al, "MPLS-TP Network Management 871 Framework", draft-ietf-mpls-tp-nm-framework, work in 872 progress. 874 12.2. Informative References 876 [10] Beller, D., et al, "An Inband Data Communication Network 877 For the MPLS Transport Profile", draft-ietf-mpls-tp-gach- 878 dcn, work in progress. 880 [11] Chisholm, S. and D. Romascanu, "Alarm Management 881 Information Base (MIB)", RFC 3877, September 2004. 883 [12] ITU-T Recommendation M.20, "Maintenance philosophy for 884 telecommunication networks", October 1992. 886 [13] Telcordia, "Network Maintenance: Network Element and 887 Transport Surveillance Messages" (GR-833-CORE), Issue 5, 888 August 2004. 890 [14] Bocci, M. et al, "MPLS Generic Associated Channel", RFC 891 5586, June 2009. 893 [15] Harrington, D., "Guidelines for Considering Operations and 894 Management of New Protocols and Protocol Extensions", 895 draft-ietf-opsawg-operations-and-management, work in 896 progress. 898 [16] Enns, R. et al, "NETCONF Configuration Protocol", draft- 899 ietf-netconf-4741bis, work in progress. 901 [17] Presuhn, R. et al, "Version 2 of the Protocol Operations 902 for the Simple Network Management Protocol (SNMP)", RFC 903 3416, December 2002. 905 [18] OMG Document formal/04-03-12, "The Common Object Request 906 Broker: Architecture and Specification", Revision 3.0.3. 907 March 12, 2004. 909 [19] Caviglia, D. et al, "Requirements for the Conversion 910 between Permanent Connections and Switched Connections in a 911 Generalized Multiprotocol Label Switching (GMPLS) Network", 912 RFC 5493, April 2009. 914 [20] Caviglia, D. et al, "RSVP-TE Signaling Extension For The 915 Conversion Between Permanent Connections And Soft Permanent 916 Connections In A GMPLS Enabled Transport Network", draft- 917 ietf-ccamp-pc-spc-rsvpte-ext, work in progress. 919 [21] ITU-T Recommendation G.806, "Characteristics of transport 920 equipment - Description methodology and generic 921 functionality", January, 2009. 923 [22] ITU-T Recommendation Y.1731, "OAM functions and mechanisms 924 for Ethernet based networks", February, 2008. 926 [23] ITU-T Recommendation G.8601, "Architecture of service 927 management in multi bearer, multi carrier environment", 928 June 2006. 930 [24] Lam, H., et al, "Alarm Reporting Control Management 931 Information Base (MIB)", RFC 3878, September 2004. 933 [25] ITU-T Recommendation Y.1563, "Ethernet frame transfer and 934 availability performance", January 2009. 936 [26] Handley, M., et al, "Internet Denial-of-Service 937 Considerations", RFC 4732, November 2006. 939 Authors' Addresses 941 Eric Gray 942 Ericsson 943 900 Chelmsford Street 944 Lowell, MA, 01851 945 Phone: +1 978 275 7470 946 Email: Eric.Gray@Ericsson.com 948 Scott Mansfield 949 Ericsson 950 250 Holger Way 951 San Jose CA, 95134 952 +1 724 931 9316 953 EMail: Scott.Mansfield@Ericsson.com 955 Hing-Kam (Kam) Lam 956 Alcatel-Lucent 957 600-700 Mountain Ave 958 Murray Hill, NJ, 07974 959 Phone: +1 908 582 0672 960 Email: hklam@Alcatel-Lucent.com 962 Contributor's Address 964 Adrian Farrel 965 Old Dog Consulting 966 Email: adrian@olddog.co.uk 968 Copyright Statement 970 Copyright (c) 2009 IETF Trust and the persons identified as the 971 document authors. All rights reserved. 973 This document is subject to BCP 78 and the IETF Trust's Legal 974 Provisions Relating to IETF Documents in effect on the date of 975 publication of this document (http://trustee.ietf.org/license- 976 info). Please review these documents carefully, as they describe 977 your rights and restrictions with respect to this document. 979 Acknowledgment 981 Funding for the RFC Editor function is currently provided by the 982 Internet Society. 984 Appendix A- Communication Channel (CCh) Examples 986 A CCh can be realized in a number of ways. 988 1. The CCh can be provided by a link in a physically distinct 989 network. That is, a link that is not part of the transport 990 network that is being managed. For example, the nodes in the 991 transport network can be interconnected in two distinct physical 992 networks: the transport network and the DCN. 994 This is a "physically distinct out-of-band CCh". 996 2. The CCh can be provided by a link in the transport network 997 that is terminated at the ends of the DCC and which is capable of 998 encapsulating and terminating packets of the management 999 protocols. For example, in MPLS-TP a single-hop LSP might be 1000 established between two adjacent nodes, and that LSP might be 1001 capable of carrying IP traffic. Management traffic can then be 1002 inserted into the link in an LSP parallel to the LSPs that carry 1003 user traffic. 1005 This is a "physically shared out-of-band CCh." 1007 3. The CCh can be supported as its native protocol on the 1008 interface alongside the transported traffic. For example, if an 1009 interface is capable of sending and receiving both MPLS-TP and 1010 IP, the IP-based management traffic can be sent as native IP 1011 packets on the interface. 1013 This is a "shared interface out-of-band CCh". 1015 4. The CCh can use overhead bytes available on a transport 1016 connection. For example, in TDM networks there are overhead bytes 1017 associated with a data channel, and these can be used to provide 1018 a CCh. It is important to note that the use of overhead bytes 1019 does not reduce the capacity of the associated data channel. 1021 This is an "overhead-based CCh". 1023 This alternative is not available in MPLS-TP because there is no 1024 overhead available. 1026 5. The CCh can provided by a dedicated channel associated with 1027 the data link. For example, the generic associated label (GAL) 1028 [14] can be used to label DCC traffic being exchanged on a data 1029 link between adjacent transport nodes, potentially in the absence 1030 of any data LSP between those nodes. 1032 This is a "data link associated CCh". 1034 It is very similar to case 2, and by its nature can only span a 1035 single hop in the transport network. 1037 6. The CCh can be provided by a dedicated channel associated with 1038 a data channel. For example, in MPLS-TP the GAL [14] can be 1039 imposed under the top label in the label stack for an MPLS-TP LSP 1040 to create a channel associated with the LSP that can carry 1041 management traffic. This CCh requires the receiver to be capable 1042 of demultiplexing management traffic from user traffic carried on 1043 the same LSP by use of the GAL. 1045 This is a "data channel associated CCh". 1047 7. The CCh can be provided by mixing the management traffic with 1048 the user traffic such that is indistinguishable on the link 1049 without deep-packet inspection. In MPLS-TP this could arise if 1050 there is a data-carrying LSP between two nodes, and management 1051 traffic is inserted into that LSP. This approach requires that 1052 the termination point of the LSP is able to demultiplex the 1053 management and user traffic. Such might be possible in MPLS-TP if 1054 the MPLS-TP LSP was carrying IP user traffic. 1056 This is an "in-band CCh". 1058 These realizations can be categorized as: 1060 A. Out-of-fiber, out-of-band (types 1 and 2) 1061 B. In-fiber, out-of-band (types 2, 3, 4, and 5) 1062 C. In-band (types 6 and 7) 1064 The MCN and SCN are logically separate networks and can be 1065 realized by the same DCN or as separate networks. In practice, 1066 that means that, between any pair of nodes, the MCC and SCC can 1067 be the same link or separate links. 1069 It is also important to note that the MCN and SCN do not need to 1070 be categorised as in-band, out-of-band, etc. This definition only 1071 applies to the individual links, and it is possible for some 1072 nodes to be connected in the MCN or SCN by one type of link, and 1073 other nodes by other types of link. Furthermore, a pair of 1074 adjacent nodes can be connected by multiple links of different 1075 types. 1077 Lastly note that the division of DCN traffic between links 1078 between a pair of adjacent nodes is purely an implementation 1079 choice. Parallel links can be deployed for DCN resilience or load 1080 sharing. Links can be designated for specific use. For example, 1081 so that some links carry management traffic and some carry 1082 control plane traffic, or so that some links carry signaling 1083 protocol traffic while others carry routing protocol traffic. 1085 It is important to note that the DCN can be a routed network with 1086 forwarding capabilities, but that this is not a requirement. The 1087 ability to support forwarding of management or control traffic 1088 within the DCN can substantially simplify the topology of the DCN 1089 and improve its resilience, but does increase the complexity of 1090 operating the DCN. 1092 See also RFC 3877 [11], ITU-T M.20 [12], and Telcordia document 1093 GR-833-CORE [13] for further information.