idnits 2.17.1 draft-helvoort-mpls-tp-rosetta-stone-00.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.ii 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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 41 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 227 has weird spacing: '...example netw...' == Line 762 has weird spacing: '...only to provi...' -- The document date (March 3, 2009) is 5533 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'RFC3945' on line 746 == Unused Reference: '6' is defined on line 804, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 807, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 810, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 814, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 817, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 820, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 823, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 826, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 828, but no explicit reference was found in the text -- No information found for draft-ietf-mpls-mpls-tp-requirements - is the name correct? Summary: 2 errors (**), 0 flaws (~~), 12 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group H. van Helvoort (Ed) 3 Internet Draft Huawei Technologies 4 Intended status: Informational 5 Expires: September 2009 L. Andersson (Ed) 6 Redback 8 N. Sprecher (Ed) 9 Nokia Siemens Networks 11 March 3, 2009 13 A Thesaurus for the Terminology used in Multiprotocol Label 14 Switching Transport Profile (MPLS-TP) drafts/RFCs and ITU-T's 15 Transport Network Recommendations. 16 draft-helvoort-mpls-tp-rosetta-stone-00 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on September 1, 2009. 41 Copyright Notice 43 Copyright (c) 2009 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents in effect on the date of 48 publication of this document (http://trustee.ietf.org/license-info). 49 Please review these documents carefully, as they describe your 50 rights and restrictions with respect to this document. 52 Abstract 54 MPLS-TP is based on a profile of the MPLS and PW procedures as 55 specified in the MPLS-TE and (MS-)PW architectures developed by the 56 IETF. The ITU-T has specified a Transport Network architecture. 58 This document provides a thesaurus for the interpretation of MPLS-TP 59 terminology within the context of the ITU-T Transport Network 60 recommendations. 62 It is important to note that MPLS-TP is applicable in a wider set of 63 contexts than just Transport Networks. The definitions presented in 64 this document do not provide exclusive nor complete interpretations 65 of MPLS-TP concepts. This document simply allows the MPLS-TP terms 66 to be applied within the Transport Network context. 68 Table of Contents 70 1. Introduction 3 71 1.1. Contributing Authors 4 72 1.2. Abbreviations 4 73 2. Terminology 4 74 2.1. MPLS-TP Terminology Sources 4 75 2.2. ITU-T Transport Network Terminology Sources 4 76 2.3. Common Terminology Sources 5 77 3. Thesaurus 5 78 3.1. Associated bidirectional path: 5 79 3.2. Bidirectional path: 5 80 3.3. Concatenated Segment: 5 81 3.4. Co-routed bidirectional path: 5 82 3.5. Domain: 5 83 3.6. Layer network: 6 84 3.7. Link: 6 85 3.8. Logical Ring: 6 86 3.9. Path: 6 87 3.10. Physical Ring: 6 88 3.11. Ring Topology: 6 89 3.12. Section: 7 90 3.13. Segment: 7 91 3.14. Service layer: 7 92 3.15. Span: 7 93 3.16. Sublayer: 7 94 3.17. Tandem Connection: 7 95 3.18. Transport path: 8 96 3.19. Transport path layer: 8 97 3.20. Transport service layer: 8 98 3.21. Transmission media layer: 8 99 3.22. Unidirectional path: 8 100 3.23. Failure: 8 101 3.24. Fault: 9 102 3.25. Defect: 9 103 3.26. MPLS Transport Profile (MPLS-TP): 9 104 3.27. MPLS Section: 9 105 3.28. MPLS-TP NE: 9 106 3.29. MPLS-TP network: 9 107 3.30. Equipment Management Function (EMF): 9 108 3.31. Data Communication Network (DCN): 10 109 3.32. Communication Channel (CC): 10 110 3.33. Embedded Communication Channel (ECC): 10 111 3.34. Management Communication Channel (MCC): 10 112 3.35. Management Communication Network (MCN): 10 113 3.36. Signaling Communication Channel (SCC): 10 114 3.37. Signaling Communication Network (SCN): 10 115 3.38. Operations System (OS): 10 116 3.39. Maintenance Entity 11 117 3.40. Maintenance End Points (MEPs) 11 118 3.41. Maintenance Intermediate Points (MIPs) 12 119 3.42. Server MEPs 12 120 4. Guidance on the Application of this Thesaurus 16 121 5. Management Considerations 17 122 6. Security Considerations 17 123 7. IANA Considerations 17 124 8. Acknowledgments 17 125 9. References 17 126 9.1. Normative References 17 127 9.2. Informative References 18 128 Authors' Addresses 18 129 Contributing Authors' Addresses 19 130 Intellectual Property Statement 19 131 Disclaimer of Validity 19 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, Vincenzo Sestito, Nurit Sprecher, Huub van 159 Helvoort, Martin Vigoureux, Yaacov Weingarten 161 1.2. Abbreviations 163 ME Maintenance Entity 165 MEP Maintenance End Point 167 MIP Maintenance Intermediate Point 169 2. Terminology 171 Throughout this document, angle brackets ("<" and ">") are used to 172 indicate that the term is used by both IETF and ITU-T but has a 173 different definition. The bracketed term is the IETF term. 175 [editor: check all terms used that this applies to, TBD] 177 2.1. MPLS-TP Terminology Sources 179 MPLS-TP terminology is principally defined in [RFC....]. Other 180 documents provide further key definitions including [RFC....], and 181 [RFC....]. 183 2.2. ITU-T Transport Network Terminology Sources 185 The ITU-T Transport Network is specified in a number of 186 recommendations: generic functional architectures and requirements 187 are specified in G.805 [ITU-T_G.805], G.806 [ITU-T_G.806], and G.872 188 [ITU-T_G.872]. G.8101 [ITU-T_G.8101] contains an overview of the 189 Terms and Definitions for transport MPLS. 191 2.3. Common Terminology Sources 193 The work in this document builds on the shared view of MPLS 194 requirements. 196 3. Thesaurus 198 From: draft-ietf-mpls-tp-requirements-04 [1] 200 3.1. Associated bidirectional path: 202 A path that supports traffic flow in both directions but which is 203 constructed from a pair of unidirectional paths (one for each 204 direction) which are associated with one another at the path's 205 ingress/egress points. The forward and backward directions may or 206 may not follow the same route (links and nodes) across the network. 208 3.2. Bidirectional path: 210 A path where the forward and backward directions follow the same 211 route (links and nodes) across the network. 213 3.3. Concatenated Segment: 215 A serial-compound link connection as defined in G.805 [ITU-T_G.805]. 216 A concatenated segment is a contiguous part of an LSP or multi- 217 segment PW that comprises a set of segments and their 218 interconnecting nodes in sequence. 220 3.4. Co-routed bidirectional path: 222 A bidirectional path where the forward and backward directions 223 follow the same route (links and nodes) across its layer network. 225 3.5. Domain: 227 A domain represents a collection of entities (for example network 228 elements) that are grouped for a particular purpose, examples of 229 which are administrative and/or managerial responsibilities, trust 230 relationships, addressing schemes, infrastructure capabilities, 231 aggregation, survivability techniques, distributions of control 232 functionality, etc. Examples of such domains include IGP areas and 233 Autonomous Systems. 235 3.6. Layer network: 237 Layer network is defined in G.805 [ITU-T_G.805]. A layer network 238 provides for the transfer of client information and independent 239 operation of the client OAM. A Layer Network may be described in a 240 service context as follows: one layer network may provide a 241 (transport) service to higher client layer network and may, in turn, 242 be a client to a lower layer network. A layer network is a logical 243 construction somewhat independent of arrangement or composition of 244 physical network elements. A particular physical network element 245 may topologically belong to more than one layer network, depending 246 on the actions it takes on the encapsulation(s) associated with the 247 logical layers (e.g. the label stack), and thus could be modeled as 248 multiple logical elements. A layer network may consist of zero or 249 more sublayers. For additional explanation of how layer networks 250 relate to the OSI concept of layering see Appendix I of Y.2611 [ITU- 251 T_Y.2611]. 253 3.7. Link: 255 A physical or logical connection between a pair of LSRs that are 256 adjacent at the (sub)layer network under consideration. A link may 257 carry zero, one or more LSPs or PWs. A packet entering a link will 258 emerge with the same label stack entry values. 260 A link as defined in G.805 [ITU-T_G.805] is used to describe a fixed 261 relationship between two ports. 263 3.8. Logical Ring: 265 An MPLS-TP logical ring is constructed from a set of LSRs and 266 logical data links (such as MPLS-TP LSP tunnels or MSPL-TP 267 pseudowires) and physical data links that form a ring topology. 269 3.9. Path: 271 See Transport path. 273 3.10. Physical Ring: 275 An MPLS-TP physical ring is constructed from a set of LSRs and 276 physical data links that form a ring topology. 278 3.11. Ring Topology: 280 In an MPLS-TP ring topology each LSR is connected to exactly two 281 other LSRs, each via a single point-to-point bidirectional MPLS-TP 282 capable data link. A ring may also be constructed from only two 283 LSRs where there are also exactly two links. Rings may be connected 284 to other LSRs to form a larger network. Traffic originating or 285 terminating outside the ring may be carried over the ring. Client 286 network nodes (such as CEs) may be connected directly to an LSR in 287 the ring. 289 3.12. Section: 291 A section is a server layer (which may be MPLS-TP or a different 292 technology) which provides for encapsulation and OAM of a MPLS-TP 293 transport path client layer. A section layer may provide for 294 aggregation of multiple MPLS-TP clients. Note that G.805 [ITU- 295 T_G.805] defines the section layer as one of the two layer 296 networks in a transmission media layer network. The other layer 297 network is the physical media layer network. 299 3.13. Segment: 301 A link connection as defined in G.805 [ITU-T_G.805]. A segment is 302 the part of an LSP that traverses a single link or the part of a PW 303 that traverses a single link (i.e. that connects a pair of adjacent 304 {S|T}-PEs). 306 3.14. Service layer: 308 A layer network in which transport paths are used to carry a 309 customer's (individual or bundled) service (may be point-to-point, 310 point-to-multipoint or multipoint-to-multipoint services). 312 3.15. Span: 314 A span is synonymous with a link. 316 3.16. Sublayer: 318 Sublayer is defined in G.805 [ITU-T_G.805]. The distinction between 319 a layer network and a sublayer is that a sublayer is not directly 320 accessible to clients outside of its encapsulating layer network and 321 offers no direct transport service for a higher layer (client) 322 network. 324 3.17. Tandem Connection: 326 A tandem connection is an arbitrary part of a transport path that 327 can be monitored (via OAM) independently from the end-to-end 328 monitoring (OAM). It may be a monitored segment, a monitored 329 concatenated segment or any other monitored ordered sequence of 330 contiguous hops and/or segments (and their interconnecting nodes) of 331 a transport path. 333 3.18. Transport path: 335 A network connection as defined in G.805 [ITU-T_G.805]. In an MPLS- 336 TP environment a transport path corresponds to an LSP or a PW. 338 3.19. Transport path layer: 340 A layer network which provides point-to-point or point-to-multipoint 341 transport paths which are used to carry a higher (client) layer 342 network or aggregates of higher (client) layer networks, for example 343 the transport service layer. It provides for independent OAM (of 344 the client OAM) in the transport of the clients. 346 3.20. Transport service layer: 348 A layer network in which transport paths are used to carry a 349 customer's (individual or bundled) service (may be point-to-point, 350 point-to-multipoint or multipoint-to-multipoint services). 352 3.21. Transmission media layer: 354 A layer network which provides sections (two-port point-to-point 355 connections) to carry the aggregate of network transport path or 356 network service layers on various physical media. 358 3.22. Unidirectional path: 360 A path that supports traffic flow in only one direction. 362 === 364 from: draft-ietf-mpls-tp-oam-requirements-00 [2] 366 3.23. Failure: 368 [editor: this is not in [2] BUT added fro completeness] 370 The fault cause persisted long enough to consider the ability of an 371 item to perform a required function to be terminated. The item may 372 be considered as failed; a fault has now been detected. See also 373 G.806 [ITU-T_.G.806]. 375 3.24. Fault: 377 The inability of a function to perform a required action. This does 378 not include an inability due to preventive maintenance, lack of 379 external resources, or planned actions. See also G.806 [ITU- 380 T_G.806]. 382 3.25. Defect: 384 The situation for which density of anomalies has reached a level 385 where the ability to perform a required function has been 386 interrupted. Defects are used as input for PM, the control of 387 consequent actions, and the determination of fault cause. See also 388 G.806 [ITU-T_G.806]. 390 3.26. MPLS Transport Profile (MPLS-TP): 392 The set of MPLS functions used to support packet transport services 393 and network operations. 395 3.27. MPLS Section: 397 A network segment between two LSRs that are immediately adjacent at 398 the MPLS layer. 400 == 402 From: draft-ietf-mpls-tp-framework-00 [3] 404 == 406 From: draft-gray-mpls-tp-nm-req-03 [4] 408 3.28. MPLS-TP NE: 410 A network element (NE) that supports MPLS-TP functions. 412 3.29. MPLS-TP network: 414 A network in which MPLS-TP NEs are deployed 416 3.30. Equipment Management Function (EMF): 418 The management functions within an NE. See G.7710 [ITU-T_G.7710]. 420 3.31. Data Communication Network (DCN): 422 A network that supports Layer 1 (physical layer), Layer 2 (data-link 423 layer), and Layer 3 (network layer) functionality for distributed 424 management communications related to the management plane, for 425 distributed signaling communications related to the control plane, 426 and other operations communications (e.g., order-wire/voice 427 communications, software downloads, etc.). 429 3.32. Communication Channel (CC): 431 A logical channel between network elements (NEs) that can be used - 432 e.g. - for management plane application or control plane 433 applications. The physical channel supporting the CC is technology 434 specific. See [4] APPENDIX A 436 3.33. Embedded Communication Channel (ECC): 438 A logical operations channel between network elements (NEs) that can 439 be utilized by multiple applications (e.g., management plane 440 applications, control plane applications, etc.). The physical 441 channel supporting the ECC is technology specific. An example of 442 physical channels supporting the ECC is a DCC channel within SDH. 444 3.34. Management Communication Channel (MCC): 446 A CC dedicated for management plane communications. 448 3.35. Management Communication Network (MCN): 450 A DCN supporting management plane communication is referred to as a 451 Management Communication Network (MCN). 453 3.36. Signaling Communication Channel (SCC): 455 A CC dedicated for control plane communications. The SCC may be used 456 for GMPLS/ASON signaling and/or other control plane messages (e.g., 457 routing messages). 459 3.37. Signaling Communication Network (SCN): 461 A DCN supporting control plane communication is referred to as a 462 Signaling Communication Network (SCN). 464 3.38. Operations System (OS): 466 A system that performs the functions that support processing of 467 information related to operations, administration, maintenance, and 468 provisioning (OAM&P) for the networks, including surveillance and 469 testing functions to support customer access maintenance. 471 == 473 From: draft-busi-mpls-tp-oam-framework-00 [5] 475 MPLS Section: [editor: see 3.27] 477 OAM flow: to be added in a future revision of this document. 479 Tandem Connection: [editor: see 3.17] 481 3.39. Maintenance Entity 483 A Maintenance Entity can be viewed as the association of two (or 484 more) Maintenance End Points (MEPs), that should be configured and 485 managed in order to bound the OAM responsibilities of an OAM flow 486 [editor: definition?] across a network or sub-network, i.e. a 487 transport path or segment, in the specific layer network that is 488 being monitored and managed. 490 A Maintenance Entity may be defined to monitor and manage bi- 491 directional or unidirectional point-to-point connectivity or point- 492 to-multipoint connectivity in an MPLS-TP layer network. 494 [editor: should the following be included?] 496 Therefore, in the context of MPLS-TP LSP or PW Maintenance Entity 497 (defined below) LERs and T-PEs can be MEPs while LSRs and S-PEs can 498 be MIPs. In the case of Tandem Connection Maintenance Entity 499 (defined below), LSRs and S-PEs can be either MEPs or MIPs. 501 The following properties apply to all MPLS-TP MEs: 503 o OAM entities can be nested but not overlapped. 505 o Each OAM flow is associated to a unique Maintenance Entity. 507 o OAM packets are subject to the same forwarding treatment as the 508 data traffic, but they are distinct from the data traffic. 510 3.40. Maintenance End Points (MEPs) 512 Maintenance End Points (MEPs) are the end points of a pre-configured 513 (through the management or control planes) ME. MEPs are responsible 514 for activating and controlling all of the OAM functionality for the 515 ME. A MEP may initiate an OAM packet to be transferred to its 516 corresponding MEP, or to an intermediate MIP that is part of the ME. 518 A MEP terminates all the OAM packets that it receives corresponding 519 to its ME and does not forward them further along the path. 521 All OAM packets coming to a MEP source are tunnelled via label 522 stacking and are not processed within the ME as they belong either 523 to the client network layers or to an higher TCM level. 525 A MEP in a tandem connection is not coincident with the termination 526 of the MPLS-TP transport path (LSP or PW), though it can monitor its 527 connectivity (e.g. count packets). A MEP of an MPLS-TP network 528 transport path is coincident with transport path termination and 529 monitors its connectivity (e.g. count packets). 531 MPLS-TP MEP notifies a fault indication to the MPLS-TP client layer 532 network. 534 3.41. Maintenance Intermediate Points (MIPs) 536 A Maintenance Intermediate Point (MIP) is a point between the two 537 MEPs in an ME and is capable of responding to some OAM packets and 538 forwarding all OAM packets while ensuring fate sharing with data 539 plane packets. A MIP responds only to OAM packets that are sent on 540 the ME it belongs to and that are addressed to the MIP, it does not 541 initiate OAM messages. 543 3.42. Server MEPs 545 A server MEP is a MEP of an ME that is defined in a layer network 546 below the MPLS-TP layer network being referenced. A server MEP 547 coincides with either a MIP or a MEP in the client (MPLS-TP) layer 548 network. 550 For example, a server MEP can be either: 552 . A termination point of a physical link (e.g. 802.3), an SDH VC or 553 OTH ODU for the MPLS-TP Section layer network, defined in [5] 554 section 3.1.; 556 . An MPLS-TP Section MEP for MPLS-TP LSPs, defined in [5] section 557 3.2.; 559 . An MPLS-TP LSP MEP for MPLS-TP PWs, defined in [5] section 3.4.; 561 . An MPLS-TP TCM MEP for higher-level TCMs, defined in [5] sections 562 3.3. and 3.5. 564 The server MEP can run appropriate OAM functions for fault 565 detection, and notifies a fault indication to the MPLS-TP layer 566 network. 568 [editor: the following are definitions from G.8101 which should be 569 defined only if they will cause misunderstanding. It is not usefull 570 to define them if the definition is the same in IETF and ITU-T, TBD] 572 ===== ITU-T Rec. G.8101/Y.1355 (12/2006) ===== 574 3.1 access point 576 3.2 adapted information 578 3.3 characteristic information 580 3.4 client/server relationship 582 3.5 connection 584 3.6 connection point 586 3.9 forward direction 588 3.12 link connection 590 3.13 matrix 592 3.14 network 594 3.15 network connection 596 3.16 network operator 598 3.17 port 599 3.18 reference point 601 3.19 service provider 603 3.20 subnetwork 605 3.21 subnetwork connection 607 3.22 termination connection point 609 3.23 trail 611 3.24 trail termination 613 3.25 trail termination point 615 3.26 transport 617 3.27 transport entity 619 3.28 transport processing function 621 3.29 unidirectional connection 623 3.30 unidirectional trail 625 3.31 Z layer 627 Transport MPLS (T-MPLS) Recommendations uses the following terms 628 defined in ITU-T Rec. G.809: 630 3.33 access point 632 3.34 adaptation 634 3.35 adapted information 636 3.36 characteristic information 638 3.37 client/server relationship 640 3.50 network 642 3.52 port 644 3.53 reference point 645 3.56 traffic unit 647 3.57 transport 649 3.58 transport entity 651 Transport MPLS (T-MPLS) Recommendations uses the following term 652 defined in ITU-T Rec. G.8010/Y.1306: 654 3.59 point-to-point Ethernet connection 656 Transport MPLS (T-MPLS) Recommendations uses the following terms 657 defined in ITU-T Rec. Y.1711: 659 3.60 backward direction 661 3.62 client/server (relationship between layer networks) 663 3.63 failure 665 3.64 forward direction 667 3.65 user-plane 669 Transport MPLS (T-MPLS) Recommendations uses the following terms 670 defined in ITU-T Rec. Y.1720: 672 3.66 1+1 protection 674 3.67 1:1 protection 676 3.68 bidirectional protection switching 678 3.69 bridge 680 3.71 extra traffic 682 3.72 failure 684 3.73 forced switch for working LSP 686 3.74 hold-off time 688 3.75 manual switch 690 3.76 MPLS protection domain 691 3.77 non-revertive protection switching 693 3.78 no request 695 3.79 packet 1+1 protection 697 3.80 path switch LSR 699 3.81 path merge LSR 701 3.82 protection LSP 703 3.83 protection switching 705 3.84 rerouting 707 3.85 revertive protection switching 709 3.86 selector 711 3.87 shared mesh protection 713 3.88 Shared Risk Group (SRG) 715 3.89 sink of the protection domain 717 3.90 source of the protection domain 719 3.91 unidirectional protection switching 721 3.92 wait to restore 723 3.93 wait to restore timer 725 3.94 working LSP 727 Transport MPLS (T-MPLS) Recommendations uses the following terms 728 defined in ITU-T Rec. Y.1731: 730 3.95 in-service OAM 732 ===== end of ITU-T Rec. G.8101/Y.1355 (12/2006) ===== 733 4. Guidance on the Application of this Thesaurus 735 As discussed in the introduction to this document, this thesaurus is 736 intended to bring the concepts and terms associated with MPLS-TP 737 into the context of the ITU-T's Transport Network architecture. 738 Thus, it should help those familiar with MPLS to see how they may 739 use the features and functions of the Transport Network in order to 740 meet the requirements of MPLS-TP. 742 This lexicography should not be used in order to obtain or derive 743 definitive definitions of GMPLS terms. To obtain definitions of 744 GMPLS terms that are applicable across all GMPLS architectural 745 models, the reader should refer to the RFCs listed in the references 746 sections of this document. [RFC3945] provides an overview of the 747 GMPLS architecture and should be read first. 749 5. Management Considerations 751 The MPLS-TP based network requires management. The MPLS-TP 752 specifications include considerable efforts to provide operator 753 control and monitoring, as well as Operations and Management 754 (OAM)functionality. 756 These concepts are, however, out of scope of this document. 758 6. Security Considerations 760 Security is also a significant requirement of MPLS-TP. 762 However, this informational document is intended only to provide a 763 lexicography, and the security concerns are, therefore, out of 764 scope. 766 7. IANA Considerations 768 To be incorporated in a future revision of this document 770 <> 772 8. Acknowledgments 774 The authors would like to thank all members of the teams (the Joint 775 Working Team, the MPLS Interoperability Design Team in IETF and the 776 T-MPLS Ad Hoc Group in ITU-T) involved in the definition and 777 specification of MPLS Transport Profile. 779 9. References 781 9.1. Normative References 783 [1] B. Niven-Jenkins, et al., ''MPLS-TP Requirements'', draft-ietf- 784 mpls-mpls-tp-requirements, november 2008 786 [2] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM in 787 MPLS Transport Networks", draft-vigoureux-mpls-tp-oam- 788 requirements, november 2008 790 [3] Bocci, M., Bryant, S., "A Framework for MPLS in Transport 791 Networks'', draft-ietf-mpls-tp-framework, november 2008 793 [4] Gray, E., Mansfield, S., et al., ''MPLS TP Network Management 794 Requirements'', draft-gray-mpls-tp-nm-req, november 2008 796 [5] Busi, I., Niven-Jenkins, B., et al., ''MPLS-TP OAM Framework 797 and Overview'', draft-busi-mpls-tp-oam-framework, november 2008 799 9.2. Informative References 801 For information on the availability of the following documents, 802 please see http://www.itu.int 804 [6] [ITU-T_G.8101] ITU-T Recommendation G.8101/Y.1355 (12/2006), 805 Terms and definitions for transport MPLS. 807 [7] [ITU-T_G.805] ITU-T Recommendation G.805 (2000), Generic 808 functional architecture of transport networks. 810 [8] [ITU-T_G.806] ITU-T Recommendation G.806 (03/2006), 811 Characteristics of transport equipment - - Description 812 methodology and generic functionality. 814 [9] [ITU-T_Y.1711] ITU-T Recommendation Y.1711 (10/2005) Operation 815 & Maintenance mechanism for MPLS networks. 817 [10] [ITU-T_Y.1720] ITU-T Recommendation Y.1720 (02/2008), 818 Protection switching for MPLS networks. 820 [11] [ITU-T_Y.1731] ITU-T Recommendation Y.1731 (02/2008), OAM 821 functions and mechanisms for Ethernet based networks. 823 [12] [ITU-T_G.872] ITU-T Recommendation G.872 (2001), Architecture 824 of optical transport networks. 826 [13] [ITU-T_G.7710] ITU-T Recommendation G.7710 (), 828 [14] [ITU_Y.2611] ITU-T Recommendation Y.2611 (), 830 Authors' Addresses 832 Huub van Helvoort (editor) 833 Huawei Technologies 834 Email: hhelvoort@huawei.com 836 Loa Andersson (editor) 837 Redback 838 Email: loa@pi.nu 840 Nurit Sprecher (editor) 841 Nokia Siemens Networks 842 Email: nurit.sprecher@nsn.com 844 Contributing Authors' Addresses