idnits 2.17.1 draft-ietf-mpls-tp-nm-framework-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 date (February 22, 2010) is 5176 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-12) exists of draft-ietf-mpls-tp-framework-10 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-mpls-and-gmpls-security-framework-07 == Outdated reference: A later version (-10) exists of draft-ietf-opsawg-mpls-tp-oam-def-03 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Mansfield, Ed. 3 Internet-Draft E. Gray, Ed. 4 Intended status: Informational Ericsson 5 Expires: August 26, 2010 K. Lam, Ed. 6 Alcatel-Lucent 7 February 22, 2010 9 MPLS-TP Network Management Framework 10 draft-ietf-mpls-tp-nm-framework-05 12 Abstract 14 This document provides the network management framework for the 15 Transport Profile for Multi-Protocol Label Switching (MPLS-TP). 17 This framework relies on the management terminology from the ITU-T to 18 describe the management architecture that could be used for an 19 MPLS-TP management network. 21 The management of the MPLS-TP network could be based on multi-tiered 22 distributed management systems. This document provides a description 23 of the network and element management architectures that could be 24 applied and also describes heuristics associated with fault, 25 configuration, and performance aspects of the management system. 27 This document is a product of a joint Internet Engineering Task Force 28 (IETF) / International Telecommunication Union Telecommunication 29 Standardization Sector (ITU-T) effort to include an MPLS Transport 30 Profile within the IETF MPLS and PWE3 architectures to support the 31 capabilities and functionalities of a packet transport network. 33 This Informational Internet-Draft is aimed at achieving IETF 34 Consensus before publication as an RFC and will be subject to an IETF 35 Last Call. 37 [RFC Editor, please remove this note before publication as an RFC and 38 insert the correct Streams Boilerplate to indicate that the published 39 RFC has IETF Consensus.] 41 Status of this Memo 43 This Internet-Draft is submitted to IETF in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF), its areas, and its working groups. Note that 48 other groups may also distribute working documents as Internet- 49 Drafts. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 The list of current Internet-Drafts can be accessed at 57 http://www.ietf.org/ietf/1id-abstracts.txt. 59 The list of Internet-Draft Shadow Directories can be accessed at 60 http://www.ietf.org/shadow.html. 62 This Internet-Draft will expire on August 26, 2010. 64 Copyright Notice 66 Copyright (c) 2010 IETF Trust and the persons identified as the 67 document authors. All rights reserved. 69 This document is subject to BCP 78 and the IETF Trust's Legal 70 Provisions Relating to IETF Documents 71 (http://trustee.ietf.org/license-info) in effect on the date of 72 publication of this document. Please review these documents 73 carefully, as they describe your rights and restrictions with respect 74 to this document. Code Components extracted from this document must 75 include Simplified BSD License text as described in Section 4.e of 76 the Trust Legal Provisions and are provided without warranty as 77 described in the BSD License. 79 Table of Contents 81 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 82 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 83 2. Management Architecture . . . . . . . . . . . . . . . . . . . 6 84 2.1. Network Management Architecture . . . . . . . . . . . . . 6 85 2.2. Element Management Architecture . . . . . . . . . . . . . 7 86 2.3. Standard Management Interfaces . . . . . . . . . . . . . . 11 87 2.4. Management and Control specific terminology . . . . . . . 12 88 2.5. Management Channel . . . . . . . . . . . . . . . . . . . . 12 89 3. Fault Management . . . . . . . . . . . . . . . . . . . . . . . 13 90 3.1. Supervision . . . . . . . . . . . . . . . . . . . . . . . 14 91 3.2. Validation . . . . . . . . . . . . . . . . . . . . . . . . 14 92 3.3. Alarm Handling . . . . . . . . . . . . . . . . . . . . . . 14 93 4. Configuration Management . . . . . . . . . . . . . . . . . . . 14 94 4.1. LSP ownership handover . . . . . . . . . . . . . . . . . . 15 95 5. Performance Management . . . . . . . . . . . . . . . . . . . . 15 96 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 97 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 98 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 99 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 100 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 101 9.2. Informative References . . . . . . . . . . . . . . . . . . 18 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 104 1. Introduction 106 This document provides the network management framework for the 107 Transport Profile for Multi-Protocol Label Switching (MPLS-TP). 108 Requirements for network management in an MPLS-TP network are 109 documented in MPLS-TP NM requirements [3], and this document explains 110 how network elements and networks that support MPLS-TP can be managed 111 using solutions that satisfy those requirements. The relationship 112 between OAM, management and other framework documents is described in 113 the MPLS-TP framework [4] document. 115 This document is a product of a joint Internet Engineering Task Force 116 (IETF) / International Telecommunication Union Telecommunication 117 Standardization Sector (ITU-T) effort to include an MPLS Transport 118 Profile within the IETF MPLS and PWE3 architectures to support the 119 capabilities and functionalities of a packet transport network. 121 1.1. Terminology 123 This framework relies on the management terminology from the ITU-T to 124 describe the management architecture that could be used for an 125 MPLS-TP management network. The terminology listed below are taken 126 from/based on the definitions found in ITU-T G.7710 [6], ITU-T G.7712 127 [7] and ITU-T M.3013 [13]. 129 o Communication Channel (CCh): A logical channel between network 130 elements (NEs) that can be used in (for example) management plane 131 applications or control plane applications. For MPLS-TP, the 132 physical channel supporting the CCh is the MPLS-TP Management 133 Communication Channel (MCC). 135 o Data Communication Network (DCN): A network that supports Layer 1 136 (physical), Layer 2 (data-link), and Layer 3 (network) 137 functionality for distributed management communications related to 138 the management plane, for distributed signaling communications 139 related to the control plane, and other operations communications 140 (e.g., order-wire/voice communications, software downloads, etc.). 141 See ITU-T G.7712 [7]. 143 o Equipment Management Function (EMF): The management functions 144 within an NE. See ITU-T G.7710 [6]. 146 o Local Craft Terminal (LCT): An out-of-band device that connects to 147 an NE for management purposes. See ITU-T G.7710 [6]. 149 o Label Switched Path (LSP): An MPLS-TP LSP is an LSP that uses a 150 subset of the capabilities of an MPLS LSP in order to meet the 151 requirements of an MPLS transport network as described in the 152 MPLS-TP framework [4]. 154 o Management Application Function (MAF): An application process that 155 participates in system management. See ITU-T G.7710 [6]. 157 o Management Communication Channel (MCC): A CCh dedicated for 158 management plane communications. See ITU-T G.7712 [7]. 160 o Message Communication Function (MCF): The communications process 161 that performs functions such as information interchange and relay. 162 See ITU-T M.3013 [13]. 164 o Management Communication Network (MCN): A DCN supporting 165 management plane communication is referred to as a Management 166 Communication Network (MCN). See ITU-T G.7712 [7]. 168 o MPLS-TP NE: A network element (NE) that supports MPLS-TP 169 functions. Another term that is used for a network element is 170 node. In terms of this document, the term node is equivalent to 171 NE. 173 o MPLS-TP network: A network in which MPLS-TP NEs are deployed. 175 o Network Element Function (NEF): The set of functions necessary to 176 manage a network element. See ITU-T M.3010 [11]. 178 o Operations, Administration and Maintenance (OAM): For the MPLS-TP 179 effort the term OAM means the set of tools that consist of 180 "operation" activities that are undertaken to keep the network up 181 and running, "administration" activities that keep track of 182 resources in the network and how they are used, and "maintenance" 183 activities that facilitate repairs and upgrades. For a complete 184 expansion of the acronym see The OAM Acronym Soup [15]. 186 o Operations System (OS): A system that performs the functions that 187 support processing of information related to operations, 188 administration, maintenance, and provisioning (OAM&P) (see The OAM 189 Acronym Soup [15]) for the networks, including surveillance and 190 testing functions to support customer access maintenance. See 191 ITU-T M.3010 [11]. 193 o Signaling Communication Network (SCN): A DCN supporting control 194 plane communication is referred to as a Signaling Communication 195 Network (SCN). See ITU-T G.7712 [7]. 197 o Signaling Communication Channel (SCC): A CCh dedicated for control 198 plane communications. The SCC may be used for GMPLS/ASON 199 signaling and/or other control plane messages (e.g., routing 200 messages). See ITU-T G.7712 [7]. 202 2. Management Architecture 204 The management of the MPLS-TP network could be based on a multi- 205 tiered distributed management systems, for example as described in 206 ITU-T M.3010 [11] and ITU-T M.3060/Y.2401 [12]. Each tier provides a 207 predefined level of network management capabilities. The lowest tier 208 of this organization model includes the MPLS-TP Network Element that 209 provides the transport service and the Operations System (OS) at the 210 Element Management Level. The Management Application Function (MAF) 211 within the NEs and OSs provides the management support. The MAF at 212 each entity can include agents only, managers only, or both agents 213 and managers. The MAF that include managers are capable of managing 214 an agent included in other MAF. 216 The management communication to peer NEs and/or Operations Systems 217 (OSs) is provided via the Message Communication Function (MCF) within 218 each entity (e.g. NE and OS). The user can access the management of 219 the MPLS-TP transport network via a Local Craft Terminal (LCT) 220 attached to the NE or via a Work Station (WS) attached to the OS. 222 2.1. Network Management Architecture 224 A transport Management Network (MN) may consist of several transport 225 technology specific Management Networks. Management network 226 partitioning (Figure 1) below based on ITU-T G.7710 [6] shows the 227 management network partitioning. Notation used in G.7710 for a 228 transport technology specific MN is x.MN, where x is the transport 229 specific technology. An MPLS-TP specific MN is abbreviated as MT.MN. 230 Where there is no ambiguity, we will use "MN" for an MPLS-TP specific 231 MN. In the figure below O.MSN is equivalent to an OTN management 232 Subnetwork. 234 ______________________________ _________________________________ 235 |.-------.-------.----.-------.||.--------.--------.----.--------.| 236 |: : : : :||: : : : :| 237 |:O.MSN-1:O.MSN-2: .. :O.MSN-n:||:MT.MSN-1:MT.MSN-2: .. :MT.MSN-n:| 238 |: : : : :||: : : : :| 239 '-============================-''-===============================-' 240 _______________________________ 241 |.-------.-------.-----.-------.| 242 |: : : : :| 243 |:x.MSN-1:x.MSN-2: ... :x.MSN-n:| 244 |: : : : :| 245 '-=============================-' 247 Management Network Partitioning 249 Figure 1 251 The management of the MPLS-TP network is separable from the 252 management of the other technology-specific networks, and operates 253 independently of any particular client or server layer management 254 plane. 256 An MPLS-TP Management Network (MT.MN) could be partitioned into 257 MPLS-TP Management SubNetworks ("MT.MSN" or "MPLS-TP MSN", or just 258 "MSN" where usage is unambiguous) for consideration of scalability 259 (e.g. geographic or load balancing) or administrative (e.g. 260 administrative or ownership). 262 The MPLS-TP MSN could be connected to other parts of the MN through 263 one or more LCTs and/or OSs. The Message Communication Function 264 (MCF) of an MPLS-TP NE initiates/terminates, routes, or otherwise 265 processes management messages over CChs or via an external interface. 267 Multiple addressable MPLS-TP NEs could be present at a single 268 physical location (i.e. site or office). The inter-site 269 communications link between the MPLS-TP NEs will normally be provided 270 by the CChs. Within a particular site, the NEs could communicate via 271 an intra-site CCh or via a LAN. 273 2.2. Element Management Architecture 275 The Equipment Management Function (EMF) of a MPLS-TP NE provides the 276 means through which a management system manages the NE. 278 The EMF interacts with the NE's transport functions by exchanging 279 Management Information (MI) across the Management Point (MP) 280 Reference Points. The EMF may contain a number of functions that 281 provide a data reduction mechanism on the information received across 282 the MP Reference Points. 284 The EMF includes functions such as Date & Time, FCAPS (Fault, 285 Configuration, Accounting, Performance and Security) management, and 286 Control Plane functions. The EMF provides event message processing, 287 data storage and logging. The management Agent, a component of the 288 EMF, converts internal management information (MI signals) into 289 Management Application messages and vice versa. The Agent responds 290 to Management Application messages from the Message Communication 291 Function (MCF) by performing the appropriate operations on (for 292 example) the Managed Objects in a Management Information Base (MIB), 293 as necessary. The MCF contains communications functions related to 294 the outside world of the NE (i.e. Date & Time source, Management 295 Plane, Control Plane, Local Craft Terminal and Local Alarms). 297 The Date & Time functions keep track of the NE's date/time which is 298 used by the FCAPS management functions to e.g. time stamp event 299 reports. 301 Below are diagrams that illustrate the components of the Element 302 Management Function (EMF) of a Network Element (NE). The high-level 303 decomposition of the Network Element Function (NEF) picture 304 (Figure 2) provides the breakdown of the NEF, then the EMF picture 305 (Figure 3) provides the details of Equipment Management Function, and 306 finally the Message Communication Function (MCF) picture (Figure 4) 307 details the MCF. 309 ____________________________________________________ 310 | Network Element Function (NEF) | 311 | _________________________________________ | 312 || | | 313 || Transport Plane Atomic Functions | | 314 ||_________________________________________| | 315 | | | 316 | | Management | 317 | | Information | 318 | ___________________|_________________ | 319 | | (from date/time)<-----------+ | 320 | | Equipment | | | 321 | | Management (to/from management)<--------+ | | 322 | | Function | | | | 323 | | (EMF) (to/from control)<-----+ | | | 324 | | | | | | | 325 | | (to local alarm)---+ | | | | 326 | |_____________________________________| | | | | | 327 | | | | | | 328 | +--------------------------------------+ | | | | 329 | | +---------------------------------------+ | | | 330 | | | +----------------------------------------+ | | 331 | | | | +-----------------------------------------+ |external 332 | | | | | Date & Time _________________ |time 333 | | | | | Interface | Message | |source 334 | | | | +-------------- Communication <----------------------- 335 | | | | | Function (MCF) | | 336 | | | | Management | | |management 337 | | | +----------------> | |plane 338 | | | Plane Interface <----------------------> 339 | | | | | |local 340 | | | | | |craft 341 | | | Control Plane | | |terminal 342 | | +------------------> <----------------------> 343 | | Interface | | |control 344 | | | | |plane 345 | | Local Alarm | <----------------------> 346 | +--------------------> | | 347 | Interface | | |to local 348 | | | |alarms 349 | |_________________---------------------> 350 |____________________________________________________| 352 High-level decomposition of NEF 354 Figure 2 356 ______________________________________________________ 357 | _______________________________________ | 358 | Equipment | Management Application || 359 | Management | Function (MAF) || 360 | Function | _________________ || 361 | (EMF) || | __________________|| 362 | ___________||_______________ | | || 363 | | | | | Date & Time || 364 | | Date & Time Functions | | | Interface ||<-- 1 365 | |____________________________| | |__________________|| 366 | ___________||_______________ | __________________|| 367 | | | | | || 368 | | Fault Management | | | Management || 369 | |____________________________| | | Plane Interface ||<-> 2 370 | ___________||_______________ | |__________________|| 371 | | | | || 372 | | Configuration Management | | __________________|| 373 | |____________________________| | | || 374 | ___________||_______________ | | Control || 375 | | | | | Plane Interface ||<-> 3 376 | | Account Management | | |__________________|| 377 | |____________________________| | || 378 | ___________||_______________ | || 379 | | | | || 380 | | Performance Management | | || 381 | |____________________________| | || 382 | ___________||_______________ | || 383 | | | | || 384 | | Security Management | | || 385 | |____________________________| | || 386 | ___________||_______________ | || 387 | | | | || 388 | | Control Plane Function | | || 389 | |____________________________| | || 390 | || | __________________|| 391 | || | | || 392 | || | | Local Alarm || 393 | +----->| Agent | | Interface ||--> 4 394 | v ||_________________| |__________________|| 395 | .-===-. |_______________________________________|| 396 | | MIB | | 397 | `-._.-' | 398 |______________________________________________________| 400 Equipment Management Function 402 Figure 3 404 _________________ 405 | | 406 | Message | 407 | Communication | 408 | Function (MCF) | 409 | _______________ | 410 Date & Time || || external 411 1 <--------------|| Date & Time ||<-------------- 412 Information || Communication || time source 413 ||_______________|| 414 | | 415 | _______________ | 416 Management || || management 417 Plane || Management || plane 418 2 <------------->|| Plane ||<-------------> 419 Information || Communication || (e.g. - EMS, 420 ||_______________|| peer NE) 421 | | 422 | _______________ | control 423 Control Plane || || plane 424 3 <------------->|| Control Plane ||<-------------> 425 Information || Communication || (e.g. - EMS, 426 ||_______________|| peer NE) 427 | : | 428 | : | local craft 429 | : | terminal 430 | : |<-------------> 431 | _______________ | 432 Local Alarm || || to local 433 4 -------------->|| Local Alarm ||--------------> 434 Information || Communication || alarms... 435 ||_______________|| 436 |_________________| 438 Message Communication Function 440 Figure 4 442 2.3. Standard Management Interfaces 444 The MPLS-TP NM requirements [3] document places no restriction on 445 which management interface is to be used for managing an MPLS-TP 446 network. It is possible to provision and manage an end-to-end 447 connection across a network where some segments are created/managed/ 448 deleted, for example by netconf or snmp and other segments by CORBA 449 interfaces. Use of any network management interface for one 450 management related purpose does not preclude use of another network 451 management interface for other management related purposes, or the 452 same purpose at another time. The protocol(s) to be supported are at 453 the discretion of the operator. 455 2.4. Management and Control specific terminology 457 Data Communication Network (DCN) is the common term for the network 458 used to transport Management and Signaling information between: 459 management systems and network elements, management systems to other 460 management systems, and networks elements to other network elements. 461 The Management Communications Network (MCN) is the part of the DCN 462 which supports the transport of Management information for the 463 Management Plane. The Signaling Communications Network (SCN) is the 464 part of the DCN which supports transport for signaling information 465 for the Control Plane. As shown in the communication channel 466 terminology picture (Figure 5) each technology has its own 467 terminology that is used for the channels that support management and 468 control plane information transfer. For MPLS-TP, the management 469 plane uses the Management Communication Channel (MCC) and the control 470 plane uses the Signaling Communication Channel (SCC). 472 2.5. Management Channel 474 The Communication Channel (CCh) provides a logical channel between 475 NEs for transferring Management and/or Signaling information. Note 476 that some technologies provide separate communication channels for 477 Management (MCC) and Signaling (SCC). 479 MPLS-TP NEs communicate via the DCN. The DCN connects NEs with 480 management systems, NEs with NEs, and management systems with 481 management systems. 483 Common Terminology ____ 484 __________ __________ | | 485 | | | | /->| NE | \ ____ 486 |Management| |Operations| / |____| \ | | 487 |Station | <---> |System | |(CCh) | NE | 488 |__________| |__________| \ _|__ / |____| 489 \->| | / 490 | NE | 491 |____| 492 Network Elements use a Communication 493 Channel (CCh) for Transport of Information 495 Management Terminology ____ 496 __________ __________ | | 497 | | | | /->| NE | \ ____ 498 |Management| |Operations| / |____| \ | | 499 |Station | <---> |System | |(MCC) | NE | 500 |__________| |__________| \ _|__ / |____| 501 \->| | / 502 | NE | 503 |____| 504 Network Elements use a Management 505 Communication Channel (MCC) for Transport 506 of Management Information 508 Control Terminology ____ 509 __________ __________ | | 510 | | | | /->| NE | \ ____ 511 |Management| |Operations| / |____| \ | | 512 |Station | <---> |System | |(SCC) | NE | 513 |__________| |__________| \ _|__ / |____| 514 \->| | / 515 | NE | 516 |____| 517 Network Elements use a Control/Signaling 518 Communication Channel (SCC) for Transport 519 of Signaling Information 521 Communication Channel Terminology 523 Figure 5 525 3. Fault Management 527 A fault is the inability of a function to perform a required action. 528 This does not include an inability due to preventive maintenance, 529 lack of external resources, or planned actions. Fault management 530 provides the mechanisms to detect, verify, isolate, notify, and 531 recover from the fault. 533 3.1. Supervision 535 ITU-T G.7710 [6] lists five basic categories of supervision that 536 provide the functionality necessary to detect, verify, and notify a 537 fault. The categories are: Transmission Supervision, Quality of 538 Service Supervision, Processing Supervision, Hardware Supervision, 539 and Environment Supervision. Each of the categories provides a set 540 of recommendations to ensure the fault management process is 541 fulfilled. 543 3.2. Validation 545 ITU-T G.7710 [6] describes a fault cause as a limited interruption of 546 the required function. It is not reasonable for every fault cause to 547 be reported to maintenance personnel. The validation process is used 548 to turn fault causes (events) into failures (alarms). 550 3.3. Alarm Handling 552 Within an element management system, it is important to consider 553 mechanisms to support severity assignment, alarm reporting control, 554 and logging. 556 4. Configuration Management 558 Configuration management provides the mechanisms to: 560 o provision the MPLS-TP services 562 o setup security for the MPLS-TP services and MPLS-TP network 563 elements 565 o provide the destination for fault notifications and performance 566 parameters 568 o configure and control OAM 570 Also associated with configuration management are hardware and 571 software provisioning and inventory reporting. 573 4.1. LSP ownership handover 575 MPLS-TP networks can be managed not only by Network Management 576 Systems (i.e. Management Plane (MP)), but also by Control Plane (CP) 577 protocols. The utilization of the control plane is not a mandatory 578 requirement (see MPLS-TP Requirements [2]) but it is often used by 579 network operators in order to make network configuration and Label 580 Switched Path (LSP) recovery both faster and simpler. 582 In networks where both CP and MP are provided, an LSP could be 583 created by either (CP or MP). The entity creating an LSP owns the 584 data plane resources comprising that LSP. Only the owner of an LSP 585 is typically able to modify/delete it. This results in a need for 586 interaction between the MP and CP to allow either to manage all the 587 resources of a network. 589 Network operators might prefer to have full control of the network 590 resources during the set-up phase and then allow the network to be 591 automatically maintained by the Control Plane. This can be achieved 592 by creating LSPs via the Management Plane and subsequently 593 transferring LSP ownership to the Control Plane. This is referred to 594 as "ownership handover" RFC 5493 [10]. MP to CP ownership handover 595 is then considered a requirement where a Control Plane is in use that 596 supports it. The converse (CP to MP ownership handover) is a feature 597 that is recommended - but not required - for (G)MPLS networks because 598 it has only minor applications (for example moving LSPs from one path 599 to another as a maintenance operation). 601 The LSP handover procedure has already been standardized for GMPLS 602 networks, where the signaling protocol used is RSVP-TE RFC 3209 [1]. 603 The utilization of RSVP-TE enhancements are defined in [5]. 605 MP and CP interworking includes also the exchange of information that 606 is either requested by the MP, or a notification by the CP as a 607 consequence of a request from the MP or an automatic action (for 608 example a failure occurs or an operation is performed). The CP is 609 asked to notify the MP in a reliable manner about the status of the 610 operations it performs and to provide a mechanism to monitor the 611 status of Control Plane objects (e.g. TE Link status, available 612 resources), and to log Control Plane LSP related operations. Logging 613 is one of the most critical aspects because the MP always needs to 614 have an accurate history and status of each LSP and all Data Plane 615 resources involved in it. 617 5. Performance Management 619 Performance statistics could overwhelm a Management Network, so it is 620 important to provide flexible instrumentation that enables control 621 over the amount of performance data to be collected. Mechanisms for 622 limiting the quantity of information collected are well known and 623 deployed in IETF standards (see RFC 2819 (RMON) [8] and RFC 4502 624 (RMON2) [9]). The details of the performance data collected 625 (including loss and delay measurement data) are found in the MPLS-TP 626 NM requirements [3] document. 628 A distinction is made between performance data that is collected on- 629 demand and data that is collected proactively. The definitions of 630 on-demand and proactive measurement are provided for OAM in the 631 MPLS-TP NM requirements [3] document. 633 On-demand measurement provides the operator with the ability to do 634 performance measurement for maintenance purpose such as diagnosis or 635 to provide detailed verification of proactive measurement. It is 636 used typically on specific LSP service instances for a limited time, 637 thus limiting its impact on network performance under normal 638 operations. Therefore on demand measurement does not result in 639 scaling issues. 641 Proactive measurement is used continuously over time after being 642 configured with periodicity and storage information. Data collected 643 from proactive measurement are usually used for verifying the 644 performance of the service. Proactive performance monitoring has the 645 potential to overwhelm both the process of collecting performance 646 data at a Network Element (for some arbitrary number of service 647 instances traversing the NE), and the process of reporting this 648 information to the OS. As a consequence of these considerations, 649 operators would typically limit the services to which proactive 650 performance measurement would be applied to a very selective subset 651 of the services being provided and would limit the reporting of this 652 information to statistical summaries (as opposed to raw or detailed 653 performance statistics). 655 6. Acknowledgements 657 The authors/editors gratefully acknowledge the thoughtful review, 658 comments and explanations provided by Diego Caviglia, Bernd Zeuner 659 and Dan Romascanu. 661 7. IANA Considerations 663 This memo includes no request to IANA. 665 8. Security Considerations 667 The ability for the authorized network operator to access EMF 668 interfaces (section 2.3) when needed is critical to proper operation. 669 Therefore the EMF interfaces need to be protected from denial of 670 service conditions or attack. The EMF Interfaces that use or access 671 private information should be protected from eavesdropping, mis- 672 configuration, and/or mal-configuration by unauthorized network 673 elements, systems, or users. 675 Performance of diagnostic functions and path characterization 676 involves extracting a significant amount of information about network 677 construction that the network operator considers private. 679 Section 4.3 of the Security Framework for MPLS and GMPLS Networks 680 [14] document provides a description of the attacks on the Operation 681 and Management Plane and also discusses the background necessary to 682 understand security practices in Internet Service Provider 683 environments. The security practices described are applicable to 684 MPLS-TP environments. 686 9. References 688 9.1. Normative References 690 [1] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and 691 G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", 692 RFC 3209, December 2001. 694 [2] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., and 695 S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, 696 September 2009. 698 [3] Mansfield, S. and K. Lam, "MPLS TP Network Management 699 Requirements", draft-ietf-mpls-tp-nm-req-06 (work in progress), 700 October 2009. 702 [4] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. Berger, "A 703 Framework for MPLS in Transport Networks", 704 draft-ietf-mpls-tp-framework-10 (work in progress), 705 February 2010. 707 [5] Caviglia, D., Ceccarelli, D., Li, D., and S. Bardalai, "RSVP-TE 708 Signaling Extension For Management Plane To Control Plane LSP 709 Handover In A GMPLS Enabled Transport Network.", 710 draft-ietf-ccamp-pc-spc-rsvpte-ext-07 (work in progress), 711 February 2010. 713 [6] International Telecommunication Union, "Common equipment 714 management function requirements", ITU-T Recommendation G.7710/ 715 Y.1701, July 2007. 717 [7] International Telecommunication Union, "Architecture and 718 specification of data communication network", ITU- 719 T Recommendation G.7712/Y.1703, June 2008. 721 9.2. Informative References 723 [8] Waldbusser, S., "Remote Network Monitoring Management 724 Information Base", STD 59, RFC 2819, May 2000. 726 [9] Waldbusser, S., "Remote Network Monitoring Management 727 Information Base Version 2", RFC 4502, May 2006. 729 [10] Caviglia, D., Bramanti, D., Li, D., and D. McDysan, 730 "Requirements for the Conversion between Permanent Connections 731 and Switched Connections in a Generalized Multiprotocol Label 732 Switching (GMPLS) Network", RFC 5493, April 2009. 734 [11] International Telecommunication Union, "Principles for a 735 telecommunication management network", ITU-T Recommendation 736 M.3010, April 2005. 738 [12] International Telecommunication Union, "Principles for the 739 Management of Next Generation Networks", ITU-T Recommendation 740 M.3060/Y.2401, March 2006. 742 [13] International Telecommunication Union, "Considerations for a 743 telecommunication management network", ITU-T Recommendation 744 M.3013, February 2000. 746 [14] Fang, L. and M. Behringer, "Security Framework for MPLS and 747 GMPLS Networks", 748 draft-ietf-mpls-mpls-and-gmpls-security-framework-07 (work in 749 progress), October 2009. 751 [15] Andersson, L., Helvoort, H., Bonica, R., Romascanu, D., and S. 752 Mansfield, ""The OAM Acronym Soup"", 753 draft-ietf-opsawg-mpls-tp-oam-def-03 (work in progress), 754 February 2010. 756 Authors' Addresses 758 Scott Mansfield (editor) 759 Ericsson 760 300 Holger Way 761 San Jose, CA 95134 762 US 764 Phone: +1 724 931 9316 765 Email: scott.mansfield@ericsson.com 767 Eric Gray (editor) 768 Ericsson 769 900 Chelmsford Street 770 Lowell, MA 01851 771 US 773 Phone: +1 978 275 7470 774 Email: eric.gray@ericsson.com 776 Hing-Kam Lam (editor) 777 Alcatel-Lucent 778 600-700 Mountain Ave 779 Murray Hill, NJ 07974 780 US 782 Phone: +1 908 582 0672 783 Email: Kam.Lam@alcatel-lucent.com