idnits 2.17.1 draft-ietf-mpls-tp-rosetta-stone-03.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 (November 28, 2010) is 4898 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '5' is mentioned on line 625, but not defined == Missing Reference: 'RFC3945' is mentioned on line 810, but not defined == Unused Reference: 'ITU-T Y.2611' is defined on line 901, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-mpls-tp-oam-framework-01 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 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: May 2011 L. Andersson (Ed) 5 Ericsson 7 N. Sprecher (Ed) 8 Nokia Siemens Networks 10 November 28, 2010 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-03 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 November 1, 2010. 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: 7 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: 8 93 3.12. MPLS-TP Ring Topology: 8 94 3.13. Path: 8 95 3.14. Section Layer Network: 8 96 3.15. Segment: 8 97 3.16. Server layer: 9 98 3.17. Span: 9 99 3.18. Sublayer: 9 100 3.19. Tandem Connection: 9 101 3.20. Transport path: 10 102 3.21. Transport path layer: 10 103 3.22. Transport service layer: 10 104 3.23. Transmission media layer: 10 105 3.24. Unidirectional path: 10 106 3.25. Failure: 10 107 3.26. Fault: 10 108 3.27. Defect: 11 109 3.28. MPLS Transport Profile (MPLS-TP): 11 110 3.29. MPLS Section: 11 111 3.30. MPLS-TP NE: 11 112 3.31. MPLS-TP network: 11 113 3.32. Equipment Management Function (EMF): 11 114 3.33. Data Communication Network (DCN): 11 115 3.34. Communication Channel (CC): 11 116 3.35. Embedded Communication Channel (ECC): 12 117 3.36. Management Communication Channel (MCC): 12 118 3.37. Management Communication Network (MCN): 12 119 3.38. Signaling Communication Channel (SCC): 12 120 3.39. Signaling Communication Network (SCN): 12 121 3.40. Operations System (OS): 12 122 3.41. Maintenance Entity 12 123 3.42. Maintenance End Points (MEPs) 13 124 3.43. Maintenance Intermediate Points (MIPs) 14 125 3.44. Server MEPs 14 126 4. Guidance on the Application of this Thesaurus 18 127 5. Management Considerations 18 128 6. Security Considerations 18 129 7. IANA Considerations 19 130 8. Acknowledgments 19 131 9. References 19 132 9.1. Normative References 19 133 9.2. Informative References 20 134 Authors' Addresses 20 135 Contributing Authors' Addresses 21 137 1. Introduction 139 Multiprotocol Label Switching - Transport Profile (MPLS-TP) has been 140 developed by the IETF to facilitate the Operation, Administration 141 and Management of Label Switched Paths (LSPs) in a Transport Network 142 environment as defined by the ITU-T. 144 The ITU-T has specified a Transport Network architecture for the 145 transfer of signals from different technologies. This architecture 146 forms the basis of many Recommendations within the ITU-T. 148 Because of the difference in historic background of MPLS, and 149 inherently MPLS-TP (the Internet) and the Transport Network (ITU 150 telecommunication Sector), the terminology used is different. 152 This document provides a thesaurus for the interpretation of ITU-T 153 Transport Network terminology within the context of the MPLS-TP. 154 This allows MPLS-TP documents to be generally understood by those 155 familiar with MPLS RFCs. The definitions presented in this document 156 do not provide exclusive or complete interpretations of the ITU-T 157 Transport Network concepts. 159 1.1. Contributing Authors 161 Italo Busi, Ben Niven-Jenkins, Enrique Hernandez-Valencia, Lieven 162 Levrau, Dinesh Mohan, Stuart Bryant, Dan Frost, Matthew Bocci, 163 Vincenzo Sestito, Vigoureux, Yaacov Weingarten 165 1.2. Abbreviations 167 CC Communications Channel 169 DCN Data Communication Network 171 ECC Embedded Communication Channel 173 EMF Equipment Management Function 175 MCC Management Communication Channel 177 MCN Management Communication Network 179 ME Maintenance Entity 181 MEG ME Group 183 MEP MEG End Point 185 MIP MEG Intermediate Point 187 MPLS Multiprotocol Label Switching 188 MPLS-TP MPLS Transport Profile 190 NE Network Element 192 OAM Operations, Administration and Maintenance 194 O&M OAM and Management 196 SCC Signaling Communication Channel 198 SCN Signaling Communication Network 200 2. Terminology 202 Throughout this document, angle brackets ("<" and ">") are used to 203 indicate that the term is used by both IETF and ITU-T but has a 204 different definition. The bracketed term is the IETF term. 206 [editor: check all terms used that this applies to, TBD] 208 2.1. MPLS-TP Terminology Sources 210 MPLS-TP terminology is principally defined in [RFC3031]. Other 211 documents provide further key definitions including [RFC4397], and 212 [RFC....]. 214 2.2. ITU-T Transport Network Terminology Sources 216 The ITU-T Transport Network is specified in a number of 217 recommendations: generic functional architectures and requirements 218 are specified in [ITU-T_G.805], [ITU-T_G.806], and [ITU-T_G.872]. 219 [ITU-T_G.8101] contains an overview of the Terms and Definitions for 220 transport MPLS. 222 2.3. Common Terminology Sources 224 The work in this document builds on the shared view of MPLS 225 requirements. 227 3. Thesaurus 229 [editor: from [RFC5654] mpls-tp-requirements] 231 3.1. Associated bidirectional path: 233 A path that supports traffic flow in both directions but that is 234 constructed from a pair of unidirectional paths (one for each 235 direction) that are associated with one another at the path's 236 ingress/egress points. The forward and backward directions are 237 setup, monitored, and protected independently. As a consequence, 238 they may or may not follow the same route (links and nodes) across 239 the network. 241 3.2. Bidirectional path: 243 A path that supports traffic flow in two opposite directions, i.e. 244 the forward and backward direction. 246 3.3. Client layer network: 248 In a client/server relationship (see [ITU-T_G.805]), the client 249 layer network receives a (transport) service from the lower server 250 layer network (usually the layer network under consideration). 252 3.4. Concatenated Segment: 254 A serial-compound link connection as defined in [ITU-T_G.805]. A 255 concatenated segment is a contiguous part of an LSP or multi-segment 256 PW that comprises a set of segments and their interconnecting nodes 257 in sequence. See also "Segment". 259 3.5. Control Plane: 261 Within the scope of [RFC5654], the control plane performs transport 262 path control functions. Through signalling, the control plane sets 263 up, modifies and releases transport paths, and may recover a 264 transport path in case of a failure. The control plane also 265 performs other functions in support of transport path control, such 266 as routing information dissemination. 268 3.6. Co-routed bidirectional path: 270 A path where the forward and backward directions follow the same 271 route (links and nodes) across the network. Both directions are 272 setup, monitored and protected as a single entity. A transport 273 network path is typically co-routed. 275 3.7. Domain: 277 A domain represents a collection of entities (for example network 278 elements) that are grouped for a particular purpose, examples of 279 which are administrative and/or managerial responsibilities, trust 280 relationships, addressing schemes, infrastructure capabilities, 281 aggregation, survivability techniques, distributions of control 282 functionality, etc. Examples of such domains include IGP areas and 283 Autonomous Systems. 285 3.8. Layer network: 287 Layer network is defined in [ITU-T_G.805]. A layer network provides 288 for the transfer of client information and independent operation of 289 the client OAM. A layer network may be described in a service 290 context as follows: one layer network may provide a (transport) 291 service to a higher client layer network and may, in turn, be a 292 client to a lower-layer network. A layer network is a logical 293 construction somewhat independent of arrangement or composition of 294 physical network elements. A particular physical network element 295 may topologically belong to more than one layer network, depending 296 on the actions it takes on the encapsulation associated with the 297 logical layers (e.g., the label stack), and thus could be modeled as 298 multiple logical elements. A layer network may consist of one or 299 more sublayers. For additional explanation of how layer networks 300 relate to the OSI concept of layering, see Appendix I of [ITU-T 301 Y.2611]. 303 3.9. Link: 305 A physical or logical connection between a pair of LSRs that are 306 adjacent at the (sub)layer network under consideration. A link may 307 carry zero, one or more LSPs or PWs. A packet entering a link will 308 emerge with the same label stack entry values. 310 A link as defined in [ITU-T_G.805] is used to describe a fixed 311 relationship between two ports. 313 3.10. MPLS-TP Logical Ring: 315 An MPLS-TP logical ring is constructed from a set of LSRs and 316 logical data links (such as MPLS-TP LSP tunnels or MSPL-TP 317 pseudowires) and physical data links that form a ring topology. 319 3.11. MPLS-TP Physical Ring: 321 An MPLS-TP physical ring is constructed from a set of LSRs and 322 physical data links that form a ring topology. 324 3.12. MPLS-TP Ring Topology: 326 In an MPLS-TP ring topology, each LSR is connected to exactly two 327 other LSRs, each via a single point-to-point bidirectional MPLS-TP 328 capable link. A ring may also be constructed from only two LSRs 329 where there are also exactly two links. Rings may be connected to 330 other LSRs to form a larger network. Traffic originating or 331 terminating outside the ring may be carried over the ring. Client 332 network nodes (such as CEs) may be connected directly to an LSR in 333 the ring. 335 3.13. Path: 337 See Transport path. 339 3.14. Section Layer Network: 341 A section layer is a server layer (which may be MPLS-TP or a 342 different technology) that provides for the transfer of the section- 343 layer client information between adjacent nodes in the transport- 344 path layer or transport-service layer. A section layer may provide 345 for aggregation of multiple MPLS-TP clients. Note that [ITU- 346 T_G.805] defines the section layer as one of the two layer networks 347 in a transmission-media layer network. The other layer network is 348 the physical-media layer network. 350 Section layer networks are concerned with all the functions which 351 provide for the transfer of information between locations in path 352 layer networks. 354 Physical media layer networks are concerned with the actual fibres, 355 metallic wires or radio frequency channels which support a section 356 layer network. 358 3.15. Segment: 360 A link connection as defined in [ITU-T_G.805]. A segment is the 361 part of an LSP that traverses a single link or the part of a PW that 362 traverses a single link (i.e., that connects a pair of adjacent 363 {Switching|Terminating} Provider Edges). See also "Concatenated 364 Segment". 366 3.16. Server layer: 368 A layer network in which transport paths are used to carry a 369 customer's (individual or bundled) service (may be point-to-point, 370 point-to-multipoint or multipoint-to-multipoint services). 372 In a client/server relationship (see [ITU-T_G.805]). the server 373 layer network provides a (transport) service to the higher client 374 layer network (usually the layer network under consideration). 376 3.17. Span: 378 A span is synonymous with a link. 380 3.18. Sublayer: 382 Sublayer is defined in [ITU-T_G.805]. The distinction between a 383 layer network and a sublayer is that a sublayer is not directly 384 accessible to clients outside of its encapsulating layer network and 385 offers no direct transport service for a higher layer (client) 386 network. 388 3.19. Tandem Connection: 390 A tandem connection is an arbitrary part of a transport path that 391 can be monitored (via OAM) independently from the end-to-end 392 monitoring (OAM). It may be a monitored segment, a monitored 393 concatenated segment or any other monitored ordered sequence of 394 contiguous hops and/or segments (and their interconnecting nodes) of 395 a transport path. 397 [editor: this is not in [RFC5654] but added for completeness] 399 3.20. Transport Network: 401 A Transport Network provides transmission of traffic between 402 attached client devices by establishing and maintaining point-to- 403 point or point-to-multipoint connections between such devices. A 404 Transport Network is independent of any higher-layer network that 405 may exist between clients, except to the extent required to supply 406 this transmission service. In addition to client traffic, a 407 Transport Network may carry traffic to facilitate its own operation, 408 such as that required to support connection control, network 409 management, and Operations, Administration and Maintenance (OAM) 410 functions. 412 3.21. Transport path: 414 A network connection as defined in [ITU-T_G.805]. In an MPLS-TP 415 environment a transport path corresponds to an LSP or a PW. 417 3.22. Transport path layer: 419 A (sub)layer network that provides point-to-point or point-to- 420 multipoint transport paths. It provides OAM that is independent of 421 the clients that it is transporting. 423 3.23. Transport service layer: 425 A layer network in which transport paths are used to carry a 426 customer's (individual or bundled) service (may be point-to-point, 427 point-to-multipoint or multipoint-to-multipoint services). 429 3.24. Transmission media layer: 431 A layer network, consisting of a section layer network and a 432 physical layer network as defined in [ITU-T_G.805], that provides 433 sections (two-port point-to-point connections) to carry the 434 aggregate of network-transport path or network-service layers on 435 various physical media. 437 3.25. Unidirectional path: 439 A path that supports traffic flow in only one direction. 441 [editor: from: [RFC5860] ] 443 3.26. Failure: 445 [editor: this is not in [RFC5860] but added for completeness] 447 The fault cause persisted long enough to consider the ability of an 448 item to perform a required function to be terminated. The item may 449 be considered as failed; a fault has now been detected. See also 450 [ITU-T_G.806]. 452 3.27. Fault: 454 The inability of a function to perform a required action. This does 455 not include an inability due to preventive maintenance, lack of 456 external resources, or planned actions. See also [ITU-T_G.806]. 458 3.28. Defect: 460 The situation for which density of anomalies has reached a level 461 where the ability to perform a required function has been 462 interrupted. Defects are used as input for PM, the control of 463 consequent actions, and the determination of fault cause. See also 464 [ITU-T_G.806]. 466 3.29. MPLS Transport Profile (MPLS-TP): 468 The set of MPLS functions used to support packet transport services 469 and network operations. 471 3.30. MPLS Section: 473 A network segment between two LSRs that are immediately adjacent at 474 the MPLS layer. 476 [editor: from: [RFC5921] and [RFC5951] ] 478 3.31. MPLS-TP NE: 480 A network element (NE) that supports MPLS-TP functions. 482 3.32. MPLS-TP network: 484 A network in which MPLS-TP NEs are deployed 486 3.33. Equipment Management Function (EMF): 488 The management functions within an NE. See [ITU-T G.7710]. 490 3.34. Data Communication Network (DCN): 492 A network that supports Layer 1 (physical layer), Layer 2 (data-link 493 layer), and Layer 3 (network layer) functionality for distributed 494 management communications related to the management plane, for 495 distributed signaling communications related to the control plane, 496 and other operations communications (e.g., order-wire/voice 497 communications, software downloads, etc.). 499 3.35. Communication Channel (CC): 501 A logical channel between network elements (NEs) that can be used - 502 e.g. - for management plane application or control plane 503 applications. The physical channel supporting the CC is technology 504 specific. See [RFC5951] APPENDIX A 506 3.36. Embedded Communication Channel (ECC): 508 A logical operations channel between network elements (NEs) that can 509 be utilized by multiple applications (e.g., management plane 510 applications, control plane applications, etc.). The physical 511 channel supporting the ECC is technology specific. An example of 512 physical channels supporting the ECC is a DCC channel within SDH. 514 3.37. Management Communication Channel (MCC): 516 A CC dedicated for management plane communications. 518 3.38. Management Communication Network (MCN): 520 A DCN supporting management plane communication is referred to as a 521 Management Communication Network (MCN). 523 3.39. Signaling Communication Channel (SCC): 525 A CC dedicated for control plane communications. The SCC may be used 526 for GMPLS/ASON signaling and/or other control plane messages (e.g., 527 routing messages). 529 3.40. Signaling Communication Network (SCN): 531 A DCN supporting control plane communication is referred to as a 532 Signaling Communication Network (SCN). 534 3.41. Operations System (OS): 536 A system that performs the functions that support processing of 537 information related to operations, administration, maintenance, and 538 provisioning (OAM&P) for the networks, including surveillance and 539 testing functions to support customer access maintenance. 541 [editor: from: draft-busi-mpls-tp-oam-framework-00 [1] ] 543 [editor: OAM flow: to be added in future revision of this document.] 545 3.42. Maintenance Entity 547 A Maintenance Entity can be viewed as the association of two (or 548 more) Maintenance End Points (MEPs), that should be configured and 549 managed in order to bound the OAM responsibilities of an OAM flow 550 [editor: definition?] across a network or sub-network, i.e. a 551 transport path or segment, in the specific layer network that is 552 being monitored and managed. 554 A Maintenance Entity may be defined to monitor and manage 555 bidirectional or unidirectional point-to-point connectivity or 556 point-to-multipoint connectivity in an MPLS-TP layer network. 558 [editor: should the following be included?] 560 Therefore, in the context of MPLS-TP LSP or PW Maintenance Entity 561 (defined below) LERs and T-PEs can be MEPs while LSRs and S-PEs can 562 be MIPs. In the case of Tandem Connection Maintenance Entity 563 (defined below), LSRs and S-PEs can be either MEPs or MIPs. 565 The following properties apply to all MPLS-TP MEs: 567 o OAM entities can be nested but not overlapped. 569 o Each OAM flow is associated to a unique Maintenance Entity. 571 o OAM packets are subject to the same forwarding treatment as the 572 data traffic, but they are distinct from the data traffic. 574 3.43. Maintenance End Points (MEPs) 576 Maintenance End Points (MEPs) are the end points of a pre-configured 577 (through the management or control planes) ME. MEPs are responsible 578 for activating and controlling all of the OAM functionality for the 579 ME. A MEP may initiate an OAM packet to be transferred to its 580 corresponding MEP, or to an intermediate MIP that is part of the ME. 582 A MEP terminates all the OAM packets that it receives corresponding 583 to its ME and does not forward them further along the path. 585 All OAM packets coming to a MEP source are tunnelled via label 586 stacking and are not processed within the ME as they belong either 587 to the client network layers or to an higher TCM level. 589 A MEP in a tandem connection is not coincident with the termination 590 of the MPLS-TP transport path (LSP or PW), though it can monitor its 591 connectivity (e.g. count packets). A MEP of an MPLS-TP network 592 transport path is coincident with transport path termination and 593 monitors its connectivity (e.g. count packets). 595 MPLS-TP MEP notifies a fault indication to the MPLS-TP client layer 596 network. 598 3.44. Maintenance Intermediate Points (MIPs) 600 A Maintenance Intermediate Point (MIP) is a point between the two 601 MEPs in an ME and is capable of responding to some OAM packets and 602 forwarding all OAM packets while ensuring fate sharing with data 603 plane packets. A MIP responds only to OAM packets that are sent on 604 the ME it belongs to and that are addressed to the MIP, it does not 605 initiate OAM messages. 607 3.45. Server MEPs 609 A server MEP is a MEP of an ME that is defined in a layer network 610 below the MPLS-TP layer network being referenced. A server MEP 611 coincides with either a MIP or a MEP in the client (MPLS-TP) layer 612 network. 614 For example, a server MEP can be either: 616 . A termination point of a physical link (e.g. 802.3), an SDH VC or 617 OTH ODU for the MPLS-TP Section layer network, defined in [5] 618 section 3.1.; 620 . An MPLS-TP Section MEP for MPLS-TP LSPs, defined in [5] section 621 3.2.; 623 . An MPLS-TP LSP MEP for MPLS-TP PWs, defined in [5] section 3.4.; 625 . An MPLS-TP TCM MEP for higher-level TCMs, defined in [5] sections 626 3.3. and 3.5. 628 The server MEP can run appropriate OAM functions for fault 629 detection, and notifies a fault indication to the MPLS-TP layer 630 network. 632 [editor: the following are definitions from G.8101 which should be 633 defined only if they will cause misunderstanding. It is not usefull 634 to define them if the definition is the same in IETF and ITU-T, TBD] 636 ===== [ITU-T_G.8101] ===== 638 3.1 access point 640 3.2 adapted information 642 3.3 characteristic information 644 3.4 client/server relationship 645 3.5 connection 647 3.6 connection point 649 3.9 forward direction 651 3.12 link connection 653 3.13 matrix 655 3.14 network 657 3.15 network connection 659 3.16 network operator 661 3.17 port 663 3.18 reference point 665 3.19 service provider 667 3.20 subnetwork 669 3.21 subnetwork connection 671 3.22 termination connection point 673 3.23 trail 675 3.24 trail termination 677 3.25 trail termination point 679 3.26 transport 681 3.27 transport entity 683 3.28 transport processing function 685 3.29 unidirectional connection 687 3.30 unidirectional trail 689 3.31 Z layer 690 Transport MPLS (MPLS-TP) Recommendations uses the following terms 691 defined in ITU-T Rec. G.809: 693 3.33 access point 695 3.34 adaptation 697 3.35 adapted information 699 3.36 characteristic information 701 3.37 client/server relationship 703 3.50 network 705 3.52 port 707 3.53 reference point 709 3.56 traffic unit 711 3.57 transport 713 3.58 transport entity 715 Transport MPLS (MPLS-TP) Recommendations uses the following term 716 defined in ITU-T Rec. G.8010/Y.1306: 718 3.59 point-to-point Ethernet connection 720 Transport MPLS (MPLS-TP) Recommendations uses the following terms 721 defined in [ITU-T_Y.1711]: 723 3.60 backward direction 725 3.62 client/server (relationship between layer networks) 727 3.63 failure 729 3.64 forward direction 731 3.65 user-plane 733 Transport MPLS (MPLS-TP) Recommendations uses the following terms 734 defined in [ITU-T_Y.1720]: 736 3.66 1+1 protection 737 3.67 1:1 protection 739 3.68 bidirectional protection switching 741 3.69 bridge 743 3.71 extra traffic 745 3.72 failure 747 3.73 forced switch for working LSP 749 3.74 hold-off time 751 3.75 manual switch 753 3.76 MPLS protection domain 755 3.77 non-revertive protection switching 757 3.78 no request 759 3.79 packet 1+1 protection 761 3.80 path switch LSR 763 3.81 path merge LSR 765 3.82 protection LSP 767 3.83 protection switching 769 3.84 rerouting 771 3.85 revertive protection switching 773 3.86 selector 775 3.87 shared mesh protection 777 3.88 Shared Risk Group (SRG) 779 3.89 sink of the protection domain 781 3.90 source of the protection domain 783 3.91 unidirectional protection switching 784 3.92 wait to restore 786 3.93 wait to restore timer 788 3.94 working LSP 790 Transport MPLS (MPLS-TP) Recommendations uses the following terms 791 defined in [ITU-T_Y.1731]: 793 3.95 in-service OAM 795 ===== end of [ITU-T_G.8101] ===== 797 4. Guidance on the Application of this Thesaurus 799 As discussed in the introduction to this document, this thesaurus is 800 intended to bring the concepts and terms associated with MPLS-TP 801 into the context of the ITU-T's Transport Network architecture. 802 Thus, it should help those familiar with MPLS to see how they may 803 use the features and functions of the Transport Network in order to 804 meet the requirements of MPLS-TP. 806 This lexicography should not be used in order to obtain or derive 807 definitive definitions of GMPLS terms. To obtain definitions of 808 GMPLS terms that are applicable across all GMPLS architectural 809 models, the reader should refer to the RFCs listed in the references 810 sections of this document. [RFC3945] provides an overview of the 811 GMPLS architecture and should be read first. 813 5. Management Considerations 815 The MPLS-TP based network requires management. The MPLS-TP 816 specifications include considerable efforts to provide operator 817 control and monitoring, as well as Operations and Management (OAM) 818 functionality. 820 These concepts are, however, out of scope of this document. 822 6. Security Considerations 824 Security is also a significant requirement of MPLS-TP. 826 However, this informational document is intended only to provide a 827 lexicography, and the security concerns are, therefore, out of 828 scope. 830 7. IANA Considerations 832 To be incorporated in a future revision of this document 834 <> 836 8. Acknowledgments 838 The authors would like to thank all members of the teams (the Joint 839 Working Team, the MPLS Interoperability Design Team in IETF and the 840 MPLS-TP Ad Hoc Group in ITU-T) involved in the definition and 841 specification of MPLS Transport Profile. 843 9. References 845 9.1. Normative References 847 [1] Busi, I., Niven-Jenkins, B., et al., "MPLS-TP OAM Framework 848 and Overview", draft-ietf-mpls-tp-oam-framework-01, july 2009 850 [RFC5654] B. Niven-Jenkins, et al., "Requirements of an MPLS 851 Transport Profile", September 2009 853 [RFC5921] Bocci, M., Bryant, S., Levrau, L., "A Framework for MPLS 854 in Transport Networks", July 2010 856 [RFC5860] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM 857 in MPLS Transport Networks", May 2010 859 [RFC5951] Gray, E., Mansfield, S., et al., "MPLS TP Network 860 Management Requirements", September 2010 862 [RFC3031] E. Rosen, etal., "Requirements of an MPLS Transport 863 Profile", january 2001 865 [RFC4397] I. Bryskin, A. Farrel, "A Lexicography for the 866 Interpretation of Generalized Multiprotocol Label 867 Switching (GMPLS) Terminology within the Context of the 868 ITU-T's Automatically Switched Optical Network (ASON) 869 Architecture", february 2006 871 9.2. Informative References 873 For information on the availability of the following documents, 874 please see http://www.itu.int 876 [ITU-T_G.8101] ITU-T Recommendation G.8101/Y.1355 (12/2006), Terms 877 and definitions for transport MPLS. 879 [ITU-T_G.805] ITU-T Recommendation G.805 (03/2000), Generic 880 functional architecture of transport networks. 882 [ITU-T_G.806] ITU-T Recommendation G.806 (03/2006), Characteristics 883 of transport equipment - Description methodology and 884 generic functionality. 886 [ITU-T_Y.1711] ITU-T Recommendation Y.1711 (10/2005) Operation & 887 Maintenance mechanism for MPLS networks. 889 [ITU-T_Y.1720] ITU-T Recommendation Y.1720 (02/2008), Protection 890 switching for MPLS networks. 892 [ITU-T_Y.1731] ITU-T Recommendation Y.1731 (02/2008), OAM functions 893 and mechanisms for Ethernet based networks. 895 [ITU-T_G.872] ITU-T Recommendation G.872 (11/2001), Architecture of 896 optical transport networks. 898 [ITU-T G.7710] ITU-T Recommendation G.7710 (07/2007), Common 899 equipment management function requirements 901 [ITU-T Y.2611] ITU-T Recommendation Y.2611 (12/2006), High-level 902 architecture of future packet-based networks 904 Authors' Addresses 906 Huub van Helvoort (Editor) 907 Huawei Technologies Co., Ltd. 908 Email: hhelvoort@huawei.com 910 Loa Andersson (Editor) 911 Ericsson 912 Email: loa.andersson@ericsson.com 913 Nurit Sprecher (Editor) 914 Nokia Siemens Networks 915 Email: nurit.sprecher@nsn.com 917 Contributing Authors' Addresses