idnits 2.17.1 draft-ietf-ccamp-transport-lmp-02.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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 800. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 659. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 666. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 672. ** 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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 17 longer pages, the longest (page 2) being 60 lines 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 (May 2005) is 6893 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TAP' is mentioned on line 315, but not defined == Missing Reference: 'GMPLS-ARCH' is mentioned on line 408, but not defined == Missing Reference: 'RFC 3471' is mentioned on line 506, but not defined == Unused Reference: 'BCP 78' is defined on line 679, but no explicit reference was found in the text == Unused Reference: 'BCP 79' is defined on line 682, but no explicit reference was found in the text == Unused Reference: 'RFC3471' is defined on line 698, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3667 (ref. 'BCP 78') (Obsoleted by RFC 3978) ** Obsolete normative reference: RFC 3668 (ref. 'BCP 79') (Obsoleted by RFC 3979) -- No information found for draft-ietf-draft-ietf-ccamp-lmp-test-sonet-sdh - is the name correct? -- Unexpected draft version: The latest known version of draft-bryskin-ccamp-gmpls-ason-lexicography is -01, but you're referring to -02. (However, the state information for draft-ietf-draft-ietf-ccamp-lmp-test-sonet-sdh is not up-to-date. The last update was unsuccessful) Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Don Fedyk (Nortel Networks) 2 Internet Draft Osama Aboul-Magd (Nortel Networks) 3 Category: Informational Deborah Brungard (AT&T) 4 Expires October 2005 Jonathan Lang (Sonos, Inc.) 5 Dimitri Papadimitriou (Alcatel) 7 May 2005 9 A Transport Network View of the Link Management Protocol 10 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other documents 26 at any time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 The Link Management Protocol (LMP) has been developed as part of the 37 Generalized MPLS (GMPLS) protocol suite to manage Traffic 38 Engineering (TE) resources and links. The GMPLS control plane 39 (routing and signaling) uses TE links for establishing Label 40 Switched Paths (LSPs). This memo describes the relationship of the 41 LMP procedures to 'discovery' as defined in the International 42 Telecommunication Union (ITU-T), and on-going ITU-T work. This 43 document provides an overview of LMP in the context of the ITU-T 44 Automatically Switched Optical Networks (ASON) and transport network 45 terminology and relates it to the ITU-T discovery work to promote a 46 common understanding for progressing the work of IETF and ITU-T. 48 D. Fedyk, Editor Informational 1 49 Table of Contents 51 1. ASON Terminology and Abbreviations related to Discovery.........2 52 1.1 Terminology....................................................2 53 1.2 Abbreviations.................................................3 54 2. Introduction....................................................3 55 3. Transport Network Architecture..................................4 56 3.1 G.8080 Discovery Framework.....................................6 57 4. Discovery Technologies..........................................8 58 4.1 Generalized automatic discovery techniques G.7714..............8 59 4.2 LMP and G.8080 Terminology Mapping.............................9 60 4.2.1 TE Link Definition and Scope................................10 61 4.3 LMP and G.8080 Discovery Relationship.........................12 62 4.4 Comparing LMP and G.8080......................................13 63 5. Security Considerations........................................13 64 6. IANA Considerations............................................14 65 7. Intellectual Property Considerations...........................14 66 8. References.....................................................15 67 8.1 Normative References..........................................15 68 8.2 Informational References......................................15 69 9. Acknowledgements...............................................16 70 10. Author's Addresses............................................16 71 11. Disclaimer of Validity........................................17 72 12. Full Copyright Statement......................................17 74 1. ASON Terminology and Abbreviations related to Discovery 76 1.1 Terminology 78 The reader is assumed to be familiar with the terminology in [LMP] 79 and [LMP-TEST]. The following ITU-T terminology/abbreviations are 80 used in this document: 82 Connection Point (CP): A "reference point" that consists of a pair 83 of co-located "unidirectional connection points" and therefore 84 represents the binding of two paired bidirectional "connections". 86 Connection Termination Point (CTP): A Connection Termination Point 87 (CTP) represents the state of a CP [M.3100]. 89 Characteristic Information: Signal with a specific format, which is 90 transferred on "network connections". The specific formats will be 91 defined in the technology specific Recommendations. For trails the 92 Characteristic Information is the payload plus the overhead. The 93 information transferred is characteristic of the layer network. 95 Link: a subset of ports at the edge of a subnetwork or access group 96 which are associated with a corresponding subset of ports at the 97 edge of another subnetwork or access group. 99 Link Connection (LC): a transport entity that transfers information 100 between ports across a link. 102 D. Fedyk, Editor Informational 2 103 Network Connection (NC): A concatenation of link and subnetwork 104 connections. 106 Subnetwork: a set of ports which are available for the purpose of 107 routing 'characteristic information'. 109 Subnetwork Connection (SNC): a flexible connection that is setup and 110 released using management or control plane procedures. 112 Subnetwork Point (SNP): SNP is an abstraction that represents an 113 actual or potential underlying connection point (CP) or termination 114 connection point (TCP) for the purpose of control plane 115 representation. 117 Subnetwork Point Pool (SNPP): A set of SNP that are grouped together 118 for the purpose of routing. 120 Termination Connection Point (TCP): A reference point that 121 represents the output of a Trail Termination source function or the 122 input to a Trail Termination sink function. A network connection 123 represents a transport entity between TCPs. 125 Trail Termination source/sink function: A "transport processing 126 function" which accepts the characteristic information of the layer 127 network at its input, removes the information related to "trail" 128 monitoring and presents the remaining information at its output. 129 Unidirectional Connection: A "transport entity" which transfers 130 information transparently from input to output. 132 Unidirectional Connection Point: A "reference point" that represents 133 the binding of the output of a "unidirectional connection" to the 134 input of another "unidirectional connection". 136 1.2 Abbreviations 138 LMP: Link Management Protocol 140 OTN: Optical transport network 142 PDH: Plesiosynchronous digital hierarchy 144 SDH: Synchronous digital hierarchy. 145 2. Introduction 147 The GMPLS control plane consists of several building blocks as 148 described in [RFC3945]. The building blocks include signaling, 149 routing, and link management for establishing LSPs. For scalability 150 purposes, multiple physical resources can be combined to form a 151 single traffic engineering (TE) link for the purposes of path 152 computation and GMPLS control plane signaling. 154 D. Fedyk, Editor Informational 3 155 As manual provisioning and management of these links is impractical 156 in large networks, LMP was specified to manage TE links. Two 157 mandatory management capabilities of LMP are control channel 158 management and TE link property correlation. Additional optional 159 capabilities include verifying physical connectivity and fault 160 management. [LMP] defines the messages and procedures for GMPLS TE 161 link management. [LMP-TEST] defines SONET/SDH specific messages and 162 procedures for link verification. 164 ITU-T Recommendation G.8080 Amendment 1 [G.8080] defines control 165 plane discovery as two separate processes, one process occurs within 166 the transport plane space and the other process occurs within the 167 control plane space. 169 The ITU-T has developed Recommendation G.7714 'Generalized automatic 170 discovery techniques' [G.7714] defining the functional processes and 171 information exchange related to transport plane discovery aspects: 172 i.e., layer adjacency discovery and physical media adjacency 173 discovery. Specific methods and protocols are not defined in 174 Recommendation G.7714. ITU-T Recommendation G.7714.1 'Protocol for 175 automatic discovery in SDH and OTN networks' [G.7714.1] defines a 176 protocol and procedure for transport plane layer adjacency discovery 177 (e.g. discovering the transport plane layer end point relationships 178 and verifying their connectivity). The ITU-T is currently working to 179 extend discovery to control plane aspects providing detail on a 180 Discovery framework architecture in G.8080 and a new Recommendation 181 on 'Control plane initial establishment, reconfiguration'. 183 3. Transport Network Architecture 185 A generic functional architecture for transport networks is defined 186 in the International Telecommunications Union (ITU-T) recommendation 187 [G.805]. This recommendation describes the functional architecture 188 of transport networks in a technology independent way. This 189 architecture forms the basis for a set of technology specific 190 architectural recommendations for transport networks (e.g., SDH, 191 PDH, OTN, etc.) 193 The architecture defined in G.805 is designed using a layered model 194 with a client-server relationship between layers. The architecture 195 is recursive in nature; a network layer is both a server to the 196 client layer above it and a client to the server layer below it. 197 There are two basic building blocks defined in G.805: "subnetworks" 198 and "links". A subnetwork is defined as a set of ports which are 199 available for the purpose of routing "characteristic information". A 200 link consists of a subset of ports at the edge of one subnetwork (or 201 "access group") and is associated with a corresponding subset of 202 ports at the edge of another subnetwork or access group. 204 Two types of connections are defined in G.805: "link connection" 205 (LC) and "subnetwork connection" (SNC). A link connection is a fixed 207 D. Fedyk, Editor Informational 4 208 and inflexible connection, while a subnetwork connection is flexible 209 and is setup and released using management or control plane 210 procedures. A network connection is defined as a concatenation of 211 subnetwork and link connections. Figure 1 illustrates link and 212 subnetwork connections. 214 (++++++++) (++++++++) 215 ( SNC ) LC ( SNC ) 216 (o)--------(o)----------(o)--------(o) 217 ( ) CP CP ( ) 218 (++++++++) (++++++++) 220 subnetwork subnetwork 222 Figure 1: Subnetwork and Link Connections 224 G.805 defines a set of reference points for the purpose of 225 identification in both the management and the control plane. These 226 identifiers are NOT required to be the same. A link connection or a 227 subnetwork connection is delimited by connection points (CP). A 228 network connection is delimited by a termination connection point 229 (TCP). A link connection in the client layer is represented by a 230 pair of adaptation functions and a trail in the server layer 231 network. A trail represents the transfer of monitored adapted 232 characteristics information of the client layer network between 233 access points (AP). A trail is delimited by two access points, one 234 at each end of the trail. Figure 2 shows a network connection and 235 its relationship with link and subnetwork connections. Figure 2 also 236 shows the CP and TCP reference points. 238 D. Fedyk, Editor Informational 5 239 |<-------Network Connection---------->| 240 | | 241 | (++++++++) (++++++++) | 242 |( SNC ) LC ( SNC ) | 243 (o)--------(o)----------(o)--------(o)| 244 TCP( )| CP CP |( )TCP 245 (++++++++) | | (++++++++) 246 | | 247 | Trail | 248 |<-------->| 249 | | 250 --- --- 251 \ / \ / 252 - - 253 AP 0 0 AP 254 | | 255 (oo)------(oo) 257 For management plane purposes the G.805 reference points are 258 represented by a set of management objects described in ITU-T 259 recommendation M.3100 [M.3100]. Connection termination points (CTP) 260 and trail termination points (TTP) are the management plane objects 261 for CP and TCP respectively. 262 In the same way as in M.3100, the transport resources in G.805 are 263 identified for the purposes of the control plane by entities 264 suitable for connection control. G.8080 introduces the reference 265 architecture for the control plane of the automatic switched optical 266 networks (ASON). G.8080 introduces a set of reference points 267 relevant to the ASON control plane and their relationship to the 268 corresponding points in the transport plane. A Subnetwork point 269 (SNP) is an abstraction that represents an actual or potential 270 underlying CP or an actual or potential TCP. A set of SNPs that are 271 grouped together for the purpose of routing is called SNP pool 272 (SNPP). Similar to LC and SNC, the SNP-SNP relationship may be 273 static and inflexible (this is referred to as an SNP link 274 connection) or it can be dynamic and flexible (this is referred to 275 as a SNP subnetwork connection). 277 3.1 G.8080 Discovery Framework 279 G.8080 provides a reference control plane architecture based on the 280 descriptive use of functional components representing abstract 281 entities and abstract component interfaces. The description is 282 generic and no particular physical partitioning of functions is 283 implied. The input/output information flows associated with the 284 functional components serve for defining the functions of the 285 components and are considered to be conceptual, not physical. 286 Components can be combined in different ways and the description is 287 not intended to limit implementations. Control plane discovery is 289 D. Fedyk, Editor Informational 6 290 described in G.8080 by using three components: Discovery Agent (DA), 291 Termination and Adaptation Performer (TAP), and Link Resource 292 Manager (LRM). 294 The objective of the discovery framework in G.8080 is to establish 295 the relationship between CP-CP link connections (transport plane) 296 and SNP-SNP link connections (control plane). The fundamental 297 characteristics of G.8080 discovery framework is the functional 298 separation between the control and the transport plane discovery 299 processes and name spaces. From G.8080: "This separation allows 300 control plane names to be completely separate from transport plane 301 names, and completely independent of the method used to populate the 302 DAs with those transport names." "In order to assign an SNP-SNP link 303 connection to an SNPP link, it is only necessary for the transport 304 name for the link connection to exist". Thus, it is possible to 305 assign link connections to the control plane without the link 306 connection being physically connected. 308 Discovery encompasses two separate processes: (1) transport plane 309 discovery, i.e. CP-to-CP and TCP-to-TCP connectivity and (2) control 310 plane discovery, i.e. SNP-to-SNP and SNPP links. 312 G.8080 Amendment 1 defines the discovery agent (DA) as the entity 313 responsible for discovery in the transport plane. The DA operates in 314 the transport name space only and in cooperation with the 315 Termination and Adaptation performer [TAP], provides the separation 316 between that space and the control plane names. A local DA is only 317 aware of the CPs and TCPs that are assigned to it. The DA holds the 318 CP-CP link connection in the transport plane to enable SNP-SNP link 319 connections to be bound to them at a later time by the TAP. The CP- 320 CP relationship may be discovered (e.g. per G.7714.1) or provided by 321 a management system. 323 Control plane discovery takes place entirely within the control 324 plane name space (SNPs). The Link Resource Manager (LRM) holds the 325 SNP-SNP binding information necessary for the control plane name of 326 the link connection, while the termination adaptation performer 327 (TAP) holds the relation between the control plane name (SNP) and 328 the transport plane name (CP) of the resource. Figure 3 shows the 329 relationship and the different entities for transport and control 330 discoveries. 332 D. Fedyk, Editor Informational 7 333 LRM LRM 334 +-----+ holds SNP-SNP Relation +-----+ 335 | |-------------------------| | 336 +-----+ +-----+ 337 | | 338 v v 339 +-----+ +-----+ 340 | o | SNP's in SNPP | o | 341 | | | | 342 | o | | o | 343 | | | | 344 | o | | o | 345 +-----+ +-----+ 346 | | 347 v v Control Plane 348 +-----+ +-----+ Discovery 349 | | Termination and | | 350 ---|-----|-------------------------|-----|--------- 351 | | Adaptation Performer | | 352 +-----+ (TAP) +-----+ Transport Plane 353 | \ / | Discovery 354 | \ / | 355 | +-----+ +-----+ | 356 | | DA | | DA | | 357 | | | | | | 358 | +-----+ +-----+ | 359 | / \ | 360 V/ \V 361 O CP (Transport Name) O CP (Transport Name) 363 Figure 3: Discovery in the Control and the Transport Planes 365 4. Discovery Technologies 367 4.1 Generalized automatic discovery techniques G.7714 369 Generalized automatic discovery techniques are described in G.7714 370 to aid resource management and routing for G.8080. The term routing 371 here is described in the transport context of routing connections in 372 an optical network as opposed to the routing context typically 373 associated in packet networks. 375 G.7714 is concerned with two types of discovery: 376 - Layer adjacency discovery 377 - Physical media adjacency discovery 379 Layer adjacency discovery can be used to correlate physical 380 connections with management configured attributes. Among other 381 features this capability allows reduction in configuration and the 382 detection of miswired equipment. 384 D. Fedyk, Editor Informational 8 385 Physical media adjacency discovery is a process that allows the 386 physical testing of the media for the purpose of inventory capacity 387 and verifying the port characteristics of physical media adjacent 388 networks. 390 G.7714 does not specify specific protocols but rather the type of 391 techniques that can be used. G.7714.1 specifies a protocol for 392 layer adjacency with respect to SDH and OTN networks for Layer 393 adjacency Discovery. A GMPLS method for Layer Discovery using 394 elements of LMP is included in this set of procedures. 396 An important point about the G.7714 specification is it specifies a 397 discovery mechanism for optical networks but not necessarily how the 398 information will be used. It is intended that the Transport 399 Management plane or a Transport control plane may subsequently make 400 use of the discovered information. 402 4.2 LMP and G.8080 Terminology Mapping 404 GMPLS is a set of IP-based protocols, including LMP, providing a 405 control plane for multiple data plane technologies, including 406 optical/transport networks and their resources (i.e. wavelengths, 407 timeslots, etc.) and without assuming any restriction on the control 408 plane architecture (see [GMPLS-ARCH]). Whereas, G.8080 defines a 409 control plane reference architecture for optical/transport networks 410 and without any restriction on the control plane implementation. 411 Being developed in separate standards forums, and with different 412 scope, they use different terms and definitions. 414 Terminology mapping between LMP and ASON (G.805/G.8080) is an 415 important step towards the understanding of the two architectures 416 and allows for potential cooperation in areas where cooperation is 417 possible. To facilitate this mapping, we differentiate between the 418 two types of data links in LMP. According to LMP, a data link may be 419 considered by each node that it terminates on as either a 'port' or 420 a 'component link'. The LMP notions of port and component link are 421 supported by the G.805/G.8080 architecture. G.8080's variable 422 adaptation function is broadly equivalent to LMP's component link, 423 i.e. a single server layer trail dynamically supporting different 424 multiplexing structures. Note that when the data plane delivers its 425 own addressing space, LMP Interface_IDs and Data Links IDs are used 426 as handles by the control plane to the actual CP Name and CP-to-CP 427 Name, respectively. 429 The terminology mapping is summarized in the following table: 430 Note that the table maps ASON terms to GMPLS terms that refer to 431 equivalent objects, but in many cases there is not a one to one 432 mapping. Additional information beyond Discovery terminology can be 433 found in [LEXICO]. 435 D. Fedyk, Editor Informational 9 436 +----------------+--------------------+-------------------+ 437 | ASON Terms | GMPLS/LMP Terms | GMPLS/LMP Terms | 438 | | Port | Component Link | 439 +----------------+--------------------+-------------------+ 440 | CP | TE Resource; | TE Resource; | 441 | | Interface (Port) | Interface. | 442 | | |(Comp. link) | 443 +----------------+--------------------+-------------------+ 444 | CP Name | Interface ID | Interface ID(s) | 445 | | no further sub- | resources (such as| 446 | | division for(label)| timeslots, etc.) | 447 | | resource allocation| on this interface | 448 | | | are identified by | 449 | | | set of labels | 450 +----------------+--------------------+-------------------+ 451 | CP-to-CP Link | Data Link | Data Link | 452 +----------------+--------------------+-------------------+ 453 | CP-to-CP Name | Data Link ID | Data Link ID | 454 +----------------+--------------------+-------------------+ 455 | SNP | TE Resource | TE Resource | 456 +----------------+--------------------+-------------------+ 457 | SNP Name | Link ID | Link ID | 458 +----------------+--------------------+-------------------+ 459 | SNP LC | TE Link | TE Link | 460 +----------------+--------------------+-------------------+ 461 | SNP LC Name | TE Link ID | TE Link ID | 462 +----------------+--------------------+-------------------+ 463 | SNPP | TE Link End | TE Link End | 464 | | (Port) | (Comp. Link) | 465 +----------------+--------------------+-------------------+ 466 | SNPP Name | Link ID | Link ID | 467 +----------------+--------------------+-------------------+ 468 | SNPP Link | TE Link | TE Link | 469 +----------------+--------------------+-------------------+ 470 | SNPP Link Name | TE Link ID | TE Link ID | 471 +----------------+--------------------+-------------------+ 473 where composite identifiers are: 474 - Data Link ID: 475 - TE Link ID: 477 Composite Identifiers are defined in the LMP draft [LMP]. LMP 478 discovers Data Links and identifies them by the pair of local and 479 remote interface Ids. TE Links are comprised of Data Links or 480 component TE links. TE links are similarly identified by pair of 481 local and remote Link ID. 483 4.2.1 TE Link Definition and Scope 485 D. Fedyk, Editor Informational 10 486 In the table, TE link/resource is equated with the concept of SNP, 487 SNP LC, SNPP and SNPP link. The definition of the TE link is broad in 488 scope and it is useful to repeat it here. The original definition 489 appears in [GMPLS-RTG]: 491 "A TE link is a logical construct that represents a way to group/map 492 the information about certain physical resources (and their 493 properties) that interconnects LSRs into the information that is 494 used by Constrained SPF for GMPLS path computation, and GMPLS 495 signaling." 497 While this definition is concise it is probably worth pointing out 498 some of the implications of the definition. 500 A component of the TE link may follow different path between the 501 pair of LSRs. For example, a TE link comprising multiple STS-3cs, 502 the individual STS-3cs component links may take identical or 503 different physical (OC-3 and/or OC-48) paths between LSRs. 505 The TE link construct is a logical construction encompassing many 506 layers in networks [RFC 3471]. A TE link can represent either 507 unallocated potential or allocated actual resources. Further 508 allocation is represented by Bandwidth reservation and the resources 509 may be real or in the case of packets, virtual to allow for over 510 booking or other forms of statistical multiplexing schemes. 512 Since TE links may represent large numbers of parallel resources 513 they can be bundled for efficient summarization of resource 514 capacity. Typically bundling represents a logical TE link resource 515 at a particular Interface Switching Capability. Once TE link 516 resources are allocated the actual capacity may be represented as 517 LSP hierarchical (tunneled) TE link capability in another logical TE 518 link [HIER]. 520 TE links also incorporate the notion of a Forwarding Adjacency (FA) 521 and Interface Switching Capability [RFC3945]. The FA allows 522 transport resources to be represented as TE-links. The Interface 523 Switching Capability specifies the type of transport capability such 524 as Packet Switch Capable(PSC), Layer-2 Switch Capable (L2SC), 525 Time-Division Multiplex (TDM), Lambda Switch Capable (LSC) and 526 Fiber-Switch Capable (FSC). 528 A TE link between GMPLS controlled optical nodes may consist of a 529 bundled (TE link) which itself consists of a mix of point-to-point 530 component links [BUNDLE]. A TE link is identified by the tuple: 531 (link Identifier (32 bit number), Component link Identifier (32 bit 532 number) and generalized label (media specific)). 534 D. Fedyk, Editor Informational 11 535 4.3 LMP and G.8080 Discovery Relationship 537 LMP currently consists of four primary procedures, of which, the 538 first two are mandatory and the last two are optional: 540 1. Control channel management 541 2. Link property correlation 542 3. Link verification 543 4. Fault management 545 LMP procedures that are relevant to G.8080 control plane discovery 546 are control channel management, link property correlation and Link 547 Verification. Key to understanding G.8080 discovery aspects in 548 relation to [LMP] is that LMP procedures are specific for an 549 IP-based control plane abstraction of the transport plane. 551 LMP control channel management is used to establish and maintain 552 control channel connectivity between LMP adjacent nodes. In GMPLS, 553 the control channels between two adjacent nodes are not required to 554 use the same physical medium as the TE links between those nodes. 555 The control channels that are used to exchange the GMPLS control 556 plane information exist independently of the TE links they manage 557 (i.e., control channels may be in-band or out-of-band, provided the 558 associated control points terminate the LMP packets). The Link 559 Management Protocol [LMP] was designed to manage TE links, 560 independently of the physical medium capabilities of the data links. 562 Link property correlation is used to aggregate multiple data links 563 into a single TE Link and to synchronize the link properties. 565 Link verification is used to verify the physical connectivity of the 566 data links and verify the mapping of the Interface-ID to Link-ID (CP 567 to SNP). The local-to-remote associations can be obtained using a 568 priori knowledge or using the Link verification procedure. 570 Fault management is primarily used to suppress alarms and to 571 localize failures. It is an optional LMP procedure, its use will 572 depend on the specific technology's capabilities. 574 [LMP] supports distinct transport and control plane name spaces with 575 the (out-of-band) TRACE object (see [LMP-TEST]). The LMP TRACE 576 object allows transport plane names to be associated with interface 577 identifiers [LMP-TEST]. 579 Aspects of LMP link verification appear similar to G.7714.1 580 discovery, however the two procedures are different. G.7714.1 581 provides discovery of the transport plane layer adjacencies. It 582 provides a generic procedure to discover the connectivity of two end 583 points in the transport plane. Whereas, LMP link verification 584 procedure is a control plane driven procedure and assumes either (1) 585 a priori knowledge of the associated data plane's local and remote 586 end point connectivity and Interface_IDs (e.g. via management plane 587 or use of G.7714.1), or (2) support of the remote node for 589 D. Fedyk, Editor Informational 12 590 associating the data interface being verified with the content of 591 the TRACE object (inferred mapping). For SONET/SDH transport 592 networks, LMP verification uses the SONET/SDH Trail Trace identifier 593 (see [G.783]). 595 G.7714.1 supports the use of transport plane discovery independent 596 of the platform using the capability. Furthermore G.7714.1 specifies 597 the use of a Discovery Agent that could be located in an external 598 system and the need to support the use of text-oriented man-machine 599 language to provide the interface. Therefore, G.7714.1 limits the 600 discovery messages to printable characters defined by [T.50] and 601 requires Base64 encoding for the TCP-ID and DA ID. External 602 name-servers may be used to resolve the G.7714.1 TCP name, allowing 603 the TCP to have an IP, NSAP or any other address format. Whereas, 604 LMP is based on the use of an IP-based control plane, and the LMP 605 interface ID uses IPv4, IPv6, or unnumbered interface IDs. 607 4.4 Comparing LMP and G.8080 609 LMP exists to support GMPLS TE resource and TE link discovery. In 610 section 4.2.1 we elaborated on the definition of the TE link. LMP 611 enables the aspects of TE links to be discovered, and reported to 612 the control plane, more specifically the routing plane. G.8080 and 613 G.7714 are agnostic to the type of control plane and discovery 614 protocol used. LMP is a valid realization of a control plane 615 discovery process under a G.8080 model. 617 G.7714 specifies transport plane discovery with respect to the 618 transport layer CTPs or TCPs using ASON conventions and naming for 619 the elements of the ASON control plane and the ASON management 620 plane. This discovery supports a centralized management model of 621 configuration as well as a distributed control plane model, in other 622 words discovered items can be reported to the management plane or 623 the control plane. G.7714.1 provides one realization of a transport 624 plane discovery process. 626 Today LMP and G.7714, G7714.1 are defined in different Standards 627 Organizations. They have evolved out of different naming schemes 628 and architectural concepts. Whereas G.7714.1 supports a transport 629 plane layer adjacency connectivity verification which can be used by 630 a control plane or a management plane, LMP is a control plane 631 procedure for managing GMPLS TE links (GMPLS's control plane 632 representation of the transport plane connections). 634 5. Security Considerations 636 Since this document is purely descriptive in nature it does not 637 introduce any security issues. 639 G.8080 and G.7714/G.7714.1 provide security as associated with the 640 Data Communications Network on which they are implemented. 642 D. Fedyk, Editor Informational 13 643 LMP is specified using IP which provides security mechanisms 644 associated with the IP network on which it is implemented. 646 6. IANA Considerations 648 This informational document makes no requests for IANA action. 650 7. Intellectual Property Considerations 652 The IETF takes no position regarding the validity or scope of any 653 Intellectual Property Rights or other rights that might be claimed 654 to pertain to the implementation or use of the technology described 655 in this document or the extent to which any license under such 656 rights might or might not be available; nor does it represent that 657 it has made any independent effort to identify any such rights. 658 Information on the procedures with respect to rights in RFC 659 documents can be found in BCP 78 and BCP 79. 661 Copies of IPR disclosures made to the IETF Secretariat and any 662 assurances of licenses to be made available, or the result of an 663 attempt made to obtain a general license or permission for the use 664 of such proprietary rights by implementers or users of this 665 specification can be obtained from the IETF on-line IPR repository 666 at http://www.ietf.org/ipr. 668 The IETF invites any interested party to bring to its attention any 669 copyrights, patents or patent applications, or other proprietary 670 rights that may cover technology that may be required to implement 671 this standard. Please address the information to the IETF at ietf- 672 ipr@ietf.org. 674 D. Fedyk, Editor Informational 14 675 8. References 677 8.1 Normative References 679 [BCP 78] S. Bradner, "Intellectual Property Rights in IETF 680 Technology", BCP 79, RFC 3667, February 2004. 682 [BCP 79] S. Bradner, "IETF Rights in Contributions", BCP 79, 683 RFC 3668, February 2004. 685 8.2 Informational References 687 [LMP] J.P.Lang (Editor), "Link Management Protocol," draft- 688 ietf-ccamp-lmp-10.txt, October 2003. 690 [LMP-TEST] J.P.Lang et al., "SONET/SDH Encoding for Link 691 Management Protocol (LMP) Test messages," draft-ietf- 692 draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt, December 693 2004. 695 [RFC3945] Eric Mannie (Editor), "Generalized Multi-protocol Label 696 Switching Architecture," RFC3945, October 2004. 698 [RFC3471] Lou Berger (Editor), "Generalized Multi-Protocol Label 699 Switching (GMPLS)Signaling Functional Description," 700 RFC3471, January 2003. 702 [GMPLS-RTG] K. Kompella & Y. Rekhter (editors) "Routing Extensions 703 in Support of Generalized Multi-Protocol Label 704 Switching", draft-ietf-ccamp-gmpls-routing-09.txt, 705 December 2003. 707 [HIER] K. Kompella & Y. Rekhter "LSP Hierarchy with Generalized 708 MPLS TE", draft-ietf-mpls-lsp-hierarchy-08.txt, 709 September 2002. 711 [BUNDLE] K. Kompella, Y. Rekhter, Lou Berger "Link Bundling in 712 MPLS Traffic Engineering", draft-ietf-mpls-bundle- 713 06.txt, December 2004. 715 [LEXICO] A. Farrel & I Bryskin "A Lexicography for the 716 Interpretation of Generalized Multiprotocol Label 717 Switching (GMPLS) Terminology within The Context of the 718 ITU-T's Automatically Switched Optical Network (ASON) 719 Architecture", draft-bryskin-ccamp-gmpls-ason- 720 lexicography-02.txt, April 2005. 722 "For information on the availability of ITU-T Documents, please see 723 http://www.itu.int" 725 D. Fedyk, Editor Informational 15 727 [G.783] ITU-T G.783 (2004), Characteristics of synchronous 728 digital hierarchy (SDH) equipment functional blocks. 730 [G.805] ITU-T G.805 (2000), Generic functional architecture of 731 transport networks. 733 [G.7714] ITU-T G.7714/Y.1705 (2001), Generalized automatic 734 discovery techniques. 736 [G.7714.1] ITU-T G.7714.1/Y.1705.1 (2003), Protocol for automatic 737 discovery in SDH and OTN networks. 739 [G.8080] ITU-T G.8080/Y.1304 (2001), Architecture for the 740 automatically switched optical network (ASON). 742 [M.3100] ITU-T M.3100 (1995), Generic Network Information Model. 744 [T.50] ITU-T T.50 (1992), International Reference Alphabet. 746 9. Acknowledgements 748 The authors would like to thank Astrid Lozano, John Drake, Adrian 749 Farrel and Stephen Shew for their valuable comments. 751 The authors would like to thank ITU-T Study Group 15 Question 14 for 752 their careful review and comments. 754 10. Author's Addresses 756 Don Fedyk 757 Nortel Networks 758 600 Technology Park Drive 759 Billerica, MA, 01821 760 Phone: +1 978 288-3041 761 Email: dwfedyk@nortel.com 763 Osama Aboul-Magd 764 Nortel Networks 765 P.O. Box 3511, Station 'C' 766 Ottawa, Ontario, Canada 767 K1Y-4H7 768 Phone: +1 613 763-5827 769 Email: osama@nortel.com 771 D. Fedyk, Editor Informational 16 772 Deborah Brungard 773 AT&T 774 Rm. D1-3C22 775 200 S. Laurel Ave. 776 Middletown, NJ 07748, USA 777 Email: dbrungard@att.com 779 Jonathan P. Lang 780 Sonos, Inc. 781 506 Chapala Street 782 Santa Barbara, CA 93101 783 Email : jplang@ieee.org 785 Dimitri Papadimitriou 786 Alcatel 787 Francis Wellesplein, 1 788 B-2018 Antwerpen, Belgium 789 Phone: +32 3 240-84-91 790 Email: dimitri.papadimitriou@alcatel.be 792 11. Disclaimer of Validity 794 This document and the information contained herein are provided on 795 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 796 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 797 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 798 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 799 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 800 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 802 12. Full Copyright Statement 804 Copyright (C) The Internet Society (2005). This document is subject 805 to the rights, licenses and restrictions contained in BCP 78, and 806 except as set forth therein, the authors retain all their rights. 808 D. Fedyk, Editor Informational 17