idnits 2.17.1 draft-ietf-mpls-tp-nm-req-01.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 (April 15, 2009) is 5491 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'LM' on line 386 -- Looks like a reference, but probably isn't: 'DM' on line 386 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Hing-Kam Lam 3 Internet Draft Alcatel-Lucent 4 Expires: October, 2009 Scott Mansfield 5 Intended Status: Informational Eric Gray 6 Ericsson 7 April 15, 2009 9 MPLS TP Network Management Requirements 10 draft-ietf-mpls-tp-nm-req-01.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 October 15, 2009. 36 Abstract 38 This document specifies the requirements necessary to manage the 39 elements and networks that support an MPLS Transport Profile 40 (MPLS-TP). This document is a product of a joint International 41 Telecommunications Union - Telecommunications Standardization 42 Sector (ITU-T) and Internet Engineering Task Force (IETF) effort 43 to include a MPLS Transport Profile within the IETF MPLS 44 architecture. The requirements are driven by the management 45 functionality needs defined by ITU-T for packet transport 46 networks. 48 Table of Contents 50 1. Introduction................................................3 51 1.1. Terminology............................................3 52 2. Management Interface Requirements...........................4 53 3. Management Communication Channel (MCC) Requirements.........4 54 4. Management Communication Network (MCN) Requirements.........5 55 5. Fault Management Requirements...............................5 56 5.1. Supervision Function...................................5 57 5.2. Validation Function....................................6 58 5.3. Alarm Handling Function................................7 59 5.3.1. Alarm Severity Assignment.........................7 60 5.3.2. Alarm Suppression.................................7 61 5.3.3. Alarm Reporting Control...........................8 62 5.3.4. Alarm Reporting...................................8 63 6. Configuration Management Requirements.......................8 64 6.1. System Configuration...................................9 65 6.2. Control Plane Configuration............................9 66 6.3. Path Configuration.....................................9 67 6.4. Protection Configuration...............................9 68 6.5. OAM Configuration.....................................10 69 7. Performance Management Requirements........................10 70 7.1. Path Characterization Performance Metrics.............10 71 7.2. Performance Measurement Instrumentation..............12 72 7.2.1. Measurement Frequency............................12 73 7.2.2. Measurement Scope................................12 74 8. Security Management Requirements...........................13 75 8.1. Management Communication Channel Security.............13 76 8.2. Signaling Communication Channel Security..............13 77 8.3. Distributed Denial of Service.........................13 78 9. Security Considerations....................................14 79 10. IANA Considerations......................................14 80 11. Acknowledgments...........................................14 81 12. References................................................14 82 12.1. Normative References.................................14 83 12.2. Informative References...............................15 84 13. Author's Addresses........................................16 85 Copyright Statement...........................................16 86 Acknowledgment................................................17 87 APPENDIX A: Communication Channel (CC) Examples...............18 89 1. Introduction 91 This document describes the requirements necessary to manage the 92 elements and networks that support an MPLS Transport Profile 93 (MPLS-TP). It leverages the management requirements specified 94 in ITU-T G.7710/Y.1701 [1] and RFC 4377 [2]. ITU-T G.7710/Y.1701 95 [1] specifies generic management requirements for transport 96 (including packet-based and circuit-based) networks. RFC 4377 97 specifies the OAM requirements, including OAM-related network 98 management requirements, for MPLS networks. This document 99 expands on the requirements in [1] and [2] to cover fault, 100 configuration, performance, and security management for MPLS-TP 101 networks, and the requirements for object and information models 102 needed to manage MPLS-TP Networks and Network Elements. 104 1.1. Terminology 106 Although this document is not a protocol specification, the key 107 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 109 this document are to be interpreted as described in RFC 2119 [6] 110 and are to be interpreted as instructions to protocol designers 111 producing solutions that satisfy the requirements set out in 112 this document. 114 MPLS-TP NE: a network element (NE) that supports MPLS-TP 115 functions 117 MPLS-TP network: a network in which MPLS-TP NEs are deployed 119 Data Communication Network (DCN): a network that supports Layer 120 1 (physical layer), Layer 2 (data-link layer), and Layer 3 121 (network layer) functionality for distributed management 122 communications related to the management plane, for distributed 123 signaling communications related to the control plane, and other 124 operations communications (e.g., order-wire/voice 125 communications, software downloads, etc.). 127 Management Communication Network (MCN): A DCN supporting 128 management plane communication is referred to as a Management 129 Communication Network (MCN). 131 Signaling Communication Network (SCN): A DCN supporting control 132 plane communication is referred to as a Signaling Communication 133 Network (SCN). 135 Communication Channel (CC): a logical channel between network 136 elements (NEs) that can be used - e.g. - for management plane 137 application or control plane applications. The physical channel 138 supporting the CC is technology specific. See APPENDIX A: 140 Management Communication Channel (MCC): a CC dedicated for 141 management plane communications. 143 Signaling Communication Channel (SCC): a CC dedicated for 144 control plane communications. The SCC may be used for GMPLS/ASON 145 signaling and/or other control plane messages (e.g., routing 146 messages). 148 Operations System (OS): A system that performs the functions 149 that support processing of information related to operations, 150 administration, maintenance, and provisioning (OAM&P) for the 151 networks, including surveillance and testing functions to 152 support customer access maintenance. 154 2. Management Interface Requirements 156 This document does not specify which management interface 157 protocol should be the standard protocol for managing MPLS-TP 158 networks. Managing an end-to-end connection across multiple 159 operator domains where one domain is managed (for example) via 160 NETCONF/XML or SNMP/SMI, and another domain via CORBA/IDL, is 161 allowed. 163 For the management interface to the management system, an MPLS- 164 TP NE MAY actively support more than one management protocol in 165 any given deployment. For example, an MPLS-TP NE may use one 166 protocol for configuration and another for monitoring. The 167 protocols to be supported are at the discretion of the operator. 169 3. Management Communication Channel (MCC) Requirements 171 An MPLS-TP management network SHOULD support seamless management 172 connectivity with remote MPLS-TP domains and NEs as well as with 173 termination points located in NEs under control by a third party 174 network operator. See ITU-T G.8601 [8] for example scenarios in 175 multi-carrier multi-transport-technology environments. 177 For management purpose, every MPLS-TP NE MUST connect to an OS 178 either directly or indirectly via another MPLS-TP NE. When an 179 MPLS-TP NE is connected indirectly to an OS, an MCC MUST be 180 supported between the MPLS-TP NE and the other MPLS-TP NE. 182 4. Management Communication Network (MCN) Requirements 184 Entities of the MPLS-TP management plane communicate via a DCN, 185 or more specifically via the MCN. The MCN connects MPLS-TP NEs 186 with management systems, NEs with NEs, and management systems 187 with management systems. Transport DCN architecture and 188 requirements are specified in ITU-T G.7712/Y.1703 [7], including 189 network layer protocols and their interworking. 191 As a practical requirement, MCN connections require addressing. 192 See the section on addressing in [13] for further information. 194 In order to have the MCN operate properly, a number of 195 management functions for the MCN are required, including: 197 . Retrieval of DCN network parameters to ensure compatible 198 functioning, e.g. packet size, timeouts, quality of 199 service, window size, etc.; 201 . Establishment of message routing between DCN nodes; 203 . Management of DCN network addresses; 205 . Retrieval of operational status of the DCN at a given node; 207 . Capability to enable/disable access to the DCN. 209 5. Fault Management Requirements 211 The Fault Management functions within an MPLS-TP NE enable the 212 supervision, detection, validation, isolation, correction, and 213 reporting of abnormal operation of the MPLS-TP network and its 214 environment. 216 5.1. Supervision Function 218 The supervision function analyses the actual occurrence of a 219 disturbance or fault for the purpose of providing an appropriate 220 indication of performance and/or detected fault condition to 221 maintenance personnel and operations systems. 223 The MPLS-TP NE MUST support supervision of the OAM mechanisms 224 that are deployed for supporting the OAM requirements defined in 225 [3]. 227 The MPLS-TP NE MUST support the following transmission 228 supervision functions: 230 . Supervision of looping check functions used to detect loops 231 in the data-plane forwarding path (which result in non- 232 delivery of traffic, wasting of forwarding resources and 233 unintended self-replication of traffic); 235 . Supervision of the detection of failure in the sequence of 236 a protocol exchange (e.g. automatic protection switching 237 protocol); 239 The MPLS-TP NE transmission-related supervision mechanisms MUST 240 support the flexibility to be configured to perform on-demand or 241 proactively. 243 The MPLS-TP NE MUST support supervision for software processing 244 e.g., processing fault, storage capacity problem, version 245 mismatch, corrupted data, out of memory, etc. 247 The MPLS-TP NE MUST support hardware-related supervision for 248 interchangeable and non-interchangeable units, cable, and power 249 problem. 251 The MPLS-TP NE SHOULD support environment-related supervision 252 for temperature, humidity, etc. 254 5.2. Validation Function 256 Validation is concerned with the integration of Fault Causes 257 into Failures. A Fault Cause indicates a limited interruption of 258 the required transport function. A Fault Cause is not reported 259 to maintenance personnel because it could exist only for a very 260 short time. Note that some of these events however are summed up 261 in the Performance Monitoring process, and when this sum exceeds 262 a certain value, a Threshold Report can be generated. 264 When the Fault Cause lasts long enough, an inability to perform 265 the required transport function arises. This Failure condition 266 is subject to reporting to maintenance personnel and/or an OS 267 because corrective action might be required. Conversely, when 268 the Fault Cause ceases after a certain time, clearing of the 269 Failure condition is also subject to reporting. 271 The MPLS-TP NE MUST perform persistency checks on fault causes 272 before it declares a fault cause a failure. 274 A transmission failure SHALL be declared if the fault cause 275 persists continuously for a configurable time (Time-D). The 276 failure SHALL be cleared if the fault cause is absent 277 continuously for a configurable time (Time-C). Typically the 278 default time values would be as follows: 280 Time-D = 2.5 +/- 0.5 seconds 282 Time-C = 10 +/- 0.5 seconds 284 These time values are as defined in G.7710 [1]. 286 The failure declaration and clearing MUST be time stamped. The 287 time-stamp SHALL indicate the time at which the fault cause is 288 activated at the input of the fault cause persistency (i.e. 289 defect-to-failure integration) function, and the time at which 290 the fault cause is deactivated at the input of the fault cause 291 persistency function. 293 5.3. Alarm Handling Function 295 5.3.1. Alarm Severity Assignment 297 Failures might be categorized to indicate the severity or 298 urgency of the fault. 300 An MPLS-TP NE SHOULD support the flexibility of assignment of 301 severity (e.g., Critical, Major, Minor, Warning) by the 302 management system. 304 See G.7710 [1] for more description about alarm severity 305 assignment. 307 5.3.2. Alarm Suppression 309 Alarms may be generated from many sources, including OAM, device 310 status, etc. 312 An MPLS-TP NE MUST provide alarm suppression functionality that 313 prevents the generation of superfluous alarms. 315 Examples of alarm suppression mechanisms include simply 316 discarding the alarms (or not generating them in the first 317 place), or aggregating the alarms together, thereby greatly 318 reducing the number of alarm notifications to be emitted. 320 Note: An MPLS-TP NE supporting the inter-working of one or more 321 networking technologies (e.g., Ethernet, SDH/SONET, MPLS) with 322 MPLS-TP needs to translate an MPLS-TP fault into an existing 323 transport technology failure condition for reporting to the 324 management system. 326 See RFC 4377 [2] for more description. 328 5.3.3. Alarm Reporting Control 330 Alarm Reporting Control (ARC) supports an automatic in-service 331 provisioning capability. Alarm reporting MAY be turned off on a 332 per-managed entity (e.g., LSP) basis to allow sufficient time 333 for customer service testing and other maintenance activities in 334 an "alarm free" state. Once a managed entity is ready, alarm 335 reporting is automatically turned on. 337 An MPLS-TP NE SHOULD support the Alarm Reporting Control 338 function for controlling the reporting of alarm conditions. 340 See G.7710 [1] and RFC 3878 [9] for more description of ARC. 342 5.3.4. Alarm Reporting 344 Alarm Reporting is concerned with the reporting of relevant 345 events and conditions, which occur in the network (including the 346 NE, incoming signal, and external environment). 348 Local reporting is concerned with automatic alarming by means of 349 audible and visual indicators near the failed equipment. 351 An MPLS-TP NE MUST support local reporting of alarms. 353 The MPLS-TP NE MUST support reporting of alarms to an OS. These 354 reports are either autonomous reports (notifications) or reports 355 on request by maintenance personnel. The MPLS-TP NE SHOULD 356 report local (environmental) alarms to a network management 357 system. 359 6. Configuration Management Requirements 361 Configuration Management provides functions to identify, collect 362 data from, provide data to and control NEs. Specific 363 configuration tasks requiring network management support include 364 hardware and software configuration, configuration of NEs to 365 support transport paths (including required working and 366 protection paths), and configuration of required path 367 integrity/connectivity and performance monitoring (i.e. - OAM). 369 6.1. System Configuration 371 The MPLS-TP NE MUST support the configuration requirements 372 specified in G.7710 [1] for hardware, software, and date/time. 374 6.2. Control Plane Configuration 376 If a control plane is supported in an implementation of MPLS-TP, 377 the MPLS-TP NE MUST support the configuration of MPLS-TP control 378 plane functions by the management plane. Further detailed 379 requirements might be provided along with progress in defining 380 the MPLS-TP control plane in appropriate specifications. 382 6.3. Path Configuration 384 The MPLS-TP NE MUST support the capability of configuring 385 required path performance characteristic thresholds (e.g. - Loss 386 Measurement [LM], Delay Measurement [DM] thresholds). 388 The MPLS-TP NE MUST support the capability of configuring 389 required LSPs as follows: 391 . configure LSP indentifier and/or other information 392 necessary to retrieve LSP status information. 394 6.4. Protection Configuration 396 The MPLS-TP NE MUST support the capability of configuring 397 required path protection as follows: 399 . Designate specifically identified LSPs as working or 400 protection LSPs; 401 . define associations of working and protection paths; 402 . operate/release manual protection switching; 403 . operate/release force protection switching; 404 . operate/release protection lockout; 405 . set/retrieve Automatic Protection Switching (APS) 406 parameters, including - 407 . Wait to Restore time, 408 . Protection Switching threshold information. 410 6.5. OAM Configuration 412 The MPLS-TP NE MUST provide the capability to configure the OAM 413 entities and functions specified in [3]. 415 The MPLS-TP NE MUST support the capability to choose which OAM 416 functions to use and which maintenance entity to apply them. 418 The MPLS-TP NE MUST support the capability to configure the OAM 419 entities/functions as part of LSP setup and tear-down, including 420 co-routed bidirectional point-to-point, associated bidirectional 421 point-to-point, and uni-directional (both point-to-point and 422 point-to-multipoint) connections. 424 The MPLS-TP NE MUST support the configuration of maintenance 425 entity identifiers (e.g. MEP ID and MIP ID) for the purpose of 426 LSP connectivity checking. 428 The MPLS-TP NE MUST have the flexibility to configure OAM 429 parameters to meet their specific operational requirements, such 430 as whether (1) one-time on-demand immediately or (2) one-time 431 on-demand pre-scheduled or (3) on-demand periodically based on a 432 specified schedule or (4) proactive on-going. 434 The MPLS-TP NE MUST support the enabling/disabling of the 435 connectivity check processing. The connectivity check process of 436 the MPLS-TP NE MUST support provisioning of the identifiers to 437 be transmitted and the expected identifiers. 439 7. Performance Management Requirements 441 Performance Management provides functions to evaluate and report 442 upon the behavior of the equipment, NE, and network for the 443 purpose of Maintenance, Bring-into-service, Quality of service, 444 and Performance monitoring for signal degradation. ITU-T 445 Recommendation G.7710 [1] provides transport performance 446 monitoring requirements for packet-switched and circuit-switched 447 transport networks with the objective of providing coherent and 448 consistent interpretation of the network behavior, in particular 449 for hybrid network which consists of multiple transport 450 technologies. The performance management requirements specified 451 in this document are driven by such an objective. 453 7.1. Path Characterization Performance Metrics 455 The MPLS-TP NE MUST support collection of loss measurement (LM) 456 so that they can be used to detect performance degradation. 458 The MPLS-TP NE MUST support collection of delay measurement (DM) 459 so that they can be used to detect performance degradation. 461 The MPLS-TP NE MUST support reporting of Performance degradation 462 via fault management for corrective actions (e.g. protection 463 switching). 465 The MPLS-TP NE MUST support collection of loss ratio measurement 466 so that they can be used to determine Severely Errored Second 467 (SES). 469 A SES is declared for a one second interval when the ratio of 470 lost packets to total transmitted packets in that one second 471 interval exceeds a predetermined threshold. 473 The packet lost threshold for declaring SES MUST be 474 configurable. 476 The number of SESs MUST be collected per configurable intervals 477 (e.g. 15-minute and 24-hour). 479 The MPLS-TP NE MUST support collection of SES measurement so 480 that they can be used to determine service unavailable time. 482 A period of unavailable time (UAT) begins at the onset of 10 483 consecutive SES events. These 10 seconds are considered to be 484 part of unavailable time. A new period of available time begins 485 at the onset of 10 consecutive non-SES events. These 10 seconds 486 are considered to be part of available time. 488 The MPLS-TP NE MUST support collection of Unavailable Seconds 489 (UAS) so that they can be used to determine service 490 availability. 492 The number of UAS MUST be collected per configurable intervals 493 (e.g. 15-minute and 24-hour). 495 SES and UAS history (the number of readings to be retained and 496 available) is as defined in ITU and ANSI documents associated 497 with specific transport technologies (for instance, ITU-T 498 G.7710, and ANSI T1.231-2003 [T1.231.01-2003 for DSL,.02 for 499 DS1,.03 for DS3 and T1.231.04-2003 for SONET] - see [1] and [14] 500 respectively), however these are fairly consistently defined as 501 follows: 503 - Current and previous 1-day statistics 504 - Current and 16 recent 15-minute statistics (ITU-T) 506 - Current, previous and 31 recent 15-minute statistics (ANSI) 508 Note that - worst case (ANSI) requires 2 copies of 1-day 509 statistics (current and previous) and 33 copies of 15-minute 510 statistics (current, previous and 31 recent). 512 7.2. Performance Measurement Instrumentation 514 7.2.1. Measurement Frequency 516 The performance measurement mechanisms MUST support the 517 flexibility to be configured to operate on-demand or proactively 518 (i.e. continuously over a period of time). 520 7.2.2. Measurement Scope 522 On measurement of packet loss and loss ratio: 524 - For bidirectional (both co-routed and associated) P2P 525 connections - 527 . on-demand measurement of single-ended packet loss, 528 and loss ratio, measurement are required; 530 . proactive measurement of packet loss, and loss 531 ratio, measurement for each direction are required. 533 Note: for associated bidirectional P2P connections, this data 534 can only be measured at end-points. 536 - For unidirectional (P2P and P2MP) connection, proactive 537 measurement of packet loss, and loss ratio, are required. 539 On Delay measurement: 541 - For unidirectional (P2P and P2MP) connection, on-demand 542 measurement of delay measurement is required. 544 - For co-routed bidirectional (P2P) connection, on-demand 545 measurement of one-way and two-way delay are required. 547 - For associated bidirectional (P2P) connection, on-demand 548 measurement of one-way delay is required. 550 8. Security Management Requirements 552 The MPLS-TP NE MUST support secure management and control 553 planes. 555 8.1. Management Communication Channel Security 557 Secure channels MUST be provided for all network traffic and 558 protocols used to support management functions. This MUST 559 include, at least, protocols used for configuration, monitoring, 560 configuration backup, logging, time synchronization, 561 authentication, and routing. The MCC MUST support application 562 protocols that provide confidentiality and data integrity 563 protection. 565 If management communication security is provided, the MPLS-TP NE 566 MUST support the following: 568 - Use of open cryptographic algorithms (See RFC 3871 [5]) 570 - Authentication - allow management connectivity only from 571 authenticated entities. 573 - Authorization - allow management activity originated by an 574 authorized entity, using (for example) an Access Control 575 List (ACL). 577 Port Access Control - allow management activity received on an 578 authorized (management) port. 580 8.2.Signaling Communication Channel Security 582 Security considerations for the SCC are similar to the 583 considerations driving the requirements described in section 584 8.1. Security Requirements for the control plane are out of 585 scope for this document and are expected to be defined in the 586 appropriate control plane specifications. Management of the 587 control plane security must also be defined at that time. 589 8.3. Distributed Denial of Service 591 Denial of Service (DoS) attack is an attack which tries to 592 prevent a target from performing an assigned task, or providing 593 its intended service(s), through any means. A Distributed DoS 594 (DDoS) can multiply attack severity (possibly by an arbitrary 595 amount) by using multiple (potentially compromised) systems to 596 act as topologically (and potentially geographically) 597 distributed attack sources. It is possible to lessen the impact 598 and potential for DDOS by using secure protocols, turning off 599 unnecessary processes, logging and monitoring, and ingress 600 filtering. RFC 4732 [4] provides background on DOS in the 601 context of the Internet. 603 9. Security Considerations 605 Section 8 includes a set of security requirements that apply to 606 MPLS-TP network management. 608 Solutions MUST provide mechanisms to prevent unauthorized and/or 609 unauthenticated access to private information by network 610 elements, systems or users. 612 Performance of diagnostic functions and path characterization 613 involves extracting a significant amount of information about 614 network construction that the network operator MAY consider 615 private. 617 10. IANA Considerations 619 There are no IANA actions associated with this document. 621 11. Acknowledgments 623 The authors/editors gratefully acknowledge the thoughtful 624 review, comments and explanations provided by Adrian Farrel, 625 Andrea Maria Mazzini, Ben Niven-Jenkins, Bernd Zeuner, Diego 626 Caviglia, Dieter Beller, He Jia, Leo Xiao, Maarten Vissers, Neil 627 Harrison and Rolf Winter. 629 12. References 631 12.1. Normative References 633 [1] ITU-T Recommendation G.7710/Y.1701, "Common equipment 634 management function requirements", July, 2007. 636 [2] Nadeau, T., et al, "Operations and Management (OAM) 637 Requirements for Multi-Protocol Label Switched (MPLS) 638 Networks", RFC 4377, February 2006. 640 [3] Vigoureus, M., et al, "Requirements for OAM in MPLS 641 Transport Networks", work in progress. 643 [4] Handley, M., et al, "Internet Denial-of-Service 644 Considerations", RFC 4732, November 2006. 646 [5] Jones, G., "Operational Security Requirements for Large 647 Internet Service Provider (ISP) IP Network 648 Infrastructure", RFC 3871, September 2004. 650 [6] Bradner, S., "Key words for use in RFCs to Indicate 651 Requirement Levels", RFC 2119, March 1997. 653 [7] ITU-T Recommendation G.7712/Y.1703, "Architecture and 654 Specification of Data Communication Network", June 2008. 656 [8] ITU-T Recommendation G.8601, "Architecture of service 657 management in multi bearer, multi carrier environment", 658 June 2006. 660 [9] Lam, H., et al, "Alarm Reporting Control Management 661 Information Base (MIB)", RFC 3878, September 2004. 663 12.2. Informative References 665 [10] Chisholm, S. and D. Romascanu, "Alarm Management 666 Information Base (MIB)", RFC 3877, September 2004. 668 [11] ITU-T Recommendation M.20, "Maintenance Philosophy for 669 Telecommunication Networks", October 1992. 671 [12] Telcordia, "Network Maintenance: Network Element and 672 Transport Surveillance Messages" (GR-833-CORE), Issue 5, 673 August 2004. 675 [13] Bocci, M. et al, "A Framework for MPLS in Transport 676 Networks", Work in Progress, November 27, 2008. 678 [14] ANSI T1.231-2003, "Layer 1 In-Service Transmission 679 Performance Monitoring", American National Standards 680 Institute, 2003. 682 [15] Vigoureux, M. et al, "MPLS Generic Associated Channel", 683 draft-ietf-mpls-tp-gach-gal, work in progress. 685 13. Author's Addresses 687 Editors: 689 Scott Mansfield 690 Ericsson 691 5000 Ericsson Drive 692 Warrendale, PA, 15086 693 Phone: +1 724 742 6726 694 EMail: Scott.Mansfield@Ericsson.com 696 Hing-Kam (Kam) Lam 697 Alcatel-Lucent 698 600-700 Mountain Ave 699 Murray Hill, NJ, 07974 700 Phone: +1 908 582 0672 701 Email: hklam@Alcatel-Lucent.com 703 Eric Gray 704 Ericsson 705 900 Chelmsford Street 706 Lowell, MA, 01851 707 Phone: +1 978 275 7470 708 Email: Eric.Gray@Ericsson.com 710 Author(s): 712 Contributor(s): 714 Adrian Farrel 715 Old Dog Consulting 716 Email: adrian@olddog.co.uk 718 Copyright Statement 720 Copyright (c) 2009 IETF Trust and the persons identified as the 721 document authors. All rights reserved. 723 This document is subject to BCP 78 and the IETF Trust's Legal 724 Provisions Relating to IETF Documents in effect on the date of 725 publication of this document (http://trustee.ietf.org/license- 726 info). Please review these documents carefully, as they 727 describe your rights and restrictions with respect to this 728 document. 730 Acknowledgment 732 Funding for the RFC Editor function is currently provided by the 733 Internet Society. 735 APPENDIX A: Communication Channel (CC) Examples 737 A CC may be realized in a number of ways. 739 1. The CC may be provided by a link in a physically distinct 740 network. That is, a link that is not part of the transport 741 network that is being managed. For example, the nodes in the 742 transport network may be interconnected in two distinct physical 743 networks: the transport network and the DCN. 745 This is a "physically distinct out-of-band CC". 747 2. The CC may be provided by a link in the transport network 748 that is terminated at the ends of the DCC and which is capable 749 of encapsulating and terminating packets of the management 750 protocols. For example, in MPLS-TP an single-hop LSP might be 751 established between two adjacent nodes, and that LSP might be 752 capable of carrying IP traffic. Management traffic can then be 753 inserted into the link in an LSP parallel to the LSPs that carry 754 user traffic. 756 This is a "physically shared out-of-band CC." 758 3. The CC may be supported as its native protocol on the 759 interface alongside the transported traffic. For example, if an 760 interface is capable of sending and receiving both MPLS-TP and 761 IP, the IP-based management traffic can be sent as native IP 762 packets on the interface. 764 This is a "shared interface out-of-band CC". 766 4. The CC may use overhead bytes available on a transport 767 connection. For example, in TDM networks there are overhead 768 bytes associated with a data channel, and these can be used to 769 provide a CC. It is important to note that the use of overhead 770 bytes does not reduce the capacity of the associated data 771 channel. 773 This is an "overhead-based CC". 775 This alternative is not available in MPLS-TP because there is no 776 overhead available. 778 5. The CC may provided by a dedicated channel associated with 779 the data link. For example, the generic associated label (GAL) 780 [15] may be used to label DCC traffic being exchanged on a data 781 link between adjacent transport nodes, potentially in the 782 absence of any data LSP between those nodes. 784 This is a "data link associated CC". 786 It is very similar to case 2, and by its nature can only span a 787 single hop in the transport network. 789 6. The CC may be provided by a dedicated channel associated with 790 a data channel. For example, in MPLS-TP the GAL [15] may be 791 imposed under the top label in the label stack for an MPLS-TP 792 LSP to create a channel associated with the LSP that may carry 793 management traffic. This CC requires the receiver to be capable 794 of demultiplexing management traffic from user traffic carried 795 on the same LSP by use of the GAL. 797 This is a "data channel associated CC". 799 7. The CC may be provided by mixing the management traffic with 800 the user traffic such that is indistinguishable on the link 801 without deep-packet inspection. In MPLS-TP this could arise if 802 there is a data-carrying LSP between two nodes, and management 803 traffic is inserted into that LSP. This approach requires that 804 the termination point of the LSP is able to demultiplex the 805 management and user traffic. Such might be possible in MPLS-TP 806 if the MPLS-TP LSP was carrying IP user traffic. 808 This is an "in-band CC". 810 These realizations may be categorized as: 812 A. Out-of-fiber, out-of-band (types 1 and 2) 813 B. In-fiber, out-of-band (types 2, 3, 4, and 5) 814 C. In-band (types 6 and 7) 816 The MCN and SCN are logically separate networks and may be 817 realized by the same DCN or as separate networks. In practice, 818 that means that, between any pair of nodes, the MCC and SCC may 819 be the same link or separate links. 821 It is also important to note that the MCN and SCN do not need to 822 be categorised as in-band, out-of-band, etc. This definition 823 only applies to the individual links, and it is possible for 824 some nodes to be connected in the MCN or SCN by one type of 825 link, and other nodes by other types of link. Furthermore, a 826 pair of adjacent nodes may be connected by multiple links of 827 different types. 829 Lastly note that the division of DCN traffic between links 830 between a pair of adjacent nodes is purely an implementation 831 choice. Parallel links may be deployed for DCN resilience or 832 load sharing. Links may be designated for specific use. For 833 example, so that some links carry management traffic and some 834 carry control plane traffic, or so that some links carry 835 signaling protocol traffic while others carry routing protocol 836 traffic. 838 It should be noted that the DCN may be a routed network with 839 forwarding capabilities, but that this is not a requirement. The 840 ability to support forwarding of management or control traffic 841 within the DCN may substantially simplify the topology of the 842 DCN and improve its resilience, but does increase the complexity 843 of operating the DCN. 845 See also RFC 3877 [10], ITU-T M.20 [11], and Telcordia document 846 GR-833-CORE [12] for further information.