idnits 2.17.1 draft-ietf-mpls-tp-nm-req-02.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 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 date (June 24, 2009) is 5413 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) -- Looks like a reference, but probably isn't: 'LM' on line 541 -- Looks like a reference, but probably isn't: 'DM' on line 541 == Unused Reference: '16' is defined on line 864, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Downref: Normative reference to an Informational RFC: RFC 4377 (ref. '2') -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Downref: Normative reference to an Informational RFC: RFC 4732 (ref. '4') ** Downref: Normative reference to an Informational RFC: RFC 3871 (ref. '5') -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 7 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: December, 2009 Scott Mansfield 5 Intended Status: Standards Track Eric Gray 6 Ericsson 7 June 24, 2009 9 MPLS TP Network Management Requirements 10 draft-ietf-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 December 24, 2009. 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.........6 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................................10 63 5.3.3. Alarm Reporting..................................11 64 5.3.4. Alarm Reporting Control..........................11 65 6. Configuration Management Requirements......................11 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.....................................13 71 7. Performance Management Requirements........................14 72 7.1. Path Characterization Performance Metrics.............14 73 7.2. Performance Measurement Instrumentation...............15 74 7.2.1. Measurement Frequency............................15 75 7.2.2. Measurement Scope................................16 76 8. Security Management Requirements...........................16 77 8.1. Management Communication Channel Security.............16 78 8.2. Signaling Communication Channel Security..............17 79 8.3. Distributed Denial of Service.........................17 80 9. Security Considerations....................................18 81 10. IANA Considerations.......................................18 82 11. Acknowledgments...........................................18 83 12. References................................................18 84 12.1. Normative References.................................18 85 12.2. Informative References...............................19 86 Author's Addresses............................................21 87 Copyright Statement...........................................21 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 106 in ITU-T G.7710/Y.1701 [1] and RFC 4377 [2], and attempts to 107 comply with best common practice as defined in [18]. 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 130 cover fault, configuration, performance, and security management 131 for MPLS-TP networks, and the requirements for object and 132 information models needed to manage MPLS-TP Networks and Network 133 Elements. 135 In writing this document, the authors assume the reader is 136 familiar with references [19] and [20]. 138 1.1. Terminology 140 Although this document is not a protocol specification, the key 141 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 143 this document are to be interpreted as described in RFC 2119 [6] 144 and are to be interpreted as instructions to protocol designers 145 producing solutions that satisfy the requirements set out in 146 this document. 148 Anomaly: The smallest discrepancy which can be observed between 149 actual and desired characteristics of an item. The occurrence of 150 a single anomaly does not constitute an interruption in ability 151 to perform a required function. Anomalies are used as the input 152 for the Performance Monitoring (PM) process and for detection of 153 defects ([27], 3.7). 155 Communication Channel (CCh): A logical channel between network 156 elements (NEs) that can be used - e.g. - for management or 157 control plane applications. The physical channel supporting the 158 CCh is technology specific. See APPENDIX A: 160 Data Communication Network (DCN): A network that supports Layer 161 1 (physical layer), Layer 2 (data-link layer), and Layer 3 162 (network layer) functionality for distributed management 163 communications related to the management plane, for distributed 164 signaling communications related to the control plane, and other 165 operations communications (e.g., order-wire/voice 166 communications, software downloads, etc.). 168 Defect: The density of anomalies has reached a level where the 169 ability to perform a required function has been interrupted. 170 Defects are used as input for performance monitoring, the 171 control of consequent actions, and the determination of fault 172 cause ([27], 3.24). 174 Failure: The fault cause persisted long enough to consider the 175 ability of an item to perform a required function to be 176 terminated. The item may be considered as failed; a fault has 177 now been detected ([27], 3.25). 179 Fault: A fault is the inability of a function to perform a 180 required action. This does not include an inability due to 181 preventive maintenance, lack of external resources, or planned 182 actions ([27], 3.26). 184 Fault Cause: A single disturbance or fault may lead to the 185 detection of multiple defects. A fault cause is the result of a 186 correlation process which is intended to identify the defect 187 that is representative of the disturbance or fault that is 188 causing the problem ([27], 3.27). 190 Fault Cause Indication (FCI): An indication of a fault cause. 192 Management Communication Channel (MCC): A CCh dedicated for 193 management plane communications. 195 Management Communication Network (MCN): A DCN supporting 196 management plane communication is referred to as a Management 197 Communication Network (MCN). 199 MPLS-TP NE: A network element (NE) that supports the functions 200 of MPLS necessary to participate in an MPLS-TP based transport 201 service. See [24] for further information on functionality 202 required to support MPLS-TP. 204 MPLS-TP network: A network in which MPLS-TP NEs are deployed. 206 OAM, On-Demand and Proactive: One feature of OAM that is largely 207 a management issue is control of OAM; on-demand and proactive 208 are modes of OAM mechanism operation defined - for example - in 209 Y.1731 ([28] - 3.45 and 3.44 respectively) as: 211 - On-demand OAM - OAM actions which are initiated via manual 212 intervention for a limited time to carry out diagnostics. 213 On-demand OAM can result in singular or periodic OAM 214 actions during the diagnostic time interval. 216 - Proactive OAM - OAM actions which are carried on 217 continuously to permit timely reporting of fault and/or 218 performance status. 220 (Note that it is possible for specific OAM mechanisms to only 221 have a sensible use in either on-demand or proactive mode.) 223 Operations System (OS): A system that performs the functions 224 that support processing of information related to operations, 225 administration, maintenance, and provisioning (OAM&P) for the 226 networks, including surveillance and testing functions to 227 support customer access maintenance. 229 Signaling Communication Channel (SCC): A CCh dedicated for 230 control plane communications. The SCC may be used for GMPLS/ASON 231 signaling and/or other control plane messages (e.g., routing 232 messages). 234 Signaling Communication Network (SCN): A DCN supporting control 235 plane communication is referred to as a Signaling Communication 236 Network (SCN). 238 2. Management Interface Requirements 240 This document does not specify which management interface 241 protocol should be used as the standard protocol for managing 242 MPLS-TP networks. Managing an end-to-end connection across 243 multiple operator domains where one domain is managed (for 244 example) via NETCONF/XML ([21]) or SNMP/SMI ([22]), and another 245 domain via CORBA/IDL ([23]), is allowed. 247 For the management interface to the management system, an MPLS- 248 TP NE MAY actively support more than one management protocol in 249 any given deployment. For example, an MPLS-TP NE may use one 250 protocol for configuration and another for monitoring. The 251 protocols to be supported are at the discretion of the operator. 253 3. Management Communication Channel (MCC) Requirements 255 Specifications SHOULD define support for management connectivity 256 with remote MPLS-TP domains and NEs, as well as with termination 257 points located in NEs under the control of a third party network 258 operator. See ITU-T G.8601 [8] for example scenarios in multi- 259 carrier multi-transport-technology environments. 261 For management purpose, every MPLS-TP NE MUST connect to an OS. 262 The connection MAY be direct (e.g. - via a software, hardware or 263 proprietary protocol connection) or indirect (via another MPLS- 264 TP NE). In this document, any management connection that is not 265 via another MPLS-TP NE is a direct management connection. When 266 an MPLS-TP NE is connected indirectly to an OS, an MCC MUST be 267 supported between that MPLS-TP NE and any MPLS-TP NE(s) used to 268 provide the connection to an OS. 270 4. Management Communication Network (MCN) Requirements 272 Entities of the MPLS-TP management plane communicate via a DCN, 273 or more specifically via the MCN. The MCN connects management 274 systems with management systems, management systems with MPLS-TP 275 NEs, and (in the indirect connectivity case discussed in section 276 3) MPLS-TP NEs with MPLS-TP NEs. 278 RFC 5586 ([10]) defines a Generic Associated Channel (G-ACh) to 279 enable the realization of a communication channel (CCh) between 280 adjacent MPLS-TP NEs for management and control. Reference [11] 281 describes how the G-ACh may be used to provide infrastructure 282 that forms part of the MCN and a SCN. It also explains how MCN 283 and SCN messages are encapsulated, carried on the G-ACh, and 284 demultiplexed for delivery to management or signaling/routing 285 control plane components on a label switching router (LSR). 287 ITU-T G.7712/Y.1703 [7], section 7, describes the transport DCN 288 architecture and requirements. The MPLS-TP MCN MUST support the 289 requirements (in reference [7]) for: 291 - CCh access functions specified in section 7.1.1; 293 - MPLS-TP SCC data-link layer termination functions specified 294 in section 7.1.2.3; 296 - MPLS-TP MCC data-link layer termination functions specified 297 in section 7.1.2.4; 299 - Network layer PDU into CCh data-link frame encapsulation 300 functions specified in section 7.1.3; 302 - Network layer PDU forwarding (7.1.6), interworking (7.1.7) 303 and encapsulation (7.1.8) functions, as well as tunneling 304 (7.1.9) and routing (7.1.10) functions specified in [7]. 306 As a practical matter, MCN connections will typically have 307 addresses. See the section on addressing in [15] for further 308 information. 310 In order to have the MCN operate properly, a number of 311 management functions for the MCN are needed, including: 313 - Retrieval of DCN network parameters to ensure compatible 314 functioning, e.g. packet size, timeouts, quality of 315 service, window size, etc.; 317 - Establishment of message routing between DCN nodes; 319 - Management of DCN network addresses; 321 - Retrieval of operational status of the DCN at a given node; 322 - Capability to enable/disable access by an NE to the DCN. 323 Note that this is to allow isolating a malfunctioning NE 324 from impacting the rest of the network. 326 5. Fault Management Requirements 328 The Fault Management functions within an MPLS-TP NE enable the 329 supervision, detection, validation, isolation, correction, and 330 reporting of abnormal operation of the MPLS-TP network and its 331 environment. 333 5.1. Supervision Function 335 The supervision function analyses the actual occurrence of a 336 disturbance or fault for the purpose of providing an appropriate 337 indication of performance and/or detected fault condition to 338 maintenance personnel and operations systems. 340 The MPLS-TP NE MUST support supervision of the OAM mechanisms 341 that are deployed for supporting the OAM requirements defined in 342 [3]. 344 The MPLS-TP NE MUST support the following data-plane forwarding 345 path supervision functions: 347 - Supervision of loop-checking functions used to detect loops 348 in the data-plane forwarding path (which result in non- 349 delivery of traffic, wasting of forwarding resources and 350 unintended self-replication of traffic); 352 - Supervision of failure detection; 354 The MPLS-TP NE MUST support the capability to configure data- 355 plane forwarding path related supervision mechanisms to perform 356 on-demand or proactively. 358 The MPLS-TP NE MUST support supervision for software processing 359 e.g., processing faults, storage capacity, version mismatch, 360 corrupted data and out of memory problems, etc. 362 The MPLS-TP NE MUST support hardware-related supervision for 363 interchangeable and non-interchangeable unit, cable, and power 364 problems. 366 The MPLS-TP NE SHOULD support environment-related supervision 367 for temperature, humidity, etc. 369 5.2. Validation Function 371 Validation is the process of integrating Fault Cause indications 372 into Failures. A Fault Cause Indication (FCI) indicates a 373 limited interruption of the required transport function. A Fault 374 Cause is not reported to maintenance personnel because it might 375 exist only for a very short time. Note that some of these events 376 are summed up in the Performance Monitoring process (see section 377 7), and when this sum exceeds a configured value, a threshold 378 crossing alert (report) can be generated. 380 When the Fault Cause lasts long enough, an inability to perform 381 the required transport function arises. This failure condition 382 is subject to reporting to maintenance personnel and/or an OS 383 because corrective action might be required. Conversely, when 384 the Fault Cause ceases after a certain time, clearing of the 385 Failure condition is also subject to reporting. 387 The MPLS-TP NE MUST perform persistency checks on fault causes 388 before it declares a fault cause a failure. 390 The MPLS-TP NE SHOULD provide a configuration capability for 391 control parameters associated with performing the persistency 392 checks described above. 394 An MPLS-TP NE MAY provide configuration parameters to control 395 reporting, and clearing, of failure conditions. 397 A data-plane forwarding path failure MUST be declared if the 398 fault cause persists continuously for a configurable time (Time- 399 D). The failure MUST be cleared if the fault cause is absent 400 continuously for a configurable time (Time-C). 402 Note: As an example, the default time values might be as 403 follows: 405 Time-D = 2.5 +/- 0.5 seconds 407 Time-C = 10 +/- 0.5 seconds 409 These time values are as defined in G.7710 [1]. 411 MIBs - or other object management semantics specifications - 412 defined to enable configuration of these timers SHOULD 413 explicitly provide default values and MAY provide guidelines on 414 ranges and value determination methods for scenarios where the 415 default value chosen might be inadequate. In addition, such 416 specifications SHOULD define the level of granularity at which 417 tables of these values are to be defined. Examples of levels of 418 granularity MAY include per-failure-cause and per-deduced-fault. 420 Implementations MUST provide the ability to configure the 421 preceding set of timers, and SHOULD provide default values to 422 enable rapid configuration. Suitable default values, timer 423 ranges, and level of granularity are out of scope in this 424 document and form part of the specification of fault management 425 details. Timers SHOULD be configurable per NE for broad 426 categories of failure causes and deduced faults, and MAY be 427 configurable per-interface on an NE or per individual failure 428 cause or deduced fault. 430 The failure declaration and clearing MUST be time stamped. The 431 time-stamp MUST indicate the time at which the fault cause is 432 activated at the input of the fault cause persistency (i.e. 433 defect-to-failure integration) function, and the time at which 434 the fault cause is deactivated at the input of the fault cause 435 persistency function. 437 5.3. Alarm Handling Function 439 5.3.1. Alarm Severity Assignment 441 Failures can be categorized to indicate the severity or urgency 442 of the fault. 444 An MPLS-TP NE SHOULD support the ability to assign severity 445 (e.g., Critical, Major, Minor, Warning) to alarm conditions via 446 configuration. 448 See G.7710 [1], section 7.2.2 for more detail on alarm severity 449 assignment. 451 5.3.2. Alarm Suppression 453 Alarms can be generated from many sources, including OAM, device 454 status, etc. 456 An MPLS-TP NE MUST support suppression of alarms based on 457 configuration. 459 5.3.3. Alarm Reporting 461 Alarm Reporting is concerned with the reporting of relevant 462 events and conditions, which occur in the network (including the 463 NE, incoming signal, and external environment). 465 Local reporting is concerned with automatic alarming by means of 466 audible and visual indicators near the failed equipment. 468 An MPLS-TP NE MUST support local reporting of alarms. 470 The MPLS-TP NE MUST support reporting of alarms to an OS. These 471 reports are either autonomous reports (notifications) or reports 472 on request by maintenance personnel. The MPLS-TP NE SHOULD 473 report local (environmental) alarms to a network management 474 system. 476 An MPLS-TP NE supporting one or more other networking 477 technologies (e.g. - Ethernet, SDH/SONET, MPLS) over MPLS-TP 478 MUST be capable of translating an MPLS-TP defects into failure 479 conditions that are meaningful to the client layer, as described 480 in RFC 4377 [2], section 4.7. 482 5.3.4. Alarm Reporting Control 484 Alarm Reporting Control (ARC) supports an automatic in-service 485 provisioning capability. Alarm reporting can be turned off on a 486 per-managed entity (e.g., LSP) basis to allow sufficient time 487 for customer service testing and other maintenance activities in 488 an "alarm free" state. Once a managed entity is ready, alarm 489 reporting is automatically turned on. 491 An MPLS-TP NE SHOULD support the Alarm Reporting Control 492 function for controlling the reporting of alarm conditions. 494 See G.7710 [1] (section 7.1.3.2) and RFC 3878 [9] for more 495 information about ARC. 497 6.Configuration Management Requirements 499 Configuration Management provides functions to identify, collect 500 data from, provide data to and control NEs. Specific 501 configuration tasks requiring network management support include 502 hardware and software configuration, configuration of NEs to 503 support transport paths (including required working and 504 protection paths), and configuration of required path 505 integrity/connectivity and performance monitoring (i.e. - OAM). 507 6.1. System Configuration 509 The MPLS-TP NE MUST support the configuration requirements 510 specified in G.7710 [1] section 8.1 for hardware. 512 The MPLS-TP NE MUST support the configuration requirements 513 specified in G.7710 [1] section 8.2 for software. 515 The MPLS-TP NE MUST support the configuration requirements 516 specified in G.7710 [1] section 8.13.2.1 for local real time 517 clock functions. 519 The MPLS-TP NE MUST support the configuration requirements 520 specified in G.7710 [1] section 8.13.2.2 for local real time 521 clock alignment with external time reference. 523 The MPLS-TP NE MUST support the configuration requirements 524 specified in G.7710 [1] section 8.13.2.3 for performance 525 monitoring of the clock function. 527 6.2. Control Plane Configuration 529 If a control plane is supported in an implementation of MPLS-TP, 530 the MPLS-TP NE MUST support the configuration of MPLS-TP control 531 plane functions by the management plane. Further detailed 532 requirements will be provided along with progress in defining 533 the MPLS-TP control plane in appropriate specifications. 535 6.3. Path Configuration 537 In addition to the requirement to support static provisioning of 538 transport paths (defined in [24], section 2.1 - General 539 Requirements - requirement 18), an MPLS-TP NE MUST support the 540 configuration of required path performance characteristic 541 thresholds (e.g. - Loss Measurement [LM], Delay Measurement [DM] 542 thresholds) necessary to support performance monitoring of the 543 MPLS-TP service(s). 545 In order to accomplish this, an MPLS-TP NE MUST support 546 configuration of LSP information (such as an LSP identifier of 547 some kind) and/or any other information needed to retrieve LSP 548 status information, performance attributes, etc. 550 If a control plane is supported, and that control plane includes 551 support for control-plane/management-plane hand-off for LSP 552 setup/maintenance, the MPLS-TP NE MUST support management of the 553 hand-off of Path control. See, for example, references [25] and 554 [26]. 556 Further detailed requirements will be provided along with 557 progress in defining the MPLS-TP control plane in appropriate 558 specifications. 560 If MPLS-TP transport paths cannot be statically provisioned 561 using MPLS LSP and pseudo-wire management tools (either already 562 defined in standards or under development), further management 563 specifications MUST be provided as needed. 565 6.4. Protection Configuration 567 The MPLS-TP NE MUST support configuration of required path 568 protection information as follows: 570 - designate specifically identified LSPs as working or 571 protection LSPs; 573 - define associations of working and protection paths; 575 - operate/release manual protection switching; 577 - operate/release force protection switching; 579 - operate/release protection lockout; 581 - set/retrieve Automatic Protection Switching (APS) 582 parameters, including - 584 o Wait to Restore time, 586 o Protection Switching threshold information. 588 6.5. OAM Configuration 590 The MPLS-TP NE MUST support configuration of the OAM entities 591 and functions specified in [3]. 593 The MPLS-TP NE MUST support the capability to choose which OAM 594 functions to use and which maintenance entity will apply them. 596 The MPLS-TP NE MUST support the capability to configure the OAM 597 entities/functions as part of LSP setup and tear-down, including 598 co-routed bidirectional point-to-point, associated bidirectional 599 point-to-point, and uni-directional (both point-to-point and 600 point-to-multipoint) connections. 602 The MPLS-TP NE MUST support the configuration of maintenance 603 entity identifiers (e.g. MEP ID and MIP ID) for the purpose of 604 LSP connectivity checking. 606 The MPLS-TP NE MUST support configuration of OAM parameters to 607 meet their specific operational requirements, such as whether - 609 1) one-time on-demand immediately or 611 2) one-time on-demand pre-scheduled or 613 3) on-demand periodically based on a specified schedule or 615 4) proactive on-going. 617 The MPLS-TP NE MUST support the enabling/disabling of the 618 connectivity check processing. The connectivity check process of 619 the MPLS-TP NE MUST support provisioning of the identifiers to 620 be transmitted and the expected identifiers. 622 7. Performance Management Requirements 624 Performance Management provides functions for the purpose of 625 Maintenance, Bring-into-service, Quality of service, and 626 statistics gathering. 628 This information could be used, for example, to compare behavior 629 of the equipment, MPLS-TP NE or network at different moments in 630 time to evaluate changes in network performance. 632 ITU-T Recommendation G.7710 [1] provides transport performance 633 monitoring requirements for packet-switched and circuit-switched 634 transport networks with the objective of providing coherent and 635 consistent interpretation of the network behavior in a multi- 636 technology environment. The performance management requirements 637 specified in this document are driven by such an objective. 639 7.1. Path Characterization Performance Metrics 641 It MUST be possible to determine when an MPLS-TP based transport 642 service is available and when it is unavailable. 644 From a performance perspective, a service is unavailable if 645 there is an indication that performance has degraded to the 646 extent that a configurable performance threshold has been 647 crossed and the degradation persists long enough (i.e. - the 648 indication persists for some amount of time - which is either 649 configurable, or well-known) to be certain it is not a 650 measurement anomaly. 652 Methods, mechanisms and algorithms for exactly how 653 unavailability is to be determined - based on collection of raw 654 performance data - are out of scope for this document. 656 For the purposes of this document, it is sufficient to state 657 that an MPLS-TP NE MUST support collection, and reporting, of 658 raw performance data that MAY be used in determining 659 availability of a transport service, and that implementations 660 SHOULD support some as yet to be defined mechanism for 661 determining service availability. 663 The MPLS-TP NE MUST support collection of loss measurement (LM) 664 statistics. 666 The MPLS-TP NE MUST support collection of delay measurement (DM) 667 statistics. 669 The MPLS-TP NE MUST support reporting of Performance degradation 670 via fault management for corrective actions. "Reporting" in this 671 context could mean: 673 - reporting to an autonomous protection component to trigger 674 protection switching, 676 - reporting via a craft interface to allow replacement of a 677 faulty component (or similar manual intervention), 679 - etc. 681 The MPLS-TP NE MUST support reporting of performance statistics 682 on request from a management system. 684 7.2. Performance Measurement Instrumentation 686 7.2.1. Measurement Frequency 688 For performance measurement mechanisms that support both 689 proactive and on-demand modes, the MPLS-TP NE MUST support the 690 capability to be configured to operate on-demand or proactively. 692 7.2.2. Measurement Scope 694 On measurement of packet loss and loss ratio: 696 - For bidirectional (both co-routed and associated) P2P 697 connections - 699 o on-demand measurement of single-ended packet loss, and 700 loss ratio, measurement is REQUIRED; 702 o proactive measurement of packet loss, and loss ratio, 703 measurement for each direction is REQUIRED. 705 - for unidirectional (P2P and P2MP) connection, proactive 706 measurement of packet loss, and loss ratio, is REQUIRED. 708 On Delay measurement: 710 - for unidirectional (P2P and P2MP) connection, on-demand 711 measurement of delay measurement is REQUIRED. 713 - for co-routed bidirectional (P2P) connection, on-demand 714 measurement of one-way and two-way delay is REQUIRED. 716 - for associated bidirectional (P2P) connection, on-demand 717 measurement of one-way delay is REQUIRED. 719 8. Security Management Requirements 721 The MPLS-TP NE MUST support secure management and control 722 planes. 724 8.1. Management Communication Channel Security 726 Secure communication channels MUST be supported for all network 727 traffic and protocols used to support management functions. 728 This MUST include, at least, protocols used for configuration, 729 monitoring, configuration backup, logging, time synchronization, 730 authentication, and routing. The MCC MUST support application 731 protocols that provide confidentiality and data integrity 732 protection. 734 The MPLS-TP NE MUST support the following: 736 - Use of open cryptographic algorithms (See RFC 3871 [5]) 737 - Authentication - allow management connectivity only from 738 authenticated entities. 740 - Authorization - allow management activity originated by an 741 authorized entity, using (for example) an Access Control 742 List (ACL). 744 - Port Access Control - allow management activity received on 745 an authorized (management) port. 747 8.2.Signaling Communication Channel Security 749 Security requirements for the SCC are driven by considerations 750 similar to MCC requirements described in section 8.1. 752 Security Requirements for the control plane are out of scope for 753 this document and are expected to be defined in the appropriate 754 control plane specifications. 756 Management of control plane security MUST also be defined at 757 that time. 759 8.3. Distributed Denial of Service 761 A Denial of Service (DoS) attack is an attack that tries to 762 prevent a target from performing an assigned task, or providing 763 its intended service(s), through any means. A Distributed DoS 764 (DDoS) can multiply attack severity (possibly by an arbitrary 765 amount) by using multiple (potentially compromised) systems to 766 act as topologically (and potentially geographically) 767 distributed attack sources. It is possible to lessen the impact 768 and potential for DoS and DDoS by using secure protocols, 769 turning off unnecessary processes, logging and monitoring, and 770 ingress filtering. RFC 4732 [4] provides background on DOS in 771 the context of the Internet. 773 An MPLS-TP NE MUST support secure management protocols and 774 SHOULD do so in a manner the reduce potential impact of a DoS 775 attack. 777 An MPLS-TP NE SHOULD support additional mechanisms that mitigate 778 a DoS (or DDoS) attack against the management component while 779 allowing the NE to continue to meet its primary functions. 781 9. Security Considerations 783 Section 8 includes a set of security requirements that apply to 784 MPLS-TP network management. 786 Solutions MUST provide mechanisms to prevent unauthorized and/or 787 unauthenticated access to management capabilities and private 788 information by network elements, systems or users. 790 Performance of diagnostic functions and path characterization 791 involves extracting a significant amount of information about 792 network construction that the network operator might consider 793 private. 795 10. IANA Considerations 797 There are no IANA actions associated with this document. 799 11. Acknowledgments 801 The authors/editors gratefully acknowledge the thoughtful 802 review, comments and explanations provided by Adrian Farrel, 803 Alexander Vainshtein, Andrea Maria Mazzini, Ben Niven-Jenkins, 804 Bernd Zeuner, Dan Romascanu, Daniele Ceccarelli, Diego Caviglia, 805 Dieter Beller, He Jia, Leo Xiao, Maarten Vissers, Neil Harrison, 806 Rolf Winter, Yoav Cohen and Yu Liang. 808 12. References 810 12.1. Normative References 812 [1] ITU-T Recommendation G.7710/Y.1701, "Common equipment 813 management function requirements", July, 2007. 815 [2] Nadeau, T., et al, "Operations and Management (OAM) 816 Requirements for Multi-Protocol Label Switched (MPLS) 817 Networks", RFC 4377, February 2006. 819 [3] Vigoureux, M., et al, "Requirements for OAM in MPLS 820 Transport Networks", work in progress. 822 [4] Handley, M., et al, "Internet Denial-of-Service 823 Considerations", RFC 4732, November 2006. 825 [5] Jones, G., "Operational Security Requirements for Large 826 Internet Service Provider (ISP) IP Network 827 Infrastructure", RFC 3871, September 2004. 829 [6] Bradner, S., "Key words for use in RFCs to Indicate 830 Requirement Levels", RFC 2119, March 1997. 832 [7] ITU-T Recommendation G.7712/Y.1703, "Architecture and 833 Specification of Data Communication Network", June 2008. 835 [8] ITU-T Recommendation G.8601, "Architecture of service 836 management in multi bearer, multi carrier environment", 837 June 2006. 839 [9] Lam, H., et al, "Alarm Reporting Control Management 840 Information Base (MIB)", RFC 3878, September 2004. 842 [10] Bocci, M., et al, "MPLS Generic Associated Channel", RFC 843 5586, June 2009. 845 [11] Beller, D., et al, "An Inband Data Communication Network 846 For the MPLS Transport Profile", draft-ietf-mpls-tp-gach- 847 dcn, work in progress. 849 12.2. Informative References 851 [12] Chisholm, S. and D. Romascanu, "Alarm Management 852 Information Base (MIB)", RFC 3877, September 2004. 854 [13] ITU-T Recommendation M.20, "Maintenance Philosophy for 855 Telecommunication Networks", October 1992. 857 [14] Telcordia, "Network Maintenance: Network Element and 858 Transport Surveillance Messages" (GR-833-CORE), Issue 5, 859 August 2004. 861 [15] Bocci, M. et al, "A Framework for MPLS in Transport 862 Networks", Work in Progress, November 27, 2008. 864 [16] ANSI T1.231-2003, "Layer 1 In-Service Transmission 865 Performance Monitoring", American National Standards 866 Institute, 2003. 868 [17] Vigoureux, M. et al, "MPLS Generic Associated Channel", 869 draft-ietf-mpls-tp-gach-gal, work in progress. 871 [18] Harrington, D., "Guidelines for Considering Operations and 872 Management of New Protocols and Protocol Extensions", 873 draft-ietf-opsawg-operations-and-management, work in 874 progress. 876 [19] Mansfield, S. et al, "MPLS-TP Network Management 877 Framework", draft-ietf-mpls-tp-nm-framework, work in 878 progress. 880 [20] Bocci, M. et al, "A Framework for MPLS in Transport 881 Networks", draft-ietf-mpls-tp-framework, work in progress. 883 [21] Enns, R. et al, "NETCONF Configuration Protocol", draft- 884 ietf-netconf-4741bis, work in progress. 886 [22] McCloghrie, K. et al, "Structure of Management Information 887 Version 2 (SMIv2)", RFC 2578, April 1999. 889 [23] OMG Document formal/04-03-12, "The Common Object Request 890 Broker: Architecture and Specification", Revision 3.0.3. 891 March 12, 2004. 893 [24] Niven-Jenkins, B. et al, "MPLS-TP Requirements", draft- 894 ietf-mpls-tp-requirements, work in progress. 896 [25] Caviglia, D. et al, "Requirements for the Conversion 897 between Permanent Connections and Switched Connections in 898 a Generalized Multiprotocol Label Switching (GMPLS) 899 Network", RFC 5493, April 2009. 901 [26] Caviglia, D. et al, "RSVP-TE Signaling Extension For The 902 Conversion Between Permanent Connections And Soft 903 Permanent Connections In A GMPLS Enabled Transport 904 Network", draft-ietf-ccamp-pc-spc-rsvpte-ext, work in 905 progress. 907 [27] ITU-T Recommendation G.806, "Characteristics of transport 908 equipment - Description methodology and generic 909 functionality", January, 2009. 911 [28] ITU-T Recommendation Y.1731, "OAM Functions and Mechanisms 912 for Ethernet Based Networks", February, 2008. 914 Author's Addresses 916 Editors: 918 Eric Gray 919 Ericsson 920 900 Chelmsford Street 921 Lowell, MA, 01851 922 Phone: +1 978 275 7470 923 Email: Eric.Gray@Ericsson.com 925 Scott Mansfield 926 Ericsson 927 250 Holger Way 928 San Jose CA, 95134 929 +1 724 931 9316 930 EMail: Scott.Mansfield@Ericsson.com 932 Hing-Kam (Kam) Lam 933 Alcatel-Lucent 934 600-700 Mountain Ave 935 Murray Hill, NJ, 07974 936 Phone: +1 908 582 0672 937 Email: hklam@Alcatel-Lucent.com 939 Author(s): 941 Contributor(s): 943 Adrian Farrel 944 Old Dog Consulting 945 Email: adrian@olddog.co.uk 947 Copyright Statement 949 Copyright (c) 2009 IETF Trust and the persons identified as the 950 document authors. All rights reserved. 952 This document is subject to BCP 78 and the IETF Trust's Legal 953 Provisions Relating to IETF Documents in effect on the date of 954 publication of this document (http://trustee.ietf.org/license- 955 info). Please review these documents carefully, as they 956 describe your rights and restrictions with respect to this 957 document. 959 Acknowledgment 961 Funding for the RFC Editor function is currently provided by the 962 Internet Society. 964 APPENDIX A: Communication Channel (CCh) Examples 966 A CCh may be realized in a number of ways. 968 1. The CCh may be provided by a link in a physically distinct 969 network. That is, a link that is not part of the transport 970 network that is being managed. For example, the nodes in the 971 transport network may be interconnected in two distinct physical 972 networks: the transport network and the DCN. 974 This is a "physically distinct out-of-band CCh". 976 2. The CCh may be provided by a link in the transport network 977 that is terminated at the ends of the DCC and which is capable 978 of encapsulating and terminating packets of the management 979 protocols. For example, in MPLS-TP an single-hop LSP might be 980 established between two adjacent nodes, and that LSP might be 981 capable of carrying IP traffic. Management traffic can then be 982 inserted into the link in an LSP parallel to the LSPs that carry 983 user traffic. 985 This is a "physically shared out-of-band CCh." 987 3. The CCh may be supported as its native protocol on the 988 interface alongside the transported traffic. For example, if an 989 interface is capable of sending and receiving both MPLS-TP and 990 IP, the IP-based management traffic can be sent as native IP 991 packets on the interface. 993 This is a "shared interface out-of-band CCh". 995 4. The CCh may use overhead bytes available on a transport 996 connection. For example, in TDM networks there are overhead 997 bytes associated with a data channel, and these can be used to 998 provide a CCh. It is important to note that the use of overhead 999 bytes does not reduce the capacity of the associated data 1000 channel. 1002 This is an "overhead-based CCh". 1004 This alternative is not available in MPLS-TP because there is no 1005 overhead available. 1007 5. The CCh may provided by a dedicated channel associated with 1008 the data link. For example, the generic associated label (GAL) 1009 [17] may be used to label DCC traffic being exchanged on a data 1010 link between adjacent transport nodes, potentially in the 1011 absence of any data LSP between those nodes. 1013 This is a "data link associated CCh". 1015 It is very similar to case 2, and by its nature can only span a 1016 single hop in the transport network. 1018 6. The CCh may be provided by a dedicated channel associated 1019 with a data channel. For example, in MPLS-TP the GAL [17] may be 1020 imposed under the top label in the label stack for an MPLS-TP 1021 LSP to create a channel associated with the LSP that may carry 1022 management traffic. This CCh requires the receiver to be capable 1023 of demultiplexing management traffic from user traffic carried 1024 on the same LSP by use of the GAL. 1026 This is a "data channel associated CCh". 1028 7. The CCh may be provided by mixing the management traffic with 1029 the user traffic such that is indistinguishable on the link 1030 without deep-packet inspection. In MPLS-TP this could arise if 1031 there is a data-carrying LSP between two nodes, and management 1032 traffic is inserted into that LSP. This approach requires that 1033 the termination point of the LSP is able to demultiplex the 1034 management and user traffic. Such might be possible in MPLS-TP 1035 if the MPLS-TP LSP was carrying IP user traffic. 1037 This is an "in-band CCh". 1039 These realizations may be categorized as: 1041 A. Out-of-fiber, out-of-band (types 1 and 2) 1042 B. In-fiber, out-of-band (types 2, 3, 4, and 5) 1043 C. In-band (types 6 and 7) 1045 The MCN and SCN are logically separate networks and may be 1046 realized by the same DCN or as separate networks. In practice, 1047 that means that, between any pair of nodes, the MCC and SCC may 1048 be the same link or separate links. 1050 It is also important to note that the MCN and SCN do not need to 1051 be categorised as in-band, out-of-band, etc. This definition 1052 only applies to the individual links, and it is possible for 1053 some nodes to be connected in the MCN or SCN by one type of 1054 link, and other nodes by other types of link. Furthermore, a 1055 pair of adjacent nodes may be connected by multiple links of 1056 different types. 1058 Lastly note that the division of DCN traffic between links 1059 between a pair of adjacent nodes is purely an implementation 1060 choice. Parallel links may be deployed for DCN resilience or 1061 load sharing. Links may be designated for specific use. For 1062 example, so that some links carry management traffic and some 1063 carry control plane traffic, or so that some links carry 1064 signaling protocol traffic while others carry routing protocol 1065 traffic. 1067 It should be noted that the DCN may be a routed network with 1068 forwarding capabilities, but that this is not a requirement. The 1069 ability to support forwarding of management or control traffic 1070 within the DCN may substantially simplify the topology of the 1071 DCN and improve its resilience, but does increase the complexity 1072 of operating the DCN. 1074 See also RFC 3877 [12], ITU-T M.20 [13], and Telcordia document 1075 GR-833-CORE [14] for further information.