idnits 2.17.1 draft-ietf-mpls-tp-rosetta-stone-06.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 (July 16, 2012) is 4274 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '5' on line 636 == Missing Reference: 'RFC3945' is mentioned on line 696, but not defined == Unused Reference: 'RFC6371' is defined on line 733, but no explicit reference was found in the text == Unused Reference: 'RFC6372' is defined on line 737, but no explicit reference was found in the text == Unused Reference: 'RFC5921' is defined on line 743, but no explicit reference was found in the text == Unused Reference: 'RFC5860' is defined on line 746, but no explicit reference was found in the text == Unused Reference: 'ITU-T Y.2611' is defined on line 782, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). 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: January 2013 L. Andersson (Ed) 5 Ericsson 7 N. Sprecher (Ed) 8 Nokia Siemens Networks 10 July 16, 2012 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-06 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 January 2013. 40 Copyright Notice 42 Copyright (c) 2010 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 6 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: 10 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): 11 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 17 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 Throughout this document, angle brackets ("<" and ">") are used to 211 indicate that the term is used by both IETF and ITU-T but has a 212 different definition. The bracketed term is the IETF term. 214 [editor: check all terms used that this applies to, TBD] 216 2.1. MPLS-TP Terminology Sources 218 MPLS-TP terminology is principally defined in [RFC3031]. Other 219 documents provide further key definitions including [RFC4397], and 220 [RFC....]. 222 2.2. ITU-T Transport Network Terminology Sources 224 The ITU-T Transport Network is specified in a number of 225 recommendations: generic functional architectures and requirements 226 are specified in [ITU-T_G.805], [ITU-T_G.806], and [ITU-T_G.872]. 227 ITU-T Recommendation [ITU-T_G.8101] contains an overview of the 228 Terms and Definitions for transport MPLS. 230 2.3. Common Terminology Sources 232 The work in this document builds on the shared view of MPLS 233 requirements. 235 3. Thesaurus 237 3.1. Associated bidirectional path: 239 A path that supports traffic flow in both directions but that is 240 constructed from a pair of unidirectional paths (one for each 241 direction) that are associated with one another at the path's 242 ingress/egress points. The forward and backward directions are 243 setup, monitored, and protected independently. As a consequence, 244 they may or may not follow the same route (links and nodes) across 245 the network. 247 3.2. Bidirectional path: 249 A path that supports traffic flow in two opposite directions, i.e. 250 the forward and backward direction. 252 3.3. Client layer network: 254 In a client/server relationship (see [ITU-T_G.805]), the client 255 layer network receives a (transport) service from the lower server 256 layer network (usually the layer network under consideration). 258 3.4. Concatenated Segment: 260 A serial-compound link connection as defined in [ITU-T_G.805]. A 261 concatenated segment is a contiguous part of an LSP or multi-segment 262 PW that comprises a set of segments and their interconnecting nodes 263 in sequence. See also "Segment". 265 3.5. Control Plane: 267 Within the scope of [RFC5654], the control plane performs transport 268 path control functions. Through signalling, the control plane sets 269 up, modifies and releases transport paths, and may recover a 270 transport path in case of a failure. The control plane also 271 performs other functions in support of transport path control, such 272 as routing information dissemination. 274 3.6. Co-routed bidirectional path: 276 A path where the forward and backward directions follow the same 277 route (links and nodes) across the network. Both directions are 278 setup, monitored and protected as a single entity. A transport 279 network path is typically co-routed. 281 3.7. Domain: 283 A domain represents a collection of entities (for example network 284 elements) that are grouped for a particular purpose, examples of 285 which are administrative and/or managerial responsibilities, trust 286 relationships, addressing schemes, infrastructure capabilities, 287 aggregation, survivability techniques, distributions of control 288 functionality, etc. Examples of such domains include IGP areas and 289 Autonomous Systems. 291 3.8. Layer network: 293 Layer network is defined in [ITU-T_G.805]. A layer network provides 294 for the transfer of client information and independent operation of 295 the client OAM. A layer network may be described in a service 296 context as follows: one layer network may provide a (transport) 297 service to a higher client layer network and may, in turn, be a 298 client to a lower-layer network. A layer network is a logical 299 construction somewhat independent of arrangement or composition of 300 physical network elements. A particular physical network element 301 may topologically belong to more than one layer network, depending 302 on the actions it takes on the encapsulation associated with the 303 logical layers (e.g., the label stack), and thus could be modeled as 304 multiple logical elements. A layer network may consist of one or 305 more sublayers. For additional explanation of how layer networks 306 relate to the OSI concept of layering, see Appendix I of [ITU-T 307 Y.2611]. 309 3.9. Link: 311 A physical or logical connection between a pair of LSRs that are 312 adjacent at the (sub)layer network under consideration. A link may 313 carry zero, one or more LSPs or PWs. A packet entering a link will 314 emerge with the same label stack entry values. 316 A link as defined in [ITU-T_G.805] is used to describe a fixed 317 relationship between two ports. 319 3.10. MPLS-TP Logical Ring: 321 An MPLS-TP logical ring is constructed from a set of LSRs and 322 logical data links (such as MPLS-TP LSP tunnels or MSPL-TP 323 pseudowires) and physical data links that form a ring topology. 325 3.11. MPLS-TP Physical Ring: 327 An MPLS-TP physical ring is constructed from a set of LSRs and 328 physical data links that form a ring topology. 330 3.12. MPLS-TP Ring Topology: 332 In an MPLS-TP ring topology, each LSR is connected to exactly two 333 other LSRs, each via a single point-to-point bidirectional MPLS-TP 334 capable link. A ring may also be constructed from only two LSRs 335 where there are also exactly two links. Rings may be connected to 336 other LSRs to form a larger network. Traffic originating or 337 terminating outside the ring may be carried over the ring. Client 338 network nodes (such as CEs) may be connected directly to an LSR in 339 the ring. 341 3.13. Path: 343 See Transport path. 345 3.14. Section Layer Network: 347 A section layer is a server layer (which may be MPLS-TP or a 348 different technology) that provides for the transfer of the section- 349 layer client information between adjacent nodes in the transport- 350 path layer or transport-service layer. A section layer may provide 351 for aggregation of multiple MPLS-TP clients. Note that [ITU- 352 T_G.805] defines the section layer as one of the two layer networks 353 in a transmission-media layer network. The other layer network is 354 the physical-media layer network. 356 Section layer networks are concerned with all the functions which 357 provide for the transfer of information between locations in path 358 layer networks. 360 Physical media layer networks are concerned with the actual fibres, 361 metallic wires or radio frequency channels which support a section 362 layer network. 364 3.15. Segment: 366 A link connection as defined in [ITU-T_G.805]. A segment is the 367 part of an LSP that traverses a single link or the part of a PW that 368 traverses a single link (i.e., that connects a pair of adjacent 369 {Switching|Terminating} Provider Edges). See also "Concatenated 370 Segment". 372 3.16. Server layer: 374 A layer network in which transport paths are used to carry a 375 customer's (individual or bundled) service (may be point-to-point, 376 point-to-multipoint or multipoint-to-multipoint services). 378 In a client/server relationship (see [ITU-T_G.805]). the server 379 layer network provides a (transport) service to the higher client 380 layer network (usually the layer network under consideration). 382 3.17. Span: 384 A span is synonymous with a link. 386 3.18. Sublayer: 388 Sublayer is defined in [ITU-T_G.805]. The distinction between a 389 layer network and a sublayer is that a sublayer is not directly 390 accessible to clients outside of its encapsulating layer network and 391 offers no direct transport service for a higher layer (client) 392 network. 394 3.19. Tandem Connection: 396 A tandem connection is an arbitrary part of a transport path that 397 can be monitored (via OAM) independently from the end-to-end 398 monitoring (OAM). It may be a monitored segment, a monitored 399 concatenated segment or any other monitored ordered sequence of 400 contiguous hops and/or segments (and their interconnecting nodes) of 401 a transport path. 403 3.20. Transport Network: 405 A Transport Network provides transmission of traffic between 406 attached client devices by establishing and maintaining point-to- 407 point or point-to-multipoint connections between such devices. A 408 Transport Network is independent of any higher-layer network that 409 may exist between clients, except to the extent required to supply 410 this transmission service. In addition to client traffic, a 411 Transport Network may carry traffic to facilitate its own operation, 412 such as that required to support connection control, network 413 management, and Operations, Administration and Maintenance (OAM) 414 functions. 416 3.21. Transport path: 418 A network connection as defined in [ITU-T_G.805]. In an MPLS-TP 419 environment a transport path corresponds to an LSP or a PW. 421 3.22. Transport path layer: 423 A (sub)layer network that provides point-to-point or point-to- 424 multipoint transport paths. It provides OAM that is independent of 425 the clients that it is transporting. 427 3.23. Transport service layer: 429 A layer network in which transport paths are used to carry a 430 customer's (individual or bundled) service (may be point-to-point, 431 point-to-multipoint or multipoint-to-multipoint services). 433 3.24. Transmission media layer: 435 A layer network, consisting of a section layer network and a 436 physical layer network as defined in [ITU-T_G.805], that provides 437 sections (two-port point-to-point connections) to carry the 438 aggregate of network-transport path or network-service layers on 439 various physical media. 441 3.25. Unidirectional path: 443 A Unidirectional Path is a path that supports traffic flow in only 444 one direction. 446 3.26. Failure: 448 The fault cause persisted long enough to consider the ability of an 449 item to perform a required function to be terminated. The item may 450 be considered as failed; a fault has now been detected. See also 451 [ITU-T_G.806]. 453 3.27. Fault: 455 A Fault is the inability of a function to perform a required action. 456 This does not include an inability due to preventive maintenance, 457 lack of external resources, or planned actions. See also [ITU- 458 T_G.806]. 460 3.28. Defect: 462 The situation for which the density of anomalies has reached a level 463 where the ability to perform a required function has been 464 interrupted. Defects are used as input for PM, the control of 465 consequent actions, and the determination of fault cause. See also 466 [ITU-T_G.806]. 468 3.29. MPLS Transport Profile (MPLS-TP): 470 The set of MPLS functions used to support packet transport services 471 and network operations. 473 3.30. MPLS Section: 475 A network segment between two LSRs that are immediately adjacent at 476 the MPLS layer. 478 3.31. MPLS-TP NE: 480 A network element (NE) that supports MPLS-TP functions. 482 3.32. MPLS-TP network: 484 A network in which MPLS-TP NEs are deployed 486 3.33. Equipment Management Function (EMF): 488 The management functions within an NE. See [ITU-T G.7710]. 490 3.34. Data Communication Network (DCN): 492 A network that supports Layer 1 (physical layer), Layer 2 (data-link 493 layer), and Layer 3 (network layer) functionality for distributed 494 management communications related to the management plane, for 495 distributed signaling communications related to the control plane, 496 and other operations communications (e.g., order-wire/voice 497 communications, software downloads, etc.). 499 3.35. Communication Channel (CC): 501 A logical channel between network elements (NEs) that can be used - 502 e.g. - for management plane application or control plane 503 applications. The physical channel supporting the CC is technology 504 specific. See [RFC5951] APPENDIX A 506 3.36. Embedded Communication Channel (ECC): 508 A logical operations channel between network elements (NEs) that can 509 be utilized by multiple applications (e.g., management plane 510 applications, control plane applications, etc.). The physical 511 channel supporting the ECC is technology specific. An example of 512 physical channels supporting the ECC is a DCC channel within SDH. 514 3.37. Management Communication Channel (MCC): 516 A CC dedicated for management plane communications. 518 3.38. Management Communication Network (MCN): 520 A DCN supporting management plane communication is referred to as a 521 Management Communication Network (MCN). 523 3.39. Signaling Communication Channel (SCC): 525 A CC dedicated for control plane communications. The SCC may be used 526 for GMPLS/ASON signaling and/or other control plane messages (e.g., 527 routing messages). 529 3.40. Signaling Communication Network (SCN): 531 A DCN supporting control plane communication is referred to as a 532 Signaling Communication Network (SCN). 534 3.41. Operations System (OS): 536 A system that performs the functions that support processing of 537 information related to operations, administration, maintenance, and 538 provisioning (OAM&P) for the networks, including surveillance and 539 testing functions to support customer access maintenance. 541 3.42. OAM flow: 543 An OAM flow is the set of all OAM packets originating with a 544 specific source MEP that instrument one direction of a MEG (or 545 possibly both in the special case of data plane loopback). 547 3.43. Maintenance Entity Group (MEG): 549 A Maintenance Entity Group is defined, for the purpose of connection 550 monitoring, between a set of connection points within a connection. 551 This set of connection points may be located at the boundary of one 552 administrative domain or a protection domain, or the boundaries of 553 two adjacent administrative domains. The MEG may consist of one or 554 more Maintenance Entities (ME). 556 In an MPLS-TP layer network an MEG consists of only one ME. 558 3.44. Maintenance Entity (ME): 560 A Maintenance Entity can be viewed as the association of two (or 561 more) MEG End Points (MEPs), that should be configured and managed 562 in order to bound the OAM responsibilities of an OAM flow across a 563 network or sub-network, i.e. a transport path or segment, in the 564 specific layer network that is being monitored and managed. 566 A Maintenance Entity may be defined to monitor and manage 567 bidirectional or unidirectional point-to-point connectivity or 568 point-to-multipoint connectivity in an MPLS-TP layer network. 570 Therefore, in the context of MPLS-TP LSP or PW Maintenance Entity 571 (defined below) LERs and T-PEs can be MEPs while LSRs and S-PEs can 572 be MIPs. In the case of Tandem Connection Maintenance Entity 573 (defined below), LSRs and S-PEs can be either MEPs or MIPs. 575 The following properties apply to all MPLS-TP MEs: 577 o OAM entities can be nested but not overlapped. 579 o Each OAM flow is associated to a unique Maintenance Entity. 581 o OAM packets are subject to the same forwarding treatment as the 582 data traffic, but they are distinct from the data traffic. 584 3.45. Maintenance Entity Group End Point (MEP): 586 Maintenance Entity Group End Points (MEPs) are the end points of a 587 pre-configured (through the management or control planes) ME. MEPs 588 are responsible for activating and controlling all of the OAM 589 functionality for the ME. A MEP may initiate an OAM packet to be 590 transferred to its corresponding MEP, or to an intermediate MIP that 591 is part of the ME. 593 A MEP terminates all the OAM packets that it receives corresponding 594 to its ME and does not forward them further along the path. 596 All OAM packets coming to a MEP source are tunnelled via label 597 stacking and are not processed within the ME as they belong either 598 to the client network layers or to an higher TCM level. 600 A MEP in a tandem connection is not coincident with the termination 601 of the MPLS-TP transport path (LSP or PW), though it can monitor its 602 connectivity (e.g. count packets). A MEP of an MPLS-TP network 603 transport path is coincident with transport path termination and 604 monitors its connectivity (e.g. count packets). 606 MPLS-TP MEP notifies a fault indication to the MPLS-TP client layer 607 network. 609 3.46. Maintenance Entity Group Intermediate Point (MIP): 611 A Maintenance Entity Group Intermediate Point (MIP) is a point 612 between the two MEPs in an ME and is capable of responding to some 613 OAM packets and forwarding all OAM packets while ensuring fate 614 sharing with data plane packets. A MIP responds only to OAM packets 615 that are sent on the ME it belongs to and that are addressed to the 616 MIP, it does not initiate OAM messages. 618 3.47. Server MEPs: 620 A server MEP is a MEP of an ME that is defined in a layer network 621 below the MPLS-TP layer network being referenced. A server MEP 622 coincides with either a MIP or a MEP in the client (MPLS-TP) layer 623 network. 625 For example, a server MEP can be either: 627 . A termination point of a physical link (e.g. 802.3), an SDH VC or 628 OTH ODU for the MPLS-TP Section layer network, defined in [5] 629 section 3.1.; 631 . An MPLS-TP Section MEP for MPLS-TP LSPs, defined in [5] section 632 3.2.; 634 . An MPLS-TP LSP MEP for MPLS-TP PWs, defined in [5] section 3.4.; 636 . An MPLS-TP TCM MEP for higher-level TCMs, defined in [5] sections 637 3.3. and 3.5. 639 The server MEP can run appropriate OAM functions for fault 640 detection, and notifies a fault indication to the MPLS-TP layer 641 network. 643 3.48. Link recovery: 645 MPLS-TP link recovery refers to the recovery of an individual link 646 (and hence all or a subset of the LSPs routed over the link) between 647 two MPLS-TP nodes. For example, link recovery may be provided by 648 server layer recovery. 650 3.49. Segment recovery: 652 Segment recovery refers to the recovery of an LSP segment (i.e., 653 segment and concatenated segment in the language of [RFC5654]) 654 between two nodes and is used to recover from the failure of one or 655 more links or nodes. 657 3.50. End-to-end recovery: 659 End-to-end recovery refers to the recovery of an entire LSP, from 660 its ingress to its egress node. 662 3.51. Transport Entity: 664 A "Transport Entity" is a node, link, transport path segment, 665 concatenated transport path segment, or entire transport path. 667 3.52. Working Entity: 669 A "Working Entity" is a transport entity that carries traffic during 670 normal network operation. 672 3.53. Protection Entity: 674 A "Protection Entity" is a transport entity that is pre-allocated 675 and used to protect and transport traffic when the working entity 676 fails. 678 3.54. Recovery entity: 680 A "Recovery Entity" is a transport entity that is used to recover 681 and transport traffic when the working entity fails. 683 4. Guidance on the Application of this Thesaurus 685 As discussed in the introduction to this document, this thesaurus is 686 intended to bring the concepts and terms associated with MPLS-TP 687 into the context of the ITU-T's Transport Network architecture. 688 Thus, it should help those familiar with MPLS to see how they may 689 use the features and functions of the Transport Network in order to 690 meet the requirements of MPLS-TP. 692 This lexicography should not be used in order to obtain or derive 693 definitive definitions of GMPLS terms. To obtain definitions of 694 GMPLS terms that are applicable across all GMPLS architectural 695 models, the reader should refer to the RFCs listed in the references 696 sections of this document. [RFC3945] provides an overview of the 697 GMPLS architecture and should be read first. 699 5. Management Considerations 701 The MPLS-TP based network requires management. The MPLS-TP 702 specifications include considerable efforts to provide operator 703 control and monitoring, as well as Operations and Management (OAM) 704 functionality. 706 These concepts are, however, out of scope of this document. 708 6. Security Considerations 710 Security is also a significant requirement of MPLS-TP. 712 However, this informational document is intended only to provide a 713 lexicography, and the security concerns are, therefore, out of 714 scope. 716 7. IANA Considerations 718 To be incorporated in a future revision of this document 720 <> 722 8. Acknowledgments 724 The authors would like to thank all members of the teams (the Joint 725 Working Team, the MPLS Interoperability Design Team in IETF and the 726 MPLS-TP Ad Hoc Group in ITU-T) involved in the definition and 727 specification of MPLS Transport Profile. 729 9. References 731 9.1. Normative References 733 [RFC6371] Busi, I., Allan, D., "Operations, Administration, and 734 Maintenance Framework for MPLS-Based Transport Networks", 735 September 2011 737 [RFC6372] Sprecher, N., Farrel, A., "MPLS Transport Profile (MPLS- 738 TP) Survivability Framework", September 2011 740 [RFC5654] B. Niven-Jenkins, et al., "Requirements of an MPLS 741 Transport Profile", September 2009 743 [RFC5921] Bocci, M., Bryant, S., Levrau, L., "A Framework for MPLS 744 in Transport Networks", July 2010 746 [RFC5860] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM 747 in MPLS Transport Networks", May 2010 749 [RFC5951] Gray, E., Mansfield, S., et al., "MPLS TP Network 750 Management Requirements", September 2010 752 [RFC3031] E. Rosen, etal., "Requirements of an MPLS Transport 753 Profile", january 2001 755 [RFC4397] I. Bryskin, A. Farrel, "A Lexicography for the 756 Interpretation of Generalized Multiprotocol Label 757 Switching (GMPLS) Terminology within the Context of the 758 ITU-T's Automatically Switched Optical Network (ASON) 759 Architecture", february 2006 761 9.2. Informative References 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 Authors' Addresses 787 Huub van Helvoort (Editor) 788 Huawei Technologies Co., Ltd. 789 Email: Huub.van.Helvoort@huawei.com 791 Loa Andersson (Editor) 792 Ericsson 793 Email: loa.andersson@ericsson.com 795 Nurit Sprecher (Editor) 796 Nokia Siemens Networks 797 Email: nurit.sprecher@nsn.com 799 Contributing Authors' Addresses