idnits 2.17.1 draft-gray-mpls-tp-nm-req-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 839. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 815. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 822. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 828. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 3, 2008) is 5775 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4835 (ref. '10') (Obsoleted by RFC 7321) ** Obsolete normative reference: RFC 4306 (ref. '11') (Obsoleted by RFC 5996) ** Obsolete normative reference: RFC 4307 (ref. '12') (Obsoleted by RFC 8247) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 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: January, 2009 Scott Mansfield 5 Intended Status: Informational Eric Gray 6 Ericsson 7 July 3, 2008 9 MPLS TP Network Management Requirements 10 draft-gray-mpls-tp-nm-req-00.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that 15 any applicable patent or other IPR claims of which he or she is 16 aware have been or will be disclosed, and any of which he or she 17 becomes aware will be disclosed, in accordance with Section 6 of 18 BCP 79. 20 Internet-Drafts are working documents of the Internet 21 Engineering Task Force (IETF), its areas, and its working 22 groups. Note that other groups may also distribute working 23 documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other 27 documents at any time. It is inappropriate to use Internet- 28 Drafts as reference material or to cite them other than as "work 29 in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 This Internet-Draft will expire on January 3, 2009. 39 Abstract 41 This document specifies the network management requirements for 42 supporting the Transport Profile for Multi-Protocol Label 43 Switching (MPLS-TP). 45 Table of Contents 47 1. Introduction................................................3 48 1.1. Terminology............................................3 49 2. Management Architecture.....................................4 50 2.1. Network Management Architecture........................4 51 2.2. Element Management Architecture........................5 52 3. Management Channel Requirements.............................5 53 4. OAM Management Requirements.................................6 54 4.1. Standard Management Interfaces.........................7 55 5. Fault Management Requirements...............................7 56 5.1. Supervision Function...................................8 57 5.2. Validation Function....................................9 58 5.3. Alarm Handling Function...............................10 59 5.3.1. Alarm Severity Assignment........................10 60 5.3.2. Alarm Suppression................................10 61 5.3.3. Alarm Reporting Control..........................11 62 5.3.4. Alarm Reporting..................................11 63 6. Configuration Requirements.................................11 64 7. Performance Requirements...................................12 65 7.1. Path Characterization Performance Metrics.............12 66 7.2. SLA Performance Metrics...............................13 67 7.3. ATM/Ethernet/MPLS OAM Based Performance Metrics.......13 68 7.4. Performance Collection Instrumentation................13 69 7.4.1. Collection Frequency.............................13 70 7.4.2. Collection Granularity...........................13 71 8. Security Requirements......................................14 72 8.1. Management Communication Channel Security.............14 73 8.1.1. In-Band management security......................14 74 8.1.2. Out-of-Band management security..................15 75 8.2. Signaling Communication Channel Security..............15 76 8.3. Distributed Denial of Service.........................15 77 9. Accounting Requirements....................................15 78 10. Security Considerations...................................15 79 11. IANA Considerations.......................................15 80 12. Acknowledgments...........................................16 81 13. References................................................16 82 13.1. Normative References.................................16 83 13.2. Informative References...............................17 84 14. Author's Addresses........................................18 85 Intellectual Property Statement...............................18 86 Disclaimer of Validity........................................19 87 Copyright Statement...........................................19 88 Acknowledgment................................................19 90 1. Introduction 92 This document describes the requirements necessary to manage the 93 elements and networks that support a Transport Profile for MPLS. 94 These requirements are derived from the set of requirements 95 specified in ITU-T G.7710/Y.1701 [1], which addresses generic 96 management requirements for transport networks (including 97 packet-based and circuit-based). This document also leverages 98 the OAM requirements for MPLS Networks (RFC4377)[2] and MPLS-TP 99 Networks [3] documents and expands on the requirements to cover 100 the modifications necessary for configuration, performance, 101 fault, and security for the Transport Profile. 103 1.1. Terminology 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 106 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 107 "OPTIONAL" in this document are to be interpreted as described 108 in RFC 2119 [18]. 110 MPLS-TP NE: a network element (NE) that supports MPLS-TP 111 functions 113 MPLS-TP network: a network in which MPLS-TP NEs are deployed 115 Equipment Management Function (EMF): the management functions 116 within an NE. See ITU-T G.7710 [1]. 118 Data Communication Network (DCN): a network that supports Layer 119 1 (physical), Layer 2 (data-link), and Layer 3 (network) 120 functionality for distributed management communications related 121 to the management plane, for distributed signaling 122 communications related to the control plane, and other 123 operations communications (e.g., order-wire/voice 124 communications, software downloads, etc.). 126 Embedded Communication Channel (ECC): a logical operations 127 channel between network elements (NEs) that can be utilized by 128 multiple applications (e.g., management plane applications, 129 control plane applications, etc.). The physical channel 130 supporting the ECC is technology specific. An example of 131 physical channels supporting the ECC is a DCC channel within 132 SDH. 134 Management Communication Channel (MCC): a dedicated logical 135 operations channel between NEs for management communications. 136 The physical channel supporting the MCC is technology specific. 138 Signaling Communication Channel (SCC): a dedicated logical 139 operations channel between NEs for control plane communications. 140 This SCC MAY be used for GMPLS/ASON signaling and/or other 141 control plane messages like e.g., routing messages. The physical 142 channel supporting the SCC is technology specific. 144 Management Application Function (MAF): an application process 145 that participates in system management. Each NE and Operations 146 System (OS) MUST support a MAF. A MAF is the origin and 147 termination for all TMN messages. 149 2. Management Architecture 151 The management of the MPLS-TP network is based on a multi-tiered 152 distributed management systems as described in ITU-T M.3010 [20] 153 and M.3060 [21]. Each tier provides a predefined level of 154 network management capabilities. The lowest tier of this 155 organization model includes the MPLS-TP Network Element 156 Functions (NEFs) that provides the transport service and the 157 Operations System Functions (OSFs) at the Element Management 158 Level. The Management Application Function (MAF) within the NEFs 159 and OSFs provides the management support. The MAF at each entity 160 can include agents only, managers only, or both agents and 161 managers. Entities that include managers are capable of managing 162 other entities. 164 The management communication to peer NEFs and/or Operations 165 System Functions (OSFs) is provided via the Message 166 Communication Function (MCF) within each entity (e.g. NEF and 167 OSF). The user can access the management of the MPLS-TP 168 transport network via a Local Craft Terminal (LCT) attached to 169 the NEF or via a Work Station (WS) attached to the OSF. 171 2.1. Network Management Architecture 173 A transport Management Network (MN) MAY consist of several 174 transport-technology-specific Management Networks. The 175 management of the MPLS-TP network shall be separable from the 176 management of the other technology-specific networks. 178 A MPLS-TP Management Network MAY be partitioned into Management 179 SubNetworks (MSN). 181 The MPLS-TP MSN MAY be connected to other parts of the MN 182 through one or more Local Craft Terminals (via F-interface, see 183 M.3010) and/or Operations Systems (via Q-interface, see M.3010 184 [20]). The MCF of an MPLS-TP NE initiates/terminates, routes, or 185 otherwise processes management messages over ECCs or via an 186 external Q-interface or F-interface. 188 Multiple addressable MPLS-TP NEs MAY be present at a single 189 physical location (i.e. site or office). The inter-site 190 communications link between the MPLS-TP NEs will normally be 191 provided by the ECCs. Within a particular site, the NEs MAY 192 communicate via an intra-site ECC or via a LAN. 194 2.2. Element Management Architecture 196 The Equipment Management Function (EMF) of a MPLS-TP NE provides 197 the means through which a management system manages the NE. 198 Figure 5/G.7710 [1] illustrates examples of EMF components 199 within an NE. 201 The EMF interacts with the NE's transport functions and control 202 functions (i.e., control plane functions that reside in the NE) 203 by exchanging Management Information (MI) across the Management 204 Point (MP) Reference Points. The EMF contains a number of 205 functions that provide a data reduction mechanism on the 206 information received across the MP Reference Points. 208 The EMF includes functions such as Date & Time and the FCAPS 209 (Fault, Configuration, Accounting, Performance and Security) 210 management functions. The EMF provides event message processing, 211 data storage and logging. The management Agent, a component of 212 the EMF, converts internal management information (MI signals) 213 into Management Application messages and vice versa. The Agent 214 responds to Management Application messages from the Message 215 Communications Function (MCF) by performing the appropriate 216 operations on the Managed Objects in a Management Information 217 Base (MIB), as necessary. The MCF contains communications 218 functions related to the outside world of the NE (i.e. Date & 219 Time source, Management Plane, Control Plane, Local Craft 220 Terminal and Local Alarms). 222 The Date & Time functions keep track of the NE's date/time which 223 is used by the FCAPS management functions to e.g. time stamp 224 event reports. 226 3. Management Channel Requirements 228 The Embedded Communication Channel (ECC) provides a logical 229 operations channel between NEs for transferring Management 230 and/or Signaling information. Note that some technologies 231 provide separate communication channels for Management (MCC) and 232 Signaling (SCC). In this document, whenever the generic term ECC 233 is used, it mainly focuses on the utilization of the ECC for 234 Management (i.e., MCC only). 236 This document places no restriction on the physical topology of 237 the MN to support management communications. However, the MPLS- 238 TP MN SHOULD support seamless connectivity with remote transport 239 domains and NEs as specified in ITU-T G.8601 [22] as well as 240 with termination points located in NEs under control by a third 241 party network operator as specified in G.8601. 243 See ITU-T G.7712/Y.1703 [19] for management DCN's architecture 244 and specifications, including network layer protocol. 246 Each MPLS-TP MSN MUST have at least one MPLS-TP NE which is 247 connected to an OS (possibly via a Mediation Device). This NE is 248 called a Gateway Network Element (GNE). The GNE SHOULD be able 249 to perform an intermediate system network layer routing function 250 for ECC messages destined for any end system in the MSN. 251 Messages passing between the OS and any of the end systems in 252 the subnetwork are routed through the GNE and, in general, other 253 intermediate systems. 255 MPLS-TP NEs communicate via the DCN. In order to have the DCN 256 operate properly, a number of management functions are required. 257 Examples are: 259 . Retrieval of network parameters to ensure compatible 260 functioning, e.g. packet size, timeouts, quality of 261 service, window size, etc.; 263 . Establishment of message routing between DCN nodes; 265 . Management of network addresses; 267 . Retrieval of operational status of the DCN at a given node; 269 . Capability to enable/disable access to the DCN. 271 4. OAM Management Requirements 273 The purpose of the Operation and Maintenance (OAM) functionality 274 is to maintain the integrity of the network and to ensure that 275 the transport service is compliant with the committed Service 276 Level Agreement (SLA). 278 [3] specifies the requirements for the OAM functionality that 279 are deployed in the transport plane to maintain the integrity of 280 the client signal between ingress and egress ports of the MPLS- 281 TP network. These OAM functionalities are sometimes called 282 "Horizontal OAM". 284 There are OAM functionalities that are deployed in the 285 management plane to support maintaining the overall network 286 integrity and achieving the SLA. These OAM functionalities are 287 sometimes called "Vertical OAM" or OAM&P (Operation, 288 Administration, Maintenance, & Provisioning), in the sense that 289 they involves higher level systems, such as element management 290 systems (EMS), network management systems (NMS), and/or service 291 management systems (SMS). Examples of vertical OAM functions 292 include hardware provisioning, software configuration, alarm 293 notification/retrieval, performance monitoring (PM) data 294 collection & reporting. 296 Note that management of horizontal OAM parameters is also part 297 of the vertical OAM function. Regardless what specific 298 horizontal OAM mechanisms (tools) will be deployed in the 299 transport plane, these mechanisms (tools) need to be managed 300 (e.g. configured and monitored) to ensure their proper 301 functioning. The management requirements for the horizontal OAM 302 mechanisms will be specified in the subsequence sections, along 303 with the vertical OAM management requirements. 305 4.1. Standard Management Interfaces 307 This document places no restriction on which management 308 interface to be used for managing an MPLS-TP network. It is 309 allowed to provision and manage an end-to-end connection across 310 a network where some segments are created/managed/deleted, for 311 examples by netconf or snmp and other segments by XML or CORBA 312 interfaces. It is allowed to run maintenance on a connection 313 independent of the mechanism used to establish the connection. 314 An MPLS-TP NE is not required to offer more than one standard 315 management interface. 317 5. Fault Management Requirements 319 The Fault Management functions within the EMF of an MPLS-TP NE 320 enable the supervision, detection, validation, isolation, 321 correction, and reporting of abnormal operation of the MPLS-TP 322 network and its environment. 324 5.1. Supervision Function 326 The supervision function analyses the actual occurrence of a 327 disturbance or fault for the purpose of providing an appropriate 328 indication of performance and/or detected fault condition to 329 maintenance personnel and operations systems. 331 The MPLS-TP NE shall support the following types of supervision: 333 A) Transmission supervision: 335 . Continuity supervision for the detection of a broken 336 connection; 338 . Connectivity supervision for the detection of a 339 misconnection; 341 . Looping supervision for unintended self-replication; 343 . Alarm suppression based on native OAM, e.g., AIS (Alarm 344 Indication Signal) and FDI (Forward Defect Indication) 346 . Lock indication supervision; 348 . Packet loss measurement in both directions of the 349 bidirectional connection; 351 . Misinsertion supervision for misinserted packet in the 352 connection 354 . Diagnostic test supervision; 356 . Route trace supervision; 358 . Remote defect indication supervision; 360 . Protocol supervision for the detection of failure in 361 the sequence of a protocol exchange (e.g. automatic 362 protection switching protocol); 364 The transmission supervision mechanisms MUST support the 365 flexibility to be configured to perform on-demand or 366 proactively. 368 B) Software Processing Supervision for software or software 369 processing fault, such as storage capacity problem, version 370 mismatch, Corrupted data, Out of memory, etc. 372 C) Hardware Supervision for interchangeable and non- 373 interchangeable units, cable, and power problem. 375 D) Environment Supervision for temperature, humidity, etc. 377 The following requirements related to defect detection specified 378 in RFC 4377 [2] are applicable for MPLS-TP NE. 380 . The ability to detect defects in a broken connection 381 (LSP, PW) MUST NOT require manual hop-by-hop 382 troubleshooting of each node used to switch traffic for 383 that connection. 385 . The automation of path liveliness is desired in cases 386 where large numbers of connections might be tested. 388 . Synchronization of detection time bounds by tools used to 389 detect broken connections is required. 391 . Any detection mechanisms that depend on receiving the 392 status via a return path SHOULD provide multiple return 393 options with the expectation that one of them will not be 394 impacted by the original defect. 396 . The OAM packet for defect detection MUST follow the 397 customer data path exactly in order to reflect path 398 liveliness used by customer data. 400 . Defect SHOULD be detected by the network operator prior 401 to the customers of the service in question detecting 402 them. 404 . Recovery of service from faults MAY be automatically 405 taken according to the type of fault. 407 5.2. Validation Function 409 Validation is concerned with the integration of Fault Causes 410 into Failures. A Fault Cause indicates a limited interruption of 411 the required function. A Fault Cause is not reported to 412 maintenance personnel because it could exist only for a very 413 short time. Some of these events however are summed up in the 414 Performance Monitoring process, and when this sum exceeds a 415 certain value, a Threshold Report can be generated. 417 When the Fault Cause lasts long enough, an inability to perform 418 the required function arises. This Failure condition is subject 419 to be alarmed to maintenance personnel because corrective action 420 might be required. Conversely, when the Fault Cause ceases after 421 a certain time, the Failure condition MUST disappear. 423 The EMF within the MPLS-TP NE MUST perform a persistency check 424 on the fault causes before it declares a fault cause a failure. 426 A transmission failure shall be declared if the fault cause 427 persists continuously for 2.5 +/- 0.5 sec. The failure shall be 428 cleared if the fault cause is absent continuously for 10 +/- 0.5 429 sec. 431 The failure declaration and clearing MUST be time stamped. The 432 time-stamp shall indicate the time at which the fault cause is 433 activated at the input of the fault cause persistency (i.e. 434 defect-to-failure integration) function, and the time at which 435 the fault cause is deactivated at the input of the fault cause 436 persistency function. 438 5.3. Alarm Handling Function 440 5.3.1. Alarm Severity Assignment 442 Failures MAY have been categorized to indicate the severity or 443 urgency of the fault. The MPLS-TP NE SHOULD support the 444 flexibility of assignment of severity (e.g., Critical, Major, 445 Minor, Warning) by the management system. 447 See G.7710 [1] for more description. 449 5.3.2. Alarm Suppression 451 An MPLS-TP NE MUST provide alarm suppression functionality that 452 prevents the generation of a superfluous generation of alarms, 453 e.g., by simply discarding them (or not generating them in the 454 first place), or by aggregating them together, thereby greatly 455 reducing the number of notifications emitted. 457 An MPLS-TP NE supporting the inter-working of one or more 458 networking technologies (e.g., Ethernet, SDH/SONET, OTN, MPLS) 459 over MPLS-TP MUST be able to translate an MPLS-TP defect into 460 the native technology's error condition. 462 See RFC 4377 [2] for more description. 464 5.3.3. Alarm Reporting Control 466 Alarm Reporting Control (ARC) supports an automatic in-service 467 provisioning capability. Alarm reporting MAY be turned off on a 468 per-managed entity basis to allow sufficient time for customer 469 service testing and other maintenance activities in an "alarm 470 free" state. Once a managed entity is ready, alarm reporting is 471 automatically turned on (to ALM). 473 See G.7710 [1] for more description. 475 5.3.4. Alarm Reporting 477 Alarm Reporting is concerned with the reporting of relevant 478 events and conditions, which occur in the network (including the 479 NE, incoming signal, and external environment). 481 The MPLS-TP NE MUST support local reporting of alarms. Local 482 reporting is concerned with automatic alarming by means of 483 audible and visual indicators near the failed equipment. 485 The MPLS-TP NE MUST support reporting of alarms to an OS. These 486 reports are either autonomous reports (notifications) or reports 487 on request by maintenance personnel. 489 6. Configuration Requirements 491 Configuration Management provides functions to exercise control 492 over, identify, collect data from, and provide data to NEs. 493 Generic configuration management requirements for transport 494 network are specified in G.7710 [1], for examples hardware, 495 software, protection switching, alarm reporting control, and 496 date/time. 498 The EMF of the MPLS-TP NE MUST support the capability of 499 configuring the OAM functions as part of connectivity 500 management, including bidirectional point-to-point connection, 501 uni-directional point-to-point connection, and uni-directional 502 point-to-multipoint connection. 504 The EMF of the MPLS-TP NE MUST have the flexibility to configure 505 OAM parameters to meet their specific operational requirements, 506 such as whether (1) one-time on-demand or (2) periodically based 507 on a specified frequency. 509 The EMF of the MPLS-TP NE MUST support the capability to choose 510 which OAM functions to use and which maintenance entity to apply 511 them. 513 The EMF of the MPLS-TP NE MUST support the configuration of 514 maintenance entity identifiers (e.g. MEP ID and MIP ID) for the 515 purpose of connection connectivity checking. The connectivity 516 check process of the MPLS-TP NE needs to be provisioned with the 517 identifiers to transmit, the expected identifiers, and 518 enable/disable the connectivity check processing. 520 The EMF of the MPLS-TP NE MUST support retrieval of the details 521 of the NE's path forwarding operations. These details can then 522 be compared during subsequent testing relevant to OAM 523 functionality. 525 7. Performance Requirements 527 Performance Management provides functions to evaluate and report 528 upon the behavior of the equipment, NE, and network for the 529 purpose of Maintenance, Bring-into-service, Quality of service, 530 and Performance monitoring for signal degradation. Generic 531 requirements for packet-switched and circuit-switched transport 532 networks are specified in G.7710 [1] with the objective of 533 providing coherent and consistent interpretation of the network 534 behavior, in particular for hybrid network which consists of 535 multiple transport technologies. The performance management 536 requirements specified in this document are driven by such an 537 objective. 539 7.1. Path Characterization Performance Metrics 541 Packet loss measurement and delay measurement MUST be collected 542 so that they can be used to detect performance degradation. 544 Performance degradation MUST be reported via fault management 545 for corrective actions (e.g. protection switch). 547 Performance degradation MUST be reported via performance 548 monitoring, e.g. as Errored Second (ES), Severely Errored Second 549 (SES), and Unavailable Second (UAS), for Service Level Agreement 550 (SLA) verification and billing. 552 An ES is declared when, during one second period, there is one 553 or more Errored Blocks (EBs) detected, or when a defect is 554 declared. In a packet layer, a block is a packet. An EB is an 555 indication of a lost packet. 557 A SES is declared when, during one second, the number of EBs 558 exceeds a threshold, or when a defect is declared. 560 The number of SESs (and ESs) is summed over 15-minute and 24- 561 hour intervals. 563 A Background Block Error (BBE) is an EB not occurring as part of 564 a SES. 566 The number of BBEs is summed over 15-minute and 24-hour 567 intervals, over which the trend analysis is performed. 569 A period of unavailable time (UAT) begins at the onset of 10 570 consecutive SES events. These 10 seconds are considered to be 571 part of unavailable time. A new period of available time begins 572 at the onset of 10 consecutive non-SES events. These 10 seconds 573 are considered to be part of available time. 575 The number of unavailable time in seconds (UAS) is summed over 576 15-minute and 24-hour intervals. 578 7.2. SLA Performance Metrics 580 TBD 582 7.3. ATM/Ethernet/MPLS OAM Based Performance Metrics 584 TBD 586 7.4. Performance Collection Instrumentation 588 7.4.1. Collection Frequency 590 The performance collection mechanisms MUST support the 591 flexibility to be configured to operate on-demand or 592 proactively. 594 7.4.2. Collection Granularity 596 On Packet loss measurement: 598 - For bidirectional (P2P) connection, collection of on-demand 599 single-ended packet loss measurement is required. 601 - For bidirectional (P2P) connection, collection of proactive 602 packet loss measurements for both directions is required. 604 - For unidirectional (P2P and P2MP) connection, collection of 605 proactive packet loss measurement is required. 607 On Delay measurement: 609 - For unidirectional (P2P and P2MP) connection, collection of 610 on-demand delay measurement is required. 612 - For bidirectional (P2P) connection, collection of on-demand 613 one-way and two-way delay measurement is required. 615 8. Security Requirements 617 The EMF of the MPLS-TP NE MUST support the ability to detect 618 denial of service (DoS) attacks against the transport plane and 619 control plane. 621 8.1. Management Communication Channel Security 623 Secure channels MUST be provided for all network traffic and 624 protocols used to support management functions. This MUST 625 include, at least, protocols used for configuration, monitoring, 626 configuration backup, logging, time synchronization, 627 authentication, and routing. The MCC MUST support application 628 protocols that provide confidentiality and data integrity 629 protection. IPsec and IKE protocols according to RFC 2403 [4], 630 RFC 2405 [5], RFC 4301-4309 ([6], [7], [8], [9], [10], [11], 631 [12], [13], [14]), and RFC 4312 [15] MUST be supported for IPv6. 632 For IPv4, IPsec MUST be supported. 634 8.1.1. In-Band management security 636 If in-band management is provided, the MCC MUST require the 637 following: 639 - Use of open cryptographic algorithms (See RFC 3871 [17] 640 section 4.5) 642 - Authentication 644 - Allow management connectivity only from authorized IP 645 addresses or MAC Addresses. 647 8.1.2. Out-of-Band management security 649 The MPLS TP NE MUST support an out-of-band management console 650 port. The management traffic MUST remain separate from the data 651 and control plane traffic (no routing or forwarding between the 652 management plane and the data/control plane). 654 8.2. Signaling Communication Channel Security 656 Secure control plane protocols MAY be used in place of their 657 insecure counterparts. If an insecure protocol is used, the 658 transport layer protocol MAY be used to secure the SCC. 660 8.3. Distributed Denial of Service 662 A Distributed Denial of Service (DDOS) attack is an attempt to 663 hinder the target from performing its assigned task by 664 overloading the target with spurious requests. It is possible 665 to lessen the impact and potential for DDOS by using secure 666 protocols, turning off unnecessary processes, logging and 667 monitoring, and ingress filtering. RFC 4732 [16] provides 668 background on DOS in the context of the Internet. 670 9. Accounting Requirements 672 TBD 674 10. Security Considerations 676 Provisions to any of the network mechanisms designed to satisfy 677 the requirements described herein are required to prevent their 678 unauthorized use. Likewise, these network mechanisms MUST 679 provide a means by which an operator can prevent denial of 680 service attacks if those network mechanisms are used in such an 681 attack. 683 The performance of diagnostic functions and path 684 characterization involve extracting a significant amount of 685 information about network construction that the network operator 686 MAY consider private. 688 11. IANA Considerations 690