idnits 2.17.1 draft-ietf-mpls-tp-rosetta-stone-05.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 17, 2012) is 4482 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '5' on line 627 == Missing Reference: 'RFC3945' is mentioned on line 820, but not defined == Unused Reference: 'ITU-T Y.2611' is defined on line 915, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 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: July 2012July L. Andersson (Ed) 5 Ericsson 7 N. Sprecher (Ed) 8 Nokia Siemens Networks 10 January 17, 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-05 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 on July 2012. 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 3 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 5 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: 6 88 3.7. Domain: 6 89 3.8. Layer network: 7 90 3.9. Link: 7 91 3.10. MPLS-TP Logical Ring: 7 92 3.11. MPLS-TP Physical Ring: 7 93 3.12. MPLS-TP Ring Topology: 8 94 3.13. Path: 8 95 3.14. Section Layer Network: 8 96 3.15. Segment: 8 97 3.16. Server layer: 8 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: 9 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: 10 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): 11 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. Maintenance Entity 12 124 3.43. Maintenance End Points (MEPs) 13 125 3.44. Maintenance Intermediate Points (MIPs) 13 126 3.45. Server MEPs 14 127 4. Guidance on the Application of this Thesaurus 18 128 5. Management Considerations 18 129 6. Security Considerations 18 130 7. IANA Considerations 18 131 8. Acknowledgments 19 132 9. References 19 133 9.1. Normative References 19 134 9.2. Informative References 19 136 1. Introduction 138 Multiprotocol Label Switching - Transport Profile (MPLS-TP) has been 139 developed by the IETF to facilitate the Operation, Administration 140 and Management of Label Switched Paths (LSPs) in a Transport Network 141 environment as defined by the ITU-T. 143 The ITU-T has specified a Transport Network architecture for the 144 transfer of signals from different technologies. This architecture 145 forms the basis of many Recommendations within the ITU-T. 147 Because of the difference in historic background of MPLS, and 148 inherently MPLS-TP (the Internet) and the Transport Network (ITU 149 telecommunication Sector), the terminology used is different. 151 This document provides a thesaurus for the interpretation of ITU-T 152 Transport Network terminology within the context of the MPLS-TP. 153 This allows MPLS-TP documents to be generally understood by those 154 familiar with MPLS RFCs. The definitions presented in this document 155 do not provide exclusive or complete interpretations of the ITU-T 156 Transport Network concepts. 158 1.1. Contributing Authors 160 Italo Busi, Ben Niven-Jenkins, Enrique Hernandez-Valencia, Lieven 161 Levrau, Dinesh Mohan, Stuart Bryant, Dan Frost, Matthew Bocci, 162 Vincenzo Sestito, Vigoureux, Yaacov Weingarten 164 1.2. Abbreviations 166 CC Communications Channel 168 DCN Data Communication Network 170 ECC Embedded Communication Channel 172 EMF Equipment Management Function 174 MCC Management Communication Channel 176 MCN Management Communication Network 178 ME Maintenance Entity 180 MEG ME Group 182 MEP MEG End Point 184 MIP MEG Intermediate Point 186 MPLS Multiprotocol Label Switching 188 MPLS-TP MPLS Transport Profile 189 NE Network Element 191 OAM Operations, Administration and Maintenance 193 O&M OAM and Management 195 SCC Signaling Communication Channel 197 SCN Signaling Communication Network 199 2. Terminology 201 Throughout this document, angle brackets ("<" and ">") are used to 202 indicate that the term is used by both IETF and ITU-T but has a 203 different definition. The bracketed term is the IETF term. 205 [editor: check all terms used that this applies to, TBD] 207 2.1. MPLS-TP Terminology Sources 209 MPLS-TP terminology is principally defined in [RFC3031]. Other 210 documents provide further key definitions including [RFC4397], and 211 [RFC....]. 213 2.2. ITU-T Transport Network Terminology Sources 215 The ITU-T Transport Network is specified in a number of 216 recommendations: generic functional architectures and requirements 217 are specified in [ITU-T_G.805], [ITU-T_G.806], and [ITU-T_G.872]. 218 [ITU-T_G.8101] contains an overview of the Terms and Definitions for 219 transport MPLS. 221 2.3. Common Terminology Sources 223 The work in this document builds on the shared view of MPLS 224 requirements. 226 3. Thesaurus 228 [editor: from [RFC5654] mpls-tp-requirements == complete] 230 3.1. Associated bidirectional path: 232 A path that supports traffic flow in both directions but that is 233 constructed from a pair of unidirectional paths (one for each 234 direction) that are associated with one another at the path's 235 ingress/egress points. The forward and backward directions are 236 setup, monitored, and protected independently. As a consequence, 237 they may or may not follow the same route (links and nodes) across 238 the network. 240 3.2. Bidirectional path: 242 A path that supports traffic flow in two opposite directions, i.e. 243 the forward and backward direction. 245 3.3. Client layer network: 247 In a client/server relationship (see [ITU-T_G.805]), the client 248 layer network receives a (transport) service from the lower server 249 layer network (usually the layer network under consideration). 251 3.4. Concatenated Segment: 253 A serial-compound link connection as defined in [ITU-T_G.805]. A 254 concatenated segment is a contiguous part of an LSP or multi-segment 255 PW that comprises a set of segments and their interconnecting nodes 256 in sequence. See also "Segment". 258 3.5. Control Plane: 260 Within the scope of [RFC5654], the control plane performs transport 261 path control functions. Through signalling, the control plane sets 262 up, modifies and releases transport paths, and may recover a 263 transport path in case of a failure. The control plane also 264 performs other functions in support of transport path control, such 265 as routing information dissemination. 267 3.6. Co-routed bidirectional path: 269 A path where the forward and backward directions follow the same 270 route (links and nodes) across the network. Both directions are 271 setup, monitored and protected as a single entity. A transport 272 network path is typically co-routed. 274 3.7. Domain: 276 A domain represents a collection of entities (for example network 277 elements) that are grouped for a particular purpose, examples of 278 which are administrative and/or managerial responsibilities, trust 279 relationships, addressing schemes, infrastructure capabilities, 280 aggregation, survivability techniques, distributions of control 281 functionality, etc. Examples of such domains include IGP areas and 282 Autonomous Systems. 284 3.8. Layer network: 286 Layer network is defined in [ITU-T_G.805]. A layer network provides 287 for the transfer of client information and independent operation of 288 the client OAM. A layer network may be described in a service 289 context as follows: one layer network may provide a (transport) 290 service to a higher client layer network and may, in turn, be a 291 client to a lower-layer network. A layer network is a logical 292 construction somewhat independent of arrangement or composition of 293 physical network elements. A particular physical network element 294 may topologically belong to more than one layer network, depending 295 on the actions it takes on the encapsulation associated with the 296 logical layers (e.g., the label stack), and thus could be modeled as 297 multiple logical elements. A layer network may consist of one or 298 more sublayers. For additional explanation of how layer networks 299 relate to the OSI concept of layering, see Appendix I of [ITU-T 300 Y.2611]. 302 3.9. Link: 304 A physical or logical connection between a pair of LSRs that are 305 adjacent at the (sub)layer network under consideration. A link may 306 carry zero, one or more LSPs or PWs. A packet entering a link will 307 emerge with the same label stack entry values. 309 A link as defined in [ITU-T_G.805] is used to describe a fixed 310 relationship between two ports. 312 3.10. MPLS-TP Logical Ring: 314 An MPLS-TP logical ring is constructed from a set of LSRs and 315 logical data links (such as MPLS-TP LSP tunnels or MSPL-TP 316 pseudowires) and physical data links that form a ring topology. 318 3.11. MPLS-TP Physical Ring: 320 An MPLS-TP physical ring is constructed from a set of LSRs and 321 physical data links that form a ring topology. 323 3.12. MPLS-TP Ring Topology: 325 In an MPLS-TP ring topology, each LSR is connected to exactly two 326 other LSRs, each via a single point-to-point bidirectional MPLS-TP 327 capable link. A ring may also be constructed from only two LSRs 328 where there are also exactly two links. Rings may be connected to 329 other LSRs to form a larger network. Traffic originating or 330 terminating outside the ring may be carried over the ring. Client 331 network nodes (such as CEs) may be connected directly to an LSR in 332 the ring. 334 3.13. Path: 336 See Transport path. 338 3.14. Section Layer Network: 340 A section layer is a server layer (which may be MPLS-TP or a 341 different technology) that provides for the transfer of the section- 342 layer client information between adjacent nodes in the transport- 343 path layer or transport-service layer. A section layer may provide 344 for aggregation of multiple MPLS-TP clients. Note that [ITU- 345 T_G.805] defines the section layer as one of the two layer networks 346 in a transmission-media layer network. The other layer network is 347 the physical-media layer network. 349 Section layer networks are concerned with all the functions which 350 provide for the transfer of information between locations in path 351 layer networks. 353 Physical media layer networks are concerned with the actual fibres, 354 metallic wires or radio frequency channels which support a section 355 layer network. 357 3.15. Segment: 359 A link connection as defined in [ITU-T_G.805]. A segment is the 360 part of an LSP that traverses a single link or the part of a PW that 361 traverses a single link (i.e., that connects a pair of adjacent 362 {Switching|Terminating} Provider Edges). See also "Concatenated 363 Segment". 365 3.16. Server layer: 367 A layer network in which transport paths are used to carry a 368 customer's (individual or bundled) service (may be point-to-point, 369 point-to-multipoint or multipoint-to-multipoint services). 371 In a client/server relationship (see [ITU-T_G.805]). the server 372 layer network provides a (transport) service to the higher client 373 layer network (usually the layer network under consideration). 375 3.17. Span: 377 A span is synonymous with a link. 379 3.18. Sublayer: 381 Sublayer is defined in [ITU-T_G.805]. The distinction between a 382 layer network and a sublayer is that a sublayer is not directly 383 accessible to clients outside of its encapsulating layer network and 384 offers no direct transport service for a higher layer (client) 385 network. 387 3.19. Tandem Connection: 389 A tandem connection is an arbitrary part of a transport path that 390 can be monitored (via OAM) independently from the end-to-end 391 monitoring (OAM). It may be a monitored segment, a monitored 392 concatenated segment or any other monitored ordered sequence of 393 contiguous hops and/or segments (and their interconnecting nodes) of 394 a transport path. 396 [editor: this is not in [RFC5654] but added for completeness] 398 3.20. Transport Network: 400 A Transport Network provides transmission of traffic between 401 attached client devices by establishing and maintaining point-to- 402 point or point-to-multipoint connections between such devices. A 403 Transport Network is independent of any higher-layer network that 404 may exist between clients, except to the extent required to supply 405 this transmission service. In addition to client traffic, a 406 Transport Network may carry traffic to facilitate its own operation, 407 such as that required to support connection control, network 408 management, and Operations, Administration and Maintenance (OAM) 409 functions. 411 3.21. Transport path: 413 A network connection as defined in [ITU-T_G.805]. In an MPLS-TP 414 environment a transport path corresponds to an LSP or a PW. 416 3.22. Transport path layer: 418 A (sub)layer network that provides point-to-point or point-to- 419 multipoint transport paths. It provides OAM that is independent of 420 the clients that it is transporting. 422 3.23. Transport service layer: 424 A layer network in which transport paths are used to carry a 425 customer's (individual or bundled) service (may be point-to-point, 426 point-to-multipoint or multipoint-to-multipoint services). 428 3.24. Transmission media layer: 430 A layer network, consisting of a section layer network and a 431 physical layer network as defined in [ITU-T_G.805], that provides 432 sections (two-port point-to-point connections) to carry the 433 aggregate of network-transport path or network-service layers on 434 various physical media. 436 3.25. Unidirectional path: 438 A path that supports traffic flow in only one direction. 440 [editor: from: [RFC5860] == complete] 442 3.26. Failure: 444 [editor: this is not in [RFC5860] but added for completeness] 446 The fault cause persisted long enough to consider the ability of an 447 item to perform a required function to be terminated. The item may 448 be considered as failed; a fault has now been detected. See also 449 [ITU-T_G.806]. 451 3.27. Fault: 453 The inability of a function to perform a required action. This does 454 not include an inability due to preventive maintenance, lack of 455 external resources, or planned actions. See also [ITU-T_G.806]. 457 3.28. Defect: 459 The situation for which density of anomalies has reached a level 460 where the ability to perform a required function has been 461 interrupted. Defects are used as input for PM, the control of 462 consequent actions, and the determination of fault cause. See also 463 [ITU-T_G.806]. 465 3.29. MPLS Transport Profile (MPLS-TP): 467 The set of MPLS functions used to support packet transport services 468 and network operations. 470 3.30. MPLS Section: 472 A network segment between two LSRs that are immediately adjacent at 473 the MPLS layer. 475 [editor: from: [RFC5921] and [RFC5951] == complete] 477 3.31. MPLS-TP NE: 479 A network element (NE) that supports MPLS-TP functions. 481 3.32. MPLS-TP network: 483 A network in which MPLS-TP NEs are deployed 485 3.33. Equipment Management Function (EMF): 487 The management functions within an NE. See [ITU-T G.7710]. 489 3.34. Data Communication Network (DCN): 491 A network that supports Layer 1 (physical layer), Layer 2 (data-link 492 layer), and Layer 3 (network layer) functionality for distributed 493 management communications related to the management plane, for 494 distributed signaling communications related to the control plane, 495 and other operations communications (e.g., order-wire/voice 496 communications, software downloads, etc.). 498 3.35. Communication Channel (CC): 500 A logical channel between network elements (NEs) that can be used - 501 e.g. - for management plane application or control plane 502 applications. The physical channel supporting the CC is technology 503 specific. See [RFC5951] APPENDIX A 505 3.36. Embedded Communication Channel (ECC): 507 A logical operations channel between network elements (NEs) that can 508 be utilized by multiple applications (e.g., management plane 509 applications, control plane applications, etc.). The physical 510 channel supporting the ECC is technology specific. An example of 511 physical channels supporting the ECC is a DCC channel within SDH. 513 3.37. Management Communication Channel (MCC): 515 A CC dedicated for management plane communications. 517 3.38. Management Communication Network (MCN): 519 A DCN supporting management plane communication is referred to as a 520 Management Communication Network (MCN). 522 3.39. Signaling Communication Channel (SCC): 524 A CC dedicated for control plane communications. The SCC may be used 525 for GMPLS/ASON signaling and/or other control plane messages (e.g., 526 routing messages). 528 3.40. Signaling Communication Network (SCN): 530 A DCN supporting control plane communication is referred to as a 531 Signaling Communication Network (SCN). 533 3.41. Operations System (OS): 535 A system that performs the functions that support processing of 536 information related to operations, administration, maintenance, and 537 provisioning (OAM&P) for the networks, including surveillance and 538 testing functions to support customer access maintenance. 540 [editor: from: OAM Framework RFC [RFC6371] == complete] 542 3.42. OAM flow: 544 The set of all OAM packets originating with a specific source MEP 545 that instrument one direction of a MEG (or possibly both in the 546 special case of data plane loopback). 548 3.43. Maintenance Entity 550 A Maintenance Entity can be viewed as the association of two (or 551 more) Maintenance End Points (MEPs), that should be configured and 552 managed in order to bound the OAM responsibilities of an OAM flow 553 across a network or sub-network, i.e. a transport path or segment, 554 in the specific layer network that is being monitored and managed. 556 A Maintenance Entity may be defined to monitor and manage 557 bidirectional or unidirectional point-to-point connectivity or 558 point-to-multipoint connectivity in an MPLS-TP layer network. 560 [editor: should the following be included?] 562 Therefore, in the context of MPLS-TP LSP or PW Maintenance Entity 563 (defined below) LERs and T-PEs can be MEPs while LSRs and S-PEs can 564 be MIPs. In the case of Tandem Connection Maintenance Entity 565 (defined below), LSRs and S-PEs can be either MEPs or MIPs. 567 The following properties apply to all MPLS-TP MEs: 569 o OAM entities can be nested but not overlapped. 571 o Each OAM flow is associated to a unique Maintenance Entity. 573 o OAM packets are subject to the same forwarding treatment as the 574 data traffic, but they are distinct from the data traffic. 576 3.44. Maintenance End Points (MEPs) 578 Maintenance End Points (MEPs) are the end points of a pre-configured 579 (through the management or control planes) ME. MEPs are responsible 580 for activating and controlling all of the OAM functionality for the 581 ME. A MEP may initiate an OAM packet to be transferred to its 582 corresponding MEP, or to an intermediate MIP that is part of the ME. 584 A MEP terminates all the OAM packets that it receives corresponding 585 to its ME and does not forward them further along the path. 587 All OAM packets coming to a MEP source are tunnelled via label 588 stacking and are not processed within the ME as they belong either 589 to the client network layers or to an higher TCM level. 591 A MEP in a tandem connection is not coincident with the termination 592 of the MPLS-TP transport path (LSP or PW), though it can monitor its 593 connectivity (e.g. count packets). A MEP of an MPLS-TP network 594 transport path is coincident with transport path termination and 595 monitors its connectivity (e.g. count packets). 597 MPLS-TP MEP notifies a fault indication to the MPLS-TP client layer 598 network. 600 3.45. Maintenance Intermediate Points (MIPs) 602 A Maintenance Intermediate Point (MIP) is a point between the two 603 MEPs in an ME and is capable of responding to some OAM packets and 604 forwarding all OAM packets while ensuring fate sharing with data 605 plane packets. A MIP responds only to OAM packets that are sent on 606 the ME it belongs to and that are addressed to the MIP, it does not 607 initiate OAM messages. 609 3.46. Server MEPs 611 A server MEP is a MEP of an ME that is defined in a layer network 612 below the MPLS-TP layer network being referenced. A server MEP 613 coincides with either a MIP or a MEP in the client (MPLS-TP) layer 614 network. 616 For example, a server MEP can be either: 618 . A termination point of a physical link (e.g. 802.3), an SDH VC or 619 OTH ODU for the MPLS-TP Section layer network, defined in [5] 620 section 3.1.; 622 . An MPLS-TP Section MEP for MPLS-TP LSPs, defined in [5] section 623 3.2.; 625 . An MPLS-TP LSP MEP for MPLS-TP PWs, defined in [5] section 3.4.; 627 . An MPLS-TP TCM MEP for higher-level TCMs, defined in [5] sections 628 3.3. and 3.5. 630 The server MEP can run appropriate OAM functions for fault 631 detection, and notifies a fault indication to the MPLS-TP layer 632 network. 634 [editor: check definitions in [RFC6372] ] 636 o MPLS-TP link recovery refers to the recovery of an individual 637 link (and hence all or a subset of the LSPs routed over the link) 638 between two MPLS-TP nodes. For example, link recovery may be 639 provided by server layer recovery. 641 o Segment recovery refers to the recovery of an LSP segment (i.e., 642 segment and concatenated segment in the language of [RFC5654]) 643 between two nodes and is used to recover from the failure of one or 644 more links or nodes. 646 o End-to-end recovery refers to the recovery of an entire LSP, from 647 its ingress to its egress node. 649 o A "Transport Entity" is a node, link, transport path segment, 650 concatenated transport path segment, or entire transport path. 652 o A "Working Entity" is a transport entity that carries traffic 653 during normal network operation. 655 o A "Protection Entity" is a transport entity that is pre-allocated 656 and used to protect and transport traffic when the working entity 657 fails. 659 o A "Recovery Entity" is a transport entity that is used to recover 660 and transport traffic when the working entity fails. 662 [editor: the following are definitions from G.8101 which should be 663 defined only if they will cause misunderstanding. It is not usefull 664 to define them if the definition is the same in IETF and ITU-T, TBD] 666 ===== [ITU-T_G.8101] ===== 668 3.1 access point 670 3.2 adapted information 672 3.3 characteristic information 674 3.4 client/server relationship 676 3.5 connection 678 3.6 connection point 680 3.9 forward direction 682 3.12 link connection 684 3.13 matrix 686 3.14 network 688 3.15 network connection 690 3.16 network operator 692 3.17 port 693 3.18 reference point 695 3.19 service provider 697 3.20 subnetwork 699 3.21 subnetwork connection 701 3.22 termination connection point 703 3.23 trail 705 3.24 trail termination 707 3.25 trail termination point 709 3.26 transport 711 3.27 transport entity 713 3.28 transport processing function 715 3.29 unidirectional connection 717 3.30 unidirectional trail 719 3.31 Z layer 721 Transport MPLS (MPLS-TP) Recommendations uses the following terms 722 defined in ITU-T Rec. G.809: 724 3.34 adaptation 726 3.37 client/server relationship (relationship between layer 727 networks) 729 3.56 traffic unit 731 Transport MPLS (MPLS-TP) Recommendations uses the following term 732 defined in ITU-T Rec. G.8010/Y.1306: 734 3.59 point-to-point Ethernet connection 736 Transport MPLS (MPLS-TP) Recommendations uses the following terms 737 defined in [ITU-T_Y.1711]: 739 3.60 backward direction 740 3.65 user-plane 742 Transport MPLS (MPLS-TP) Recommendations uses the following terms 743 defined in [ITU-T_Y.1720]: 745 3.66 1+1 protection 747 3.67 1:1 protection 749 3.68 bidirectional protection switching 751 3.69 bridge 753 3.71 extra traffic 755 3.72 failure 757 3.73 forced switch for working LSP 759 3.74 hold-off time 761 3.75 manual switch 763 3.76 MPLS protection domain 765 3.77 non-revertive protection switching 767 3.78 no request 769 3.79 packet 1+1 protection 771 3.80 path switch LSR 773 3.81 path merge LSR 775 3.82 protection LSP 777 3.83 protection switching 779 3.84 rerouting 781 3.85 revertive protection switching 783 3.86 selector 785 3.87 shared mesh protection 786 3.88 Shared Risk Group (SRG) 788 3.89 sink of the protection domain 790 3.90 source of the protection domain 792 3.91 unidirectional protection switching 794 3.92 wait to restore 796 3.93 wait to restore timer 798 3.94 working LSP 800 Transport MPLS (MPLS-TP) Recommendations uses the following terms 801 defined in [ITU-T_Y.1731]: 803 3.95 in-service OAM 805 ===== end of [ITU-T_G.8101] ===== 807 4. Guidance on the Application of this Thesaurus 809 As discussed in the introduction to this document, this thesaurus is 810 intended to bring the concepts and terms associated with MPLS-TP 811 into the context of the ITU-T's Transport Network architecture. 812 Thus, it should help those familiar with MPLS to see how they may 813 use the features and functions of the Transport Network in order to 814 meet the requirements of MPLS-TP. 816 This lexicography should not be used in order to obtain or derive 817 definitive definitions of GMPLS terms. To obtain definitions of 818 GMPLS terms that are applicable across all GMPLS architectural 819 models, the reader should refer to the RFCs listed in the references 820 sections of this document. [RFC3945] provides an overview of the 821 GMPLS architecture and should be read first. 823 5. Management Considerations 825 The MPLS-TP based network requires management. The MPLS-TP 826 specifications include considerable efforts to provide operator 827 control and monitoring, as well as Operations and Management (OAM) 828 functionality. 830 These concepts are, however, out of scope of this document. 832 6. Security Considerations 834 Security is also a significant requirement of MPLS-TP. 836 However, this informational document is intended only to provide a 837 lexicography, and the security concerns are, therefore, out of 838 scope. 840 7. IANA Considerations 842 To be incorporated in a future revision of this document 844 <> 846 8. Acknowledgments 848 The authors would like to thank all members of the teams (the Joint 849 Working Team, the MPLS Interoperability Design Team in IETF and the 850 MPLS-TP Ad Hoc Group in ITU-T) involved in the definition and 851 specification of MPLS Transport Profile. 853 9. References 855 9.1. Normative References 857 [RFC6371] Busi, I., Allan, D., "Operations, Administration, and 858 Maintenance Framework for MPLS-Based Transport Networks", 859 September 2011 861 [RFC6372] Sprecher, N., Farrel, A., "MPLS Transport Profile (MPLS- 862 TP) Survivability Framework", September 2011 864 [RFC5654] B. Niven-Jenkins, et al., "Requirements of an MPLS 865 Transport Profile", September 2009 867 [RFC5921] Bocci, M., Bryant, S., Levrau, L., "A Framework for MPLS 868 in Transport Networks", July 2010 870 [RFC5860] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM 871 in MPLS Transport Networks", May 2010 873 [RFC5951] Gray, E., Mansfield, S., et al., "MPLS TP Network 874 Management Requirements", September 2010 876 [RFC3031] E. Rosen, etal., "Requirements of an MPLS Transport 877 Profile", january 2001 879 [RFC4397] I. Bryskin, A. Farrel, "A Lexicography for the 880 Interpretation of Generalized Multiprotocol Label 881 Switching (GMPLS) Terminology within the Context of the 882 ITU-T's Automatically Switched Optical Network (ASON) 883 Architecture", february 2006 885 9.2. Informative References 887 For information on the availability of the following documents, 888 please see http://www.itu.int 890 [ITU-T_G.8101] ITU-T Recommendation G.8101/Y.1355 (12/2006), Terms 891 and definitions for transport MPLS. 893 [ITU-T_G.805] ITU-T Recommendation G.805 (03/2000), Generic 894 functional architecture of transport networks. 896 [ITU-T_G.806] ITU-T Recommendation G.806 (03/2006), Characteristics 897 of transport equipment - Description methodology and 898 generic functionality. 900 [ITU-T_Y.1711] ITU-T Recommendation Y.1711 (10/2005) Operation & 901 Maintenance mechanism for MPLS networks. 903 [ITU-T_Y.1720] ITU-T Recommendation Y.1720 (02/2008), Protection 904 switching for MPLS networks. 906 [ITU-T_Y.1731] ITU-T Recommendation Y.1731 (02/2008), OAM functions 907 and mechanisms for Ethernet based networks. 909 [ITU-T_G.872] ITU-T Recommendation G.872 (11/2001), Architecture of 910 optical transport networks. 912 [ITU-T G.7710] ITU-T Recommendation G.7710 (07/2007), Common 913 equipment management function requirements 915 [ITU-T Y.2611] ITU-T Recommendation Y.2611 (12/2006), High-level 916 architecture of future packet-based networks 918 Authors' Addresses 920 Huub van Helvoort (Editor) 921 Huawei Technologies Co., Ltd. 922 Email: Huub.van.Helvoort@huawei.com 924 Loa Andersson (Editor) 925 Ericsson 926 Email: loa.andersson@ericsson.com 928 Nurit Sprecher (Editor) 929 Nokia Siemens Networks 930 Email: nurit.sprecher@nsn.com 932 Contributing Authors' Addresses