idnits 2.17.1 draft-aboulmagd-ccamp-transport-lmp-02.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There is 1 instance of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 15 longer pages, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) 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 (July 2004) is 7218 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TAP' is mentioned on line 301, but not defined == Unused Reference: 'RFC3668' is defined on line 631, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3668 (Obsoleted by RFC 3979) -- No information found for draft-ietf-draft-ietf-ccamp-lmp-test-sonet-sdh - is the name correct? -- Duplicate reference: draft-ietf-ccamp-gmpls-architecture, mentioned in 'RFC 3471', was also mentioned in 'GMPLS-ARCH'. == Outdated reference: A later version (-06) exists of draft-ietf-mpls-bundle-04 Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Osama Aboul-Magd 2 Don Fedyk 3 Internet Draft Nortel Networks 4 Document: draft-aboulmagd-ccamp-transport-lmp-02.txt 5 Category: Informational Deborah Brungard 6 AT&T 8 Jonathan Lang 9 Sonos, Inc. 11 Dimitri Papadimitriou 12 Alcatel 14 July 2004 16 A Transport Network View of LMP 17 19 Status of this Memo 21 This document is an Internet-Draft and is in full conformance with 22 all provisions of Section 10 of RFC2026 [RFC2026]. 24 By submitting this Internet-Draft, I certify that any applicable 25 patent or other IPR claims of which I am aware have been disclosed, 26 and any of which I become aware will be disclosed, in accordance 27 with RFC3668 [RFC3668]. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. Internet-Drafts are draft documents valid for a maximum of 33 six months and may be updated, replaced, or obsoleted by other 34 documents at any time. It is inappropriate to use Internet Drafts as 35 reference material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 1. Abstract 44 The Link Management Protocol (LMP) has been developed as part of the 45 Generalized MPLS (GMPLS) protocol suite to manage Traffic 46 Engineering (TE) links. The GMPLS control plane (routing and 47 signaling) uses TE links for establishing Label Switched Paths 48 (LSPs). This memo describes the relationship of the LMP procedures 50 Aboul-magd Expires Jaunary 2005 1 51 to 'discovery' as defined in the International Telecommunication 52 Union (ITU), and on-going ITU-T work. This document provides an 53 overview of LMP in the context of the ITU-T Automatically Switched 54 Optical Networks (ASON) and transport network terminology and 55 relates it to the ITU-T discovery work to promote a common 56 understanding for progressing the work of IETF and ITU-T. 58 2. Table of Contents 60 1. Abstract........................................................1 61 2. Table of Contents...............................................2 62 3. Terminology.....................................................2 63 4. Introduction....................................................3 64 5. Transport Network Architecture..................................4 65 5.1 G.8080 Discovery Framework.....................................6 66 6. Discovery Technologies..........................................8 67 6.1 Generalized automatic discovery techniques G.7714..............8 68 6.2 LMP and G.8080 Terminology Mapping.............................8 69 6.2.1 TE Link Definition and Scope................................10 70 6.3 LMP and G.8080 Discovery Relationship.........................11 71 6.4 Comparing LMP and G.8080......................................12 72 7. Security Considerations........................................13 73 8. References.....................................................13 74 8.1 Normative References..........................................13 75 8.2 Informational References......................................13 76 9. Acknowledgements...............................................14 77 10. Author's Addresses............................................14 78 Full Copyright Statement..........................................16 80 3. Terminology 82 The reader is assumed to be familiar with the terminology in [LMP] 83 and [LMP-TEST]. The following ITU terminology/abbreviations are used 84 in this document: 86 Characteristic Information: Signal with a specific format, which is 87 transferred on "network connections". The specific formats will be 88 defined in the technology specific Recommendations. For trails the 89 Characteristic Information is the payload plus the overhead. . The 90 information transferred is characteristic of the layer network. 92 Link: a subset of ports at the edge of a subnetwork or access group 93 which are associated with a corresponding subset of ports at the 94 edge of another subnetwork or access group. 96 OTN: Optical transport network 98 PDH: Plesiosynchronous digital hierarchy 100 SDH: Synchronous digital hierarchy. 102 Aboul-magd Expires January 2005 2 103 Subnetwork: a set of ports which are available for the purpose of 104 routing 'characteristic information'. 106 Subnetwork Connection (SNC): a flexible connection that is setup and 107 released using management or control plane procedures. 109 Link Connection (LC): a transport entity that transfers information 110 between ports across a link. 112 Network Connection (NC): A concatenation of link and subnetwork 113 connections. 115 Connection Termination Point (CTP): A Connection Termination Point 116 (CTP) represents the state of a Connection Point (CP) [M.3100] The 117 CP is a reference point representing the end point of a link 118 connection and represents the North input port of an Adaptation 119 function. 121 Termination Connection Point (TCP): A reference point that 122 represents the output of a Trail Termination source function or the 123 input to a Trail Termination sink function. A network connection 124 represents a transport entity between TCPs. 126 Subnetwork Point (SNP): SNP is an abstraction that represents an 127 actual or potential underlying connection point (CP) or termination 128 connection point (TCP) for the purpose of control plane 129 representation. 131 Subnetwork Point Pool (SNPP): A set of SNP that are grouped together 132 for the purpose of routing. 134 4. Introduction 136 The GMPLS control plane consists of several building blocks as 137 described in [GMPLS-ARCH]. The building blocks include signaling, 138 routing, and link management for establishing LSPs. For scalability 139 purposes, multiple physical resources can be combined to form a 140 single traffic engineering (TE) link for the purposes of path 141 computation and GMPLS control plane signaling. 143 As manual provisioning and management of these links is impractical 144 in large networks, LMP was specified to manage TE links. Two 145 mandatory management capabilities of LMP are control channel 146 management and TE link property correlation. Additional optional 147 capabilities include verifying physical connectivity and fault 148 management. [LMP] defines the messages and procedures for GMPLS TE 149 link management. [LMP-TEST] defines SONET/SDH specific messages and 150 procedures for link verification. 152 G.8080 Amendment 1 [G.8080] defines control plane discovery as two 153 separate processes, one process occurs within the transport plane 154 space and the other process occurs within the control plane space. 156 Aboul-magd Expires January 2005 3 157 The ITU-T has developed Recommendation G.7714 'Generalized automatic 158 discovery techniques' [G.7714] defining the functional processes and 159 information exchange related to transport plane discovery aspects: 160 i.e., layer adjacency discovery and physical media adjacency 161 discovery. Specific methods and protocols are not defined in 162 Recommendation G.7714. ITU-T Recommendation G.7714.1 'Protocol for 163 automatic discovery in SDH and OTN networks' [G.7714.1] defines a 164 protocol and procedure for transport plane layer adjacency discovery 165 (e.g. discovering the transport plane layer end point relationships 166 and verifying their connectivity). The ITU-T is currently working to 167 extend discovery to control plane aspects providing detail on a 168 Discovery framework architecture in G.8080 and a new Recommendation 169 on 'Control plane initial establishment, reconfiguration'. 171 5. Transport Network Architecture 173 A generic functional architecture for transport networks is defined 174 in the International Telecommunications Union (ITU) recommendation 175 [G.805]. This recommendation describes the functional architecture 176 of transport networks in a technology independent way. This 177 architecture forms the basis for a set of technology specific 178 architectural recommendations for transport networks (e.g., SDH, 179 PDH, OTN, etc.) 181 The architecture defined in G.805 is designed using a layered model 182 with a client-server relationship between layers. The architecture 183 is recursive in nature; a network layer is both a server to the 184 client layer above it and a client to the server layer below it. 186 There are two basic building blocks defined in G.805: "subnetworks" 187 and "links". A subnetwork is defined as a set of ports which are 188 available for the purpose of routing "characteristic information". A 189 link consists of a subset of ports at the edge of one subnetwork (or 190 "access group") and is associated with a corresponding subset of 191 ports at the edge of another subnetwork or access group. 193 Two types of connections are defined in G.805: "link connection" 194 (LC) and "subnetwork connection" (SNC). A link connection is a fixed 195 and inflexible connection, while a subnetwork connection is flexible 196 and is setup and released using management or control plane 197 procedures. A network connection is defined as a concatenation of 198 subnetwork and link connections. Figure 1 illustrates link and 199 subnetwork connections. 201 Aboul-magd Expires January 2005 4 202 (++++++++) (++++++++) 203 ( SNC ) LC ( SNC ) 204 (o)--------(o)----------(o)--------(o) 205 ( ) CP CP ( ) 206 (++++++++) (++++++++) 208 subnetwork subnetwork 210 Figure 1: Subnetwork and Link Connections 212 G.805 defines a set of reference points for the purpose of 213 identification in both the management and the control plane. These 214 identifiers are NOT required to be the same. A link connection or a 215 subnetwork connection is delimited by connection points (CP). A 216 network connection is delimited by a termination connection point 217 (TCP). A link connection in the client layer is represented by a 218 pair of adaptation functions and a trail in the server layer 219 network. A trail represents the transfer of monitored adapted 220 characteristics information of the client layer network between 221 access points (AP). A trail is delimited by two access points, one 222 at each end of the trail. Figure 2 shows a network connection and 223 its relationship with link and subnetwork connections. Figure 2 also 224 shows the CP and TCP reference points. 226 |<-------Network Connection---------->| 227 | | 228 | (++++++++) (++++++++) | 229 |( SNC ) LC ( SNC ) | 230 (o)--------(o)----------(o)--------(o)| 231 TCP( )| CP CP |( )TCP 232 (++++++++) | | (++++++++) 233 | | 234 | Trail | 235 |<-------->| 236 | | 237 --- --- 238 \ / \ / 239 - - 240 AP 0 0 AP 241 | | 242 (oo)------(oo) 244 For management plane purposes the G.805 reference points are 245 represented by a set of management objects described in ITU 246 recommendation M.3100 [M.3100]. Connection termination points (CTP) 247 and trail termination points (TTP) are the management plane objects 248 for CP and TCP respectively. 250 Aboul-magd Expires January 2005 5 251 In the same way as in M.3100, the transport resources in G.805 are 252 identified for the purposes of the control plane by entities 253 suitable for connection control. G.8080 introduces the reference 254 architecture for the control plane of the automatic switched optical 255 networks (ASON). G.8080 introduces a set of reference points 256 relevant to the ASON control plane and their relationship to the 257 corresponding points in the transport plane. A Subnetwork point 258 (SNP) is an abstraction that represents an actual or potential 259 underlying CP or an actual or potential TCP. A set of SNPs that are 260 grouped together for the purpose of routing is called SNP pool 261 (SNPP). Similar to LC and SNC, the SNP-SNP relationship may be 262 static and inflexible (this is referred to as an SNP link 263 connection) or it can be dynamic and flexible (this is referred to 264 as a SNP subnetwork connection). 266 5.1 G.8080 Discovery Framework 268 G.8080 provides a reference control plane architecture based on the 269 descriptive use of functional components representing abstract 270 entities and abstract component interfaces. The description is 271 generic and no particular physical partitioning of functions is 272 implied. The input/output information flows associated with the 273 functional components serve for defining the functions of the 274 components and are considered to be conceptual, not physical. 275 Components can be combined in different ways and the description is 276 not intended to limit implementations. Control plane discovery is 277 described in G.8080 by using three components: Discovery Agent (DA), 278 Termination and adaptation performer (TAP), and Link Resource 279 Manager (LRM). 281 The objective of the discovery framework in G.8080 is to establish 282 the relationship between CP-CP link connections (transport plane) 283 and SNP-SNP link connections (control plane). The fundamental 284 characteristics of G.8080 discovery framework is the functional 285 separation between the control and the transport plane discovery 286 processes and name spaces. The separation between the two processes 287 and corresponding two name spaces has the advantage that the 288 discovery of the transport plane can be performed independent from 289 that of the control plane (and vice-versa), and independent of the 290 method used in each name space. This allows assigning link 291 connections in the control plane without the link connection being 292 physically connected. 294 Discovery encompasses two separate processes: (1) transport plane 295 discovery, i.e. CP-to-CP and TCP-to-TCP connectivity and (2) control 296 plane discovery, i.e. SNP-to-SNP and SNPP links. 298 G.8080 Amendment 1 defines the discovery agent (DA) as the entity 299 responsible for discovery in the transport plane. The DA operates in 300 the transport name space only and in cooperation with the 301 Termination and Adaptation performer [TAP], provides the separation 303 Aboul-magd Expires January 2005 6 304 between that space and the control plane names. A local DA is only 305 aware of the CPs and TCPs that are assigned to it. The DA holds the 306 CP-CP link connection in the transport plane to enable SNP-SNP link 307 connections to be bound to them at a later time by the TAP. The CP- 308 CP relationship may be discovered (e.g. per G.7714.1) or provided by 309 a management system. 311 Control plane discovery takes place entirely within the control 312 plane name space (SNPs). The Link Resource Manager (LRM) holds the 313 SNP-SNP binding information necessary for the control plane name of 314 the link connection, while the termination adaptation performer 315 (TAP) holds the relation between the control plane name (SNP) and 316 the transport plane name (CP) of the resource. Figure 3 shows the 317 relationship and the different entities for transport and control 318 discoveries. 320 LRM LRM 321 +-----+ holds SNP-SNP Relation +-----+ 322 | |-------------------------| | 323 +-----+ +-----+ 324 | | 325 v v 326 +-----+ +-----+ 327 | o | SNP's in SNPP | o | 328 | | | | 329 | o | | o | 330 | | | | 331 | o | | o | 332 +-----+ +-----+ 333 | | 334 v v Control Plane 335 +-----+ +-----+ Discovery 336 | | Termination and | | 337 ---|-----|-------------------------|-----|--------- 338 | | Adaptation Performer | | 339 +-----+ (TAP) +-----+ Transport Plane 340 | \ / | Discovery 341 | \ / | 342 | +-----+ +-----+ | 343 | | DA | | DA | | 344 | | | | | | 345 | +-----+ +-----+ | 346 | / \ | 347 V/ \V 348 O CP (Transport Name) O CP (Transport Name) 350 Figure 3: Discover in the Control and the Transport Planes 352 Aboul-magd Expires January 2005 7 353 6. Discovery Technologies 355 6.1 Generalized automatic discovery techniques G.7714 357 Generalized automatic discovery techniques are described in G.7714 358 to aid resource management and routing for G.8080. The term routing 359 here is described in the transport context of routing connections in 360 an optical network as opposed to the routing context typically 361 associated in packet networks. 363 G.7714 is concerned with two types of discovery: 364 - Layer adjacency discovery 365 - Physical media adjacency discovery 367 Layer adjacency discovery can be used to correlate physical 368 connections with management configured attributes. Among other 369 features this capability allows reduction in configuration and the 370 detection of miswired equipment. 372 Physical media adjacency discovery is a process that allows the 373 physical testing of the media for the purpose of inventory capacity 374 and verifying the port characteristics of physical media adjacent 375 networks. 377 G.7714 does not specify specific protocols but rather the type of 378 techniques that can be used. G.7714.1 specifies a protocol for 379 layer adjacency with respect to SDH and OTN networks for Layer 380 adjacency Discovery. A GMPLS method for Layer Discovery using 381 elements of LMP are included in this set of procedures. 383 An important point about the G.7714 specification is it specifies a 384 discovery mechanism for optical networks but not necessarily how the 385 information will be used. It is intended that the Transport 386 Management plane or a Transport control plane may subsequently make 387 use of the discovered information. 389 6.2 LMP and G.8080 Terminology Mapping 391 GMPLS is a set of IP-based protocols, including LMP, providing a 392 control plane for multiple data plane technologies, including 393 optical/transport networks and their resources (i.e. wavelengths, 394 timeslots, etc.) and without assuming any restriction on the control 395 plane architecture (see [GMPLS-ARCH]). Whereas, G.8080 defines a 396 control plane reference architecture for optical/ transport networks 397 and without any restriction on the control plane implementation. 398 Being developed in separate standards forums, and with different 399 scope, they use different terms and definitions. 401 Terminology mapping between LMP and ASON (G.805/G.8080) is an 402 important step towards the understanding of the two architectures 404 Aboul-magd Expires January 2005 8 405 and allows for potential cooperation in areas where cooperation is 406 possible. To facilitate this mapping, we differentiate between the 407 two types of data links in LMP. According to LMP, a data link may be 408 considered by each node that it terminates on as either a 'port' or 409 a 'component link'. The LMP notions of port and component link are 410 supported by the G.805/G.8080 architecture. G.8080 refers to a 411 component link as a variable adaptation function i.e. a single 412 server layer trail dynamically supporting different multiplexing 413 structures. Note that when the data plane delivers its own 414 addressing space, LMP Interface_IDs and Data Links IDs are used as 415 handles by the control plane to the actual CP Name and CP-to-CP 416 Name, respectively. 418 The terminology mapping is summarized in the following table: 419 +----------------+--------------------+-------------------+ 420 | ASON Terms | GMPLS/LMP Terms | GMPLS/LMP Terms | 421 | | Port | Component Link | 422 +----------------+--------------------+-------------------+ 423 | CP | Interface (Port) | Interface. | 424 | | |(Comp. link) | 425 +----------------+--------------------+-------------------+ 426 | CP Name | Interface ID | Interface ID(s) | 427 | | no further sub- | resources (such as| 428 | | division for(label)| timeslots, etc.) | 429 | | resource allocation| on this interface | 430 | | | are identified by | 431 | | | set of labels | 432 +----------------+--------------------+-------------------+ 433 | CP-to-CP | Data Link | Data Link | 434 +----------------+--------------------+-------------------+ 435 | CP-to-CP Name | Data Link ID | Data Link ID | 436 +----------------+--------------------+-------------------+ 437 | SNP | TE Link (Port) | TE Link (Comp) | 438 | | (single link) | (single link) | 439 +----------------+--------------------+-------------------+ 440 | SNP Name | Link ID | Link ID | 441 +----------------+--------------------+-------------------+ 442 | SNP LC | TE Link | TE Link | 443 +----------------+--------------------+-------------------+ 444 | SNP LC Name | TE Link ID | TE Link ID | 445 +----------------+--------------------+-------------------+ 446 | SNPP | TE Link (Port) | TE Link (Comp) | 447 +----------------+--------------------+-------------------+ 448 | SNPP Name | Link ID | Link ID | 449 +----------------+--------------------+-------------------+ 450 | SNPP Link | TE Link | TE Link | 451 +----------------+--------------------+-------------------+ 452 | SNPP Link Name | TE Link ID | TE Link ID | 453 +----------------+--------------------+-------------------+ 455 where: 456 - Data Link ID: 457 - TE Link ID: 459 Aboul-magd Expires January 2005 9 460 6.2.1 TE Link Definition and Scope 462 In the table TE link is equated the concept of SNP, SNP LC, SNPP and 463 SNPP link. The definition of the TE link is broad in scope and is 464 useful repeating here. The original definition appears in [GMPLS- 465 RTG]: 467 "A TE link is a logical construct that represents a way to group/map 468 the information about certain physical resources (and their 469 properties) that interconnects LSRs into the information that is 470 used by Constrained SPF for the purpose of path computation, and by 471 GMPLS signaling." 473 While this definition is concise it is probably worth pointing some 474 of the implications of the definition. 476 A TE link is not limited to a single path. TE links can be formed 477 over resources (e.g. individual OC-3c links) which take identical or 478 different physical paths between Nodes. 480 The TE link construct is a logical construction encompassing many 481 layers in networks [RFC 3471]. A TE link can represent either 482 unallocated potential or allocated actual resources. Further 483 allocation is represented by Bandwidth reservation and the resources 484 may be real or in the case of packets virtual to allow for over 485 booking or other form of statistical multiplexing schemes. 487 Since TE links may represent large number of parallel resources they 488 can be bundled for efficient summarization of resource capacity. 489 Typically bundling represents a logical TE link resource at a 490 particular Interface switching capability. Once TE link resources 491 are allocated the actual capacity may be represented as LSP 492 hierarchical (tunneled) TE link capability in another logical TE 493 link [HIER]. 495 TE links also incorporate the notion of a Forwarding Adjacency (FA) 496 and Interface Switching capability [GMPLS-ARCH]. The FA allows 497 transport resources to be represented as TE-links. The interface 498 switching capability specifies the type of transport capability such 499 as Packet switch Capable(PSC), Layer-2 Switch Capable (L2SC), Time- 500 Division Multiplex (TDM), Lambda Switch Capable (LSC) and Fiber- 501 Switch Capable (FSC).. 503 A typical TE link between GMPLS controlled optical nodes would 504 consist of a bundled (TE link) which itself consists 505 of a mix of point-to-point links and FAs [BUNDLE] . A TE link is 506 identified by the tuple: (Bundled link Identifier(32 bit number), 507 Component link Identifier(32 bit number) and generalized label(media 508 specific)). 510 Aboul-magd Expires January 2005 10 511 6.3 LMP and G.8080 Discovery Relationship 513 LMP currently consists of four primary procedures, of which, the 514 first two are mandatory and the last two are optional: 516 1. Control channel management 517 2. Link property correlation 518 3. Link verification 519 4. Fault management 521 LMP procedures that are relevant to G.8080 control plane discovery 522 are control channel management, link property correlation and Link 523 Verification.. Key to understanding G.8080 discovery aspects in 524 relation to [LMP] is that LMP procedures are specific for an IP- 525 based control plane abstraction of the transport plane. 527 LMP control channel management is used to establish and maintain 528 control channel connectivity between LMP adjacent nodes. In GMPLS, 529 the control channels between two adjacent nodes are not required to 530 use the same physical medium as the TE links between those nodes. 531 The control channels that are used to exchange the GMPLS control- 532 plane information exist independently of the TE links they manage 533 (i.e., control channels may be in-band or out-of-band, provided the 534 associated control points terminate the LMP packets). The Link 535 Management Protocol [LMP] was designed to manage TE links, 536 independently of the physical medium capabilities of the data links. 537 This is done using a Config message exchange followed by a 538 lightweight keep-alive message exchange. 540 Link property correlation is used to aggregate multiple data links 541 into a single TE Link and to synchronize the link properties. 543 Link verification is used to verify the physical connectivity of the 544 data links and verify the mapping of the Interface-ID to Link-ID (CP 545 to SNP). The local-to-remote associations can be obtained using a 546 priori knowledge or using the Link verification procedure. 548 Fault management is primarily used to suppress alarms and to 549 localize failures. It is an optional LMP procedure, it's use will 550 depend on the specific technology's capabilities. 552 [LMP] supports distinct transport and control plane name spaces with 553 the (out-of-band) TRACE object (see [LMP-TEST]). The LMP TRACE 554 object allows transport plane names to be associated with interface 555 identifiers [LMP-TEST]. 557 Aspects of LMP link verification appear similar to G.7714.1 558 discovery, however the two procedures are different. G.7714.1 559 provides discovery of the transport plane layer adjacencies. It 561 Aboul-magd Expires January 2005 11 562 provides a generic procedure to discover the connectivity of two end 563 points in the transport plane. Whereas, LMP link verification 564 procedure is a control plane driven procedure and assumes either (1) 565 a priori knowledge of the associated data plane's local and remote 566 end point connectivity and Interface_IDs (e.g. via management plane 567 or use of G.7714.1), or (2) support of the remote node for 568 associating the data interface being verified with the content of 569 the TRACE object (inferred mapping). For SONET/SDH transport 570 networks, LMP verification uses the SONET/SDH Trail Trace identifier 571 (see [G.783]). 573 G.7714.1 supports the use of transport plane discovery independent 574 of the platform using the capability. Furthermore G.7714.1 specifies 575 the use of a Discovery Agent could be located in an external system 576 and the need to support the use of text-oriented man-machine 577 language to provide the interface. Therefore, G.7714.1 limits the 578 discovery messages to printable characters defined by [T.50] and 579 requires Base64 encoding for the TCP-ID and DA ID. External name- 580 servers may be used to resolve the G.7714.1 TCP name, allowing the 581 TCP to have an IP, NSAP or any other address format. Whereas, LMP is 582 based on the use of an IP-based control plane, and the LMP interface 583 ID uses IPv4, IPv6, or unnumbered interface IDs. 585 6.4 Comparing LMP and G.8080 587 LMP exists to support GMPLS TE link discovery. In section 5.2.1 we 588 elaborated on the definition of the TE link. LMP enables the aspects 589 of TE links to be discovered, and delivered to the control plane, 590 more specifically the routing plane. G.8080 and G.7714 are agnostic 591 to the type of control plane and discovery protocol used. LMP is a 592 valid realization of a control plane discovery process under a 593 G.8080 model. 595 G.7714 specifies transport plane discovery with respect to the 596 transport layer CTPs or TCPs using ASON conventions and naming for 597 the elements of the ASON control plane and the ASON management 598 plane. This discovery supports a centralized management model of 599 configuration as well as a distributed control plane model, in other 600 words discovered items can be reported to the management plane or 601 the control plane. G.7714.1 provides one realization of a transport 602 plane discovery process. 604 Today LMP and G.7714, G7714.1 are defined in different Standards 605 Organizations. They have evolved out of different naming schemes 606 and architectural concepts. Whereas G.7714.1 supports a transport 607 plane layer adjacency connectivity verification which can be used by 608 a control plane or a management plane, LMP is a control plane 609 procedure for managing GMPLS TEs (GMPLS�s control plane 610 representation of the transport plane connections). 612 Aboul-magd Expires January 2005 12 613 7. Security Considerations 615 Since this draft is purely descriptive in nature it does not 616 introduce any security issues. 618 G.8080 and G.7714/G.7714.1 provide security as associated with the 619 Data Communications Network on which they are implemented. 621 LMP is specified using IP which provides security mechanisms 622 associated with the IP network on which it is implemented. 624 8. References 626 8.1 Normative References 628 [RFC2026] S.Bradner, "The Internet Standards Process -- 629 Revision3", BCP 9, RFC 2026, October 1996. 631 [RFC3668] S. Bradner, "Intellectual Property Rights in IETF 632 Technology", BCP 79, RFC 3668, February 2004. 634 8.2 Informational References 636 [LMP] J.P.Lang (Editor), "Link Management Protocol," draft- 637 ietf-ccamp-lmp-10.txt, October 2003. 639 [LMP-TEST] J.P.Lang et al., "SONET/SDH Encoding for Link 640 Management Protocol (LMP) Test messages," draft-ietf- 641 draft-ietf-ccamp-lmp-test-sonet-sdh-04.txt, December 642 2004. 644 [GMPLS-ARCH] Eric Mannie (Editor), "Generalized Multi-protocol Label 645 Switching Architecture," draft-ietf-ccamp-gmpls- 646 architecture-07.txt, May 2003. 648 [RFC 3471] Lou Berger (Editor), "Generalized Multi-Protocol Label 649 Switching (GMPLS)Signaling Functional Description," 650 draft-ietf-ccamp-gmpls-architecture-07.txt, May 2003. 652 [GMPLS-RTG] K. Kompella & Y. Rekhter (editors) "Routing Extensions 653 in Support of Generalized Multi-Protocol Label 654 Switching", draft-ietf-ccamp-gmpls-routing-09.txt, 655 December 2003. 657 [HIER] K. Kompella & Y. Rekhter " LSP Hierarchy with Generalized 658 MPLS TE", draft-ietf-mpls-lsp-hierarchy-08.txt, 659 September 2002 661 [BUNDLE] K. Kompella, Y. Rekhter, Lou Berger "Link Bundling in MPLS 662 Traffic Engineering", draft-ietf-mpls-bundle-04.txt, 663 July 2002 665 Aboul-magd Expires January 2005 13 666 "For information on the availability of ITU Documents, please see 667 http://www.itu.int" 669 [G.783] ITU-T G.783 (2004), Characteristics of synchronous 670 digital hierarchy (SDH) equipment functional blocks. 672 [G.805] ITU-T G.805 (2000), Generic functional architecture of 673 transport networks. 675 [G.7714] ITU-T G.7714/Y.1705 (2001), Generalized automatic 676 discovery techniques. 678 [G.7714.1] ITU-T G.7714.1/Y.1705.1 (2003), Protocol for automatic 679 discovery in SDH and OTN networks. 681 [G.8080] ITU-T G.8080/Y.1304 (2001), Architecture for the 682 automatically switched optical network (ASON). 684 [M.3100] ITU-T M.3100 (1995), Generic Network Information Model 686 [T.50] ITU-T T.50 (1992), International Reference Alphabet 688 9. Acknowledgements 690 The authors would like to thank Astrid Lozano, John Drake, Adrian 691 Farrel and Stephen Shew for their valuable comments. 693 10. Author's Addresses 695 Osama Aboul-Magd 696 Nortel Networks 697 P.O. Box 3511, Station 'C' 698 Ottawa, Ontario, Canada 699 K1Y-4H7 700 Phone: +1 613 763-5827 701 Email: osama@nortelnetworks.com 703 Don Fedyk 704 Nortel Networks 705 600 Technology Park Drive 706 Billerica, MA, 01821 707 Email: dwfedyk@nortelnetworks.com 709 Deborah Brungard 710 AT&T 711 Rm. D1-3C22 712 200 S. Laurel Ave. 713 Middletown, NJ 07748, USA 714 Email: dbrungard@att.com 716 Aboul-magd Expires January 2005 14 717 Jonathan P. Lang 718 Sonos, Inc. 719 506 Chapala Street 720 Santa Barbara, CA 93101 721 Email : jplang@ieee.org 723 Dimitri Papadimitriou 724 Alcatel 725 Francis Wellesplein, 1 726 B-2018 Antwerpen, Belgium 727 Phone: +32 3 240-84-91 728 Email: dimitri.papadimitriou@alcatel.be 730 Aboul-magd Expires January 2005 15 731 Full Copyright Statement 733 "Copyright (C) The Internet Society (2004). This document is 734 subject to the rights, licenses and restrictions contained in BCP 735 78, and except as set forth therein, the authors retain all their 736 rights." 738 "This document and the information contained herein are provided on 739 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 740 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 741 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 742 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 743 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 744 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 746 Aboul-magd Expires January 2005 16