idnits 2.17.1 draft-ietf-mpls-tp-rosetta-stone-11.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 13, 2013) is 3939 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: January 2014 L. Andersson (Ed) 5 Huawei Technologies 7 N. Sprecher (Ed) 8 Nokia Siemens Networks 10 July 13, 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-11 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 January 13, 2014. 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 2. Terminology 5 77 2.1. MPLS-TP Terminology Sources 5 78 2.2. ITU-T Transport Network Terminology Sources 5 79 2.3. Common Terminology Sources 6 80 3. Thesaurus 6 81 3.1. Associated bidirectional path: 6 82 3.2. Bidirectional path: 6 83 3.3. Client layer network: 6 84 3.4. Communication Channel (CC): 6 85 3.5. Concatenated Segment: 7 86 3.6. Control Plane: 7 87 3.7. Co-routed bidirectional path: 7 88 3.8. Data Communication Network (DCN): 7 89 3.9. Defect: 7 90 3.10. Domain: 7 91 3.11. Embedded Communication Channel (ECC): 8 92 3.12. Equipment Management Function (EMF): 8 93 3.13. Failure: 8 94 3.14. Fault: 8 95 3.15. Layer network: 8 96 3.16. Link: 9 97 3.17. Maintenance Entity (ME): 9 98 3.18. Maintenance Entity Group (MEG): 9 99 3.19. Maintenance Entity Group End Point (MEP): 10 100 3.20. Maintenance Entity Group Intermediate Point (MIP): 10 101 3.21. Management Communication Channel (MCC): 10 102 3.22. Management Communication Network (MCN): 10 103 3.23. Monitoring 11 104 3.23.1. Path Segment Tunnel (PST): 11 105 3.23.2. Sub-Path Maintenance Element (SMPE): 11 106 3.23.3. Tandem Connection: 11 107 3.24. MPLS Section: 12 108 3.25. MPLS Transport Profile (MPLS-TP): 12 109 3.26. MPLS-TP NE: 12 110 3.27. MPLS-TP network: 12 111 3.28. MPLS-TP Recovery: 12 112 3.28.1. End-to-end recovery: 12 113 3.28.2. Link recovery: 12 114 3.28.3. Segment recovery: 12 115 3.29. MPLS-TP Ring Topology: 13 116 3.29.1. MPLS-TP Logical Ring: 13 117 3.29.2. MPLS-TP Physical Ring: 13 118 3.30. OAM flow: 13 119 3.31. Operations System (OS): 13 120 3.32. Path: 13 121 3.33. Protection priority: 13 122 3.34. Section Layer Network: 14 123 3.35. Segment: 14 124 3.36. Server layer: 14 125 3.37. Server MEPs: 14 126 3.38. Signaling Communication Channel (SCC): 15 127 3.39. Signaling Communication Network (SCN): 15 128 3.40. Span: 15 129 3.41. Sublayer: 15 130 3.42. Transport Entity: 15 131 3.42.1. Working Entity: 16 132 3.42.2. Protection Entity: 16 133 3.42.3. Recovery entity: 16 134 3.43. Transmission media layer: 16 135 3.44. Transport Network: 16 136 3.45. Transport path: 16 137 3.46. Transport path layer: 16 138 3.47. Transport service layer: 17 139 3.48. Unidirectional path: 17 140 4. Guidance on the Application of this Thesaurus 17 141 5. Management Considerations 17 142 6. Security Considerations 18 143 7. IANA Considerations 18 144 8. Acknowledgments 18 145 9. References 18 146 9.1. Normative References 18 147 9.2. Informative References 20 149 1. Introduction 151 Multiprotocol Label Switching - Transport Profile (MPLS-TP) has been 152 developed by the IETF to facilitate the Operation, Administration 153 and Management of Label Switched Paths (LSPs) in a Transport Network 154 environment as defined by the ITU-T. 156 The ITU-T has specified a Transport Network architecture for the 157 transfer of signals from different technologies. This architecture 158 forms the basis of many Recommendations within the ITU-T. 160 Because of the difference in historic background of MPLS, and 161 inherently MPLS-TP (the Internet) and the Transport Network (ITU 162 telecommunication Sector), the terminology used is different. 164 This document provides a thesaurus for the interpretation of ITU-T 165 Transport Network terminology within the context of the MPLS-TP. 166 This allows MPLS-TP documents to be generally understood by those 167 familiar with MPLS RFCs. The definitions presented in this document 168 do not provide exclusive or complete interpretations of the ITU-T 169 Transport Network concepts. 171 1.1. Contributing Authors 173 Italo Busi, Ben Niven-Jenkins, Enrique Hernandez-Valencia, Lieven 174 Levrau, Dinesh Mohan, Stuart Bryant, Dan Frost, Matthew Bocci, 175 Vincenzo Sestito, Vigoureux, Yaacov Weingarten 177 1.2. Abbreviations 179 CC Communications Channel 181 CE Customer Edge 183 DCN Data Communication Network 185 ECC Embedded Communication Channel 187 EMF Equipment Management Function 189 MCC Management Communication Channel 190 MCN Management Communication Network 192 ME Maintenance Entity 194 MEG Maintenance Entity Group 196 MEP Maintenance Entity Group End Point 198 MIP Maintenance Entity Group Intermediate Point 200 MPLS Multiprotocol Label Switching 202 MPLS-TP MPLS Transport Profile 204 NE Network Element 206 OAM Operations, Administration and Maintenance 208 PST Path Segment Tunnel 210 SCC Signaling Communication Channel 212 SCN Signaling Communication Network 214 SPME Sub-Path Maintenance Element 216 TCM Tandem Connection Monitoring 218 2. Terminology 220 2.1. MPLS-TP Terminology Sources 222 MPLS-TP terminology is principally defined in [RFC3031]. Other 223 documents provide further key definitions including [RFC4397]. 225 2.2. ITU-T Transport Network Terminology Sources 227 The ITU-T Transport Network is specified in a number of 228 recommendations: generic functional architectures and requirements 229 are specified in [ITU-T_G.805], [ITU-T_G.806], and [ITU-T_G.872]. 230 ITU-T Recommendation [ITU-T_G.8101] contains an overview of the 231 Terms and Definitions for transport MPLS. 233 2.3. Common Terminology Sources 235 The work in this document builds on the shared view of MPLS 236 requirements. 238 The following sources are used: 239 IETF framework and requirements RFCs: [RFC6371], [RFC6372], 240 [RFC5654], [RFC5921], [RFC5860], [RFC5951], [RFC3031] and [RFC4397]. 241 ITU-T architecture and requirements Recommendations: [ITU-T_G.8101], 242 [ITU-T_G.805], [ITU-T_G.806], [ITU-T_G.872], [ITU-T G.7710] and 243 [ITU-T Y.2611]. 245 3. Thesaurus 247 3.1. Associated bidirectional path: 249 A path that supports traffic flow in both directions but that is 250 constructed from a pair of unidirectional paths (one for each 251 direction) that are associated with one another at the path's 252 ingress/egress points. The forward and backward directions are 253 setup, monitored, and protected independently. As a consequence, 254 they may or may not follow the same route (links and nodes) across 255 the network. 257 3.2. Bidirectional path: 259 A path that supports traffic flow in two opposite directions, i.e. 260 the forward and backward direction. 262 3.3. Client layer network: 264 In a client/server relationship (see [ITU-T_G.805]), the client 265 layer network receives a (transport) service from the lower server 266 layer network (usually the layer network under consideration). 268 3.4. Communication Channel (CC): 270 A logical channel between network elements (NEs) that can be used - 271 e.g. - for management plane application or control plane 272 applications. The physical channel supporting the CC is technology 273 specific. See [RFC5951] APPENDIX A. 275 3.5. Concatenated Segment: 277 A serial-compound link connection as defined in [ITU-T_G.805]. A 278 concatenated segment is a contiguous part of an LSP or multi-segment 279 PW that comprises a set of segments and their interconnecting nodes 280 in sequence. See also "Segment". 282 3.6. Control Plane: 284 Within the scope of [RFC5654], the control plane performs transport 285 path control functions. Through signalling, the control plane sets 286 up, modifies and releases transport paths, and may recover a 287 transport path in case of a failure. The control plane also 288 performs other functions in support of transport path control, such 289 as routing information dissemination. 291 3.7. Co-routed bidirectional path: 293 A path where the forward and backward directions follow the same 294 route (links and nodes) across the network. Both directions are 295 setup, monitored and protected as a single entity. A transport 296 network path is typically co-routed. 298 3.8. Data Communication Network (DCN): 300 A network that supports Layer 1 (physical layer), Layer 2 (data-link 301 layer), and Layer 3 (network layer) functionality for distributed 302 management communications related to the management plane, for 303 distributed signaling communications related to the control plane, 304 and other operations communications (e.g., order-wire/voice 305 communications, software downloads, etc.). 307 3.9. Defect: 309 The situation for which the density of anomalies has reached a level 310 where the ability to perform a required function has been 311 interrupted. Defects are used as input for PM, the control of 312 consequent actions, and the determination of fault cause. See also 313 [ITU-T_G.806]. 315 3.10. Domain: 317 A domain represents a collection of entities (for example network 318 elements) that are grouped for a particular purpose, examples of 319 which are administrative and/or managerial responsibilities, trust 320 relationships, addressing schemes, infrastructure capabilities, 321 aggregation, survivability techniques, distributions of control 322 functionality, etc. Examples of such domains include IGP areas and 323 Autonomous Systems. 325 3.11. Embedded Communication Channel (ECC): 327 A logical operations channel between network elements (NEs) that can 328 be utilized by multiple applications (e.g., management plane 329 applications, control plane applications, etc.). The physical 330 channel supporting the ECC is technology specific. An example of 331 physical channels supporting the ECC is a DCC channel within SDH. 333 3.12. Equipment Management Function (EMF): 335 The management functions within an NE. See [ITU-T G.7710]. 337 3.13. Failure: 339 The fault cause persisted long enough to consider the ability of an 340 item to perform a required function to be terminated. The item may 341 be considered as failed; a fault has now been detected. See also 342 [ITU-T_G.806]. 344 3.14. Fault: 346 A Fault is the inability of a function to perform a required action. 347 This does not include an inability due to preventive maintenance, 348 lack of external resources, or planned actions. See also [ITU- 349 T_G.806]. 351 3.15. Layer network: 353 Layer network is defined in [ITU-T_G.805]. A layer network provides 354 for the transfer of client information and independent operation of 355 the client OAM. A layer network may be described in a service 356 context as follows: one layer network may provide a (transport) 357 service to a higher client layer network and may, in turn, be a 358 client to a lower-layer network. A layer network is a logical 359 construction somewhat independent of arrangement or composition of 360 physical network elements. A particular physical network element 361 may topologically belong to more than one layer network, depending 362 on the actions it takes on the encapsulation associated with the 363 logical layers (e.g., the label stack), and thus could be modeled as 364 multiple logical elements. A layer network may consist of one or 365 more sublayers. For additional explanation of how layer networks 366 relate to the OSI concept of layering, see Appendix I of [ITU-T 367 Y.2611]. 369 3.16. Link: 371 A physical or logical connection between a pair of LSRs that are 372 adjacent at the (sub)layer network under consideration. A link may 373 carry zero, one or more LSPs or PWs. A packet entering a link will 374 emerge with the same label stack entry values. 376 A link as defined in [ITU-T_G.805] is used to describe a fixed 377 relationship between two ports. 379 3.17. Maintenance Entity (ME): 381 A Maintenance Entity (ME) can be viewed as the association of two 382 (or more) Maintenance Entity Group End Points (MEPs), that should be 383 configured and managed in order to bound the OAM responsibilities of 384 an OAM flow across a network or sub-network, i.e. a transport path 385 or segment, in the specific layer network that is being monitored 386 and managed. See also [RFC6371] section 3.1 and [ITU-T G.8113.1], 387 [ITU-T G.8113.2] clause 6.1. 389 A Maintenance Entity may be defined to monitor and manage 390 bidirectional or unidirectional point-to-point connectivity or 391 point-to-multipoint connectivity in an MPLS-TP layer network. 393 Therefore, in the context of MPLS-TP LSP or PW Maintenance Entity 394 (defined below) LERs and T-PEs can be MEPs while LSRs and S-PEs can 395 be MIPs. In the case of Tandem Connection Maintenance Entity 396 (defined below), LSRs and S-PEs can be either MEPs or MIPs. 398 The following properties apply to all MPLS-TP MEs: 400 o OAM entities can be nested but not overlapped. 402 o Each OAM flow is associated to a unique Maintenance Entity. 404 o OAM packets are subject to the same forwarding treatment as the 405 data traffic, but they are distinct from the data traffic. 407 3.18. Maintenance Entity Group (MEG): 409 A Maintenance Entity Group is defined, for the purpose of connection 410 monitoring, between a set of connection points within a connection. 411 This set of connection points may be located at the boundary of one 412 administrative domain or a protection domain, or the boundaries of 413 two adjacent administrative domains. The MEG may consist of one or 414 more Maintenance Entities (ME). See also [RFC6371] section 3.1 and 415 [ITU-T G.8113.1], [ITU-T G.8113.2] clause 6.2. 417 In an MPLS-TP layer network a MEG consists of only one ME. 419 3.19. Maintenance Entity Group End Point (MEP): 421 Maintenance Entity Group End Points (MEPs) are the end points of a 422 pre-configured (through the management or control planes) ME. MEPs 423 are responsible for activating and controlling all of the OAM 424 functionality for the ME. A source MEP may initiate an OAM packet to 425 be transferred to its corresponding peer or sink MEP, or to an 426 intermediate MIP that is part of the ME. See also [RFC6371] section 427 3.3 and [ITU-T G.8113.1], [ITU-T G.8113.2] clause 6.3. 429 A sink MEP terminates all the OAM packets that it receives 430 corresponding to its ME and does not forward them further along the 431 path. 433 All OAM packets coming into a source MEP are tunnelled via label 434 stacking and are not processed within the ME as they belong either 435 to the client network layers or to an higher TCM level. 437 A MEP in a tandem connection is not coincident with the termination 438 of the MPLS-TP transport path (LSP or PW), though it can monitor its 439 connectivity (e.g. count packets). A MEP of an MPLS-TP network 440 transport path is coincident with transport path termination and 441 monitors its connectivity (e.g. count packets). 443 An MPLS-TP sink MEP can notify a fault condition to its MPLS-TP 444 client layer network. 446 3.20. Maintenance Entity Group Intermediate Point (MIP): 448 A Maintenance Entity Group Intermediate Point (MIP) is a point 449 between the two MEPs in an ME and is capable of responding to some 450 OAM packets and forwarding all OAM packets while ensuring fate 451 sharing with data plane packets. A MIP responds only to OAM packets 452 that are sent on the ME it belongs to and that are addressed to the 453 MIP, it does not initiate OAM messages. See also [RFC6371] section 454 3.4 and [ITU-T G.8113.1], [ITU-T G.8113.2] clause 6.4. 456 3.21. Management Communication Channel (MCC): 458 A CC dedicated for management plane communications. 460 3.22. Management Communication Network (MCN): 462 A DCN supporting management plane communication is referred to as a 463 Management Communication Network (MCN). 465 3.23. Monitoring 467 Monitoring is applying OAM functionality to verify and to maintain 468 the performance and the quality guarantees of a transport path. 469 There is a need to not only monitor the whole transport path (e.g. 470 LSP or MS-PW), but also arbitrary parts of transport paths. The 471 connection between any two arbitrary points along a transport path 472 is described in three ways: 473 - as a Path Segment Tunnel, 474 - as a Sub-Path Maintenance Element, and 475 - as a Tandem Connections. 477 3.23.1. Path Segment Tunnel (PST): 479 A path segment is either a segment or a concatenated segment. Path 480 Segment Tunnels (PSTs) are instantiated to provide monitoring of a 481 portion of a set of co-routed transport paths (LSPs or MS-PWs). 482 Path segment tunnels can also be employed to meet the requirement to 483 provide Tandem Connection Monitoring, see Tandem Connection. 485 3.23.2. Sub-Path Maintenance Element (SMPE): 487 To monitor, protect, and manage a portion (i.e., segment or 488 concatenated segment) of an LSP, a hierarchical LSP [RFC3031] can be 489 instantiated. A hierarchical LSP instantiated for this purpose is 490 called a Sub-Path Maintenance Element (SPME). Note that by 491 definition an SPME does not carry user traffic as a direct client. 493 An SPME is defined between the edges of the portion of the LSP that 494 needs to be monitored, protected or managed. The SPME forms a MPLS- 495 TP Section that carries the original LSP over this portion of the 496 network as a client. OAM messages can be initiated at the edge of 497 the SPME and sent to the peer edge of the SPME or to a MIP along the 498 SPME. A P router only pushes or pops a label if it is at the end of 499 a SPME. In this mode, it is an LER for the SPME. 501 3.23.3. Tandem Connection: 503 A tandem connection is an arbitrary part of a transport path that 504 can be monitored (via OAM) independently from the end-to-end 505 monitoring (OAM). It may be a monitored segment, a monitored 506 concatenated segment or any other monitored ordered sequence of 507 contiguous hops and/or segments (and their interconnecting nodes) of 508 a transport path. 510 Tandem Connection Monitoring (TCM) for a given path segment of a 511 transport path is implemented by creating a path segment tunnel that 512 has a 1:1 association with the path segment of the transport path 513 that is to be uniquely monitored. This means that the PST used to 514 provide TCM can carry one and only one transport path thus allowing 515 direct correlation between all fault management and performance 516 monitoring information gathered for the PST and the monitored path 517 segment of the end-to-end transport path. The PST is monitored 518 using normal LSP monitoring. See also [RFC6371] section 3.2 and 519 [ITU-T G.8113.1], [ITU-T G.8113.2] clause 6.2.1. 521 3.24. MPLS Section: 523 A network segment between two LSRs that are immediately adjacent at 524 the MPLS layer. 526 3.25. MPLS Transport Profile (MPLS-TP): 528 The set of MPLS functions used to support packet transport services 529 and network operations. 531 3.26. MPLS-TP NE: 533 A network element (NE) that supports MPLS-TP functions. 535 3.27. MPLS-TP network: 537 A network in which MPLS-TP NEs are deployed. 539 3.28. MPLS-TP Recovery: 541 3.28.1. End-to-end recovery: 543 MPLS-TP End-to-end recovery refers to the recovery of an entire LSP, 544 from its ingress to its egress node. 546 3.28.2. Link recovery: 548 MPLS-TP link recovery refers to the recovery of an individual link 549 (and hence all or a subset of the LSPs routed over the link) between 550 two MPLS-TP nodes. For example, link recovery may be provided by 551 server layer recovery. 553 3.28.3. Segment recovery: 555 MPLS-TP Segment recovery refers to the recovery of an LSP segment 556 (i.e., segment and concatenated segment in the language of 557 [RFC5654]) between two nodes and is used to recover from the failure 558 of one or more links or nodes. 560 3.29. MPLS-TP Ring Topology: 562 In an MPLS-TP ring topology, each LSR is connected to exactly two 563 other LSRs, each via a single point-to-point bidirectional MPLS-TP 564 capable link. A ring may also be constructed from only two LSRs 565 where there are also exactly two links. Rings may be connected to 566 other LSRs to form a larger network. Traffic originating or 567 terminating outside the ring may be carried over the ring. Client 568 network nodes (such as Customer Edges (CEs)) may be connected 569 directly to an LSR in the ring. 571 3.29.1. MPLS-TP Logical Ring: 573 An MPLS-TP logical ring is constructed from a set of LSRs and 574 logical data links (such as MPLS-TP LSP tunnels or MSPL-TP 575 pseudowires) and physical data links that form a ring topology. 577 3.29.2. MPLS-TP Physical Ring: 579 An MPLS-TP physical ring is constructed from a set of LSRs and 580 physical data links that form a ring topology. 582 3.30. OAM flow: 584 An OAM flow is the set of all OAM packets originating with a 585 specific source MEP that instrument one direction of a MEG (or 586 possibly both in the special case of data plane loopback). 588 3.31. Operations System (OS): 590 A system that performs the functions that support processing of 591 information related to operations, administration, maintenance, and 592 provisioning (OAM&P) for the networks, including surveillance and 593 testing functions to support customer access maintenance. 595 3.32. Path: 597 See Transport path. 599 3.33. Protection priority: 601 Fault conditions (e.g., signal failed), external commands (e.g, 602 forced switch, manual switch) and protection states (e.g., no 603 request) are defined to have a relative priority with respect to 604 each other. Priority is applied to these conditions/command/states 605 locally at each endpoint and between the two endpoints. 607 3.34. Section Layer Network: 609 A section layer is a server layer (which may be MPLS-TP or a 610 different technology) that provides for the transfer of the section- 611 layer client information between adjacent nodes in the transport- 612 path layer or transport-service layer. A section layer may provide 613 for aggregation of multiple MPLS-TP clients. Note that [ITU- 614 T_G.805] defines the section layer as one of the two layer networks 615 in a transmission-media layer network. The other layer network is 616 the physical-media layer network. 618 Section layer networks are concerned with all the functions which 619 provide for the transfer of information between locations in path 620 layer networks. 622 Physical media layer networks are concerned with the actual fibres, 623 metallic wires or radio frequency channels which support a section 624 layer network. 626 3.35. Segment: 628 A link connection as defined in [ITU-T_G.805]. A segment is the 629 part of an LSP that traverses a single link or the part of a PW that 630 traverses a single link (i.e., that connects a pair of adjacent 631 {Switching|Terminating} Provider Edges). See also "Concatenated 632 Segment". 634 3.36. Server layer: 636 A service layer is a layer network in which transport paths are used 637 to carry a customer's (individual or bundled) service (may be point- 638 to-point, point-to-multipoint or multipoint-to-multipoint services). 640 In a client/server relationship (see [ITU-T_G.805]) the server layer 641 network provides a (transport) service to the higher client layer 642 network (usually the layer network under consideration). 644 3.37. Server MEPs: 646 A server MEP is a MEP of an ME that is defined in a layer network 647 below the MPLS-TP layer network being referenced. A server MEP 648 coincides with either a MIP or a MEP in the client (MPLS-TP) layer 649 network. See also [RFC6371] section 3.5 and [ITU-T G.8113.1] clause 650 6.5. 652 For example, a server MEP can be either: 654 . A termination point of a physical link (e.g. IEEE 802.3), an SDH 655 VC or OTH ODU for the MPLS-TP Section layer network, defined in 656 [RFC6371] section 3.1.; 658 . An MPLS-TP Section MEP for MPLS-TP LSPs, defined in [RFC6371] 659 section 3.2.; 661 . An MPLS-TP LSP MEP for MPLS-TP PWs, defined in [RFC6371] section 662 3.4.; 664 . An MPLS-TP TCM MEP for higher-level TCMs, defined in [RFC6371] 665 sections 3.3. and 3.5. 667 The server MEP can run appropriate OAM functions for fault 668 detection, and notifies a fault indication to the MPLS-TP layer 669 network. 671 3.38. Signaling Communication Channel (SCC): 673 A CC dedicated for control plane communications. The SCC may be used 674 for GMPLS/ASON signaling and/or other control plane messages (e.g., 675 routing messages). 677 3.39. Signaling Communication Network (SCN): 679 A DCN supporting control plane communication is referred to as a 680 Signaling Communication Network (SCN). 682 3.40. Span: 684 A span is synonymous with a link. 686 3.41. Sublayer: 688 Sublayer is defined in [ITU-T_G.805]. The distinction between a 689 layer network and a sublayer is that a sublayer is not directly 690 accessible to clients outside of its encapsulating layer network and 691 offers no direct transport service for a higher layer (client) 692 network. 694 3.42. Transport Entity: 696 A "Transport Entity" is a node, link, transport path segment, 697 concatenated transport path segment, or entire transport path. 699 3.42.1. Working Entity: 701 A "Working Entity" is a transport entity that carries traffic during 702 normal network operation. 704 3.42.2. Protection Entity: 706 A "Protection Entity" is a transport entity that is pre-allocated 707 and used to protect and transport traffic when the working entity 708 fails. 710 3.42.3. Recovery entity: 712 A "Recovery Entity" is a transport entity that is used to recover 713 and transport traffic when the working entity fails. 715 3.43. Transmission media layer: 717 A layer network, consisting of a section layer network and a 718 physical layer network as defined in [ITU-T_G.805], that provides 719 sections (two-port point-to-point connections) to carry the 720 aggregate of network-transport path or network-service layers on 721 various physical media. 723 3.44. Transport Network: 725 A Transport Network provides transmission of traffic between 726 attached client devices by establishing and maintaining point-to- 727 point or point-to-multipoint connections between such devices. A 728 Transport Network is independent of any higher-layer network that 729 may exist between clients, except to the extent required to supply 730 this transmission service. In addition to client traffic, a 731 Transport Network may carry traffic to facilitate its own operation, 732 such as that required to support connection control, network 733 management, and Operations, Administration and Maintenance (OAM) 734 functions. 736 3.45. Transport path: 738 A network connection as defined in [ITU-T_G.805]. In an MPLS-TP 739 environment a transport path corresponds to an LSP or a PW. 741 3.46. Transport path layer: 743 A (sub)layer network that provides point-to-point or point-to- 744 multipoint transport paths. It provides OAM that is independent of 745 the clients that it is transporting. 747 3.47. Transport service layer: 749 A layer network in which transport paths are used to carry a 750 customer's (individual or bundled) service (may be point-to-point, 751 point-to-multipoint or multipoint-to-multipoint services). 753 3.48. Unidirectional path: 755 A Unidirectional Path is a path that supports traffic flow in only 756 one direction. 758 4. Guidance on the Application of this Thesaurus 760 As discussed in the introduction to this document, this thesaurus is 761 intended to bring the concepts and terms associated with MPLS-TP 762 into the context of the ITU-T's Transport Network architecture. 763 Thus, it should help those familiar with MPLS to see how they may 764 use the features and functions of the Transport Network in order to 765 meet the requirements of MPLS-TP. 767 This lexicography should not be used in order to obtain or derive 768 definitive definitions of GMPLS terms. To obtain definitions of 769 GMPLS terms that are applicable across all GMPLS architectural 770 models, the reader should refer to the RFCs listed in the references 771 sections of this document. [RFC3945] provides an overview of the 772 GMPLS architecture and should be read first. 774 5. Management Considerations 776 The MPLS-TP based network requires management. The MPLS-TP 777 specifications described in [RFC5654], [RFC5860], [RFC5921], 778 [RFC5951], [RFC6371], [RFC6372], [ITU-T G.8110.1] and [ITU-T 779 G.7710], include considerable efforts to provide operator control 780 and monitoring, as well as Operations, Administration and 781 Maintenance (OAM) functionality. 783 These concepts are, however, out of scope of this document. 785 6. Security Considerations 787 Security is a significant requirement of MPLS-TP. See for more 788 information [SECURITY]. 790 However, this informational document is intended only to provide 791 lexicography, and the security concerns are, therefore, out of 792 scope. 794 7. IANA Considerations 796 There are no IANA actions resulting from this document. 798 8. Acknowledgments 800 The authors would like to thank all members of the teams (the Joint 801 Working Team, the MPLS Interoperability Design Team in IETF and the 802 MPLS-TP Ad Hoc Group in ITU-T) involved in the definition and 803 specification of MPLS Transport Profile. 805 9. References 807 9.1. Normative References 809 [RFC3031] E. Rosen, et al., "Requirements of an MPLS Transport 810 Profile", January 2001. 812 [RFC5654] B. Niven-Jenkins, et al., "Requirements of an MPLS 813 Transport Profile", September 2009. 815 [RFC5860] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM 816 in MPLS Transport Networks", May 2010. 818 [RFC5921] Bocci, M., Bryant, S., Levrau, L., "A Framework for MPLS 819 in Transport Networks", July 2010. 821 [RFC5951] Gray, E., Mansfield, S., et al., "MPLS TP Network 822 Management Requirements", September 2010. 824 [RFC6371] Busi, I., Allan, D., "Operations, Administration, and 825 Maintenance Framework for MPLS-Based Transport Networks", 826 September 2011. 828 [RFC6372] Sprecher, N., Farrel, A., "MPLS Transport Profile (MPLS- 829 TP) Survivability Framework", September 2011. 831 For information on the availability of the following documents, 832 please see http://www.itu.int 834 [ITU-T_G.805] ITU-T Recommendation G.805 (03/2000), "Generic 835 functional architecture of transport networks." 837 [ITU-T_G.806] ITU-T Recommendation G.806 (03/2006), "Characteristics 838 of transport equipment - Description methodology and 839 generic functionality." 841 [ITU-T_G.872] ITU-T Recommendation G.872 (11/2001), "Architecture of 842 optical transport networks." 844 [ITU-T G.7710] ITU-T Recommendation G.7710 (07/2007), "Common 845 equipment management function requirements." 847 [ITU-T_G.8101] ITU-T Recommendation G.8101/Y.1355 (12/2006), "Terms 848 and definitions for transport MPLS." 850 [ITU-T G.8110.1] ITU-T Recommendation G.8110.1/Y.1370.1 (12/2011), 851 "Architecture of the Multi-Protocol Label Switching 852 transport profile layer network." 854 [ITU-T G.8113.1] ITU-T Recommendation G.8113.1/Y.1372.1 (11/2012), 855 "Operations, Administration and Maintenance mechanism 856 for MPLS-TP in Packet Transport Network (PTN)." 858 [ITU-T G.8113.2] ITU-T Recommendation G.8113.2/Y.1372.2 (11/2012), 859 "Operations, administration and maintenance mechanisms 860 for MPLS-TP networks using the tools defined for 861 MPLS." 863 [ITU-T Y.2611] ITU-T Recommendation Y.2611 (12/2006), "High-level 864 architecture of future packet-based networks." 866 9.2. Informative References 868 [RFC3945] E. Mannie, "Generalized Multi-Protocol Label Switching 869 (GMPLS) Architecture", October 2004. 871 [RFC4397] I. Bryskin, A. Farrel, "A Lexicography for the 872 Interpretation of Generalized Multiprotocol Label 873 Switching (GMPLS) Terminology within the Context of the 874 ITU-T's Automatically Switched Optical Network (ASON) 875 Architecture", February 2006. 877 [SECURITY] L. Fang, B. Niven-Jenkins, S. Mansfield, R. Graveman, 878 "MPLS-TP Security Framework", draft-ietf-mpls-tp-security- 879 framework (work in progress). 881 Authors' Addresses 883 Huub van Helvoort (Editor) 884 Huawei Technologies Co., Ltd. 885 Email: Huub.van.Helvoort@huawei.com 887 Loa Andersson (Editor) 888 Huawei Technologies Co., Ltd. 889 Email: loa@mail01.huawei.com 891 Nurit Sprecher (Editor) 892 Nokia Siemens Networks 893 Email: nurit.sprecher@nsn.com