idnits 2.17.1 draft-ietf-mpls-tp-rosetta-stone-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 273 has weird spacing: '...example netw...' -- The document date (October 25, 2009) is 5294 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '5' is mentioned on line 627, but not defined == Missing Reference: 'RFC3945' is mentioned on line 812, but not defined == Unused Reference: '2' is defined on line 853, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 860, but no explicit reference was found in the text == Unused Reference: 'ITU-T Y.2611' is defined on line 905, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-mpls-tp-oam-requirements-03 == Outdated reference: A later version (-12) exists of draft-ietf-mpls-tp-framework-06 == Outdated reference: A later version (-11) exists of draft-ietf-mpls-tp-oam-framework-01 Summary: 1 error (**), 0 flaws (~~), 10 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: April 2010 L. Andersson (Ed) 5 Redback 7 N. Sprecher (Ed) 8 Nokia Siemens Networks 10 October 25, 2009 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-01 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 1, 2010. 40 Copyright Notice 42 Copyright (c) 2009 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 in effect on the date of 47 publication of this document (http://trustee.ietf.org/license-info). 48 Please review these documents carefully, as they describe your 49 rights and restrictions with respect to this document. 51 Abstract 53 MPLS-TP is based on a profile of the MPLS and PW procedures as 54 specified in the MPLS-TE and (MS-)PW architectures developed by the 55 IETF. The ITU-T has specified a Transport Network architecture. 57 This document provides a thesaurus for the interpretation of MPLS-TP 58 terminology within the context of the ITU-T Transport Network 59 recommendations. 61 It is important to note that MPLS-TP is applicable in a wider set of 62 contexts than just Transport Networks. The definitions presented in 63 this document do not provide exclusive nor complete interpretations 64 of MPLS-TP concepts. This document simply allows the MPLS-TP terms 65 to be applied within the Transport Network context. 67 Table of Contents 69 1. Introduction 3 70 1.1. Contributing Authors 4 71 1.2. Abbreviations 4 72 SCC Signaling Communication Channel 5 73 2. Terminology 5 74 2.1. MPLS-TP Terminology Sources 5 75 2.2. ITU-T Transport Network Terminology Sources 5 76 2.3. Common Terminology Sources 5 77 3. Thesaurus 5 78 3.1. Associated bidirectional path: 6 79 3.2. Bidirectional path: 6 80 3.3. Client layer network: 6 81 3.4. Concatenated Segment: 6 82 3.5. Control Plane: 6 83 3.6. Co-routed bidirectional path: 6 84 3.7. Domain: 7 85 3.8. Layer network: 7 86 3.9. Link: 7 87 3.10. MPLS-TP Logical Ring: 7 88 3.11. MPLS-TP Physical Ring: 8 89 3.12. MPLS-TP Ring Topology: 8 90 3.13. Path: 8 91 3.14. Section Layer Network: 8 92 3.15. Segment: 8 93 3.16. Server layer: 9 94 3.17. Span: 9 95 3.18. Sublayer: 9 96 3.19. Tandem Connection: 9 97 3.20. Transport path: 10 98 3.21. Transport path layer: 10 99 3.22. Transport service layer: 10 100 3.23. Transmission media layer: 10 101 3.24. Unidirectional path: 10 102 3.25. Failure: 10 103 3.26. Fault: 10 104 3.27. Defect: 11 105 3.28. MPLS Transport Profile (MPLS-TP): 11 106 3.29. MPLS Section: 11 107 3.30. MPLS-TP NE: 11 108 3.31. MPLS-TP network: 11 109 3.32. Equipment Management Function (EMF): 11 110 3.33. Data Communication Network (DCN): 11 111 3.34. Communication Channel (CC): 11 112 3.35. Embedded Communication Channel (ECC): 12 113 3.36. Management Communication Channel (MCC): 12 114 3.37. Management Communication Network (MCN): 12 115 3.38. Signaling Communication Channel (SCC): 12 116 3.39. Signaling Communication Network (SCN): 12 117 3.40. Operations System (OS): 12 118 3.41. Maintenance Entity 13 119 3.42. Maintenance End Points (MEPs) 13 120 3.43. Maintenance Intermediate Points (MIPs) 14 121 3.44. Server MEPs 14 122 4. Guidance on the Application of this Thesaurus 18 123 5. Management Considerations 18 124 6. Security Considerations 19 125 7. IANA Considerations 19 126 8. Acknowledgments 19 127 9. References 19 128 9.1. Normative References 19 129 9.2. Informative References 20 130 Authors' Addresses 20 131 Contributing Authors' Addresses 21 133 1. Introduction 135 Multiprotocol Label Switching - Transport Profile (MPLS-TP) has been 136 developed by the IETF to facilitate the Operation, Administration 137 and Management of Label Switched Paths (LSPs) in a Transport Network 138 environment as defined by the ITU-T. 140 The ITU-T has specified a Transport Network architecture for the 141 transfer of signals from different technologies. This architecture 142 forms the basis of many Recommendations within the ITU-T. 144 Because of the difference in historic background of MPLS, and 145 inherently MPLS-TP (the Internet) and the Transport Network (ITU 146 telecommunication Sector), the terminology used is different. 148 This document provides a thesaurus for the interpretation of ITU-T 149 Transport Network terminology within the context of the MPLS-TP. 150 This allows MPLS-TP documents to be generally understood by those 151 familiar with MPLS RFCs. The definitions presented in this document 152 do not provide exclusive or complete interpretations of the ITU-T 153 Transport Network concepts. 155 1.1. Contributing Authors 157 Italo Busi, Ben Niven-Jenkins, Enrique Hernandez-Valencia, Lieven 158 Levrau, Dinesh Mohan, Stuart Bryant, Dan Frost, Matthew Bocci, 159 Vincenzo Sestito, Vigoureux, Yaacov Weingarten 161 1.2. Abbreviations 163 CC Communications Channel 165 DCN Data Communication Network 167 ECC Embedded Communication Channel 169 EMF Equipment Management Function 171 MCC Management Communication Channel 173 MCN Management Communication Network 175 ME Maintenance Entity 177 MEG ME Group 179 MEP MEG End Point 181 MIP MEG Intermediate Point 183 MPLS Multiprotocol Label Switching 185 MPLS-TP MPLS Transport Profile 186 NE Network Element 188 OAM Operations, Administration and Maintenance 190 O&M OAM and Management 192 SCC Signaling Communication Channel 194 SCN Signaling Communication Network 196 2. Terminology 198 Throughout this document, angle brackets ("<" and ">") are used to 199 indicate that the term is used by both IETF and ITU-T but has a 200 different definition. The bracketed term is the IETF term. 202 [editor: check all terms used that this applies to, TBD] 204 2.1. MPLS-TP Terminology Sources 206 MPLS-TP terminology is principally defined in [RFC3031]. Other 207 documents provide further key definitions including [RFC4397], and 208 [RFC....]. 210 2.2. ITU-T Transport Network Terminology Sources 212 The ITU-T Transport Network is specified in a number of 213 recommendations: generic functional architectures and requirements 214 are specified in [ITU-T_G.805], [ITU-T_G.806], and [ITU-T_G.872]. 215 [ITU-T_G.8101] contains an overview of the Terms and Definitions for 216 transport MPLS. 218 2.3. Common Terminology Sources 220 The work in this document builds on the shared view of MPLS 221 requirements. 223 3. Thesaurus 225 [editor: from [RFC5654] mpls-tp-requirements] 227 3.1. Associated bidirectional path: 229 A path that supports traffic flow in both directions but that is 230 constructed from a pair of unidirectional paths (one for each 231 direction) that are associated with one another at the path's 232 ingress/egress points. The forward and backward directions are 233 setup, monitored, and protected independently. As a consequence, 234 they may or may not follow the same route (links and nodes) across 235 the network. 237 3.2. Bidirectional path: 239 A path that supports traffic flow in two opposite directions, i.e. 240 the forward and backward direction. 242 3.3. Client layer network: 244 In a client/server relationship (see [ITU-T_G.805]), the client 245 layer network receives a (transport) service from the lower server 246 layer network (usually the layer network under consideration). 248 3.4. Concatenated Segment: 250 A serial-compound link connection as defined in [ITU-T_G.805]. A 251 concatenated segment is a contiguous part of an LSP or multi-segment 252 PW that comprises a set of segments and their interconnecting nodes 253 in sequence. See also "Segment". 255 3.5. Control Plane: 257 Within the scope of [RFC5654], the control plane performs transport 258 path control functions. Through signalling, the control plane sets 259 up, modifies and releases transport paths, and may recover a 260 transport path in case of a failure. The control plane also 261 performs other functions in support of transport path control, such 262 as routing information dissemination. 264 3.6. Co-routed bidirectional path: 266 A path where the forward and backward directions follow the same 267 route (links and nodes) across the network. Both directions are 268 setup, monitored and protected as a single entity. A transport 269 network path is typically co-routed. 271 3.7. Domain: 273 A domain represents a collection of entities (for example network 274 elements) that are grouped for a particular purpose, examples of 275 which are administrative and/or managerial responsibilities, trust 276 relationships, addressing schemes, infrastructure capabilities, 277 aggregation, survivability techniques, distributions of control 278 functionality, etc. Examples of such domains include IGP areas and 279 Autonomous Systems. 281 3.8. Layer network: 283 Layer network is defined in [ITU-T_G.805]. A layer network provides 284 for the transfer of client information and independent operation of 285 the client OAM. A layer network may be described in a service 286 context as follows: one layer network may provide a (transport) 287 service to a higher client layer network and may, in turn, be a 288 client to a lower-layer network. A layer network is a logical 289 construction somewhat independent of arrangement or composition of 290 physical network elements. A particular physical network element 291 may topologically belong to more than one layer network, depending 292 on the actions it takes on the encapsulation associated with the 293 logical layers (e.g., the label stack), and thus could be modeled as 294 multiple logical elements. A layer network may consist of one or 295 more sublayers. For additional explanation of how layer networks 296 relate to the OSI concept of layering, see Appendix I of [ITU-T 297 Y.2611]. 299 3.9. Link: 301 A physical or logical connection between a pair of LSRs that are 302 adjacent at the (sub)layer network under consideration. A link may 303 carry zero, one or more LSPs or PWs. A packet entering a link will 304 emerge with the same label stack entry values. 306 A link as defined in [ITU-T_G.805] is used to describe a fixed 307 relationship between two ports. 309 3.10. MPLS-TP Logical Ring: 311 An MPLS-TP logical ring is constructed from a set of LSRs and 312 logical data links (such as MPLS-TP LSP tunnels or MSPL-TP 313 pseudowires) and physical data links that form a ring topology. 315 3.11. MPLS-TP Physical Ring: 317 An MPLS-TP physical ring is constructed from a set of LSRs and 318 physical data links that form a ring topology. 320 3.12. MPLS-TP Ring Topology: 322 In an MPLS-TP ring topology, each LSR is connected to exactly two 323 other LSRs, each via a single point-to-point bidirectional MPLS-TP 324 capable link. A ring may also be constructed from only two LSRs 325 where there are also exactly two links. Rings may be connected to 326 other LSRs to form a larger network. Traffic originating or 327 terminating outside the ring may be carried over the ring. Client 328 network nodes (such as CEs) may be connected directly to an LSR in 329 the ring. 331 3.13. Path: 333 See Transport path. 335 3.14. Section Layer Network: 337 A section layer is a server layer (which may be MPLS-TP or a 338 different technology) that provides for the transfer of the section- 339 layer client information between adjacent nodes in the transport- 340 path layer or transport-service layer. A section layer may provide 341 for aggregation of multiple MPLS-TP clients. Note that [ITU- 342 T_G.805] defines the section layer as one of the two layer networks 343 in a transmission-media layer network. The other layer network is 344 the physical-media layer network. 346 Section layer networks are concerned with all the functions which 347 provide for the transfer of information between locations in path 348 layer networks. 350 Physical media layer networks are concerned with the actual fibres, 351 metallic wires or radio frequency channels which support a section 352 layer network. 354 3.15. Segment: 356 A link connection as defined in [ITU-T_G.805]. A segment is the 357 part of an LSP that traverses a single link or the part of a PW that 358 traverses a single link (i.e., that connects a pair of adjacent 359 {Switching|Terminating} Provider Edges). See also "Concatenated 360 Segment". 362 3.16. Server layer: 364 A layer network in which transport paths are used to carry a 365 customer's (individual or bundled) service (may be point-to-point, 366 point-to-multipoint or multipoint-to-multipoint services). 368 In a client/server relationship (see [ITU-T_G.805]). the server 369 layer network provides a (transport) service to the higher client 370 layer network (usually the layer network under consideration). 372 3.17. Span: 374 A span is synonymous with a link. 376 3.18. Sublayer: 378 Sublayer is defined in [ITU-T_G.805]. The distinction between a 379 layer network and a sublayer is that a sublayer is not directly 380 accessible to clients outside of its encapsulating layer network and 381 offers no direct transport service for a higher layer (client) 382 network. 384 3.19. Tandem Connection: 386 A tandem connection is an arbitrary part of a transport path that 387 can be monitored (via OAM) independently from the end-to-end 388 monitoring (OAM). It may be a monitored segment, a monitored 389 concatenated segment or any other monitored ordered sequence of 390 contiguous hops and/or segments (and their interconnecting nodes) of 391 a transport path. 393 [editor: this is not in [RFC5654] BUT added for completeness] 395 3.20. Transport Network: 397 A Transport Network provides transmission of traffic between 398 attached client devices by establishing and maintaining point-to- 399 point or point-to-multipoint connections between such devices. A 400 Transport Network is independent of any higher-layer network that 401 may exist between clients, except to the extent required to supply 402 this transmission service. In addition to client traffic, a 403 Transport Network may carry traffic to facilitate its own operation, 404 such as that required to support connection control, network 405 management, and Operations, Administration and Maintenance (OAM) 406 functions. 408 3.21. Transport path: 410 A network connection as defined in [ITU-T_G.805]. In an MPLS-TP 411 environment a transport path corresponds to an LSP or a PW. 413 3.22. Transport path layer: 415 A (sub)layer network that provides point-to-point or point-to- 416 multipoint transport paths. It provides OAM that is independent of 417 the clients that it is transporting. 419 3.23. Transport service layer: 421 A layer network in which transport paths are used to carry a 422 customer's (individual or bundled) service (may be point-to-point, 423 point-to-multipoint or multipoint-to-multipoint services). 425 3.24. Transmission media layer: 427 A layer network, consisting of a section layer network and a 428 physical layer network as defined in [ITU-T_G.805], that provides 429 sections (two-port point-to-point connections) to carry the 430 aggregate of network-transport path or network-service layers on 431 various physical media. 433 3.25. Unidirectional path: 435 A path that supports traffic flow in only one direction. 437 [editor: from: draft-ietf-mpls-tp-oam-requirements [1]] 439 3.26. Failure: 441 [editor: this is not in [1] BUT added for completeness] 443 The fault cause persisted long enough to consider the ability of an 444 item to perform a required function to be terminated. The item may 445 be considered as failed; a fault has now been detected. See also 446 [ITU-T_G.806]. 448 3.27. Fault: 450 The inability of a function to perform a required action. This does 451 not include an inability due to preventive maintenance, lack of 452 external resources, or planned actions. See also [ITU-T_G.806]. 454 3.28. Defect: 456 The situation for which density of anomalies has reached a level 457 where the ability to perform a required function has been 458 interrupted. Defects are used as input for PM, the control of 459 consequent actions, and the determination of fault cause. See also 460 [ITU-T_G.806]. 462 3.29. MPLS Transport Profile (MPLS-TP): 464 The set of MPLS functions used to support packet transport services 465 and network operations. 467 3.30. MPLS Section: 469 A network segment between two LSRs that are immediately adjacent at 470 the MPLS layer. 472 [editor: from: draft-ietf-mpls-tp-framework [2]] 474 [editor: from: draft-gray-mpls-tp-nm-req [3]] 476 3.31. MPLS-TP NE: 478 A network element (NE) that supports MPLS-TP functions. 480 3.32. MPLS-TP network: 482 A network in which MPLS-TP NEs are deployed 484 3.33. Equipment Management Function (EMF): 486 The management functions within an NE. See [ITU-T G.7710]. 488 3.34. Data Communication Network (DCN): 490 A network that supports Layer 1 (physical layer), Layer 2 (data-link 491 layer), and Layer 3 (network layer) functionality for distributed 492 management communications related to the management plane, for 493 distributed signaling communications related to the control plane, 494 and other operations communications (e.g., order-wire/voice 495 communications, software downloads, etc.). 497 3.35. Communication Channel (CC): 499 A logical channel between network elements (NEs) that can be used - 500 e.g. - for management plane application or control plane 501 applications. The physical channel supporting the CC is technology 502 specific. See [3] APPENDIX A 504 3.36. Embedded Communication Channel (ECC): 506 A logical operations channel between network elements (NEs) that can 507 be utilized by multiple applications (e.g., management plane 508 applications, control plane applications, etc.). The physical 509 channel supporting the ECC is technology specific. An example of 510 physical channels supporting the ECC is a DCC channel within SDH. 512 3.37. Management Communication Channel (MCC): 514 A CC dedicated for management plane communications. 516 3.38. Management Communication Network (MCN): 518 A DCN supporting management plane communication is referred to as a 519 Management Communication Network (MCN). 521 3.39. Signaling Communication Channel (SCC): 523 A CC dedicated for control plane communications. The SCC may be used 524 for GMPLS/ASON signaling and/or other control plane messages (e.g., 525 routing messages). 527 3.40. Signaling Communication Network (SCN): 529 A DCN supporting control plane communication is referred to as a 530 Signaling Communication Network (SCN). 532 3.41. Operations System (OS): 534 A system that performs the functions that support processing of 535 information related to operations, administration, maintenance, and 536 provisioning (OAM&P) for the networks, including surveillance and 537 testing functions to support customer access maintenance. 539 [editor: from: draft-busi-mpls-tp-oam-framework-00 [4]] 541 [editor: MPLS Section: already defined in 3.30] 543 [editor: OAM flow: to be added in future revision of this document.] 545 [editor: Tandem Connection: already defined in 3.19] 547 3.42. Maintenance Entity 549 A Maintenance Entity can be viewed as the association of two (or 550 more) Maintenance End Points (MEPs), that should be configured and 551 managed in order to bound the OAM responsibilities of an OAM flow 552 [editor: definition?] across a network or sub-network, i.e. a 553 transport path or segment, in the specific layer network that is 554 being monitored and managed. 556 A Maintenance Entity may be defined to monitor and manage 557 bidirectional or unidirectional point-to-point connectivity or 558 point-to-multipoint connectivity in an MPLS-TP layer network. 560 [editor: should the following be included?] 562 Therefore, in the context of MPLS-TP LSP or PW Maintenance Entity 563 (defined below) LERs and T-PEs can be MEPs while LSRs and S-PEs can 564 be MIPs. In the case of Tandem Connection Maintenance Entity 565 (defined below), LSRs and S-PEs can be either MEPs or MIPs. 567 The following properties apply to all MPLS-TP MEs: 569 o OAM entities can be nested but not overlapped. 571 o Each OAM flow is associated to a unique Maintenance Entity. 573 o OAM packets are subject to the same forwarding treatment as the 574 data traffic, but they are distinct from the data traffic. 576 3.43. Maintenance End Points (MEPs) 578 Maintenance End Points (MEPs) are the end points of a pre-configured 579 (through the management or control planes) ME. MEPs are responsible 580 for activating and controlling all of the OAM functionality for the 581 ME. A MEP may initiate an OAM packet to be transferred to its 582 corresponding MEP, or to an intermediate MIP that is part of the ME. 584 A MEP terminates all the OAM packets that it receives corresponding 585 to its ME and does not forward them further along the path. 587 All OAM packets coming to a MEP source are tunnelled via label 588 stacking and are not processed within the ME as they belong either 589 to the client network layers or to an higher TCM level. 591 A MEP in a tandem connection is not coincident with the termination 592 of the MPLS-TP transport path (LSP or PW), though it can monitor its 593 connectivity (e.g. count packets). A MEP of an MPLS-TP network 594 transport path is coincident with transport path termination and 595 monitors its connectivity (e.g. count packets). 597 MPLS-TP MEP notifies a fault indication to the MPLS-TP client layer 598 network. 600 3.44. Maintenance Intermediate Points (MIPs) 602 A Maintenance Intermediate Point (MIP) is a point between the two 603 MEPs in an ME and is capable of responding to some OAM packets and 604 forwarding all OAM packets while ensuring fate sharing with data 605 plane packets. A MIP responds only to OAM packets that are sent on 606 the ME it belongs to and that are addressed to the MIP, it does not 607 initiate OAM messages. 609 3.45. Server MEPs 611 A server MEP is a MEP of an ME that is defined in a layer network 612 below the MPLS-TP layer network being referenced. A server MEP 613 coincides with either a MIP or a MEP in the client (MPLS-TP) layer 614 network. 616 For example, a server MEP can be either: 618 . A termination point of a physical link (e.g. 802.3), an SDH VC or 619 OTH ODU for the MPLS-TP Section layer network, defined in [5] 620 section 3.1.; 622 . An MPLS-TP Section MEP for MPLS-TP LSPs, defined in [5] section 623 3.2.; 625 . An MPLS-TP LSP MEP for MPLS-TP PWs, defined in [5] section 3.4.; 627 . An MPLS-TP TCM MEP for higher-level TCMs, defined in [5] sections 628 3.3. and 3.5. 630 The server MEP can run appropriate OAM functions for fault 631 detection, and notifies a fault indication to the MPLS-TP layer 632 network. 634 [editor: 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 641 3.2 adapted information 643 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 688 3.30 unidirectional trail 690 3.31 Z layer 692 Transport MPLS (T-MPLS) 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 (T-MPLS) 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 (T-MPLS) 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 734 Transport MPLS (T-MPLS) Recommendations uses the following terms 735 defined in [ITU-T_Y.1720]: 737 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) 780 3.89 sink of the protection domain 782 3.90 source of the protection domain 784 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 (T-MPLS) 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 T-MPLS 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] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM in 850 MPLS Transport Networks", draft-ietf-mpls-tp-oam-requirements- 851 03, august 2009 853 [2] Bocci, M., Bryant, S., Levrau, L., "A Framework for MPLS in 854 Transport Networks'', draft-ietf-mpls-tp-framework-06, october 855 2009 857 [3] Gray, E., Mansfield, S., et al., ''MPLS TP Network Management 858 Requirements'', draft-ietf-mpls-tp-nm-req-06, october 2009 860 [4] Busi, I., Niven-Jenkins, B., et al., ''MPLS-TP OAM Framework 861 and Overview'', draft-ietf-mpls-tp-oam-framework-01, july 2009 863 [RFC5654] B. Niven-Jenkins, et al., ''Requirements of an MPLS 864 Transport Profile'', September 2009 866 [RFC3031] E. Rosen, etal., ''Requirements of an MPLS Transport 867 Profile'', january 2001 869 [RFC4397] I. Bryskin, A. Farrel, ''A Lexicography for the 870 Interpretation of Generalized Multiprotocol Label 871 Switching (GMPLS) Terminology within the Context of the 872 ITU-T's Automatically Switched Optical Network (ASON) 873 Architecture'', february 2006 875 9.2. Informative References 877 For information on the availability of the following documents, 878 please see http://www.itu.int 880 [ITU-T_G.8101] ITU-T Recommendation G.8101/Y.1355 (12/2006), Terms 881 and definitions for transport MPLS. 883 [ITU-T_G.805] ITU-T Recommendation G.805 (03/2000), Generic 884 functional architecture of transport networks. 886 [ITU-T_G.806] ITU-T Recommendation G.806 (03/2006), Characteristics 887 of transport equipment - Description methodology and 888 generic functionality. 890 [ITU-T_Y.1711] ITU-T Recommendation Y.1711 (10/2005) Operation & 891 Maintenance mechanism for MPLS networks. 893 [ITU-T_Y.1720] ITU-T Recommendation Y.1720 (02/2008), Protection 894 switching for MPLS networks. 896 [ITU-T_Y.1731] ITU-T Recommendation Y.1731 (02/2008), OAM functions 897 and mechanisms for Ethernet based networks. 899 [ITU-T_G.872] ITU-T Recommendation G.872 (11/2001), Architecture of 900 optical transport networks. 902 [ITU-T G.7710] ITU-T Recommendation G.7710 (07/2007), Common 903 equipment management function requirements 905 [ITU-T Y.2611] ITU-T Recommendation Y.2611 (12/2006), High-level 906 architecture of future packet-based networks 908 Authors' Addresses 910 Huub van_Helvoort (Editor) 911 Huawei Technologies Co., Ltd. 912 Email: hhelvoort@huawei.com 913 Loa Andersson (Editor) 914 Redback 915 Email: loa@pi.nu 917 Nurit Sprecher (Editor) 918 Nokia Siemens Networks 919 Email: nurit.sprecher@nsn.com 921 Contributing Authors' Addresses