idnits 2.17.1 draft-ietf-mpls-tp-nm-req-03.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 (August 31, 2009) is 5345 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 -- 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 3871 (ref. '4') -- Possible downref: Non-RFC (?) normative reference: ref. '6' Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 6 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 August 31, 2009 9 MPLS TP Network Management Requirements 10 draft-ietf-mpls-tp-nm-req-03.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 March 31, 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.......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............................10 64 5.3.4. Alarm Reporting Control.....................11 65 6. Configuration Management Requirements..................11 66 6.1. System Configuration............................11 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............16 74 7.2.1. Measurement Frequency.......................16 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 [14]. 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 [12] and [15]. 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 [5] 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 (from [21], 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 (from [21], 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 (from [21], 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 (from [21], 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 (from [21], 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 [8] 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 ([22] - 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 ([16]) or SNMP/SMI ([17]), and another 245 domain via CORBA/IDL ([18]), 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 [23] 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 (Error! Reference source not found.) defines a Generic 279 Associated Channel (G-ACh) to enable the realization of a 280 communication channel (CCh) between adjacent MPLS-TP NEs for 281 management and control. Reference [7] describes how the G-ACh 282 may be used to provide infrastructure that forms part of the MCN 283 and SCN. It also explains how MCN and SCN messages are 284 encapsulated, carried on the G-ACh, and decapsulated for 285 delivery to management or signaling/routing control plane 286 components on a label switching router (LSR). 288 ITU-T G.7712/Y.1703 [6], section 7, describes the transport DCN 289 architecture and requirements. The MPLS-TP MCN MUST support the 290 requirements (in reference [6]) for: 292 - CCh access functions specified in section 7.1.1; 294 - MPLS-TP SCC data-link layer termination functions specified 295 in section 7.1.2.3; 297 - MPLS-TP MCC data-link layer termination functions specified 298 in section 7.1.2.4; 300 - Network layer PDU into CCh data-link frame encapsulation 301 functions specified in section 7.1.3; 303 - Network layer PDU forwarding (7.1.6), interworking (7.1.7) 304 and encapsulation (7.1.8) functions, as well as tunneling 305 (7.1.9) and routing (7.1.10) functions specified in [6]. 307 As a practical matter, MCN connections will typically have 308 addresses. See the section on addressing in [15] for further 309 information. 311 In order to have the MCN operate properly, a number of 312 management functions for the MCN are needed, including: 314 . Retrieval of DCN network parameters to ensure compatible 315 functioning, e.g. packet size, timeouts, quality of 316 service, window size, etc.; 318 . Establishment of message routing between DCN nodes; 320 . Management of DCN network addresses; 321 . Retrieval of operational status of the DCN at a given node; 323 . Capability to enable/disable access by an NE to the DCN. 324 Note that this is to allow isolating a malfunctioning NE 325 from impacting the rest of the network. 327 5. Fault Management Requirements 329 The Fault Management functions within an MPLS-TP NE enable the 330 supervision, detection, validation, isolation, correction, and 331 reporting of abnormal operation of the MPLS-TP network and its 332 environment. 334 5.1. Supervision Function 336 The supervision function analyses the actual occurrence of a 337 disturbance or fault for the purpose of providing an appropriate 338 indication of performance and/or detected fault condition to 339 maintenance personnel and operations systems. 341 The MPLS-TP NE MUST support supervision of the OAM mechanisms 342 that are deployed for supporting the OAM requirements defined in 343 [1]. 345 The MPLS-TP NE MUST support the following data-plane forwarding 346 path supervision functions: 348 . Supervision of loop-checking functions used to detect loops 349 in the data-plane forwarding path (which result in non- 350 delivery of traffic, wasting of forwarding resources and 351 unintended self-replication of traffic); 353 . Supervision of failure detection; 355 The MPLS-TP NE MUST support the capability to configure data- 356 plane forwarding path related supervision mechanisms to perform 357 on-demand or proactively. 359 The MPLS-TP NE MUST support supervision for software processing 360 e.g., processing faults, storage capacity, version mismatch, 361 corrupted data and out of memory problems, etc. 363 The MPLS-TP NE MUST support hardware-related supervision for 364 interchangeable and non-interchangeable unit, cable, and power 365 problems. 367 The MPLS-TP NE SHOULD support environment-related supervision 368 for temperature, humidity, etc. 370 5.2. Validation Function 372 Validation is the process of integrating Fault Cause indications 373 into Failures. A Fault Cause Indication (FCI) indicates a 374 limited interruption of the required transport function. A Fault 375 Cause is not reported to maintenance personnel because it might 376 exist only for a very short time. Note that some of these events 377 are summed up in the Performance Monitoring process (see section 378 7), and when this sum exceeds a configured value, a threshold 379 crossing alert (report) can be generated. 381 When the Fault Cause lasts long enough, an inability to perform 382 the required transport function arises. This failure condition 383 is subject to reporting to maintenance personnel and/or an OS 384 because corrective action might be required. Conversely, when 385 the Fault Cause ceases after a certain time, clearing of the 386 Failure condition is also subject to reporting. 388 The MPLS-TP NE MUST perform persistency checks on fault causes 389 before it declares a fault cause a failure. 391 The MPLS-TP NE SHOULD provide a configuration capability for 392 control parameters associated with performing the persistency 393 checks described above. 395 An MPLS-TP NE MAY provide configuration parameters to control 396 reporting, and clearing, of failure conditions. 398 A data-plane forwarding path failure MUST be declared if the 399 fault cause persists continuously for a configurable time (Time- 400 D). The failure MUST be cleared if the fault cause is absent 401 continuously for a configurable time (Time-C). 403 Note: As an example, the default time values might be as 404 follows: 406 Time-D = 2.5 +/- 0.5 seconds 408 Time-C = 10 +/- 0.5 seconds 410 These time values are as defined in G.7710 [1]. 412 MIBs - or other object management semantics specifications - 413 defined to enable configuration of these timers SHOULD 414 explicitly provide default values and MAY provide guidelines on 415 ranges and value determination methods for scenarios where the 416 default value chosen might be inadequate. In addition, such 417 specifications SHOULD define the level of granularity at which 418 tables of these values are to be defined. 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 (for example, defects and/or fault causes), and MAY 427 be configurable per-interface on an NE and/or per individual 428 defect/fault cause. 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 [24] 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 [8], 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 [19] and 554 [20]. 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 protecting LSPs; 573 . define associations of working and protecting 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 are enabled. 596 For enabled OAM functions, the MPLS-TP NE MUST support the 597 ability to associate OAM functions with specific maintenance 598 entities. 600 The MPLS-TP NE MUST support the capability to configure the OAM 601 entities/functions as part of LSP setup and tear-down, including 602 co-routed bidirectional point-to-point, associated bidirectional 603 point-to-point, and uni-directional (both point-to-point and 604 point-to-multipoint) connections. 606 The MPLS-TP NE MUST support the configuration of maintenance 607 entity identifiers (e.g. MEP ID and MIP ID) for the purpose of 608 LSP connectivity checking. 610 The MPLS-TP NE MUST support configuration of OAM parameters to 611 meet their specific operational requirements, such as whether - 613 1) one-time on-demand immediately or 615 2) one-time on-demand pre-scheduled or 617 3) on-demand periodically based on a specified schedule or 619 4) proactive on-going. 621 The MPLS-TP NE MUST support the enabling/disabling of the 622 connectivity check processing. The connectivity check process of 623 the MPLS-TP NE MUST support provisioning of the identifiers to 624 be transmitted and the expected identifiers. 626 7. Performance Management Requirements 628 Performance Management provides functions for the purpose of 629 Maintenance, Bring-into-service, Quality of service, and 630 statistics gathering. 632 This information could be used, for example, to compare behavior 633 of the equipment, MPLS-TP NE or network at different moments in 634 time to evaluate changes in network performance. 636 ITU-T Recommendation G.7710 [1] provides transport performance 637 monitoring requirements for packet-switched and circuit-switched 638 transport networks with the objective of providing coherent and 639 consistent interpretation of the network behavior in a multi- 640 technology environment. The performance management requirements 641 specified in this document are driven by such an objective. 643 7.1. Path Characterization Performance Metrics 645 It MUST be possible to determine when an MPLS-TP based transport 646 service is available and when it is unavailable. 648 From a performance perspective, a service is unavailable if 649 there is an indication that performance has degraded to the 650 extent that a configurable performance threshold has been 651 crossed and the degradation persists long enough (i.e. - the 652 indication persists for some amount of time - which is either 653 configurable, or well-known) to be certain it is not a 654 measurement anomaly. 656 Methods, mechanisms and algorithms for exactly how 657 unavailability is to be determined - based on collection of raw 658 performance data - are out of scope for this document. 660 The MPLS-TP NE MUST support collection and reporting of raw 661 performance data that MAY be used in determining the 662 unavailability of a transport service. 664 MPLS-TP MUST support the determination of the unavailability of 665 the transport service. The result of this determination MUST be 666 available via the MPLS-TP NE (at service termination points), 667 and determination of unavailability MAY be supported by the 668 MPLS-TP NE directly. To support this requirement, the MPLS-TP NE 669 management information model MUST include objects corresponding 670 to availability-state of services. 672 Transport network unavailability is based on Severely Errored 673 Seconds (SES) and Unavailable Seconds (UAS). ITU-T is 674 establishing definitions of unavailability generically 675 applicable to packet transport technologies, including MPLS-TP, 676 based on SES and UAS. Note that SES and UAS are already defined 677 for Ethernet transport networks in ITU-T Recommendation Y.1563 678 [25]. 680 The MPLS-TP NE MUST support collection of loss measurement (LM) 681 statistics. 683 The MPLS-TP NE MUST support collection of delay measurement (DM) 684 statistics. 686 The MPLS-TP NE MUST support reporting of Performance degradation 687 via fault management for corrective actions. "Reporting" in this 688 context could mean: 690 . reporting to an autonomous protection component to trigger 691 protection switching, 693 . reporting via a craft interface to allow replacement of a 694 faulty component (or similar manual intervention), 696 . etc. 698 The MPLS-TP NE MUST support reporting of performance statistics 699 on request from a management system. 701 7.2. Performance Measurement Instrumentation 703 7.2.1. Measurement Frequency 705 For performance measurement mechanisms that support both 706 proactive and on-demand modes, the MPLS-TP NE MUST support the 707 capability to be configured to operate on-demand or proactively. 709 7.2.2. Measurement Scope 711 On measurement of packet loss and loss ratio: 713 . For bidirectional (both co-routed and associated) P2P 714 connections - 716 o on-demand measurement of single-ended packet loss, and 717 loss ratio, measurement is REQUIRED; 719 o proactive measurement of packet loss, and loss ratio, 720 measurement for each direction is REQUIRED. 722 . for unidirectional (P2P and P2MP) connection, proactive 723 measurement of packet loss, and loss ratio, is REQUIRED. 725 On Delay measurement: 727 . for unidirectional (P2P and P2MP) connection, on-demand 728 measurement of delay measurement is REQUIRED. 730 . for co-routed bidirectional (P2P) connection, on-demand 731 measurement of one-way and two-way delay is REQUIRED. 733 . for associated bidirectional (P2P) connection, on-demand 734 measurement of one-way delay is REQUIRED. 736 8. Security Management Requirements 738 The MPLS-TP NE MUST support secure management and control 739 planes. 741 8.1. Management Communication Channel Security 743 Secure communication channels MUST be supported for all network 744 traffic and protocols used to support management functions. 745 This MUST include, at least, protocols used for configuration, 746 monitoring, configuration backup, logging, time synchronization, 747 authentication, and routing. The MCC MUST support application 748 protocols that provide confidentiality and data integrity 749 protection. 751 The MPLS-TP NE MUST support the following: 753 - Use of open cryptographic algorithms (See RFC 3871 [4]) 755 - Authentication - allow management connectivity only from 756 authenticated entities. 758 - Authorization - allow management activity originated by an 759 authorized entity, using (for example) an Access Control 760 List (ACL). 762 - Port Access Control - allow management activity received on 763 an authorized (management) port. 765 8.2. Signaling Communication Channel Security 767 Security requirements for the SCC are driven by considerations 768 similar to MCC requirements described in section 8.1. 770 Security Requirements for the control plane are out of scope for 771 this document and are expected to be defined in the appropriate 772 control plane specifications. 774 Management of control plane security MUST also be defined at 775 that time. 777 8.3. Distributed Denial of Service 779 A Denial of Service (DoS) attack is an attack that tries to 780 prevent a target from performing an assigned task, or providing 781 its intended service(s), through any means. A Distributed DoS 782 (DDoS) can multiply attack severity (possibly by an arbitrary 783 amount) by using multiple (potentially compromised) systems to 784 act as topologically (and potentially geographically) 785 distributed attack sources. It is possible to lessen the impact 786 and potential for DoS and DDoS by using secure protocols, 787 turning off unnecessary processes, logging and monitoring, and 788 ingress filtering. RFC 4732 [26] provides background on DOS in 789 the context of the Internet. 791 An MPLS-TP NE MUST support secure management protocols and 792 SHOULD do so in a manner the reduce potential impact of a DoS 793 attack. 795 An MPLS-TP NE SHOULD support additional mechanisms that mitigate 796 a DoS (or DDoS) attack against the management component while 797 allowing the NE to continue to meet its primary functions. 799 9. Security Considerations 801 Section 8 includes a set of security requirements that apply to 802 MPLS-TP network management. 804 Solutions MUST provide mechanisms to prevent unauthorized and/or 805 unauthenticated access to management capabilities and private 806 information by network elements, systems or users. 808 Performance of diagnostic functions and path characterization 809 involves extracting a significant amount of information about 810 network construction that the network operator might consider 811 private. 813 10. IANA Considerations 815 There are no IANA actions associated with this document. 817 11. Acknowledgments 819 The authors/editors gratefully acknowledge the thoughtful 820 review, comments and explanations provided by Adrian Farrel, 821 Alexander Vainshtein, Andrea Maria Mazzini, Ben Niven-Jenkins, 822 Bernd Zeuner, Dan Romascanu, Daniele Ceccarelli, Diego Caviglia, 823 Dieter Beller, He Jia, Leo Xiao, Maarten Vissers, Neil Harrison, 824 Rolf Winter, Yoav Cohen and Yu Liang. 826 12. References 828 12.1. Normative References 830 [1] ITU-T Recommendation G.7710/Y.1701, "Common equipment 831 management function requirements", July, 2007. 833 [2] Nadeau, T., et al, "Operations and Management (OAM) 834 Requirements for Multi-Protocol Label Switched (MPLS) 835 Networks", RFC 4377, February 2006. 837 [3] Vigoureux, M., et al, "Requirements for OAM in MPLS 838 Transport Networks", work in progress. 840 [4] Jones, G., "Operational Security Requirements for Large 841 Internet Service Provider (ISP) IP Network 842 Infrastructure", RFC 3871, September 2004. 844 [5] Bradner, S., "Key words for use in RFCs to Indicate 845 Requirement Levels", RFC 2119, March 1997. 847 [6] ITU-T Recommendation G.7712/Y.1703, "Architecture and 848 specification of data communication network", June 2008. 850 [7] Beller, D., et al, "An Inband Data Communication Network 851 For the MPLS Transport Profile", draft-ietf-mpls-tp-gach- 852 dcn, work in progress. 854 [8] Niven-Jenkins, B. et al, "MPLS-TP Requirements", draft- 855 ietf-mpls-tp-requirements, work in progress. 857 12.2. Informative References 859 [9] Chisholm, S. and D. Romascanu, "Alarm Management 860 Information Base (MIB)", RFC 3877, September 2004. 862 [10] ITU-T Recommendation M.20, "Maintenance philosophy for 863 telecommunication networks", October 1992. 865 [11] Telcordia, "Network Maintenance: Network Element and 866 Transport Surveillance Messages" (GR-833-CORE), Issue 5, 867 August 2004. 869 [12] Bocci, M. et al, "A Framework for MPLS in Transport 870 Networks", draft-ietf-mpls-tp-framework, work in progress. 872 [13] Bocci, M. et al, "MPLS Generic Associated Channel", RFC 873 5586, June 2009. 875 [14] Harrington, D., "Guidelines for Considering Operations and 876 Management of New Protocols and Protocol Extensions", 877 draft-ietf-opsawg-operations-and-management, work in 878 progress. 880 [15] Mansfield, S. et al, "MPLS-TP Network Management 881 Framework", draft-ietf-mpls-tp-nm-framework, work in 882 progress. 884 [16] Enns, R. et al, "NETCONF Configuration Protocol", draft- 885 ietf-netconf-4741bis, work in progress. 887 [17] McCloghrie, K. et al, "Structure of Management Information 888 Version 2 (SMIv2)", RFC 2578, April 1999. 890 [18] OMG Document formal/04-03-12, "The Common Object Request 891 Broker: Architecture and Specification", Revision 3.0.3. 892 March 12, 2004. 894 [19] Caviglia, D. et al, "Requirements for the Conversion 895 between Permanent Connections and Switched Connections in 896 a Generalized Multiprotocol Label Switching (GMPLS) 897 Network", RFC 5493, April 2009. 899 [20] Caviglia, D. et al, "RSVP-TE Signaling Extension For The 900 Conversion Between Permanent Connections And Soft 901 Permanent Connections In A GMPLS Enabled Transport 902 Network", draft-ietf-ccamp-pc-spc-rsvpte-ext, work in 903 progress. 905 [21] ITU-T Recommendation G.806, "Characteristics of transport 906 equipment - Description methodology and generic 907 functionality", January, 2009. 909 [22] ITU-T Recommendation Y.1731, "OAM functions and mechanisms 910 for Ethernet based networks", February, 2008. 912 [23] ITU-T Recommendation G.8601, "Architecture of service 913 management in multi bearer, multi carrier environment", 914 June 2006. 916 [24] Lam, H., et al, "Alarm Reporting Control Management 917 Information Base (MIB)", RFC 3878, September 2004. 919 [25] ITU-T Recommendation Y.1563, "Ethernet frame transfer and 920 availability performance", January 2009. 922 [26] Handley, M., et al, "Internet Denial-of-Service 923 Considerations", RFC 4732, November 2006. 925 Author's Addresses 927 Editors: 929 Eric Gray 930 Ericsson 931 900 Chelmsford Street 932 Lowell, MA, 01851 933 Phone: +1 978 275 7470 934 Email: Eric.Gray@Ericsson.com 936 Scott Mansfield 937 Ericsson 938 250 Holger Way 939 San Jose CA, 95134 940 +1 724 931 9316 941 EMail: Scott.Mansfield@Ericsson.com 943 Hing-Kam (Kam) Lam 944 Alcatel-Lucent 945 600-700 Mountain Ave 946 Murray Hill, NJ, 07974 947 Phone: +1 908 582 0672 948 Email: hklam@Alcatel-Lucent.com 950 Author(s): 952 Contributor(s): 954 Adrian Farrel 955 Old Dog Consulting 956 Email: adrian@olddog.co.uk 958 Copyright Statement 960 Copyright (c) 2009 IETF Trust and the persons identified as the 961 document authors. All rights reserved. 963 This document is subject to BCP 78 and the IETF Trust's Legal 964 Provisions Relating to IETF Documents in effect on the date of 965 publication of this document (http://trustee.ietf.org/license- 966 info). Please review these documents carefully, as they 967 describe your rights and restrictions with respect to this 968 document. 970 Acknowledgment 972 Funding for the RFC Editor function is currently provided by the 973 Internet Society. 975 Appendix A- Communication Channel (CCh) Examples 977 A CCh may be realized in a number of ways. 979 1. The CCh may be provided by a link in a physically distinct 980 network. That is, a link that is not part of the transport 981 network that is being managed. For example, the nodes in the 982 transport network may be interconnected in two distinct physical 983 networks: the transport network and the DCN. 985 This is a "physically distinct out-of-band CCh". 987 2. The CCh may be provided by a link in the transport network 988 that is terminated at the ends of the DCC and which is capable 989 of encapsulating and terminating packets of the management 990 protocols. For example, in MPLS-TP a single-hop LSP might be 991 established between two adjacent nodes, and that LSP might be 992 capable of carrying IP traffic. Management traffic can then be 993 inserted into the link in an LSP parallel to the LSPs that carry 994 user traffic. 996 This is a "physically shared out-of-band CCh." 998 3. The CCh may be supported as its native protocol on the 999 interface alongside the transported traffic. For example, if an 1000 interface is capable of sending and receiving both MPLS-TP and 1001 IP, the IP-based management traffic can be sent as native IP 1002 packets on the interface. 1004 This is a "shared interface out-of-band CCh". 1006 4. The CCh may use overhead bytes available on a transport 1007 connection. For example, in TDM networks there are overhead 1008 bytes associated with a data channel, and these can be used to 1009 provide a CCh. It is important to note that the use of overhead 1010 bytes does not reduce the capacity of the associated data 1011 channel. 1013 This is an "overhead-based CCh". 1015 This alternative is not available in MPLS-TP because there is no 1016 overhead available. 1018 5. The CCh may provided by a dedicated channel associated with 1019 the data link. For example, the generic associated label (GAL) 1020 [13] may be used to label DCC traffic being exchanged on a data 1021 link between adjacent transport nodes, potentially in the 1022 absence of any data LSP between those nodes. 1024 This is a "data link associated CCh". 1026 It is very similar to case 2, and by its nature can only span a 1027 single hop in the transport network. 1029 6. The CCh may be provided by a dedicated channel associated 1030 with a data channel. For example, in MPLS-TP the GAL [13] may be 1031 imposed under the top label in the label stack for an MPLS-TP 1032 LSP to create a channel associated with the LSP that may carry 1033 management traffic. This CCh requires the receiver to be capable 1034 of demultiplexing management traffic from user traffic carried 1035 on the same LSP by use of the GAL. 1037 This is a "data channel associated CCh". 1039 7. The CCh may be provided by mixing the management traffic with 1040 the user traffic such that is indistinguishable on the link 1041 without deep-packet inspection. In MPLS-TP this could arise if 1042 there is a data-carrying LSP between two nodes, and management 1043 traffic is inserted into that LSP. This approach requires that 1044 the termination point of the LSP is able to demultiplex the 1045 management and user traffic. Such might be possible in MPLS-TP 1046 if the MPLS-TP LSP was carrying IP user traffic. 1048 This is an "in-band CCh". 1050 These realizations may be categorized as: 1052 A. Out-of-fiber, out-of-band (types 1 and 2) 1053 B. In-fiber, out-of-band (types 2, 3, 4, and 5) 1054 C. In-band (types 6 and 7) 1056 The MCN and SCN are logically separate networks and may be 1057 realized by the same DCN or as separate networks. In practice, 1058 that means that, between any pair of nodes, the MCC and SCC may 1059 be the same link or separate links. 1061 It is also important to note that the MCN and SCN do not need to 1062 be categorised as in-band, out-of-band, etc. This definition 1063 only applies to the individual links, and it is possible for 1064 some nodes to be connected in the MCN or SCN by one type of 1065 link, and other nodes by other types of link. Furthermore, a 1066 pair of adjacent nodes may be connected by multiple links of 1067 different types. 1069 Lastly note that the division of DCN traffic between links 1070 between a pair of adjacent nodes is purely an implementation 1071 choice. Parallel links may be deployed for DCN resilience or 1072 load sharing. Links may be designated for specific use. For 1073 example, so that some links carry management traffic and some 1074 carry control plane traffic, or so that some links carry 1075 signaling protocol traffic while others carry routing protocol 1076 traffic. 1078 It should be noted that the DCN may be a routed network with 1079 forwarding capabilities, but that this is not a requirement. The 1080 ability to support forwarding of management or control traffic 1081 within the DCN may substantially simplify the topology of the 1082 DCN and improve its resilience, but does increase the complexity 1083 of operating the DCN. 1085 See also RFC 3877 [9], ITU-T M.20 [10], and Telcordia document 1086 GR-833-CORE [11] for further information.