idnits 2.17.1 draft-gray-mpls-tp-nm-req-01.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 822. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 798. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 805. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 811. 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 (October 8, 2008) is 5676 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 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: April, 2009 Scott Mansfield 5 Intended Status: Informational Eric Gray 6 Ericsson 7 October 8, 2008 9 MPLS TP Network Management Requirements 10 draft-gray-mpls-tp-nm-req-01.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 8, 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 2.3. Standard Management Interfaces.........................6 53 3. Management Channel Requirements.............................6 54 4. OAM Management Requirements.................................7 55 5. Fault Management Requirements...............................8 56 5.1. Supervision Function...................................8 57 5.2. Validation Function...................................10 58 5.3. Alarm Handling Function...............................11 59 5.3.1. Alarm Severity Assignment........................11 60 5.3.2. Alarm Suppression................................11 61 5.3.3. Alarm Reporting Control..........................11 62 5.3.4. Alarm Reporting..................................11 63 6. Configuration Requirements.................................12 64 7. Performance Requirements...................................12 65 7.1. Path Characterization Performance Metrics.............13 66 7.2. SLA Performance Metrics...............................14 67 7.3. ATM/Ethernet/MPLS OAM Based Performance Metrics.......14 68 7.4. Performance Collection Instrumentation................14 69 7.4.1. Collection Frequency.............................14 70 7.4.2. Collection Granularity...........................14 71 8. Security Requirements......................................14 72 8.1. Management Communication Channel Security.............14 73 8.1.1. In-Band management security......................15 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. Security Considerations....................................16 78 10. IANA Considerations.......................................16 79 11. Acknowledgments...........................................16 80 12. References................................................16 81 12.1. Normative References.................................16 82 12.2. Informative References...............................17 83 13. Author's Addresses........................................17 84 Intellectual Property Statement...............................18 85 Disclaimer of Validity........................................18 86 Copyright Statement...........................................18 87 Acknowledgment................................................19 89 1. Introduction 91 This document describes the requirements necessary to manage the 92 elements and networks that support a Transport Profile for MPLS. 93 These requirements are derived from the set of requirements 94 specified in ITU-T G.7710/Y.1701 [1], which addresses generic 95 management requirements for transport networks (including 96 packet-based and circuit-based). This document also leverages 97 the OAM requirements for MPLS Networks (RFC4377)[2] and MPLS-TP 98 Networks [3] documents and expands on the requirements to cover 99 the modifications necessary for configuration, performance, 100 fault, and security for the Transport Profile. 102 1.1. Terminology 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 105 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 106 "OPTIONAL" in this document are to be interpreted as described 107 in RFC 2119 [6]. 109 MPLS-TP NE: a network element (NE) that supports MPLS-TP 110 functions 112 MPLS-TP network: a network in which MPLS-TP NEs are deployed 114 Equipment Management Function (EMF): the management functions 115 within an NE. See ITU-T G.7710 [1]. 117 Data Communication Network (DCN): a network that supports Layer 118 1 (physical), Layer 2 (data-link), and Layer 3 (network) 119 functionality for distributed management communications related 120 to the management plane, for distributed signaling 121 communications related to the control plane, and other 122 operations communications (e.g., order-wire/voice 123 communications, software downloads, etc.). A DCN supporting 124 management communication is referred to as a Management 125 Communication Network (MCN). A DCN supporting signaling 126 communication is referred to as a Signaling Communication 127 Network (SCN). 129 Embedded Communication Channel (ECC): a logical operations 130 channel between network elements (NEs) that can be utilized by 131 multiple applications (e.g., management plane applications, 132 control plane applications, etc.). The physical channel 133 supporting the ECC is technology specific. An example of 134 physical channels supporting the ECC is a DCC channel within 135 SDH. 137 Management Communication Channel (MCC): a dedicated logical 138 operations channel between NEs for management plane 139 communications. The physical channel supporting the MCC is 140 technology specific. 142 Signaling Communication Channel (SCC): a dedicated logical 143 operations channel between NEs for control plane communications. 144 This SCC MAY be used for GMPLS/ASON signaling and/or other 145 control plane messages like e.g., routing messages. The physical 146 channel supporting the SCC is technology specific. 148 Management Application Function (MAF): an application process 149 that participates in system management. Each NE and Operations 150 System (OS) MUST support a MAF. A MAF is the origin and 151 termination for all TMN messages. 153 2. Management Architecture 155 The management of the MPLS-TP network is based on a multi-tiered 156 distributed management systems as described in ITU-T M.3010 [8] 157 and M.3060 [9]. Each tier provides a predefined level of network 158 management capabilities. The lowest tier of this organization 159 model includes the MPLS-TP Network Element Functions (NEFs) that 160 provides the transport service and the Operations System 161 Functions (OSFs) at the Element Management Level. The Management 162 Application Function (MAF) within the NEFs and OSFs provides the 163 management support. The MAF at each entity can include agents 164 only, managers only, or both agents and managers. MAFs that 165 include managers are capable of managing an agent included in 166 other MAFs. 168 The management communication to peer NEFs and/or Operations 169 System Functions (OSFs) is provided via the Message 170 Communication Function (MCF) within each entity (e.g. NEF and 171 OSF). The user can access the management of the MPLS-TP 172 transport network via a Local Craft Terminal (LCT) attached to 173 the NEF or via a Work Station (WS) attached to the OSF. 175 2.1. Network Management Architecture 177 A transport Management Network (MN) MAY consist of several 178 transport-technology-specific Management Networks. Notation used 179 in G.7710 ([1]) for a transport-technology-specific MN is x.MN, 180 where x is the transport specific technology. For example, a 181 MPLS-TP specific MN might be MPLS-TP.MN (this was previously TM- 182 MN for T-MPLS specific MN). Where there is no ambiguity, we 183 will use "MN" for an MPLS-TP specific MN, and "MPLS-TP.MN" (or 184 "MPLS-TP MN") and "MN" where both are used in a given context. 186 The management of the MPLS-TP network SHALL be separable from 187 the management of the other technology-specific networks, and 188 operate independently of any particular client or server layer 189 management plane. 191 A MPLS-TP Management Network MAY be partitioned into MPLS-TP 192 Management SubNetworks ("MPLS-TP.MSN" or "MPLS-TP MSN", or just 193 "MSN" where usage is unambiguous). 195 The MPLS-TP MSN MAY be connected to other parts of the MN 196 through one or more Local Craft Terminals (via F-interface, see 197 M.3010) and/or Operations Systems (via Q-interface, see M.3010 198 [8]). The MCF of an MPLS-TP NE initiates/terminates, routes, or 199 otherwise processes management messages over ECCs or via an 200 external Q-interface or F-interface. 202 Multiple addressable MPLS-TP NEs MAY be present at a single 203 physical location (i.e. site or office). The inter-site 204 communications link between the MPLS-TP NEs will normally be 205 provided by the ECCs. Within a particular site, the NEs MAY 206 communicate via an intra-site ECC or via a LAN. 208 2.2. Element Management Architecture 210 The Equipment Management Function (EMF) of a MPLS-TP NE provides 211 the means through which a management system manages the NE. 212 Figure 5/G.7710 [1] illustrates examples of EMF components 213 within an NE. 215 The EMF interacts with the NE's transport functions and control 216 functions (i.e., control plane functions that reside in the NE) 217 by exchanging Management Information (MI) across the Management 218 Point (MP) Reference Points. The EMF MAY contain a number of 219 functions that provide a data reduction mechanism on the 220 information received across the MP Reference Points. 222 The EMF includes functions such as Date & Time and the FCAPS 223 (Fault, Configuration, Accounting, Performance and Security) 224 management functions. The EMF provides event message processing, 225 data storage and logging. The management Agent, a component of 226 the EMF, converts internal management information (MI signals) 227 into Management Application messages and vice versa. The Agent 228 responds to Management Application messages from the Message 229 Communications Function (MCF) by performing the appropriate 230 operations on (for example) the Managed Objects in a Management 231 Information Base (MIB), as necessary. The MCF contains 232 communications functions related to the outside world of the NE 233 (i.e. Date & Time source, Management Plane, Control Plane, Local 234 Craft Terminal and Local Alarms). 236 The Date & Time functions keep track of the NE's date/time which 237 is used by the FCAPS management functions to e.g. time stamp 238 event reports. 240 2.3. Standard Management Interfaces 242 This document places no restriction on which management 243 interface to be used for managing an MPLS-TP network. It is 244 possible to provision and manage an end-to-end connection 245 across a network where some segments are 246 created/managed/deleted, for example by netconf/XML or snmp/smi 247 and other segments by CORBA/IDL interfaces. Use of any network 248 management interface for one management related purpose does 249 not preclude use of another network management interface for 250 other management related purposes, or the same purpose at 251 another time However, an MPLS-TP NE is not required to offer 252 more than one standard management interface. 254 3. Management Channel Requirements 256 The Embedded Communication Channel (ECC) provides a logical 257 operations channel between NEs for transferring Management 258 and/or Signaling information. Note that some technologies 259 provide separate communication channels for Management (MCC) and 260 Signaling (SCC). 262 This document places no restriction on the physical topology of 263 the MN to support management communications. However, the MPLS- 264 TP MN SHOULD support seamless connectivity with remote transport 265 domains and NEs as specified in ITU-T G.8601 [10] as well as 266 with termination points located in NEs under control by a third 267 party network operator as specified in G.8601. 269 Each MPLS-TP MSN MUST have at least one MPLS-TP NE which is 270 connected to an OS (possibly via a Mediation Device). This NE is 271 called a Gateway Network Element (GNE). The GNE SHOULD be able 272 to perform an intermediate system network layer routing function 273 for ECC messages destined for any end system in the MSN. 274 Messages passing between the OS and any of the end systems in 275 the subnetwork are routed through the GNE and, in general, other 276 intermediate systems. 278 MPLS-TP NEs communicate via the DCN. The DCN connects NEs with 279 management systems, NEs with NEs, and management systems with 280 management systems. DCN architecture and requirements are 281 specified in ITU-T G.7712/Y.1703 [7], including network layer 282 protocols and their interworking. In order to have the DCN 283 operate properly, a number of management functions are required. 284 Examples are: 286 . Retrieval of network parameters to ensure compatible 287 functioning, e.g. packet size, timeouts, quality of 288 service, window size, etc.; 290 . Establishment of message routing between DCN nodes; 292 . Management of network addresses; 294 . Retrieval of operational status of the DCN at a given node; 296 . Capability to enable/disable access to the DCN. 298 4. OAM Management Requirements 300 302 The purpose of the Operation and Maintenance (OAM) functionality 303 is to maintain the integrity of the network and to ensure that 304 the transport service is compliant with the committed Service 305 Level Agreement (SLA). 307 [3] specifies the requirements for the OAM functionality that 308 are deployed in the transport plane to maintain the integrity of 309 the client signal between ingress and egress ports of the MPLS- 310 TP network. These OAM functionalities are sometimes called 311 "Horizontal OAM". 313 There are OAM functionalities that are deployed in the 314 management plane to support maintaining the overall network 315 integrity and achieving the SLA. These OAM functionalities are 316 sometimes called "Vertical OAM" or OAM&P (Operation, 317 Administration, Maintenance, & Provisioning), in the sense that 318 they involves higher level systems, such as element management 319 systems (EMS), network management systems (NMS), and/or service 320 management systems (SMS). Examples of vertical OAM functions 321 include hardware provisioning, software configuration, alarm 322 notification/retrieval, performance monitoring (PM) data 323 collection & reporting. 325 Note that management of horizontal OAM parameters is also part 326 of the vertical OAM function. Regardless what specific 327 horizontal OAM mechanisms (tools) will be deployed in the 328 transport plane, these mechanisms (tools) need to be managed 329 (e.g. configured and monitored) to ensure their proper 330 functioning. The management requirements for the horizontal OAM 331 mechanisms will be specified in the subsequence sections, along 332 with the vertical OAM management requirements. 334 5.Fault Management Requirements 336 The Fault Management functions within the EMF of an MPLS-TP NE 337 enable the supervision, detection, validation, isolation, 338 correction, and reporting of abnormal operation of the MPLS-TP 339 network and its environment. 341 5.1. Supervision Function 343 The supervision function analyses the actual occurrence of a 344 disturbance or fault for the purpose of providing an appropriate 345 indication of performance and/or detected fault condition to 346 maintenance personnel and operations systems. 348 The MPLS-TP NE shall support the following types of supervision: 350 A) Transmission supervision: 352 . Continuity supervision for the detection of a broken 353 connection; 355 . Connectivity supervision for the detection of a 356 misconnection; 358 . Looping supervision for unintended self-replication; 360 . Alarm suppression based on native OAM, e.g., AIS (Alarm 361 Indication Signal) and FDI (Forward Defect Indication) 363 . Lock indication supervision; 365 . Packet loss measurement in both directions of the 366 bidirectional connection; 368 . Misinsertion supervision for misinserted packet in the 369 connection 371 . Diagnostic test supervision; 373 . Route trace supervision; 375 . Remote defect indication supervision; 377 . Protocol supervision for the detection of failure in 378 the sequence of a protocol exchange (e.g. automatic 379 protection switching protocol); 381 The transmission supervision mechanisms MUST support the 382 flexibility to be configured to perform on-demand or 383 proactively. 385 B) Software Processing Supervision for software or software 386 processing fault, such as storage capacity problem, version 387 mismatch, Corrupted data, Out of memory, etc. 389 C) Hardware Supervision for interchangeable and non- 390 interchangeable units, cable, and power problem. 392 D) Environment Supervision for temperature, humidity, etc. 394 The following requirements related to defect detection specified 395 in RFC 4377 [2] are applicable for MPLS-TP NE. 397 . The ability to detect defects in a broken connection 398 (LSP, PW) MUST NOT require manual hop-by-hop 399 troubleshooting of each node used to switch traffic for 400 that connection. 402 . The automation of path liveliness is desired in cases 403 where large numbers of connections might be tested. 405 . Synchronization of detection time bounds by tools used to 406 detect broken connections is required. 408 . Any detection mechanisms that depend on receiving the 409 status via a return path SHOULD provide multiple return 410 options with the expectation that one of them will not be 411 impacted by the original defect. 413 . The OAM packet for defect detection MUST follow the 414 customer data path exactly in order to reflect path 415 liveliness used by customer data. 417 . Defect SHOULD be detected by the network operator prior 418 to the customers of the service in question detecting 419 them. 421 . Recovery of service from faults MAY be automatically 422 taken according to the type of fault. 424 5.2. Validation Function 426 Validation is concerned with the integration of Fault Causes 427 into Failures. A Fault Cause indicates a limited interruption of 428 the required function. A Fault Cause is not reported to 429 maintenance personnel because it could exist only for a very 430 short time. Some of these events however are summed up in the 431 Performance Monitoring process, and when this sum exceeds a 432 certain value, a Threshold Report can be generated. 434 When the Fault Cause lasts long enough, an inability to perform 435 the required function arises. This Failure condition is subject 436 to be alarmed to maintenance personnel because corrective action 437 might be required. Conversely, when the Fault Cause ceases after 438 a certain time, the Failure condition MUST disappear. 440 The EMF within the MPLS-TP NE MUST perform a persistency check 441 on the fault causes before it declares a fault cause a failure. 443 A transmission failure shall be declared if the fault cause 444 persists continuously for 2.5 +/- 0.5 sec. The failure shall be 445 cleared if the fault cause is absent continuously for 10 +/- 0.5 446 sec. 448 The failure declaration and clearing MUST be time stamped. The 449 time-stamp shall indicate the time at which the fault cause is 450 activated at the input of the fault cause persistency (i.e. 451 defect-to-failure integration) function, and the time at which 452 the fault cause is deactivated at the input of the fault cause 453 persistency function. 455 5.3. Alarm Handling Function 457 5.3.1. Alarm Severity Assignment 459 Failures MAY have been categorized to indicate the severity or 460 urgency of the fault. The MPLS-TP NE SHOULD support the 461 flexibility of assignment of severity (e.g., Critical, Major, 462 Minor, Warning) by the management system. 464 See G.7710 [1] for more description. 466 5.3.2. Alarm Suppression 468 An MPLS-TP NE MUST provide alarm suppression functionality that 469 prevents the generation of a superfluous generation of alarms, 470 e.g., by simply discarding them (or not generating them in the 471 first place), or by aggregating them together, thereby greatly 472 reducing the number of notifications emitted. 474 An MPLS-TP NE supporting the inter-working of one or more 475 networking technologies (e.g., Ethernet, SDH/SONET, OTN, MPLS) 476 over MPLS-TP MUST be able to translate an MPLS-TP defect into 477 the native technology's error condition. 479 See RFC 4377 [2] for more description. 481 5.3.3. Alarm Reporting Control 483 Alarm Reporting Control (ARC) supports an automatic in-service 484 provisioning capability. Alarm reporting MAY be turned off on a 485 per-managed entity basis to allow sufficient time for customer 486 service testing and other maintenance activities in an "alarm 487 free" state. Once a managed entity is ready, alarm reporting is 488 automatically turned on (to ALM). 490 See G.7710 [1] for more description. 492 5.3.4. Alarm Reporting 494 Alarm Reporting is concerned with the reporting of relevant 495 events and conditions, which occur in the network (including the 496 NE, incoming signal, and external environment). 498 The MPLS-TP NE MUST support local reporting of alarms. Local 499 reporting is concerned with automatic alarming by means of 500 audible and visual indicators near the failed equipment. 502 The MPLS-TP NE MUST support reporting of alarms to an OS. These 503 reports are either autonomous reports (notifications) or reports 504 on request by maintenance personnel. 506 6. Configuration Requirements 508 Configuration Management provides functions to exercise control 509 over, identify, collect data from, and provide data to NEs. 510 Generic configuration management requirements for transport 511 network are specified in G.7710 [1], for examples hardware, 512 software, protection switching, alarm reporting control, and 513 date/time. 515 The EMF of the MPLS-TP NE MUST support the capability of 516 configuring the OAM functions as part of connectivity 517 management, including bidirectional point-to-point connection, 518 uni-directional point-to-point connection, and uni-directional 519 point-to-multipoint connection. 521 The EMF of the MPLS-TP NE MUST have the flexibility to configure 522 OAM parameters to meet their specific operational requirements, 523 such as whether (1) one-time on-demand or (2) periodically based 524 on a specified frequency. 526 The EMF of the MPLS-TP NE MUST support the capability to choose 527 which OAM functions to use and which maintenance entity to apply 528 them. 530 The EMF of the MPLS-TP NE MUST support the configuration of 531 maintenance entity identifiers (e.g. MEP ID and MIP ID) for the 532 purpose of connection connectivity checking. The connectivity 533 check process of the MPLS-TP NE needs to be provisioned with the 534 identifiers to transmit, the expected identifiers, and 535 enable/disable the connectivity check processing. 537 The EMF of the MPLS-TP NE MUST support retrieval of the details 538 of the NE's path forwarding operations. These details can then 539 be compared during subsequent testing relevant to OAM 540 functionality. 542 7. Performance Requirements 544 Performance Management provides functions to evaluate and report 545 upon the behavior of the equipment, NE, and network for the 546 purpose of Maintenance, Bring-into-service, Quality of service, 547 and Performance monitoring for signal degradation. Generic 548 requirements for packet-switched and circuit-switched transport 549 networks are specified in G.7710 [1] with the objective of 550 providing coherent and consistent interpretation of the network 551 behavior, in particular for hybrid network which consists of 552 multiple transport technologies. The performance management 553 requirements specified in this document are driven by such an 554 objective. 556 7.1. Path Characterization Performance Metrics 558 Packet loss measurement and delay measurement MUST be collected 559 so that they can be used to detect performance degradation. 561 Performance degradation MUST be reported via fault management 562 for corrective actions (e.g. protection switch). 564 Performance degradation MUST be reported via performance 565 monitoring, e.g. as Errored Second (ES), Severely Errored Second 566 (SES), and Unavailable Second (UAS), for Service Level Agreement 567 (SLA) verification and billing. 569 An ES is declared when, during one second period, there is one 570 or more Errored Blocks (EBs) detected, or when a defect is 571 declared. In a packet layer, a block is a packet. An EB is an 572 indication of a lost packet. 574 A SES is declared when, during one second, the number of EBs 575 exceeds a threshold, or when a defect is declared. 577 The number of SESs (and ESs) is summed over 15-minute and 24- 578 hour intervals. 580 A Background Block Error (BBE) is an EB not occurring as part of 581 a SES. 583 The number of BBEs is summed over 15-minute and 24-hour 584 intervals, over which the trend analysis is performed. 586 A period of unavailable time (UAT) begins at the onset of 10 587 consecutive SES events. These 10 seconds are considered to be 588 part of unavailable time. A new period of available time begins 589 at the onset of 10 consecutive non-SES events. These 10 seconds 590 are considered to be part of available time. 592 The number of unavailable time in seconds (UAS) is summed over 593 15-minute and 24-hour intervals. 595 7.2. SLA Performance Metrics 597 TBD 599 7.3. ATM/Ethernet/MPLS OAM Based Performance Metrics 601 TBD 603 7.4. Performance Collection Instrumentation 605 7.4.1. Collection Frequency 607 The performance collection mechanisms MUST support the 608 flexibility to be configured to operate on-demand or 609 proactively. 611 7.4.2. Collection Granularity 613 On Packet loss measurement: 615 - For bidirectional (P2P) connection, collection of on-demand 616 single-ended packet loss measurement is required. 618 - For bidirectional (P2P) connection, collection of proactive 619 packet loss measurements for both directions is required. 621 - For unidirectional (P2P and P2MP) connection, collection of 622 proactive packet loss measurement is required. 624 On Delay measurement: 626 - For unidirectional (P2P and P2MP) connection, collection of 627 on-demand delay measurement is required. 629 - For bidirectional (P2P) connection, collection of on-demand 630 one-way and two-way delay measurement is required. 632 8. Security Requirements 634 The EMF of the MPLS-TP NE MUST be able to secure the transport 635 plane and control plane. 637 8.1. Management Communication Channel Security 639 Secure channels MUST be provided for all network traffic and 640 protocols used to support management functions. This MUST 641 include, at least, protocols used for configuration, monitoring, 642 configuration backup, logging, time synchronization, 643 authentication, and routing. The MCC MUST support application 644 protocols that provide confidentiality and data integrity 645 protection. 647 8.1.1. In-Band management security 649 If in-band management is provided, the MCC MUST require the 650 following: 652 - Use of open cryptographic algorithms (See RFC 3871 [5] 653 section 4.5) 655 - Authentication 657 - Allow management connectivity only from authorized IP 658 addresses or MAC Addresses. 660 8.1.2. Out-of-Band management security 662 The MPLS TP NE MUST support an out-of-band management console 663 port. The management traffic MUST remain separate from the data 664 and control plane traffic (no routing or forwarding between the 665 management plane and the data/control plane). 667 8.2. Signaling Communication Channel Security 669 Secure control plane protocols MAY be used in place of their 670 insecure counterparts. If an insecure protocol is used, the 671 transport layer protocol MAY be used to secure the SCC. 673 8.3. Distributed Denial of Service 675 Denial of Service (DoS) attack is an attack which tries to 676 prevent a target from performing an assigned task, or providing 677 its intended service(s), through any means. A Distributed DoS 678 (DDoS) can multiply attack severity (possibly by an arbitrary 679 amount) by using multiple (potentially compromised) systems to 680 act as topologically (and potentially geographically) 681 distributed attack sources. It is possible to lessen the impact 682 and potential for DDOS by using secure protocols, turning off 683 unnecessary processes, logging and monitoring, and ingress 684 filtering. RFC 4732 [4] provides background on DOS in the 685 context of the Internet. 687 9. Security Considerations 689 Section 8 lists a set of security requirements that apply to 690 MPLS-TP network management. 692 Provisions to any of the network mechanisms designed to satisfy 693 the requirements described herein are required to prevent their 694 unauthorized use. Likewise, these network mechanisms MUST 695 provide a means by which an operator can prevent denial of 696 service attacks if those network mechanisms are used in such an 697 attack. 699 Solutions MUST provide mechanisms to prevent this private 700 information from being accessed by unauthorized eavesdropping, 701 or being directly obtained by an unauthenticated network 702 element, system or user. 704 Performance of diagnostic functions and path characterization 705 involves extracting a significant amount of information about 706 network construction that the network operator MAY consider 707 private. 709 10. IANA Considerations 711