idnits 2.17.1 draft-ietf-mpls-tp-rosetta-stone-13.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 (October 20, 2013) is 3840 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: April 2014 L. Andersson (Ed) 5 Huawei Technologies 7 N. Sprecher (Ed) 8 Nokia Solutions and Networks 10 October 20, 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-13 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 April 20, 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 Transport Profile (MPLS-TP) is based on a profile of the MPLS 58 and Pseudowire (PW) procedures as specified in the MPLS-TE, PW and 59 Multi-Segment Pseudowire (MS-PW) architectures developed by the 60 Internet Engineering Task Force (IETF). The International 61 Telecommunications Union Telecommunications Standardization Sector 62 (ITU-T) has specified a Transport Network architecture. 64 This document provides a thesaurus for the interpretation of MPLS-TP 65 terminology within the context of the ITU-T Transport Network 66 Recommendations. 68 It is important to note that MPLS-TP is applicable in a wider set of 69 contexts than just Transport Networks. The definitions presented in 70 this document do not provide exclusive nor complete interpretations 71 of MPLS-TP concepts. This document simply allows the MPLS-TP terms 72 to be applied within the Transport Network context. 74 Table of Contents 76 1 Introduction 4 77 1.1 Contributing Authors 4 78 1.2 Abbreviations 4 79 2 Terminology 6 80 2.1 MPLS-TP Terminology Sources 6 81 2.2 ITU-T Transport Network Terminology Sources 6 82 2.3 Common Terminology Sources 6 83 3 Thesaurus 6 84 3.1 Associated bidirectional path: 6 85 3.2 Bidirectional path: 7 86 3.3 Client layer network: 7 87 3.4 Communication Channel: 7 88 3.5 Concatenated Segment: 7 89 3.6 Control Plane: 7 90 3.7 Co-routed bidirectional path: 7 91 3.8 Data Communication Network (DCN): 8 92 3.9 Defect: 8 93 3.10 Domain: 8 94 3.11 Embedded Communication Channel (ECC): 8 95 3.12 Equipment Management Function (EMF): 8 96 3.13 Failure: 8 97 3.14 Fault: 9 98 3.15 Layer network: 9 99 3.16 Link: 9 100 3.17 Maintenance Entity (ME): 9 101 3.18 Maintenance Entity Group (MEG): 10 102 3.19 Maintenance Entity Group End Point (MEP): 10 103 3.20 Maintenance Entity Group Intermediate Point (MIP): 11 104 3.21 Management Communication Channel (MCC): 11 105 3.22 Management Communication Network (MCN): 11 106 3.23 Monitoring 11 107 3.23.1 Path Segment Tunnel (PST): 12 108 3.23.2 Sub-Path Maintenance Element (SPME): 12 109 3.23.3 Tandem Connection: 12 110 3.24 MPLS Section: 13 111 3.25 MPLS Transport Profile (MPLS-TP): 13 112 3.26 MPLS-TP NE: 13 113 3.27 MPLS-TP network: 13 114 3.28 MPLS-TP Recovery: 13 115 3.28.1 End-to-end recovery: 13 116 3.28.2 Link recovery: 13 117 3.28.3 Segment recovery: 13 118 3.29 MPLS-TP Ring Topology: 13 119 3.29.1 MPLS-TP Logical Ring: 14 120 3.29.2 MPLS-TP Physical Ring: 14 121 3.30 OAM flow: 14 122 3.31 Operations System (OS): 14 123 3.32 Path: 14 124 3.33 Protection priority: 14 125 3.34 Section Layer Network: 14 126 3.35 Segment: 15 127 3.36 Server layer: 15 128 3.37 Server MEPs: 15 129 3.38 Signaling Communication Channel (SCC): 16 130 3.39 Signaling Communication Network (SCN): 16 131 3.40 Span: 16 132 3.41 Sublayer: 16 133 3.42 Transport Entity: 16 134 3.42.1 Working Entity: 16 135 3.42.2 Protection Entity: 17 136 3.42.3 Recovery entity: 17 137 3.43 Transmission media layer: 17 138 3.44 Transport Network: 17 139 3.45 Transport path: 17 140 3.46 Transport path layer: 17 141 3.47 Transport service layer: 18 142 3.48 Unidirectional path: 18 143 4 Guidance on the Application of this Thesaurus 18 144 5 Management Considerations 18 145 6 Security Considerations 18 146 7 IANA Considerations 19 147 8 Acknowledgments 19 148 9 References 19 149 9.1 Normative References 19 150 9.2 Informative References 20 152 1 Introduction 154 Multiprotocol Label Switching - Transport Profile (MPLS-TP) has been 155 developed by the IETF to facilitate the Operation, Administration 156 and Management of Label Switched Paths (LSPs) to be used in a 157 Transport Network environment as defined by the ITU-T. 159 The ITU-T has specified a Transport Network architecture for the 160 transfer of signals from different technologies. This architecture 161 forms the basis of many Recommendations within the ITU-T. 163 Because of the difference in historic background of MPLS, and 164 inherently MPLS-TP (the Internet) and the Transport Network (ITU 165 Telecommunication Sector), the terminology used is different. 167 This document provides a thesaurus for the interpretation of MPLS-TP 168 terminology within the context of the ITU-T Transport Network 169 Recommendations. This allows MPLS-TP documents to be generally 170 understood by those familiar with MPLS RFCs. The definitions 171 presented in this document do not provide exclusive or complete 172 interpretations of the ITU-T Transport Network concepts. 174 1.1 Contributing Authors 176 Italo Busi, Ben Niven-Jenkins, Enrique Hernandez-Valencia, Lieven 177 Levrau, Dinesh Mohan, Stuart Bryant, Dan Frost, Matthew Bocci, 178 Vincenzo Sestito, Vigoureux, Yaacov Weingarten 180 1.2 Abbreviations 182 CE Customer Edge 184 DCC Data Communication Channel 186 DCN Data Communication Network 188 ECC Embedded Communication Channel 190 EMF Equipment Management Function 191 EMS Element Management System 193 GAL Generic Associated Channel Label 195 NEF Network Element Function 197 LER Label Edge Router 199 LSR Label Switching Router 201 MCC Management Communication Channel 203 MCN Management Communication Network 205 ME Maintenance Entity 207 MEG Maintenance Entity Group 209 MEP Maintenance Entity Group End Point 211 MIP Maintenance Entity Group Intermediate Point 213 MPLS Multiprotocol Label Switching 215 MPLS-TP MPLS Transport Profile 217 MS-PW Multi-Segment Pseudowire 219 NE Network Element 221 OAM Operations, Administration, and Maintenance 223 OSS Operations Support System 225 PM Performance Monitoring 227 PST Path Segment Tunnel 229 PW Pseudowire 231 S-PE PW Switching Provider Edge 233 SCC Signaling Communication Channel 235 SCN Signaling Communication Network 237 SPME Sub-Path Maintenance Element 238 T-PE PW Terminating Provider Edge 240 TCM Tandem Connection Monitoring 242 2 Terminology 244 2.1 MPLS-TP Terminology Sources 246 MPLS-TP terminology is principally defined in [RFC3031]. Other 247 documents provide further key definitions including [RFC4397]. 249 2.2 ITU-T Transport Network Terminology Sources 251 The ITU-T Transport Network is specified in a number of 252 Recommendations: generic functional architectures and requirements 253 are specified in [ITU-T_G.805], [ITU-T_G.806], and [ITU-T_G.872]. 254 ITU-T Recommendation [ITU-T_G.8101] contains an overview of the 255 Terms and Definitions for transport MPLS. 257 2.3 Common Terminology Sources 259 The work in this document builds on the shared view of MPLS 260 requirements. It is intended to provide a source for common MPLS-TP 261 terminology. In general the original terminology is used. 263 The following sources are used: 264 IETF framework and requirements RFCs: [RFC6371], [RFC6372], 265 [RFC5654], [RFC5921], [RFC5860], [RFC5951], [RFC3031] and [RFC4397]. 266 ITU-T architecture and requirements Recommendations: [ITU-T_G.8101], 267 [ITU-T_G.805], [ITU-T_G.806], [ITU-T_G.872], [ITU-T G.7710] and 268 [ITU-T Y.2611]. 270 3 Thesaurus 272 3.1 Associated bidirectional path: 274 A path that supports traffic flow in both directions but that is 275 constructed from a pair of unidirectional paths (one for each 276 direction) that are associated with one another at the path's 277 ingress/egress points. An associated bidirectional path needs not 278 be a single management and operational entity. The forward and 279 backward directions are setup, monitored, and protected 280 independently. As a consequence, they may or may not follow the 281 same route (links and nodes) across the network. 283 3.2 Bidirectional path: 285 A path that supports traffic flow in two opposite directions, i.e. 286 the forward and backward direction. 288 3.3 Client layer network: 290 In a client/server relationship (see [ITU-T_G.805]), the client 291 layer network receives a (transport) service from the lower server 292 layer network (usually the layer network under consideration). 294 3.4 Communication Channel: 296 A logical channel between network elements (NEs) that can be used - 297 e.g. - for management plane application or control plane 298 applications. The physical channel supporting the Communication 299 Channel is technology specific. See [RFC5951] Appendix A. 301 3.5 Concatenated Segment: 303 A serial-compound link connection as defined in [ITU-T_G.805]. A 304 concatenated segment is a contiguous part of an LSP or MS-PWthat 305 comprises a set of segments and their interconnecting nodes in 306 sequence. See also "Segment". 308 3.6 Control Plane: 310 Within the scope of [RFC5654], the control plane performs transport 311 path control functions. Through signalling, the control plane sets 312 up, modifies and releases transport paths, and may recover a 313 transport path in case of a failure. The control plane also 314 performs other functions in support of transport path control, such 315 as routing information dissemination. It is possible to operate an 316 MPLS-TP network without using a Control Plane. 318 3.7 Co-routed bidirectional path: 320 A path where the forward and backward directions follow the same 321 route (links and nodes) across the network. A co-routed 322 bidirectional path is managed and operated as a single entity. Both 323 directions are setup, monitored and protected as a single entity. A 324 transport network path is typically co-routed. 326 3.8 Data Communication Network (DCN): 328 A network that supports Layer 1 (physical layer), Layer 2 (data-link 329 layer), and Layer 3 (network layer) functionality for distributed 330 management communications related to the management plane, for 331 distributed routing and signaling communications related to the 332 control plane, and other operations communications (e.g., order- 333 wire/voice communications, software downloads, etc.). 335 3.9 Defect: 337 The situation for which the density of anomalies has reached a level 338 where the ability to perform a required function has been 339 interrupted. Defects are used as input for Performance Monitoring 340 (PM), the control of consequent actions, and the determination of 341 fault cause. See also [ITU-T_G.806]. 343 3.10 Domain: 345 A domain represents a collection of entities (for example network 346 elements) that are grouped for a particular purpose, examples of 347 which are administrative and/or managerial responsibilities, trust 348 relationships, addressing schemes, infrastructure capabilities, 349 aggregation, survivability techniques, distributions of control 350 functionality, etc. Examples of such domains include IGP areas and 351 Autonomous Systems. 353 3.11 Embedded Communication Channel (ECC): 355 A logical operations channel between network elements (NEs) that can 356 be utilized by multiple applications (e.g., management plane 357 applications, control plane applications, etc.). The physical 358 channel supporting the ECC is technology specific. An example of a 359 physical channel supporting the ECC is a Data Communication Channel 360 (DCC) within SDH. 362 3.12 Equipment Management Function (EMF): 364 The equipment management function (EMF) provides the means through 365 which an element management system (EMS) and other managing entities 366 manage the network element function (NEF). See [ITU-T G.7710]. 368 3.13 Failure: 370 A failure is a detected fault. A failure will be declared when the 371 fault cause persisted long enough to consider the ability of an item 372 to perform a required transport function to be terminated. The item 373 may be considered as failed; a fault has now been detected. See 374 also [ITU-T_G.806]. A failure can be used as a trigger for 375 corrective actions. 377 3.14 Fault: 379 A Fault is the inability of a transport function to perform a 380 required action. This does not include an inability due to 381 preventive maintenance, lack of external resources, or planned 382 actions. See also [ITU-T_G.806]. 384 3.15 Layer network: 386 Layer network is defined in [ITU-T_G.805]. A layer network provides 387 for the transfer of client information and independent operation of 388 the client OAM. A layer network may be described in a service 389 context as follows: one layer network may provide a (transport) 390 service to a higher client layer network and may, in turn, be a 391 client to a lower-layer network. A layer network is a logical 392 construction somewhat independent of arrangement or composition of 393 physical network elements. A particular physical network element 394 may topologically belong to more than one layer network, depending 395 on the actions it takes on the encapsulation associated with the 396 logical layers (e.g., the label stack), and thus could be modeled as 397 multiple logical elements. A layer network may consist of one or 398 more sublayers. For additional explanation of how layer networks 399 relate to the OSI concept of layering, see Appendix I of [ITU-T 400 Y.2611]. 402 3.16 Link: 404 A physical or logical connection between a pair of Label Switching 405 Routers (LSRs) that are adjacent at the (sub)layer network under 406 consideration. A link may carry zero, one or more LSPs or PWs. A 407 packet entering a link will emerge with the same label stack entry 408 values. 410 A link as defined in [ITU-T_G.805] is used to describe a fixed 411 relationship between two ports. 413 3.17 Maintenance Entity (ME): 415 A Maintenance Entity (ME) can be viewed as the association of two 416 (or more) Maintenance Entity Group End Points (MEPs), that should be 417 configured and managed in order to bound the OAM responsibilities of 418 an OAM flow across a network or sub-network, i.e. a transport path 419 or segment, in the specific layer network that is being monitored 420 and managed. See also [RFC6371] section 3.1 and [ITU-T G.8113.1], 421 [ITU-T G.8113.2] clause 6.1. 423 A Maintenance Entity may be defined to monitor and manage 424 bidirectional or unidirectional point-to-point connectivity or 425 point-to-multipoint connectivity in an MPLS-TP layer network. 427 Therefore, in the context of a MPLS-TP LSP ME or PW ME Label Edge 428 Routers (LERs) and PW Terminating Provider Edges (T-PEs) can be MEPs 429 while LSRs and PW Switching Provider Edges (S-PEs) can be MIPs. In 430 the case of a ME for a Tandem Connection, LSRs and S-PEs can be 431 either MEPs or MIPs. 433 The following properties apply to all MPLS-TP MEs: 435 = OAM entities can be nested but not overlapped. 437 = Each OAM flow is associated to a unique Maintenance Entity. 439 = OAM packets are subject to the same forwarding treatment as the 440 data traffic, but they are distinct from the data traffic by the 441 Generic Associated Channel Label (GAL). 443 3.18 Maintenance Entity Group (MEG): 445 A Maintenance Entity Group is defined, for the purpose of connection 446 monitoring, between a set of connection points within a connection. 447 This set of connection points may be located at the boundary of one 448 administrative domain or a protection domain, or the boundaries of 449 two adjacent administrative domains. The MEG may consist of one or 450 more Maintenance Entities (ME). See also [RFC6371] section 3.1 and 451 [ITU-T G.8113.1], [ITU-T G.8113.2] clause 6.2. 453 In an MPLS-TP layer network a MEG consists of only one ME. 455 3.19 Maintenance Entity Group End Point (MEP): 457 Maintenance Entity Group End Points (MEPs) are the end points of a 458 pre-configured (through the management or control planes) ME. MEPs 459 are responsible for activating and controlling all of the OAM 460 functionality for the ME. A source MEP may initiate an OAM packet to 461 be transferred to its corresponding peer or sink MEP, or to an 462 intermediate MIP that is part of the ME. See also [RFC6371] section 463 3.3 and [ITU-T G.8113.1], [ITU-T G.8113.2] clause 6.3. 465 A sink MEP terminates all the OAM packets that it receives 466 corresponding to its ME and does not forward them further along the 467 path. 469 All OAM packets coming into a source MEP are tunnelled via label 470 stacking and are not processed within the ME as they belong either 471 to the client network layers or to a higher Tandem Connection 472 Monitoring (TCM) level. 474 A MEP in a tandem connection is not coincident with the termination 475 of the MPLS-TP transport path (LSP or PW), though it can monitor its 476 connectivity (e.g. count packets). A MEP of an MPLS-TP network 477 transport path is coincident with transport path termination and 478 monitors its connectivity (e.g. counts packets). 480 An MPLS-TP sink MEP can notify a fault condition to its MPLS-TP 481 client layer network. 483 3.20 Maintenance Entity Group Intermediate Point (MIP): 485 A Maintenance Entity Group Intermediate Point (MIP) is a point 486 between the two MEPs in an ME and is capable of responding to some 487 OAM packets and forwarding all OAM packets while ensuring fate 488 sharing with data plane packets. A MIP responds only to OAM packets 489 that are sent on the ME it belongs to and that are addressed to the 490 MIP, it does not initiate OAM messages. See also [RFC6371] section 491 3.4 and [ITU-T G.8113.1], [ITU-T G.8113.2] clause 6.4. 493 3.21 Management Communication Channel (MCC): 495 A Communication Channel dedicated for management plane 496 communications. 498 3.22 Management Communication Network (MCN): 500 A DCN supporting management plane communication is referred to as a 501 Management Communication Network (MCN). 503 3.23 Monitoring 505 Monitoring is applying OAM functionality to verify and to maintain 506 the performance and the quality guarantees of a transport path. 507 There is a need to not only monitor the whole transport path (e.g. 508 LSP or MS-PW), but also arbitrary parts of transport paths. The 509 connection between any two arbitrary points along a transport path 510 is described in one of three ways: 511 - as a Path Segment Tunnel, 512 - as a Sub-Path Maintenance Element, or 513 - as a Tandem Connection. 515 3.23.1 Path Segment Tunnel (PST): 517 A path segment is either a segment or a concatenated segment. Path 518 Segment Tunnels (PSTs) are instantiated to provide monitoring of a 519 portion of a set of co-routed transport paths (LSPs or MS-PWs). 520 Path segment tunnels can also be employed to meet the requirement to 521 provide Tandem Connection Monitoring, see Tandem Connection. 523 3.23.2 Sub-Path Maintenance Element (SPME): 525 To monitor, protect, and manage a portion (i.e., segment or 526 concatenated segment) of an LSP, a hierarchical LSP [RFC3031] can be 527 instantiated. A hierarchical LSP instantiated for this purpose is 528 called a Sub-Path Maintenance Element (SPME). Note that by 529 definition an SPME does not carry user traffic as a direct client. 531 An SPME is defined between the edges of the portion of the LSP that 532 needs to be monitored, protected or managed. The SPME forms a MPLS- 533 TP Section that carries the original LSP over this portion of the 534 network as a client. OAM messages can be initiated at the edge of 535 the SPME and sent to the peer edge of the SPME or to a MIP along the 536 SPME. A P router only pushes or pops a label if it is at the end of 537 a SPME. In this mode, it is an LER for the SPME. 539 3.23.3 Tandem Connection: 541 A tandem connection is an arbitrary part of a transport path that 542 can be monitored (via OAM) independently from the end-to-end 543 monitoring (OAM). It may be a monitored segment, a monitored 544 concatenated segment or any other monitored ordered sequence of 545 contiguous hops and/or segments (and their interconnecting nodes) of 546 a transport path. 548 Tandem Connection Monitoring (TCM) for a given path segment of a 549 transport path is implemented by creating a path segment tunnel that 550 has a 1:1 association with the path segment of the transport path 551 that is to be uniquely monitored. This means that the PST used to 552 provide TCM can carry one and only one transport path thus allowing 553 direct correlation between all fault management and performance 554 monitoring information gathered for the PST and the monitored path 555 segment of the end-to-end transport path. The PST is monitored 556 using normal LSP monitoring. See also [RFC6371] section 3.2 and 557 [ITU-T G.8113.1], [ITU-T G.8113.2] clause 6.2.1. 559 3.24 MPLS Section: 561 A network segment between two LSRs that are immediately adjacent at 562 the MPLS layer. 564 3.25 MPLS Transport Profile (MPLS-TP): 566 The set of MPLS functions used to support packet transport services 567 and network operations. 569 3.26 MPLS-TP NE: 571 A network element (NE) that supports MPLS-TP functions. 573 3.27 MPLS-TP network: 575 A network in which MPLS-TP NEs are deployed. 577 3.28 MPLS-TP Recovery: 579 3.28.1 End-to-end recovery: 581 MPLS-TP End-to-end recovery refers to the recovery of an entire LSP, 582 from its ingress to its egress node. 584 3.28.2 Link recovery: 586 MPLS-TP link recovery refers to the recovery of an individual link 587 (and hence all or a subset of the LSPs routed over the link) between 588 two MPLS-TP nodes. For example, link recovery may be provided by 589 server layer recovery. 591 3.28.3 Segment recovery: 593 MPLS-TP Segment recovery refers to the recovery of an LSP segment 594 (i.e., segment and concatenated segment) between two nodes and is 595 used to recover from the failure of one or more links or nodes. 597 An LSP segment comprises one or more contiguous hops on the path of 598 the LSP. [RFC5654] defines two terms. A "segment" is a single hop 599 along the path of an LSP, while a "concatenated segment" is more 600 than one hop along the path of an LSP. 602 3.29 MPLS-TP Ring Topology: 604 In an MPLS-TP ring topology, each LSR is connected to exactly two 605 other LSRs, each via a single point-to-point bidirectional MPLS-TP 606 capable link. A ring may also be constructed from only two LSRs 607 where there are also exactly two links. Rings may be connected to 608 other LSRs to form a larger network. Traffic originating or 609 terminating outside the ring may be carried over the ring. Client 610 network nodes (such as Customer Edges (CEs)) may be connected 611 directly to an LSR in the ring. 613 3.29.1 MPLS-TP Logical Ring: 615 An MPLS-TP logical ring is constructed from a set of LSRs and 616 logical data links (such as MPLS-TP LSP tunnels or MSPL-TP 617 pseudowires) and physical data links that form a ring topology. 619 3.29.2 MPLS-TP Physical Ring: 621 An MPLS-TP physical ring is constructed from a set of LSRs and 622 physical data links that form a ring topology. 624 3.30 OAM flow: 626 An OAM flow is the set of all OAM packets originating with a 627 specific source MEP that instrument one direction of a MEG (or 628 possibly both in the special case of data plane loopback). 630 3.31 Operations Support System (OSS): 632 A system that performs the functions that support processing of 633 information related to operations, administration, maintenance, and 634 provisioning (OAM&P) for the networks, including surveillance and 635 testing functions to support customer access maintenance. 637 3.32 Path: 639 See Transport path. 641 3.33 Protection priority: 643 Fault conditions (e.g., signal failed), external commands (e.g, 644 forced switch, manual switch) and protection states (e.g., no 645 request) are defined to have a relative priority with respect to 646 each other. Priority is applied to these conditions/command/states 647 locally at each end point and between the two end points. 649 3.34 Section Layer Network: 651 A section layer is a server layer (which may be MPLS-TP or a 652 different technology) that provides for the transfer of the section- 653 layer client information between adjacent nodes in the transport- 654 path layer or transport-service layer. A section layer may provide 655 for aggregation of multiple MPLS-TP clients. Note that [ITU- 656 T_G.805] defines the section layer as one of the two layer networks 657 in a transmission-media layer network. The other layer network is 658 the physical-media layer network. 660 Section layer networks are concerned with all the functions which 661 provide for the transfer of information between locations in path 662 layer networks. 664 Physical media layer networks are concerned with the actual fibres, 665 metallic wires or radio frequency channels which support a section 666 layer network. 668 3.35 Segment: 670 A link connection as defined in [ITU-T_G.805]. A segment is the 671 part of an LSP that traverses a single link or the part of a PW that 672 traverses a single link (i.e., that connects a pair of adjacent S- 673 PEs and/or T-PEs). See also "Concatenated Segment". 675 3.36 Server layer: 677 A server layer is a layer network in which transport paths are used 678 to carry a customer's (individual or bundled) service (may be point- 679 to-point, point-to-multipoint or multipoint-to-multipoint services). 681 In a client/server relationship (see [ITU-T_G.805]) the server layer 682 network provides a (transport) service to the higher client layer 683 network (usually the layer network under consideration). 685 3.37 Server MEPs: 687 A server MEP is a MEP of an ME that is defined in a layer network 688 below the MPLS-TP layer network being referenced. A server MEP 689 coincides with either a MIP or a MEP in the client (MPLS-TP) layer 690 network. See also [RFC6371] section 3.5 and [ITU-T G.8113.1] clause 691 6.5. 693 For example, a server MEP can be either: 695 . A termination point of a physical link (e.g. IEEE 802.3), an SDH 696 VC or OTH ODU for the MPLS-TP Section layer network, defined in 697 [RFC6371] section 3.1.; 699 . An MPLS-TP Section MEP for MPLS-TP LSPs, defined in [RFC6371] 700 section 3.2.; 702 . An MPLS-TP LSP MEP for MPLS-TP PWs, defined in [RFC6371] section 703 3.4.; 705 . An MPLS-TP TCM MEP for higher-level TCMs, defined in [RFC6371] 706 sections 3.3. and 3.5. 708 The server MEP can run appropriate OAM functions for fault 709 detection, and notifies a fault indication to the MPLS-TP layer 710 network. 712 3.38 Signaling Communication Channel (SCC): 714 A Communication Channel dedicated for control plane communications. 715 The SCC may be used for GMPLS/ASON signaling and/or other control 716 plane messages (e.g., routing messages). 718 3.39 Signaling Communication Network (SCN): 720 A DCN supporting control plane communication is referred to as a 721 Signaling Communication Network (SCN). 723 3.40 Span: 725 A span is synonymous with a link. 727 3.41 Sublayer: 729 Sublayer is defined in [ITU-T_G.805]. The distinction between a 730 layer network and a sublayer is that a sublayer is not directly 731 accessible to clients outside of its encapsulating layer network and 732 offers no direct transport service for a higher layer (client) 733 network. 735 3.42 Transport Entity: 737 A "Transport Entity" is a node, link, transport path segment, 738 concatenated transport path segment, or entire transport path. 740 3.42.1 Working Entity: 742 A "Working Entity" is a transport entity that carries traffic during 743 normal network operation. 745 3.42.2 Protection Entity: 747 A "Protection Entity" is a transport entity that is pre-allocated 748 and used to protect and transport traffic when the working entity 749 fails. 751 3.42.3 Recovery entity: 753 A "Recovery Entity" is a transport entity that is used to recover 754 and transport traffic when the working entity fails. 756 3.43 Transmission media layer: 758 A layer network, consisting of a section layer network and a 759 physical layer network as defined in [ITU-T_G.805], that provides 760 sections (two-port point-to-point connections) to carry the 761 aggregate of network-transport path or network-service layers on 762 various physical media. 764 3.44 Transport Network: 766 A Transport Network provides transmission of traffic between 767 attached client devices by establishing and maintaining point-to- 768 point or point-to-multipoint connections between such devices. A 769 Transport Network is independent of any higher-layer network that 770 may exist between clients, except to the extent required to supply 771 this transmission service. In addition to client traffic, a 772 Transport Network may carry traffic to facilitate its own operation, 773 such as that required to support connection control, network 774 management, and Operations, Administration and Maintenance (OAM) 775 functions. 777 3.45 Transport path: 779 A network connection as defined in [ITU-T_G.805]. In an MPLS-TP 780 environment a transport path corresponds to an LSP or a PW. 782 3.46 Transport path layer: 784 A (sub)layer network that provides point-to-point or point-to- 785 multipoint transport paths. It provides OAM that is independent of 786 the clients that it is transporting. 788 3.47 Transport service layer: 790 A layer network in which transport paths are used to carry a 791 customer's (individual or bundled) service (may be point-to-point, 792 point-to-multipoint or multipoint-to-multipoint services). 794 3.48 Unidirectional path: 796 A Unidirectional Path is a path that supports traffic flow in only 797 one direction. 799 4 Guidance on the Application of this Thesaurus 801 As discussed in the introduction to this document, this thesaurus is 802 intended to bring the concepts and terms associated with MPLS-TP 803 into the context of the ITU-T's Transport Network architecture. 804 Thus, it should help those familiar with MPLS to see how they may 805 use the features and functions of the Transport Network in order to 806 meet the requirements of MPLS-TP. 808 5 Management Considerations 810 The MPLS-TP based network requires management. The MPLS-TP 811 specifications described in [RFC5654], [RFC5860], [RFC5921], 812 [RFC5951], [RFC6371], [RFC6372], [ITU-T G.8110.1] and [ITU-T 813 G.7710], include considerable efforts to provide operator control 814 and monitoring, as well as Operations, Administration and 815 Maintenance (OAM) functionality. 817 These concepts are, however, out of scope of this document. 819 6 Security Considerations 821 Security is a significant requirement of MPLS-TP. See for more 822 information [RFC6941]. 824 However, this informational document is intended only to provide 825 lexicography, and the security concerns are, therefore, out of 826 scope. 828 7 IANA Considerations 830 There are no IANA actions resulting from this document. 832 8 Acknowledgments 834 The authors would like to thank all members of the teams (the Joint 835 Working Team, the MPLS Interoperability Design Team in IETF and the 836 MPLS-TP Ad Hoc Group in ITU-T) involved in the definition and 837 specification of MPLS Transport Profile. We would in particular like 838 to acknowledge the contributions by Tom Petch to improve the quality 839 of this draft. 841 9 References 843 9.1 Normative References 845 [RFC3031] Rosen, E., Viswanathan, A., and Callon, R., "Multiprotocol 846 Label Switching Architecture", January 2001. 848 [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., et al., 849 "Requirements of an MPLS Transport Profile", September 850 2009. 852 [RFC5860] Vigoureux, M., Ward, D., Betts, M., "Requirements for OAM 853 in MPLS Transport Networks", May 2010. 855 [RFC5921] Bocci, M., Bryant, S., Frost, D, et al., "A Framework for 856 MPLS in Transport Networks", July 2010. 858 [RFC5951] Lam, K., Gray, E., Mansfield, S., "Network Management 859 Requirements for MPLS-based Transport Networks", September 860 2010. 862 [RFC6371] Busi, I., Allan, D., "Operations, Administration, and 863 Maintenance Framework for MPLS-Based Transport Networks", 864 September 2011. 866 [RFC6372] Sprecher, N., Farrel, A., "MPLS Transport Profile (MPLS- 867 TP) Survivability Framework", September 2011. 869 For information on the availability of the following documents, 870 please see http://www.itu.int 872 [ITU-T_G.805] ITU-T Recommendation G.805 (03/2000), "Generic 873 functional architecture of transport networks." 875 [ITU-T_G.806] ITU-T Recommendation G.806 (03/2006), "Characteristics 876 of transport equipment - Description methodology and 877 generic functionality." 879 [ITU-T_G.872] ITU-T Recommendation G.872 (11/2001), "Architecture of 880 optical transport networks." 882 [ITU-T G.7710] ITU-T Recommendation G.7710 (07/2007), "Common 883 equipment management function requirements." 885 [ITU-T_G.8101] ITU-T Recommendation G.8101/Y.1355 (09/2013), "Terms 886 and definitions for MPLS Transport Profile." 888 [ITU-T G.8110.1] ITU-T Recommendation G.8110.1/Y.1370.1 (12/2011), 889 "Architecture of the Multi-Protocol Label Switching 890 transport profile layer network." 892 [ITU-T G.8113.1] ITU-T Recommendation G.8113.1/Y.1372.1 (11/2012), 893 "Operations, Administration and Maintenance mechanism 894 for MPLS-TP in Packet Transport Network (PTN)." 896 [ITU-T G.8113.2] ITU-T Recommendation G.8113.2/Y.1372.2 (11/2012), 897 "Operations, administration and maintenance mechanisms 898 for MPLS-TP networks using the tools defined for 899 MPLS." 901 [ITU-T Y.2611] ITU-T Recommendation Y.2611 (12/2006), "High-level 902 architecture of future packet-based networks." 904 9.2 Informative References 906 [RFC4397] I. Bryskin, A. Farrel, "A Lexicography for the 907 Interpretation of Generalized Multiprotocol Label 908 Switching (GMPLS) Terminology within the Context of the 909 ITU-T's Automatically Switched Optical Network (ASON) 910 Architecture", February 2006. 912 [RFC6941] L. Fang, B. Niven-Jenkins, S. Mansfield, R. Graveman, 913 "MPLS Transport Profile (MPLS-TP) Security Framework", 914 April 2013. 916 Authors' Addresses 918 Huub van Helvoort (Editor) 919 Huawei Technologies Co., Ltd. 920 Email: Huub.van.Helvoort@huawei.com 922 Loa Andersson (Editor) 923 Huawei Technologies Co., Ltd. 924 Email: loa@mail01.huawei.com 926 Nurit Sprecher (Editor) 927 Nokia Solutions and Networks 928 Email: nurit.sprecher@nsn.com