idnits 2.17.1 draft-ietf-mpls-tp-rosetta-stone-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 (January 15, 2013) is 4112 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MPLS Working Group H. van Helvoort (Ed) 2 Internet Draft Huawei Technologies 3 Intended status: Informational 4 Expires: July 2013 L. Andersson (Ed) 5 Ericsson 7 N. Sprecher (Ed) 8 Nokia Siemens Networks 10 January 15, 2013 12 A Thesaurus for the Terminology used in Multiprotocol Label 13 Switching Transport Profile (MPLS-TP) drafts/RFCs and ITU-T's 14 Transport Network Recommendations. 15 draft-ietf-mpls-tp-rosetta-stone-08 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with 20 the provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months and may be updated, replaced, or obsoleted by other documents 29 at any time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire in July 2013. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with 50 respect to this document. Code Components extracted from this 51 document must include Simplified BSD License text as described in 52 Section 4.e of the Trust Legal Provisions and are provided without 53 warranty as described in the Simplified BSD License. 55 Abstract 57 MPLS-TP is based on a profile of the MPLS and PW procedures as 58 specified in the MPLS-TE and (MS-)PW architectures developed by the 59 IETF. The ITU-T has specified a Transport Network architecture. 61 This document provides a thesaurus for the interpretation of MPLS-TP 62 terminology within the context of the ITU-T Transport Network 63 recommendations. 65 It is important to note that MPLS-TP is applicable in a wider set of 66 contexts than just Transport Networks. The definitions presented in 67 this document do not provide exclusive nor complete interpretations 68 of MPLS-TP concepts. This document simply allows the MPLS-TP terms 69 to be applied within the Transport Network context. 71 Table of Contents 73 1. Introduction 4 74 1.1. Contributing Authors 4 75 1.2. Abbreviations 4 76 SCC Signaling Communication Channel 5 77 2. Terminology 5 78 2.1. MPLS-TP Terminology Sources 5 79 2.2. ITU-T Transport Network Terminology Sources 5 80 2.3. Common Terminology Sources 5 81 3. Thesaurus 6 82 3.1. Associated bidirectional path: 6 83 3.2. Bidirectional path: 6 84 3.3. Client layer network: 6 85 3.4. Concatenated Segment: 6 86 3.5. Control Plane: 6 87 3.6. Co-routed bidirectional path: 7 88 3.7. Domain: 7 89 3.8. Layer network: 7 90 3.9. Link: 7 91 3.10. MPLS-TP Logical Ring: 8 92 3.11. MPLS-TP Physical Ring: 8 93 3.12. MPLS-TP Ring Topology: 8 94 3.13. Path: 8 95 3.14. Section Layer Network: 8 96 3.15. Segment: 9 97 3.16. Server layer: 9 98 3.17. Span: 9 99 3.18. Sublayer: 9 100 3.19. Tandem Connection: 9 101 3.20. Transport Network: 9 102 3.21. Transport path: 10 103 3.22. Transport path layer: 10 104 3.23. Transport service layer: 10 105 3.24. Transmission media layer: 10 106 3.25. Unidirectional path: 10 107 3.26. Failure: 10 108 3.27. Fault: 11 109 3.28. Defect: 11 110 3.29. MPLS Transport Profile (MPLS-TP): 11 111 3.30. MPLS Section: 11 112 3.31. MPLS-TP NE: 11 113 3.32. MPLS-TP network: 11 114 3.33. Equipment Management Function (EMF): 11 115 3.34. Data Communication Network (DCN): 11 116 3.35. Communication Channel (CC): 12 117 3.36. Embedded Communication Channel (ECC): 12 118 3.37. Management Communication Channel (MCC): 12 119 3.38. Management Communication Network (MCN): 12 120 3.39. Signaling Communication Channel (SCC): 12 121 3.40. Signaling Communication Network (SCN): 12 122 3.41. Operations System (OS): 12 123 3.42. OAM flow: 12 124 3.43. Maintenance Entity Group (MEG): 13 125 3.44. Maintenance Entity (ME): 13 126 3.45. Maintenance Entity Group End Point (MEP): 13 127 3.46. Maintenance Entity Group Intermediate Point (MIP): 14 128 3.47. Server MEPs: 14 129 3.48. Link recovery: 15 130 3.49. Segment recovery: 15 131 3.50. End-to-end recovery: 15 132 3.51. Transport Entity: 15 133 3.52. Working Entity: 15 134 3.53. Protection Entity: 15 135 3.54. Recovery entity: 15 136 4. Guidance on the Application of this Thesaurus 16 137 5. Management Considerations 16 138 6. Security Considerations 16 139 7. IANA Considerations 16 140 8. Acknowledgments 17 141 9. References 17 142 9.1. Normative References 17 143 9.2. Informative References 18 145 1. Introduction 147 Multiprotocol Label Switching - Transport Profile (MPLS-TP) has been 148 developed by the IETF to facilitate the Operation, Administration 149 and Management of Label Switched Paths (LSPs) in a Transport Network 150 environment as defined by the ITU-T. 152 The ITU-T has specified a Transport Network architecture for the 153 transfer of signals from different technologies. This architecture 154 forms the basis of many Recommendations within the ITU-T. 156 Because of the difference in historic background of MPLS, and 157 inherently MPLS-TP (the Internet) and the Transport Network (ITU 158 telecommunication Sector), the terminology used is different. 160 This document provides a thesaurus for the interpretation of ITU-T 161 Transport Network terminology within the context of the MPLS-TP. 162 This allows MPLS-TP documents to be generally understood by those 163 familiar with MPLS RFCs. The definitions presented in this document 164 do not provide exclusive or complete interpretations of the ITU-T 165 Transport Network concepts. 167 1.1. Contributing Authors 169 Italo Busi, Ben Niven-Jenkins, Enrique Hernandez-Valencia, Lieven 170 Levrau, Dinesh Mohan, Stuart Bryant, Dan Frost, Matthew Bocci, 171 Vincenzo Sestito, Vigoureux, Yaacov Weingarten 173 1.2. Abbreviations 175 CC Communications Channel 177 DCN Data Communication Network 179 ECC Embedded Communication Channel 181 EMF Equipment Management Function 183 MCC Management Communication Channel 185 MCN Management Communication Network 187 ME Maintenance Entity 188 MEG ME Group 190 MEP MEG End Point 192 MIP MEG Intermediate Point 194 MPLS Multiprotocol Label Switching 196 MPLS-TP MPLS Transport Profile 198 NE Network Element 200 OAM Operations, Administration and Maintenance 202 O&M OAM and Management 204 SCC Signaling Communication Channel 206 SCN Signaling Communication Network 208 2. Terminology 210 2.1. MPLS-TP Terminology Sources 212 MPLS-TP terminology is principally defined in [RFC3031]. Other 213 documents provide further key definitions including [RFC4397], and 214 [RFC....]. 216 2.2. ITU-T Transport Network Terminology Sources 218 The ITU-T Transport Network is specified in a number of 219 recommendations: generic functional architectures and requirements 220 are specified in Error! Reference source not found., Error! 221 Reference source not found., and Error! Reference source not found.. 222 ITU-T Recommendation Error! Reference source not found. contains an 223 overview of the Terms and Definitions for transport MPLS. 225 2.3. Common Terminology Sources 227 The work in this document builds on the shared view of MPLS 228 requirements. 230 The following sources are used: 231 IETF framework and requirements RFCs: [RFC6371], [RFC6372], 232 [RFC5654], [RFC5921], [RFC5860], [RFC5951], [RFC3031] and [RFC4397]. 234 ITU-T architecture and requirements Recommendations: [ITU-T_G.8101], 235 [ITU-T_G.805], [ITU-T_G.806], [ITU-T_G.872], [ITU-T G.7710] and 236 [ITU-T Y.2611] 238 3. Thesaurus 240 3.1. Associated bidirectional path: 242 A path that supports traffic flow in both directions but that is 243 constructed from a pair of unidirectional paths (one for each 244 direction) that are associated with one another at the path's 245 ingress/egress points. The forward and backward directions are 246 setup, monitored, and protected independently. As a consequence, 247 they may or may not follow the same route (links and nodes) across 248 the network. 250 3.2. Bidirectional path: 252 A path that supports traffic flow in two opposite directions, i.e. 253 the forward and backward direction. 255 3.3. Client layer network: 257 In a client/server relationship (see Error! Reference source not 258 found.), the client layer network receives a (transport) service 259 from the lower server layer network (usually the layer network under 260 consideration). 262 3.4. Concatenated Segment: 264 A serial-compound link connection as defined in Error! Reference 265 source not found.. A concatenated segment is a contiguous part of 266 an LSP or multi-segment PW that comprises a set of segments and 267 their interconnecting nodes in sequence. See also "Segment". 269 3.5. Control Plane: 271 Within the scope of [RFC5654], the control plane performs transport 272 path control functions. Through signalling, the control plane sets 273 up, modifies and releases transport paths, and may recover a 274 transport path in case of a failure. The control plane also 275 performs other functions in support of transport path control, such 276 as routing information dissemination. 278 3.6. Co-routed bidirectional path: 280 A path where the forward and backward directions follow the same 281 route (links and nodes) across the network. Both directions are 282 setup, monitored and protected as a single entity. A transport 283 network path is typically co-routed. 285 3.7. Domain: 287 A domain represents a collection of entities (for example network 288 elements) that are grouped for a particular purpose, examples of 289 which are administrative and/or managerial responsibilities, trust 290 relationships, addressing schemes, infrastructure capabilities, 291 aggregation, survivability techniques, distributions of control 292 functionality, etc. Examples of such domains include IGP areas and 293 Autonomous Systems. 295 3.8. Layer network: 297 Layer network is defined in Error! Reference source not found.. A 298 layer network provides for the transfer of client information and 299 independent operation of the client OAM. A layer network may be 300 described in a service context as follows: one layer network may 301 provide a (transport) service to a higher client layer network and 302 may, in turn, be a client to a lower-layer network. A layer network 303 is a logical construction somewhat independent of arrangement or 304 composition of physical network elements. A particular physical 305 network element may topologically belong to more than one layer 306 network, depending on the actions it takes on the encapsulation 307 associated with the logical layers (e.g., the label stack), and thus 308 could be modeled as multiple logical elements. A layer network may 309 consist of one or more sublayers. For additional explanation of how 310 layer networks relate to the OSI concept of layering, see Appendix I 311 of Error! Reference source not found.. 313 3.9. Link: 315 A physical or logical connection between a pair of LSRs that are 316 adjacent at the (sub)layer network under consideration. A link may 317 carry zero, one or more LSPs or PWs. A packet entering a link will 318 emerge with the same label stack entry values. 320 A link as defined in Error! Reference source not found. is used to 321 describe a fixed relationship between two ports. 323 3.10. MPLS-TP Logical Ring: 325 An MPLS-TP logical ring is constructed from a set of LSRs and 326 logical data links (such as MPLS-TP LSP tunnels or MSPL-TP 327 pseudowires) and physical data links that form a ring topology. 329 3.11. MPLS-TP Physical Ring: 331 An MPLS-TP physical ring is constructed from a set of LSRs and 332 physical data links that form a ring topology. 334 3.12. MPLS-TP Ring Topology: 336 In an MPLS-TP ring topology, each LSR is connected to exactly two 337 other LSRs, each via a single point-to-point bidirectional MPLS-TP 338 capable link. A ring may also be constructed from only two LSRs 339 where there are also exactly two links. Rings may be connected to 340 other LSRs to form a larger network. Traffic originating or 341 terminating outside the ring may be carried over the ring. Client 342 network nodes (such as CEs) may be connected directly to an LSR in 343 the ring. 345 3.13. Path: 347 See Transport path. 349 3.14. Section Layer Network: 351 A section layer is a server layer (which may be MPLS-TP or a 352 different technology) that provides for the transfer of the section- 353 layer client information between adjacent nodes in the transport- 354 path layer or transport-service layer. A section layer may provide 355 for aggregation of multiple MPLS-TP clients. Note that Error! 356 Reference source not found. defines the section layer as one of the 357 two layer networks in a transmission-media layer network. The other 358 layer network is the physical-media layer network. 360 Section layer networks are concerned with all the functions which 361 provide for the transfer of information between locations in path 362 layer networks. 364 Physical media layer networks are concerned with the actual fibres, 365 metallic wires or radio frequency channels which support a section 366 layer network. 368 3.15. Segment: 370 A link connection as defined in Error! Reference source not found.. 371 A segment is the part of an LSP that traverses a single link or the 372 part of a PW that traverses a single link (i.e., that connects a 373 pair of adjacent {Switching|Terminating} Provider Edges). See also 374 "Concatenated Segment". 376 3.16. Server layer: 378 A layer network in which transport paths are used to carry a 379 customer's (individual or bundled) service (may be point-to-point, 380 point-to-multipoint or multipoint-to-multipoint services). 382 In a client/server relationship (see Error! Reference source not 383 found.). the server layer network provides a (transport) service to 384 the higher client layer network (usually the layer network under 385 consideration). 387 3.17. Span: 389 A span is synonymous with a link. 391 3.18. Sublayer: 393 Sublayer is defined in Error! Reference source not found.. The 394 distinction between a layer network and a sublayer is that a 395 sublayer is not directly accessible to clients outside of its 396 encapsulating layer network and offers no direct transport service 397 for a higher layer (client) network. 399 3.19. Tandem Connection: 401 A tandem connection is an arbitrary part of a transport path that 402 can be monitored (via OAM) independently from the end-to-end 403 monitoring (OAM). It may be a monitored segment, a monitored 404 concatenated segment or any other monitored ordered sequence of 405 contiguous hops and/or segments (and their interconnecting nodes) of 406 a transport path. 408 3.20. Transport Network: 410 A Transport Network provides transmission of traffic between 411 attached client devices by establishing and maintaining point-to- 412 point or point-to-multipoint connections between such devices. A 413 Transport Network is independent of any higher-layer network that 414 may exist between clients, except to the extent required to supply 415 this transmission service. In addition to client traffic, a 416 Transport Network may carry traffic to facilitate its own operation, 417 such as that required to support connection control, network 418 management, and Operations, Administration and Maintenance (OAM) 419 functions. 421 3.21. Transport path: 423 A network connection as defined in Error! Reference source not 424 found.. In an MPLS-TP environment a transport path corresponds to 425 an LSP or a PW. 427 3.22. Transport path layer: 429 A (sub)layer network that provides point-to-point or point-to- 430 multipoint transport paths. It provides OAM that is independent of 431 the clients that it is transporting. 433 3.23. Transport service layer: 435 A layer network in which transport paths are used to carry a 436 customer's (individual or bundled) service (may be point-to-point, 437 point-to-multipoint or multipoint-to-multipoint services). 439 3.24. Transmission media layer: 441 A layer network, consisting of a section layer network and a 442 physical layer network as defined in Error! Reference source not 443 found., that provides sections (two-port point-to-point connections) 444 to carry the aggregate of network-transport path or network-service 445 layers on various physical media. 447 3.25. Unidirectional path: 449 A Unidirectional Path is a path that supports traffic flow in only 450 one direction. 452 3.26. Failure: 454 The fault cause persisted long enough to consider the ability of an 455 item to perform a required function to be terminated. The item may 456 be considered as failed; a fault has now been detected. See also 457 Error! Reference source not found.. 459 3.27. Fault: 461 A Fault is the inability of a function to perform a required action. 462 This does not include an inability due to preventive maintenance, 463 lack of external resources, or planned actions. See also Error! 464 Reference source not found.. 466 3.28. Defect: 468 The situation for which the density of anomalies has reached a level 469 where the ability to perform a required function has been 470 interrupted. Defects are used as input for PM, the control of 471 consequent actions, and the determination of fault cause. See also 472 Error! Reference source not found.. 474 3.29. MPLS Transport Profile (MPLS-TP): 476 The set of MPLS functions used to support packet transport services 477 and network operations. 479 3.30. MPLS Section: 481 A network segment between two LSRs that are immediately adjacent at 482 the MPLS layer. 484 3.31. MPLS-TP NE: 486 A network element (NE) that supports MPLS-TP functions. 488 3.32. MPLS-TP network: 490 A network in which MPLS-TP NEs are deployed 492 3.33. Equipment Management Function (EMF): 494 The management functions within an NE. See Error! Reference source 495 not found.. 497 3.34. Data Communication Network (DCN): 499 A network that supports Layer 1 (physical layer), Layer 2 (data-link 500 layer), and Layer 3 (network layer) functionality for distributed 501 management communications related to the management plane, for 502 distributed signaling communications related to the control plane, 503 and other operations communications (e.g., order-wire/voice 504 communications, software downloads, etc.). 506 3.35. Communication Channel (CC): 508 A logical channel between network elements (NEs) that can be used - 509 e.g. - for management plane application or control plane 510 applications. The physical channel supporting the CC is technology 511 specific. See [RFC5951] APPENDIX A 513 3.36. Embedded Communication Channel (ECC): 515 A logical operations channel between network elements (NEs) that can 516 be utilized by multiple applications (e.g., management plane 517 applications, control plane applications, etc.). The physical 518 channel supporting the ECC is technology specific. An example of 519 physical channels supporting the ECC is a DCC channel within SDH. 521 3.37. Management Communication Channel (MCC): 523 A CC dedicated for management plane communications. 525 3.38. Management Communication Network (MCN): 527 A DCN supporting management plane communication is referred to as a 528 Management Communication Network (MCN). 530 3.39. Signaling Communication Channel (SCC): 532 A CC dedicated for control plane communications. The SCC may be used 533 for GMPLS/ASON signaling and/or other control plane messages (e.g., 534 routing messages). 536 3.40. Signaling Communication Network (SCN): 538 A DCN supporting control plane communication is referred to as a 539 Signaling Communication Network (SCN). 541 3.41. Operations System (OS): 543 A system that performs the functions that support processing of 544 information related to operations, administration, maintenance, and 545 provisioning (OAM&P) for the networks, including surveillance and 546 testing functions to support customer access maintenance. 548 3.42. OAM flow: 550 An OAM flow is the set of all OAM packets originating with a 551 specific source MEP that instrument one direction of a MEG (or 552 possibly both in the special case of data plane loopback). 554 3.43. Maintenance Entity Group (MEG): 556 A Maintenance Entity Group is defined, for the purpose of connection 557 monitoring, between a set of connection points within a connection. 558 This set of connection points may be located at the boundary of one 559 administrative domain or a protection domain, or the boundaries of 560 two adjacent administrative domains. The MEG may consist of one or 561 more Maintenance Entities (ME). 563 In an MPLS-TP layer network an MEG consists of only one ME. 565 3.44. Maintenance Entity (ME): 567 A Maintenance Entity can be viewed as the association of two (or 568 more) MEG End Points (MEPs), that should be configured and managed 569 in order to bound the OAM responsibilities of an OAM flow across a 570 network or sub-network, i.e. a transport path or segment, in the 571 specific layer network that is being monitored and managed. 573 A Maintenance Entity may be defined to monitor and manage 574 bidirectional or unidirectional point-to-point connectivity or 575 point-to-multipoint connectivity in an MPLS-TP layer network. 577 Therefore, in the context of MPLS-TP LSP or PW Maintenance Entity 578 (defined below) LERs and T-PEs can be MEPs while LSRs and S-PEs can 579 be MIPs. In the case of Tandem Connection Maintenance Entity 580 (defined below), LSRs and S-PEs can be either MEPs or MIPs. 582 The following properties apply to all MPLS-TP MEs: 584 o OAM entities can be nested but not overlapped. 586 o Each OAM flow is associated to a unique Maintenance Entity. 588 o OAM packets are subject to the same forwarding treatment as the 589 data traffic, but they are distinct from the data traffic. 591 3.45. Maintenance Entity Group End Point (MEP): 593 Maintenance Entity Group End Points (MEPs) are the end points of a 594 pre-configured (through the management or control planes) ME. MEPs 595 are responsible for activating and controlling all of the OAM 596 functionality for the ME. A MEP may initiate an OAM packet to be 597 transferred to its corresponding MEP, or to an intermediate MIP that 598 is part of the ME. 600 A MEP terminates all the OAM packets that it receives corresponding 601 to its ME and does not forward them further along the path. 603 All OAM packets coming to a MEP source are tunnelled via label 604 stacking and are not processed within the ME as they belong either 605 to the client network layers or to an higher TCM level. 607 A MEP in a tandem connection is not coincident with the termination 608 of the MPLS-TP transport path (LSP or PW), though it can monitor its 609 connectivity (e.g. count packets). A MEP of an MPLS-TP network 610 transport path is coincident with transport path termination and 611 monitors its connectivity (e.g. count packets). 613 MPLS-TP MEP notifies a fault indication to the MPLS-TP client layer 614 network. 616 3.46. Maintenance Entity Group Intermediate Point (MIP): 618 A Maintenance Entity Group Intermediate Point (MIP) is a point 619 between the two MEPs in an ME and is capable of responding to some 620 OAM packets and forwarding all OAM packets while ensuring fate 621 sharing with data plane packets. A MIP responds only to OAM packets 622 that are sent on the ME it belongs to and that are addressed to the 623 MIP, it does not initiate OAM messages. 625 3.47. Server MEPs: 627 A server MEP is a MEP of an ME that is defined in a layer network 628 below the MPLS-TP layer network being referenced. A server MEP 629 coincides with either a MIP or a MEP in the client (MPLS-TP) layer 630 network. 632 For example, a server MEP can be either: 634 . A termination point of a physical link (e.g. 802.3), an SDH VC or 635 OTH ODU for the MPLS-TP Section layer network, defined in 636 [RFC6371] section 3.1.; 638 . An MPLS-TP Section MEP for MPLS-TP LSPs, defined in [RFC6371] 639 section 3.2.; 641 . An MPLS-TP LSP MEP for MPLS-TP PWs, defined in [RFC6371] section 642 3.4.; 644 . An MPLS-TP TCM MEP for higher-level TCMs, defined in [RFC6371] 645 sections 3.3. and 3.5. 647 The server MEP can run appropriate OAM functions for fault 648 detection, and notifies a fault indication to the MPLS-TP layer 649 network. 651 3.48. Link recovery: 653 MPLS-TP link recovery refers to the recovery of an individual link 654 (and hence all or a subset of the LSPs routed over the link) between 655 two MPLS-TP nodes. For example, link recovery may be provided by 656 server layer recovery. 658 3.49. Segment recovery: 660 Segment recovery refers to the recovery of an LSP segment (i.e., 661 segment and concatenated segment in the language of [RFC5654]) 662 between two nodes and is used to recover from the failure of one or 663 more links or nodes. 665 3.50. End-to-end recovery: 667 End-to-end recovery refers to the recovery of an entire LSP, from 668 its ingress to its egress node. 670 3.51. Transport Entity: 672 A "Transport Entity" is a node, link, transport path segment, 673 concatenated transport path segment, or entire transport path. 675 3.52. Working Entity: 677 A "Working Entity" is a transport entity that carries traffic during 678 normal network operation. 680 3.53. Protection Entity: 682 A "Protection Entity" is a transport entity that is pre-allocated 683 and used to protect and transport traffic when the working entity 684 fails. 686 3.54. Recovery entity: 688 A "Recovery Entity" is a transport entity that is used to recover 689 and transport traffic when the working entity fails. 691 4. Guidance on the Application of this Thesaurus 693 As discussed in the introduction to this document, this thesaurus is 694 intended to bring the concepts and terms associated with MPLS-TP 695 into the context of the ITU-T's Transport Network architecture. 696 Thus, it should help those familiar with MPLS to see how they may 697 use the features and functions of the Transport Network in order to 698 meet the requirements of MPLS-TP. 700 This lexicography should not be used in order to obtain or derive 701 definitive definitions of GMPLS terms. To obtain definitions of 702 GMPLS terms that are applicable across all GMPLS architectural 703 models, the reader should refer to the RFCs listed in the references 704 sections of this document. [RFC3945] provides an overview of the 705 GMPLS architecture and should be read first. 707 5. Management Considerations 709 The MPLS-TP based network requires management. The MPLS-TP 710 specifications include considerable efforts to provide operator 711 control and monitoring, as well as Operations and Management (OAM) 712 functionality. 714 These concepts are, however, out of scope of this document. 716 6. Security Considerations 718 Security is also a significant requirement of MPLS-TP. 720 However, this informational document is intended only to provide a 721 lexicography, and the security concerns are, therefore, out of 722 scope. 724 7. IANA Considerations 726 To be incorporated in a future revision of this document 728 <> 730 8. Acknowledgments 732 The authors would like to thank all members of the teams (the Joint 733 Working Team, the MPLS Interoperability Design Team in IETF and the 734 MPLS-TP Ad Hoc Group in ITU-T) involved in the definition and 735 specification of MPLS Transport Profile. 737 9. References 739 9.1. Normative References 741 [RFC6371] Busi, I., Allan, D., "Operations, Administration, and 742 Maintenance Framework for MPLS-Based Transport Networks", 743 September 2011 745 [RFC6372] Sprecher, N., Farrel, A., "MPLS Transport Profile (MPLS- 746 TP) Survivability Framework", September 2011 748 [RFC5654] B. Niven-Jenkins, et al., "Requirements of an MPLS 749 Transport Profile", September 2009 751 [RFC5921] Bocci, M., Bryant, S., Levrau, L., "A Framework for MPLS 752 in Transport Networks", July 2010 754 [RFC5860] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM 755 in MPLS Transport Networks", May 2010 757 [RFC5951] Gray, E., Mansfield, S., et al., "MPLS TP Network 758 Management Requirements", September 2010 760 [RFC3031] E. Rosen, et al., "Requirements of an MPLS Transport 761 Profile", january 2001 763 For information on the availability of the following documents, 764 please see http://www.itu.int 766 [ITU-T_G.8101] ITU-T Recommendation G.8101/Y.1355 (12/2006), Terms 767 and definitions for transport MPLS. 769 [ITU-T_G.805] ITU-T Recommendation G.805 (03/2000), Generic 770 functional architecture of transport networks. 772 [ITU-T_G.806] ITU-T Recommendation G.806 (03/2006), Characteristics 773 of transport equipment - Description methodology and 774 generic functionality. 776 [ITU-T_G.872] ITU-T Recommendation G.872 (11/2001), Architecture of 777 optical transport networks. 779 [ITU-T G.7710] ITU-T Recommendation G.7710 (07/2007), Common 780 equipment management function requirements 782 [ITU-T Y.2611] ITU-T Recommendation Y.2611 (12/2006), High-level 783 architecture of future packet-based networks 785 9.2. Informative References 787 [RFC4397] I. Bryskin, A. Farrel, "A Lexicography for the 788 Interpretation of Generalized Multiprotocol Label 789 Switching (GMPLS) Terminology within the Context of the 790 ITU-T's Automatically Switched Optical Network (ASON) 791 Architecture", february 2006 793 [RFC3945] E. Mannie, "Generalized Multi-Protocol Label Switching 794 (GMPLS) Architecture", October 2004 796 Authors' Addresses 798 Huub van Helvoort (Editor) 799 Huawei Technologies Co., Ltd. 800 Email: Huub.van.Helvoort@huawei.com 802 Loa Andersson (Editor) 803 Ericsson 804 Email: loa.andersson@ericsson.com 806 Nurit Sprecher (Editor) 807 Nokia Siemens Networks 808 Email: nurit.sprecher@nsn.com 810 Contributing Authors' Addresses