idnits 2.17.1 draft-ietf-ccamp-gmpls-ason-lexicography-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 822. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 692. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 699. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 705. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 2006) is 6677 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Duplicate reference: RFC3471, mentioned in 'RFC3473', was also mentioned in 'RFC3471'. -- Obsolete informational reference (is this intentional?): RFC 4205 (Obsoleted by RFC 5307) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Igor Bryskin 2 Category: Informational Independent Consultant 3 Expires: July 2006 Adrian Farrel 4 Old Dog Consulting 6 January 2006 8 A Lexicography for the Interpretation of Generalized Multiprotocol 9 Label Switching (GMPLS) Terminology within The Context of the 10 ITU-T's Automatically Switched Optical Network (ASON) Architecture 12 draft-ietf-ccamp-gmpls-ason-lexicography-06.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be 34 accessed at http://www.ietf.org/shadow.html. 36 Abstract 38 Generalized Multiprotocol Label Switching (GMPLS) has been developed 39 by the IETF to facilitate the establishment of Label Switched Paths 40 (LSPs) in a variety of data plane technologies and across several 41 architectural models. The ITU-T has specified an architecture for 42 the control of Automatically Switched Optical Networks (ASON). 44 This document provides a lexicography for the interpretation of GMPLS 45 terminology within the context of the ASON architecture. 47 It is important to note that GMPLS is applicable in a wider set of 48 contexts than just ASON. The definitions presented in this document 49 do not provide exclusive or complete interpretations of GMPLS 50 concepts. This document simply allows the GMPLS terms to be applied 51 within the ASON context. 53 Contents 55 1. Introduction ................................................ 3 56 2. Terminology ................................................. 3 57 2.1. GMPLS Terminology Sources ................................... 3 58 2.2. ASON Terminology Sources .................................... 4 59 2.3. Common Terminology Sources .................................. 4 60 3. Lexicography................................................. 4 61 3.1. Network Presences ........................................... 4 62 3.2. Resources ................................................... 5 63 3.3. Layers ...................................................... 6 64 3.4. Labels ...................................................... 6 65 3.5. Data Links .................................................. 7 66 3.6. Link interfaces ............................................. 7 67 3.7. Connections ................................................. 8 68 3.8. Switching, Termination and Adaptation Capabilities .......... 9 69 3.9. TE Links and FAs ........................................... 10 70 3.10. TE Domains ................................................ 12 71 3.11. Component Links and Bundles ............................... 13 72 3.12. Regions ................................................... 13 73 4. Guidance on the Application of this Lexicography ............. 14 74 5. IANA Considerations .......................................... 14 75 6. Management Considerations .................................... 14 76 7. Security Considerations ...................................... 14 77 8. Acknowledgements ............................................. 14 78 9. Intellectual Property Consideration .......................... 15 79 10. Normative References ........................................ 15 80 11. Informational References .................................... 16 81 12. Authors' Addresses .......................................... 17 82 13. Disclaimer of Validity ...................................... 17 83 14. Full Copyright Statement .................................... 18 85 1. Introduction 87 Generalized Multiprotocol Label Switching (GMPLS) has been developed 88 by the IETF to facilitate the establishment of Label Switched Paths 90 (LSPs) in a variety of data plane technologies such as Packet 91 Switching Capable (PSC), Layer Two Switching Capable (L2SC), Time 92 Division Multiplexing (TDM), Lambda Switching Capable (LSC), and 93 Fiber Switching Capable (FSC). 95 The ITU-T has specified an architecture for the control of 96 Automatically Switched Optical Networks (ASON). This architecture 97 forms the basis of many Recommendations within the ITU-T. 99 Because the GMPLS and ASON architectures were developed by different 101 people in different standards bodies, and because the architectures 102 have very different historic backgrounds (the Internet, and transport 103 networks respectively), the terminology used is different. 105 This document provides a lexicography for the interpretation of GMPLS 106 terminology within the context of the ASON architecture. This 107 allows GMPLS documents to be generally understood by those familiar 108 with ASON Recommendations. The definitions presented in this document 109 do not provide exclusive or complete interpretations of the GMPLS 110 concepts. 112 2. Terminology 114 Throughout this document, angle brackets ("<" and ">") are used to 115 indicate the context in which a term applies. For example, "" as part of a description of a term means that the term 117 applies within the data plane. 119 2.1. GMPLS Terminology Sources 121 GMPLS Terminology is principally defined in [RFC3945]. Other 122 documents provide further key definitions including [RFC4201], 123 [RFC4202], [RFC4204], and [RFC4206]. 125 The reader is recommended to become familiar with these other 126 documents before attempting to use this document to provide a more 127 general mapping between GMPLS and ASON. 129 For details of GMPLS signaling please refer to [RFC3471] and 130 [RFC3473]. For details of GMPLS routing, please refer to [RFC4203] 131 and [RFC4205]. 133 2.2. ASON Terminology Sources 135 The ASON architecture is specified in ITU-T Recommendation G.8080 136 [G-8080]. This is developed from generic functional architectures and 137 requirements specified in [G-805], [G-807], and [G-872]. The ASON 138 terminology is defined in several Recommendations in the ASON family 139 such as [G-8080], [G-8081], [G-7713], [G-7714], and [G-7715]. The 140 reader must be familiar with these documents before attempting to 141 apply the lexicography set out in this document. 143 2.3. Common Terminology Sources 145 The work in this document builds on the shared view of ASON 146 requirements and requirements expressed in [RFC4139], [RFC4258] and 147 [TRANSPORT-LMP]. 149 3. Lexicography 151 3.1. Network Presences 153 3.1.1. GMPLS Terms 155 Transport node is a logical network device that is 156 capable of originating and/or terminating of a data flow and/or 157 switching it on the route to its destination. 159 Controller is a logical entity that models all 160 control plane intelligence (routing, TE and signaling protocols, 161 path computation, etc). A single controller can manage one or 162 more transport nodes. Separate functions (such as routing and 163 signaling) may be hosted at distinct sites and hence could be 164 considered as separate logical entities referred to, for example, 165 as the routing controller, the signaling controller, etc. 167 Label Switching Router (LSR) is a logical 168 combination of a transport node and the controller that manages the 169 transport node. Many implementations of LSRs collocate all control 170 plane and data plane functions associated with a transport node 171 within a single physical presence making the term LSR concrete 172 rather than logical. 174 In some instances the term LSR may be applied more loosely to 175 indicate just the transport node or just the controller function 176 dependent on the context. 178 Node is synonym for an LSR. 180 Control plane network is an IP network used for 181 delivery of control plane (protocol) messages exchanged by 182 controllers. 184 3.1.2. ASON Terms 186 A GMPLS transport node is an ASON network element. 188 A GMPLS controller is the set of ASON functional components 189 controlling a given ASON network element (or partition of a network 190 element). In ASON this set of functional components may exist in one 191 place or multiple places. 193 A GMPLS node is the combination of an ASON network element (or 194 partition of a network element) and its associated control 195 components. 197 The GMPLS control plane network is the ASON Signaling Communication 198 Network (SCN). Note that both routing and signaling exchanges are 199 carried by the SCN. 201 3.2. Resources 203 3.2.1. GMPLS Terms 205 Non-packet based resource is a channel of certain 206 bandwidth that could be allocated in a network data plane of a 207 particular technology for the purpose of user traffic delivery. 208 Examples of non-packet based resources are timeslots, lambdas 209 channels, etc. 211 Packet based resource is an abstraction hiding the means 212 related to the delivery of traffic with particular parameters (most 213 importantly, bandwidth) with particular QoS over PSC media. 214 Examples of packet based resources are forwarding queues, 215 schedulers, etc. 217 Layer Resource (Resource) . A non-packet based data plane 218 technology may yield resources in different network layers (see 219 section 3.3). For example, some TDM devices can operate with VC-12 220 timeslots, some with VC-4 timeslots and some with VC4-4c timeslots. 221 There are also multiple layers of packet based resources (i.e. one 222 per label in the label stack). Therefore, we define layer resource 223 (or simply resource) irrespective of the underlying data plane 224 technology as a basic data plane construct. It is defined by a 225 combination of a particular data encoding type and a 226 switching/terminating bandwidth granularity. Examples of layer 227 resources are: PSC1, PSC4, ATM VP, ATM VC, Ethernet, VC-12, VC-4, 228 Lambda 10G, and Lambda 40G. 230 These three definitions give rise to the concept of Resource Type. 231 Although not a formal term, this is useful shorthand to identify how 232 and where a resource can be used dependent on the switching type, 233 data encoding type and switching/terminating bandwidth granularity 234 (see section 3.8). 236 All other descriptions provided in this memo are tightly bound to the 237 resource. 239 3.2.2. ASON Terms 241 ASON terms for resource: 243 - In the context of link discovery and resource management 244 (allocation, binding into cross-connects, etc.), a GMPLS resource 245 is one end of a link connection. 247 - In the context of routing, path computation and signaling, a GMPLS 248 resource is a link connection or trail termination. 250 Resource type is identified by a client CI (Characteristics 251 Information) that could be carried by the resource. 253 3.3. Layers 255 3.3.1. GMPLS Terms 257 Layer is a set of resources of the same type that could 258 be used for establishing a connection or used for connectionless 259 data delivery. 261 Note. In GMPLS, the existence of non-blocking switching function in a 262 transport node in a particular layer is modeled explicitly as one of 263 the functions of the link interfaces connecting the transport node to 264 its data links. 266 A GMPLS layer is not the same as a GMPLS region. See section 3.12. 268 3.3.2. ASON Terms 270 A GMPLS layer is an ASON layer network. 272 3.4. Labels 274 3.4.1. GMPLS Terms 276 Label is an abstraction that provides an identifier 277 for use in the control plane in order to identify a transport plane 278 resource. 280 3.4.2. ASON Terms 282 A GMPLS label is the portion of an ASON SNP name that follows the 283 SNPP name. 285 3.5. Data Links 287 3.5.1. GMPLS Terms 289 Unidirectional data link end is a set of resources 290 that belong to the same layer and that could be allocated for the 291 transfer of traffic in that layer from a particular transport node 292 to the same neighboring transport node in the same direction. A 293 unidirectional data link end is connected to a transport node by 294 one or more link interfaces (see section 3.6). 296 Bidirectional data link end is an association of two 297 unidirectional data link ends that exist in the same layer, and 298 that could be used for the transfer of traffic in that layer 299 between a particular transport node and the same neighbor in both 300 directions. A bidirectional data link end is connected to a 301 transport node by one or more link interfaces (see section 3.6). 303 Unidirectional data link is an association of two 304 unidirectional data link ends that exist in the same layer, that 305 are connected to two transport nodes adjacent in that layer, and 306 that could be used for the transfer of traffic between the two 307 transport nodes in one direction. 309 Bidirectional data link is an association of two 310 bidirectional data link ends that exist in the same layer, that are 311 connected to two transport nodes adjacent in that layer, and that 312 could be used for the transfer of traffic between the two transport 313 nodes in both directions. 315 3.5.2. ASON Terms 317 A GMPLS unidirectional data link end is a collection of connection 318 points from the same client layer that are supported by a single 319 trail termination (access point). 321 A GMPLS data link is an ASON link supported by a single server 322 trail. 324 3.6. Link interfaces 326 3.6.1. GMPLS Terms 328 Unidirectional link interface is an abstraction that 329 connects a transport node to a unidirectional data link end and 330 represents (hides) the data plane intelligence like switching, 331 termination and adaptation in one direction. In GMPLS, link 332 interfaces are often referred to as "GMPLS interfaces" and it 333 should be understood that these are data plane interfaces and the 334 term does not refer to the ability of a control plane interface to 335 handle GMPLS protocols. 337 A single unidirectional data link end could be connected to a 338 transport node by multiple link interfaces with one of them, for 339 example, realizing switching function, while others realize the 340 function of termination/adaptation. 342 Bidirectional link interface is an association of two or 343 more unidirectional link interfaces that connects a transport node 344 to a bi-directional data link end and represents the data plane 345 intelligence like switching, termination and adaptation in both 346 directions. 348 Link interface type is identified by the function the 349 interface provides. There are three distinct functions - switching, 350 termination and adaptation, hence, there are three types of link 351 interface. Thus when a WDM link can do switching for some lambda 352 channels, and termination and TDM OC48 adaptation for some other 353 lambda channels, we say that the link is connected to the transport 354 node by three interfaces each of a separate type: switching, 355 termination, and adaptation. 357 3.6.2. ASON Terms 359 A GMPLS interface is the set of trail termination and adaptation 360 functions between one or more server layer trails and a specific 361 client layer subnetwork (which commonly is a matrix in a network 362 element). 364 The GMPLS interface type may be identified by the ASON adapted 365 client layer, or by the terminated server layer, or a combination 366 of the two, depending on the context. In some cases, a GMPLS 367 interface comprises a set of ASON trail termination/adaptation 368 functions, for which some connection points are bound to trail 369 terminations and others to matrices. 371 3.7. Connections 373 3.7.1. GMPLS Terms 375 In GMPLS a connection is known as a Label Switched Path (LSP). 377 Unidirectional LSP (connection) is a single resource or 378 a set of cross-connected resources of a particular layer that could 379 deliver traffic in that layer between a pair of transport nodes in 380 one direction. 382 Unidirectional LSP (connection) is the signaling 383 state necessary to maintain a unidirectional data plane LSP. 385 Bidirectional LSP (connection) is an association of two 386 unidirectional LSPs (connections) that could simultaneously deliver 387 traffic in a particular layer between a pair of transport nodes in 388 opposite directions. 390 In the context of GMPLS both unidirectional constituents of a 391 bidirectional LSP (connection) take identical paths in terms of 392 data links, are provisioned concurrently, and require a single 393 (shared) control state. 395 Bidirectional LSP (connection) is the signaling state 396 necessary to maintain a bidirectional data plane LSP. 398 LSP (connection) segment is a single resource or a set 399 of cross-connected resources that constitutes a segment of an LSP 400 (connection). 402 3.7.2. ASON Terms 404 A GMPLS LSP (connection) is an ASON network connection. 406 A GMPLS LSP segment is an ASON serial compound link connection. 408 3.8. Switching, Termination and Adaptation Capabilities 410 3.8.1. GMPLS Terms 412 Switching capability is a property (and defines a type) 413 of a link interface that connects a particular data link to a 414 transport node. This property/type characterizes the interface's 415 ability to cooperate with other link interfaces connecting data 416 links within the same layer to the same transport node for the 417 purpose of binding resources into cross-connects. Switching 418 capability is advertised as an attribute of the TE link local end 419 associated with the link interface. 421 Termination capability is a property of a link interface 422 that connects a particular data link to a transport node. This 423 property characterizes the interface's ability to terminate 424 connections within the layer that the data link belongs to. 426 Adaptation capability is a property of a link interface 427 that connects a particular data link to a transport node. This 428 property characterizes the interface's ability to perform a nesting 429 function - to use a locally terminated connection that belongs to 430 one layer as a data link for some other layer. 432 The need for advertisement of adaptation and termination capabilities 433 within GMPLS has been recognized and work is in progress to determine 434 how these will be advertised. It is likely that they will be 435 advertised as a single combined attribute, or as separate attributes 436 of the TE link local end associated with the link interface. 438 3.8.2. ASON Terms 440 In ASON applications: 442 The GMPLS switching capability is a property of an ASON link end 443 representing its association with a matrix. 445 The GMPLS termination capability is a property of an ASON link end 446 representing potential binding to a termination point. 448 The GMPLS adaptation capability is a property of an ASON link end 449 representing potential adaptation to/from a client layer network. 451 3.9. TE Links and FAs 453 3.9.1. GMPLS Terms 455 TE link end is a grouping for the purpose of 456 advertising and routing of resources of a particular layer. 458 Such a grouping allows for decoupling of path selection from 459 resource assignment. Specifically, a path could be selected in a 460 centralized way in terms of TE link ends, while the resource 461 assignment (resource reservation and label allocation) could be 462 performed in a distributed way during the connection setup. A TE 463 link end may reflect zero, one or more data link ends in the data 464 plane. A TE link end is associated with exactly one layer. 466 TE link is a grouping of two TE link ends associated 467 with two neighboring transport nodes in a particular layer. 469 In contrast to a data link, which provides network flexibility in a 470 particular layer and, therefore, is a "real" topological element, a 471 TE link is a logical routing element. For example, an LSP path is 472 computed in terms of TE links (or more precisely, in terms of TE 473 link ends), while the LSP is provisioned over (that is, resources 474 are allocated from) data links. 476 Virtual TE link is a TE link associated with zero data links. 478 TE link end advertising . A controller managing a 479 particular transport node advertises local TE link ends. Any 480 controller in the TE domain makes a TE link available for its local 481 path computation if it receives consistent advertisements of both 482 TE link ends. Strictly speaking, there is no such a thing as TE 483 link advertising - only TE link end advertising. TE link end 484 advertising may contain information about multiple switching 485 capabilities. This, however, should not be interpreted as 486 advertising of a multi-layer TE link end, rather, as joint 487 advertisement of ends of multiple parallel TE links, each 488 representing resources in a separate layer. The advertisement may 489 contain attributes shared by all TE links in the group (for 490 examples, protection capabilities, SRLGs, etc.), separate 491 information related to each TE link (for examples, switching 492 capability, data encoding, unreserved bandwidth, etc.) as well as 493 information related to inter-layer relationships of the advertised 494 resources (for example, termination and adaptation capabilities) 495 should the control plane decide to use them as the termination 496 points of higher layer data links. These higher layer data links, 497 however, are not real yet - they are abstract until the underlying 498 connections are established in the lower layers. LSPs created in 499 lower layers for the purpose of providing data links (extra network 500 flexibility) in higher layers are called hierarchical connections 501 or LSPs (H-LSPs), or simply hierarchies. LSPs created for the 502 purpose of providing data links in the same layer are called 503 stitching segments. H-LSPs and stitching segments could, but do not 504 have to, be advertised as TE links. Naturally, if they are 505 advertised as TE links (LSPs advertised as TE links are often 506 referred as TE-LSPs), they are made available for path computations 507 performed on any controller within the TE domain into which they 508 are advertised. H-LSPs and stitching segments could be advertised 509 either individually or in TE bundles. An H-LSP or a stitching 510 segment could be advertised as a TE link either into the same or a 511 separate TE domain compared to the one within which it was 512 provisioned. 514 A set of H-LSPs that is created (or could be created) in a 515 particular layer to provide network flexibility (data links) in 516 other layers is called a Virtual Network Topology (VNT). A single 517 H-LSP could provide several (more than one) data links (each in a 518 different layer). 520 Forwarding Adjacency (FA) is a TE link that does not 521 require a direct routing adjacency (peering) between the 522 controllers managing its ends in order to guarantee control plane 523 connectivity (a control channel) between the controllers. An 524 example of an FA is an H-LSP or stitching segment advertised as a 525 TE link into the same TE domain within which it was dynamically 526 provisioned. In such cases, the control plane connectivity between 527 the controllers at the ends of the H-LSP/stitching segment is 528 guaranteed by the concatenation of control channels interconnecting 529 the ends of each of its constituents. In contrast, an H-LSP or 530 stitching segment advertised as a TE link into a different TE 531 domain compared to one where it was provisioned, generally requires 532 a direct routing adjacency to be established within the TE domain 533 where the TE link is advertised in order to guarantee control plane 534 connectivity between the TE link ends. Therefore, is not an FA. 536 3.9.2. ASON Terms 538 The ITU term for a TE link end is SNP pool (SNPP). 540 The ITU term for a TE link is SNPP link. 542 The ITU term for an H-LSP is trail. 544 3.10. TE Domains 546 3.10.1 GMPLS Terms 548 TE link attribute is a parameter of the set of resources associated 549 with a TE link end that is significant in the context of path 550 computation. 552 Full TE visibility is a situation when a controller receives all 553 unmodified TE advertisements from every other controller in a 554 particular set of controllers. 556 Limited TE visibility is a situation when a controller receives 557 summarized TE information, or does not receive TE advertisements 558 from at least one of a particular set of controllers. 560 TE domain is a set of controllers each of which has full TE 561 visibility within the set. 563 TE database (TED) is a memory structure within a controller that 564 contains all TE advertisements generated by all controllers within 565 a particular TE domain. 567 Vertical network integration is a set of control plane mechanisms and 568 coordinated data plane mechanisms that span multiple layers. The 569 control plane mechanisms exist on one or more controllers and 570 operate either within a single control plane instance or between 571 control plane instances. The data plane mechanisms consist of 572 collaboration and adaptation between layers within a single 573 transport node. 575 Horizontal network integration is a set of control plane mechanisms 576 and coordinated data plane mechanisms that span multiple TE domains 577 within the same layer. The control plane mechanisms exist on one or 578 more controllers and operate either within a single control plane 579 instance or between control plane instances. The data plane 580 mechanisms consist of collaboration between TE domains. 582 3.11. Component Links and Bundles 584 3.11.1. GMPLS Terms 586 Component link end is a grouping of resources of a 587 particular layer that is not advertised as an individual TE link 588 end. A component link end could represent one or more data link 589 ends or any subset of resources that belong to one or more data 590 link ends. 592 Component link is a grouping of two or more component 593 link ends associated with neighboring transport nodes (that is, 594 directly interconnected by one or more data links) in a particular 595 layer. Component links are equivalent to TE links except that the 596 component link ends are not advertised separately. 598 TE bundle is an association of several parallel (that 599 is, connecting the same pair of transport nodes) component links 600 whose attributes are identical or whose differences sufficiently 601 negligible that the TE domain can view the entire association as a 602 single TE link. A TE bundle is advertised in the same way as a TE 603 link, that is, by representing the associated component link ends 604 as a single TE link end (TE bundle end) which is advertised. 606 3.12. Regions 608 3.12.1. GMPLS Terms 610 TE region is a set of one or more layers that are 611 associated with the same type of data plane technology. A TE region 612 is sometimes called an LSP region or just a region. Examples of 613 regions are: IP, ATM, TDM, photonic, fiber switching, etc. Regions 614 and region boundaries are significant for the signaling sub-system 615 of the control plane because LSPs are signaled substantially 616 differently (i.e. use different signaling object formats and 617 semantics) in different regions. Furthermore, advertising, routing 618 and path computation could be performed differently in different 619 regions. For example, computation of paths across photonic regions 620 requires a wider set of constraints (e.g. optical impairments, 621 wavelength continuity, etc) and needs to be performed in different 622 terms (e.g. in terms of individual resources - lambda channels, 623 rather than in terms of TE links) compared to path computation in 624 other regions like IP or TDM. 626 4. Guidance on the Application of this Lexicography 628 As discussed in the introduction to this document, this lexicography 629 is intended to bring the concepts and terms associated with GMPLS 630 into the context of the ITU-T's ASON architecture. Thus, it should 631 help those familiar with ASON to see how they may use the features 632 and functions of GMPLS in order to meet the requirements of an ASON. 633 For example, a service provider wishing to establish a protected 634 end-to-end service, might read [SEG-PROT] and [E2E-PROT] and wish to 635 understand how the GMPLS terms used relate to the ASON architecture 636 so that he can confirm that he will satisfy his requirements. 638 This lexicography should not be used in order to obtain or derive 639 definitive definitions of GMPLS terms. To obtain definitions of GMPLS 640 terms that are applicable across all GMPLS architectural models, the 641 reader should refer to the RFCs listed in the references sections of 642 this document. [RFC3945] provides an overview of the GMPLS 643 architecture and should be read first. 645 5. IANA Considerations 647 This informational document defines no new code points and requires 648 no action by IANA. 650 6. Management Considerations 652 Both GMPLS and ASON networks require management. Both GMPLS and ASON 653 specifications include considerable efforts to provide operator 654 control and monitoring, as well as OAM functionality. 656 These concepts are, however, out of scope of this document. 658 7. Security Considerations 660 Security is also a significant requirement of both GMPLS and ASON 661 architectures. 663 Again, however, this informational document is intended only to 664 provide a lexicography, and the security concerns are, therefore, out 665 of scope. 667 8. Acknowledgements 669 The authors would like to thank participants in the IETF's CCAMP 670 working group and the ITU-T's Study Group 15 for their help in 671 producing this document. In particular, all those who attended the 672 Study Group 15 Question 14 Interim Meeting in Holmdel, New Jersey 673 during January 2005. Further thanks to all participants of Study 674 Group 15 Questions 12 and 14 who have provided valuable discussion, 675 feedback and suggested text. 677 Many thanks to Ichiro Inoue for his useful review and input, and to 678 Scott Brim and Dimitri Papadimitriou for lengthy and constructive 679 discussions. Ben Mack-Crane and Jonathan Sadler provided very helpful 680 reviews and discussions of ASON terms. Thanks to Deborah Brungard and 681 Kohei Shiomoto for additional review comments. 683 9. Intellectual Property Consideration 685 The IETF takes no position regarding the validity or scope of any 686 Intellectual Property Rights or other rights that might be claimed to 687 pertain to the implementation or use of the technology described in 688 this document or the extent to which any license under such rights 689 might or might not be available; nor does it represent that it has 690 made any independent effort to identify any such rights. Information 691 on the procedures with respect to rights in RFC documents can be 692 found in BCP 78 and BCP 79. 694 Copies of IPR disclosures made to the IETF Secretariat and any 695 assurances of licenses to be made available, or the result of an 696 attempt made to obtain a general license or permission for the use of 697 such proprietary rights by implementers or users of this 698 specification can be obtained from the IETF on-line IPR repository at 699 http://www.ietf.org/ipr. 701 The IETF invites any interested party to bring to its attention any 702 copyrights, patents or patent applications, or other proprietary 703 rights that may cover technology that may be required to implement 704 this standard. Please address the information to the IETF at ietf- 705 ipr@ietf.org. 707 10. Normative References 709 [RFC3945] E. Mannie (Ed.). "Generalized Multi-Protocol Label 710 Switching (GMPLS) Architecture", RFC 3945, October 2004. 712 [RFC4201] Kompella, K., Rekhter, Y., and Berger, L., "Link Bundling 713 in MPLS Traffic Engineering", RFC 4201, October 2005. 715 [RFC4202] Kompella, K. and Rekhter, Y., "Routing Extensions in 716 Support of Generalized Multi-Protocol Label Switching", 717 RFC 4202, October 2005. 719 [RFC4204] J. Lang (Ed.), "Link Management Protocol (LMP)", RFC 4024, 720 October 2005. 722 [RFC4206] Kompella, K. and Rekhter, Y., "Label Switched Paths (LSP) 723 Hierarchy with Generalized Multi-Protocol Label Switching 724 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 726 11. Informational References 728 [RFC3471] L. Berger (Ed.), "Generalized Multi-Protocol Label 729 Switching (GMPLS) Signaling Functional Description", 730 RFC 3471, January 2003. 732 [RFC3473] L. Berger (Ed.), "Generalized Multi-Protocol Label 733 Switching (GMPLS) Signaling Resource ReserVation 734 Protocol-Traffic Engineering (RSVP-TE) Extensions", 735 RFC 3471, January 2003. 737 [RFC4139] Papadimitriou, D., Drake, J., Ash, J., Farrel, A., 738 and Ong, L., "Requirements for Generalized MPLS 739 (GMPLS) Signaling Usage and Extensions for 740 Automatically Switched Optical Network (ASON)", 741 RFC 4139, July 2005. 743 [RFC4203] Kompella, K., and Rekhter, Y. (Ed.), "OSPF 744 Extensions in Support of Generalized Multi-Protocol 745 label Switching (GMPLS)", RFC 4203, October 2005. 747 [RFC4205] Kompella, K., and Rekhter, Y. (Ed.), "Intermediate 748 System to Intermediate System (IS-IS) Extensions in 749 Support of Generalized Multi-Protocol Label 750 Switching (GMPLS)", RFC 4205, October 2005. 752 [RFC4258] D. Brungard (Ed.), "Requirements for Generalized 753 Multi-Protocol Label Switching (GMPLS) Routing for 754 the Automatically Switched Optical Network (ASON)", 755 RFC 4258, November 2005. 757 [E2E-PROT] Lang, J., Rekhter, Y., and Papadimitriou, D. (Eds.), 758 "RSVP-TE Extensions in support of End-to-End 759 Generalized Multi-Protocol Label Switching 760 (GMPLS)-based Recovery", 761 draft-ietf-ccamp-gmpls-recovery-e2e-signaling, 762 work in progress. 764 [SEG-PROT] Berger, L., Bryskin, I., Papadimitriou, D., and 765 Farrel, A., "GMPLS Based Segment Recovery", 766 draft-ietf-ccamp-gmpls-segment-recovery, work in 767 progress. 769 [TRANSPORT-LMP] Fedyk, D., Aboul-Magd, O., Brungard, D., Lang, J., 770 Papadimitriou, D., "A Transport Network View of LMP" 771 draft-ietf-ccamp-transport-lmp, work in progress. 773 For information on the availability of the following documents, 774 please see http://www.itu.int. 776 [G-8080] ITU-T Recommendation G.8080/Y.1304, Architecture for 777 the automatically switched optical network (ASON). 779 [G-805] ITU-T Recommendation G.805 (2000), Generic 780 functional architecture of transport networks. 782 [G-807] ITU-T Recommendation G.807/Y.1302 (2001), 783 Requirements for the automatic switched transport 784 network (ASTN). 786 [G-872] ITU-T Recommendation G.872 (2001), Architecture of 787 optical transport networks. 789 [G-8081] ITU-T Recommendation G.8081 (2004), Terms and 790 definitions for Automatically Switched Optical 791 Networks (ASON). 793 [G-7713] ITU-T Recommendation G.7713 (2001), Distributed Call 794 and Connection Management. 796 [G-7714] ITU-T Recommendation G.7714 Revision (2005), 797 Generalized automatic discovery techniques. 799 [G-7715] ITU-T Recommendation G.7715 (2002), Architecture and 800 Requirements for the Automatically Switched Optical 801 Network (ASON) 803 12. Authors' Addresses 805 Igor Bryskin 806 Independent Consultant 807 EMail: i_bryskin@yahoo.com 809 Adrian Farrel 810 Old Dog Consulting 811 Phone: +44 (0) 1978 860944 812 EMail: adrian@olddog.co.uk 814 13. Disclaimer of Validity 816 This document and the information contained herein are provided on an 817 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 818 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 819 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 820 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 821 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 822 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 824 14. Full Copyright Statement 826 Copyright (C) The Internet Society (2006). This document is subject 827 to the rights, licenses and restrictions contained in BCP 78, and 828 except as set forth therein, the authors retain all their rights.