idnits 2.17.1 draft-ietf-mpls-tp-rosetta-stone-04.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 == Line 277 has weird spacing: '...example netw...' -- The document date (June 2, 2011) is 4709 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 812, but not defined == Unused Reference: '1' is defined on line 849, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 852, but no explicit reference was found in the text == Unused Reference: 'ITU-T Y.2611' is defined on line 906, 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 (~~), 8 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: December 2011 L. Andersson (Ed) 5 Ericsson 7 N. Sprecher (Ed) 8 Nokia Siemens Networks 10 June 2, 2011 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-04 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 December 1, 2011. 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: check definitions in draft-ietf-mpls-tp-survive-fwk [2]] 634 [editor: the following are definitions from G.8101 which should be 635 defined only if they will cause misunderstanding. It is not usefull 636 to define them if the definition is the same in IETF and ITU-T, TBD] 638 ===== [ITU-T_G.8101] ===== 640 3.1 access point 642 3.2 adapted information 644 3.3 characteristic information 645 3.4 client/server relationship 647 3.5 connection 649 3.6 connection point 651 3.9 forward direction 653 3.12 link connection 655 3.13 matrix 657 3.14 network 659 3.15 network connection 661 3.16 network operator 663 3.17 port 665 3.18 reference point 667 3.19 service provider 669 3.20 subnetwork 671 3.21 subnetwork connection 673 3.22 termination connection point 675 3.23 trail 677 3.24 trail termination 679 3.25 trail termination point 681 3.26 transport 683 3.27 transport entity 685 3.28 transport processing function 687 3.29 unidirectional connection 689 3.30 unidirectional trail 691 3.31 Z layer 692 Transport MPLS (MPLS-TP) Recommendations uses the following terms 693 defined in ITU-T Rec. G.809: 695 3.33 access point 697 3.34 adaptation 699 3.35 adapted information 701 3.36 characteristic information 703 3.37 client/server relationship 705 3.50 network 707 3.52 port 709 3.53 reference point 711 3.56 traffic unit 713 3.57 transport 715 3.58 transport entity 717 Transport MPLS (MPLS-TP) Recommendations uses the following term 718 defined in ITU-T Rec. G.8010/Y.1306: 720 3.59 point-to-point Ethernet connection 722 Transport MPLS (MPLS-TP) Recommendations uses the following terms 723 defined in [ITU-T_Y.1711]: 725 3.60 backward direction 727 3.62 client/server (relationship between layer networks) 729 3.63 failure 731 3.64 forward direction 733 3.65 user-plane 735 Transport MPLS (MPLS-TP) Recommendations uses the following terms 736 defined in [ITU-T_Y.1720]: 738 3.66 1+1 protection 739 3.67 1:1 protection 741 3.68 bidirectional protection switching 743 3.69 bridge 745 3.71 extra traffic 747 3.72 failure 749 3.73 forced switch for working LSP 751 3.74 hold-off time 753 3.75 manual switch 755 3.76 MPLS protection domain 757 3.77 non-revertive protection switching 759 3.78 no request 761 3.79 packet 1+1 protection 763 3.80 path switch LSR 765 3.81 path merge LSR 767 3.82 protection LSP 769 3.83 protection switching 771 3.84 rerouting 773 3.85 revertive protection switching 775 3.86 selector 777 3.87 shared mesh protection 779 3.88 Shared Risk Group (SRG) 781 3.89 sink of the protection domain 783 3.90 source of the protection domain 785 3.91 unidirectional protection switching 786 3.92 wait to restore 788 3.93 wait to restore timer 790 3.94 working LSP 792 Transport MPLS (MPLS-TP) Recommendations uses the following terms 793 defined in [ITU-T_Y.1731]: 795 3.95 in-service OAM 797 ===== end of [ITU-T_G.8101] ===== 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 This lexicography should not be used in order to obtain or derive 809 definitive definitions of GMPLS terms. To obtain definitions of 810 GMPLS terms that are applicable across all GMPLS architectural 811 models, the reader should refer to the RFCs listed in the references 812 sections of this document. [RFC3945] provides an overview of the 813 GMPLS architecture and should be read first. 815 5. Management Considerations 817 The MPLS-TP based network requires management. The MPLS-TP 818 specifications include considerable efforts to provide operator 819 control and monitoring, as well as Operations and Management (OAM) 820 functionality. 822 These concepts are, however, out of scope of this document. 824 6. Security Considerations 826 Security is also a significant requirement of MPLS-TP. 828 However, this informational document is intended only to provide a 829 lexicography, and the security concerns are, therefore, out of 830 scope. 832 7. IANA Considerations 834 To be incorporated in a future revision of this document 836 <> 838 8. Acknowledgments 840 The authors would like to thank all members of the teams (the Joint 841 Working Team, the MPLS Interoperability Design Team in IETF and the 842 MPLS-TP Ad Hoc Group in ITU-T) involved in the definition and 843 specification of MPLS Transport Profile. 845 9. References 847 9.1. Normative References 849 [1] Busi, I., Niven-Jenkins, B., et al., "MPLS-TP OAM Framework 850 and Overview", draft-ietf-mpls-tp-oam-framework-01, july 2009 852 [2] Sprecher, N., Farrel, A., "Survivability Framework", draft- 853 ietf-mpls-tp-survive-fwk-06, June 2010 855 [RFC5654] B. Niven-Jenkins, et al., "Requirements of an MPLS 856 Transport Profile", September 2009 858 [RFC5921] Bocci, M., Bryant, S., Levrau, L., "A Framework for MPLS 859 in Transport Networks", July 2010 861 [RFC5860] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM 862 in MPLS Transport Networks", May 2010 864 [RFC5951] Gray, E., Mansfield, S., et al., "MPLS TP Network 865 Management Requirements", September 2010 867 [RFC3031] E. Rosen, etal., "Requirements of an MPLS Transport 868 Profile", january 2001 870 [RFC4397] I. Bryskin, A. Farrel, "A Lexicography for the 871 Interpretation of Generalized Multiprotocol Label 872 Switching (GMPLS) Terminology within the Context of the 873 ITU-T's Automatically Switched Optical Network (ASON) 874 Architecture", february 2006 876 9.2. Informative References 878 For information on the availability of the following documents, 879 please see http://www.itu.int 881 [ITU-T_G.8101] ITU-T Recommendation G.8101/Y.1355 (12/2006), Terms 882 and definitions for transport MPLS. 884 [ITU-T_G.805] ITU-T Recommendation G.805 (03/2000), Generic 885 functional architecture of transport networks. 887 [ITU-T_G.806] ITU-T Recommendation G.806 (03/2006), Characteristics 888 of transport equipment - Description methodology and 889 generic functionality. 891 [ITU-T_Y.1711] ITU-T Recommendation Y.1711 (10/2005) Operation & 892 Maintenance mechanism for MPLS networks. 894 [ITU-T_Y.1720] ITU-T Recommendation Y.1720 (02/2008), Protection 895 switching for MPLS networks. 897 [ITU-T_Y.1731] ITU-T Recommendation Y.1731 (02/2008), OAM functions 898 and mechanisms for Ethernet based networks. 900 [ITU-T_G.872] ITU-T Recommendation G.872 (11/2001), Architecture of 901 optical transport networks. 903 [ITU-T G.7710] ITU-T Recommendation G.7710 (07/2007), Common 904 equipment management function requirements 906 [ITU-T Y.2611] ITU-T Recommendation Y.2611 (12/2006), High-level 907 architecture of future packet-based networks 909 Authors' Addresses 911 Huub van Helvoort (Editor) 912 Huawei Technologies Co., Ltd. 913 Email: huub.van.helvoort@huawei.com 915 Loa Andersson (Editor) 916 Ericsson 917 Email: loa.andersson@ericsson.com 918 Nurit Sprecher (Editor) 919 Nokia Siemens Networks 920 Email: nurit.sprecher@nsn.com 922 Contributing Authors' Addresses