idnits 2.17.1 draft-many-oli-reqts-00.txt: -(268): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(574): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(585): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(598): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 are 22 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (June 2001) is 8348 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'GMPLS-RSVP' is mentioned on line 338, but not defined == Unused Reference: 'LMP-WDM' is defined on line 593, but no explicit reference was found in the text == Unused Reference: 'NTIP' is defined on line 598, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. 'GMPLS-ARCH' == Outdated reference: A later version (-19) exists of draft-ietf-isis-gmpls-extensions-02 ** Downref: Normative reference to an Informational draft: draft-ietf-isis-gmpls-extensions (ref. 'GMPLS-ISIS') == Outdated reference: A later version (-07) exists of draft-ietf-mpls-generalized-cr-ldp-01 == Outdated reference: A later version (-02) exists of draft-kompella-ospf-gmpls-extensions-01 -- Possible downref: Normative reference to a draft: ref. 'GMPLS-OSPF' == Outdated reference: A later version (-09) exists of draft-ietf-mpls-generalized-signaling-02 -- Possible downref: Normative reference to a draft: ref. 'LMP' == Outdated reference: A later version (-03) exists of draft-fredette-lmp-wdm-01 -- Possible downref: Normative reference to a draft: ref. 'LMP-WDM' == Outdated reference: A later version (-01) exists of draft-sahay-ccamp-ntip-00 -- Possible downref: Normative reference to a draft: ref. 'NTIP' Summary: 7 errors (**), 0 flaws (~~), 11 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Osama Aboul-Magd (Nortel Networks) 3 Internet Draft Curtis Brownmiller (WorldCom) 4 Expiration Date: December 2001 Sudheer Dharanikota (Nayna Networks) 5 Naganand Doraswamy (PhotonEx Corp.) 6 John Drake (Calient Networks) 7 Georgios Ellinas (Tellium) 8 Rohit Goyal (Axiowave Networks) 9 Riad Hartani (Caspian Networks) 10 Bilel Jamoussi (Nortel Networks) 11 John Labourdette (Tellium) 12 Jonathan Lang (Calient Networks) 13 Eric Mannie (Ebone (GTS)) 14 Babu Narayanan (Nortel Networks) 15 Dimitri Papadimitriou (Alcatel IPO-NSG) 16 Bala Rajagopalan (Tellium) 17 Rajiv Ramaswami (Nortel Networks) 18 Vasant Sahay (Nortel Networks) 19 Ed Snyder (PhotonEx Corp.) 20 Yong Xue (UUNET/WorldCom) 22 Editor: Andre Fredette (PhotonEx Corp.) 24 June 2001 26 TITLE: Optical Link Interface Requirements 28 draft-many-oli-reqts-00.txt 30 Status of this Memo 32 This document is an Internet-Draft and is in full conformance with 33 all provisions of Section 10 of RFC2026 [RFC2026]. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF), its areas, and its working groups. Note that 37 other groups may also distribute working documents as Internet- 38 Drafts. 40 Internet-Drafts are draft documents valid for a maximum of six 41 months and may be updated, replaced, or obsoleted by other documents 42 at any time. It is inappropriate to use Internet- Drafts as 43 reference material or to cite them other than as "work in progress." 45 The list of current Internet-Drafts can be accessed at 46 http://www.ietf.org/ietf/1id-abstracts.txt 48 The list of Internet-Draft Shadow Directories can be accessed at 49 http://www.ietf.org/shadow.html. 51 ABSTRACT 52 The emergence of transparent optical switches, together with a 53 movement towards more dynamic, multi-vendor networks, has introduced 54 a need for information sharing between optical line systems and 55 client devices. The information that needs to be shared includes 56 link status and link properties. We call this interface the Optical 57 Link Interface (OLI). In this document, we provide high-level 58 requirements for the OLI. 60 CONTENTS 61 ABSTRACT...........................................................2 62 CONTENTS...........................................................2 63 SUMMARY FOR SUB-IP RELATED INTERNET DRAFTS.........................3 64 1. Introduction and Overview.......................................5 65 2. Fault Detection and Notification for PXCs.......................7 66 3. Discovery of Link Properties....................................7 67 4. Requirements for the Optical Link Interface.....................8 68 4.1. OLI General Principles........................................8 69 4.2. General OLI Characteristics...................................9 70 4.3. OLI Functionality.............................................9 71 4.3.1. Neighbor Discovery..........................................9 72 4.3.2. Control Channel Maintenance................................10 73 4.3.3. OLI Synchronization........................................10 74 4.3.4. Connectivity Discovery.....................................10 75 4.3.5. Fault Management...........................................10 76 4.3.5.1. Fault Notification.......................................11 77 4.3.5.2. Trace Monitoring.........................................11 78 4.3.5.3. Alarm Suppression........................................12 79 4.3.6. Link Property Information..................................12 80 5. References.....................................................14 81 6. Author Contact Information.....................................15 83 SUMMARY FOR SUB-IP RELATED INTERNET DRAFTS 84 (Section Requested by Bert and Scott) 86 The emergence of transparent optical switches, together with a 87 movement towards more dynamic, multi-vendor networks, has introduced 88 a need for information sharing between optical line systems and 89 client devices. The information that needs to be shared includes 90 link status and link properties. We call this interface the Optical 91 Link Interface (OLI). In this document, we provide high-level 92 requirements for the OLI. 94 This work is motivated by two main issues. The first is the need to 95 enhance the fault detection and recovery support for photonic 96 switches (PXCs), and the second is to enhance the discovery of link 97 characteristics for optical networks in general. These issues are 98 discussed separately in this document. We then provide more 99 specific requirements for an interface between the optical line 100 system (OLS) and OLS client proposed to solve these issues called 101 the Optical Link Interface (OLI). 103 NOTE: This document was requested by the CCAMP co-chairs based on 104 discussions regarding the below mentioned drafts at the last two 105 IETF meetings. 107 RELATED DOCUMENTS 109 http://www.ietf.org/internet-drafts/draft-fredette-lmp-wdm-01.txt 110 http://www.ietf.org/internet-drafts/draft-sahay-ccamp-ntip-00.txt 111 http://www.ietf.org/internet-drafts/draft-ietf-mpls-lmp-02.txt 113 WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK 115 A protocol that would satisfy the OLI requirements would fit in the 116 Control part of the sub-ip work. 118 WHY IS IT TARGETED AT THIS WG 120 An OLI would enhance the ability of circuit switches and routers 121 using MPLS-based control protocols to dynamically discover link 122 properties and to learn about link status. The link properties can 123 be useful during signalling of paths, and the link status 124 information is essential for fault detection and recovery. 125 Furthermore, the OLI is independent of any signalling protocol, so 126 it can be used by both distributed control system, such as GMPLS, 127 and centralized management systems. 129 Therefore, an OLI would support the following CCAMP objectives: 131 . Define signalling protocols and measurement protocols such that 132 they support multiple physical path and tunnel technologies 133 (e.g. O-O and O-E-O optical switches, ATM and Frame Relay 134 switches, MPLS, GRE) using input from technology-specific 135 working groups such as MPLS, IPO, etc. 137 . Define signalling and measurement protocols that are 138 independent of each other. This allows applications other than 139 the signalling protocol to use the measurement protocol; it 140 also allows the signalling protocol to use knowledge obtained 141 by means other than the measurement protocol. 143 . Abstract link and path properties needed for link and path 144 protection. Define signalling mechanisms for path protection, 145 diverse routing and fast path restoration. Ensure that multi- 146 layer path protection and restoration functions are achievable 147 using the defined signalling and measurement protocols, either 148 separately or in combination. 150 . Define how the properties of network resources gathered by the 151 measurement protocol can be distributed in existing routing 152 protocols, such as OSPF and IS-IS. 154 JUSTIFICATION 156 draft-fredette-lmp-wdm-01.txt (lmp-wdm) and draft-sahay-ccamp-ntip- 157 00.txt (ntip) are both protocol proposals to satisfy the OLI 158 requirements. lmp-wdm has been discussed in the past two ccamp 159 sessions and ntip was discussed in the last one. There has been a 160 great deal of interest in this work by both network operators and 161 vendors. Given the competing proposals and some general questions 162 about the specific requirements that the proposals were intended to 163 solve, the CCAMP co-chairs asked the authors of lmp-wdm and ntip 164 (and other interested people) to work together on a set of 165 requirements. This document describes those requirements. 167 1. Introduction and Overview 169 Optical networks being deployed today consist of the following three 170 basic types of devices: service delivery platforms (e.g., routers, 171 ATM switches, and SONET/SDH devices), optical switches (OXCs), and 172 Optical Line Systems (OLSs), as shown in Figure 1. 174 +-OLI-+ +-OLI-+ 175 | | | | 176 | +-------------------------+ | 177 +----+ |+----+ OLS +----+| +----+ 178 SONET--| |--|| | +---+ +---+ | ||--| |--SONET 179 ATM--|OXC1|--||DWDM|=|Amp|=|Amp|=|DWDM||--|OXC2|--ATM 180 Router��| |--|| 1 | +---+ +---+ | 2 ||--| |--Router 181 | +----+ |+----+ +----+| +----+ | 182 | | | +-------------------------+ | | | 183 | | | | | | 184 +-LMP-+ +---------------LMP---------------+ +-LMP-+ 186 Figure 1: Optical Network 188 Before continuing, a few definitions are provided to describe 189 salient information about the above network. 191 . Opaque Device: 192 A device that terminates a connection electrically. An opaque 193 device is sometimes called an O-E-O device because it receives 194 an optical signal, converts it to an electrical signal, then 195 regenerates a new optical signal. It is also usually must be 196 aware of the type of traffic and bandwidth being carried and 197 has a specific physical interface for that type of traffic and 198 bandwidth. An example is a SONET or SDH device. 200 . Transparent Optical Device: 201 A device that transmits/propagates an optical signal without 202 terminating it. These devices are sometimes referred to as O- 203 O-O devices, because they receive an optical signal, switch it 204 optically, then transmit the same optical signal without ever 205 converting it to an electrical signal. An example is a MEMS- 206 based photonic switch in which both the interfaces and 207 switching fabric are transparent. Transparent devices, in 208 theory, can operate independent of traffic type and bandwidth. 210 . Optical Cross Connect (OXC): 211 A cross connect that switches optical connections. The term 212 OXC is used as a generic term that may apply to both opaque and 213 transparent devices. Whenever the material applies to both 214 opaque and transparent devices, we use the term OXC, as opposed 215 to the more specific PXC term defined below. 217 . Photonic Cross Connect (PXC): 218 A transparent OXC. An example is a MEMS-based photonic switch 219 in which both the interfaces and switching fabric are 220 transparent. Whenever the material in this document applies 221 specifically to transparent devices, we used the term PXC, as 222 opposed to the more generic term OXC defined above. 224 . Optical Line System (OLS): 225 An optical line system is used to transmit data over long 226 distances. There are various classes including long-haul, 227 ultra-long haul, metro, however, we do not differentiate 228 between the classes in this document. Most OLSs being deployed 229 today use wave division multiplexing (WDM), or dense division 230 multiplexing (DWDM) techniques to multiplex many channels over 231 a single pair of fibers. Therefore, the OLS is also commonly 232 referred to as a DWDM transmission system. An OLS typically 233 contains multiple types of nodes including DWDM and Optical 234 Amplifier (OA) nodes. Although an OLS contains multiple nodes, 235 they work as a single system, and for the purposes of this 236 document, we treat the OLS as a single system. Note that an 237 OLS may be either opaque or transparent, however, in this 238 document we only address opaque OLSs. 240 . OLS Client: 241 Any device that attaches to an OLS for the purpose of using its 242 data transmission services. An OLS client may be either opaque 243 or transparent. In Figure 1, the OXC is shown as an OLS client 244 with the service delivery platforms connected to the OXC; 245 however, the service delivery platforms may also be direct OLS 246 clients. Whenever the material in this document applies to any 247 OLS client, we use this most general term. 249 . Link: 250 The term link refers to a circuit or logical connection between 251 two peer OLS clients. The OLS transmits the data on a link 252 between the two peer OLS clients. A link may be uni- 253 directional or bi-directional. 255 . Port: 256 Place where an OLS client attaches to an OLS. A link requires 257 that both OLS clients are attached to corresponding ports on 258 the OLS. 260 This work is motivated by two main issues. The first is the need to 261 enhance the fault detection and recovery support for PXCs, and the 262 second is to enhance the discovery of link characteristics for 263 optical networks in general. These issues are discussed separately 264 below. We then provide more specific requirements for an interface 265 between the OLS and OLS client proposed to solve these issues called 266 the Optical Link Interface (OLI). 268 DISCLAIMER: The name �OLI�, introduced in [OIF2000.254], has been 269 chosen due to the lack of a better name at this time. Not all of 270 the co-authors agree on the name OLI. 272 2. Fault Detection and Notification for PXCs 274 Standard SONET/SDH equipment provides extensive fault detection, 275 reporting and handling capabilities. These SONET/SDH standards can 276 be employed by opaque devices using SONET/SDH overhead messaging; 277 however, as networks transition to the use of more transparent 278 optical networking devices, such as PXCs, access to the SONET/SDH 279 overhead may not exist in every node. Once a connection is 280 established, PXCs have only limited visibility into the health of 281 the connection. Even though the PXC is all-optical, an opaque OLS 282 terminates channels electrically and regenerate them optically, 283 which presents an opportunity to monitor the health of a channel 284 between PXCs. The elements of an OLS also typically communicate 285 over an internal control channel. This can provide a system wide 286 view of OLS client-to-client link health. In a sense, the OLI 287 allows the OLSs to become the �eyes and the ears� of the PXC. 289 The typical OLS located between a pair of PXCs monitors for 290 degradation and faults along the entire fiber path. Expensive 291 electronic circuitry monitors such degradations at the SONET/SDH and 292 wavelength level at various points along the fiber path. Repeaters 293 and Amplifiers detect fiber cuts and pass along the information to 294 other equipment along the path. SONET/SDH-level failures can be 295 detected as well. To use the SONET/SDH-level fault reporting 296 methods, all devices require the expensive electronic circuitry. A 297 PXC can avoid the use of SONET/SDH circuitry to provide a more cost 298 effective solution. In this perspective, an OLI between the OLS and 299 PXC can provide the same fault information to a non-SONET/SDH 300 client, while reducing the cost of that client, and, therefore 301 overall network cost. 303 3. Discovery of Link Properties 305 The establishment of connections in an optical network may be 306 accomplished either through a centralized management system or a 307 distributed control system, such as GMPLS. 309 A great deal of information about a link between two clients is 310 known by the OLS. Exposing this information to the control plane 311 can improve network usability by further reducing required manual 312 configuration and also greatly enhancing fault detection and 313 recovery. 315 The configuration and management of today�s transport networks are 316 largely driven by significant human intervention, which increases 317 the time to turn up revenue generating services and is prone to 318 errors and inefficiencies. Even where management systems provide 319 automation for some provisioning and management tasks, the 320 management systems are still largely proprietary and cumbersome. 321 Furthermore, optical networks are more commonly being deployed with 322 equipment from multiple vendors which further burdens the user with 323 multiple management systems. A standard interface between the OLS 324 and its clients can simplify the users job by allowing some 325 provisioning functions to be accomplished by just the client 326 management application. 328 The Generalized Multi-protocol Label Switching (GMPLS) body of work 329 [GMPLS-ARCH] is being specified in the IETF to provide a standard 330 automated and distributed IP control plane for optical networks. 331 The use of GMPLS will enable the dynamic provisioning of resources 332 and provide network survivability using protection and restoration 333 techniques. The main intent of GMPLS is to make optical networks 334 more manageable, scalable and efficient, while maintaining or 335 improving on their current high availability characteristics. GMPLS 336 protocols define standard control interfaces between service 337 delivery platforms and OXCs to exchange routing [GMPLS-OSPF, GMPLS- 338 ISIS] and signaling [GMPLS-SIG, GMPLS-RSVP, GMPLS-LDP] information, 339 and perform link management functions [LMP]. An interface with the 340 OLS can allow GMPLS devices to automatically learn information about 341 the links, and therefore, will reduce required manual configuration. 343 4. Requirements for the Optical Link Interface 345 In this section we define more specific requirements for an Optical 346 Link Interface (OLI) between the OLS and its clients. As described 347 above, the OLI is required to provide fast failure detection and 348 notification for PXCs, as well as to provide much-needed information 349 for the operation of both centralized and GMPLS-controlled optical 350 networks. 352 4.1. OLI General Principles 354 . In optical networks there will be a management plane and a 355 control plane. The fundamental purpose of the control plane is 356 to accurately and rapidly create, maintain, and delete 357 connections within the optical network; while the purpose of 358 the management plane is to provide operators with capabilities 359 such as root cause analysis, service definition, and SLA 360 verification. The OLI is targeted at the information that is 361 required for the control plane to accomplish its task. 363 . The OLI should be a simple protocol mechanism for reporting the 364 health and properties of OLSs based on a well-defined set of 365 parameters. 367 . The OLI-defined parameters should be accessible via query by 368 both the control and the management plane of the network 369 regardless of the architecture used (i.e., distributed or 370 centralized). 372 . The OLI should be extensible so that we can start with a set of 373 most-needed parameters initially, and be able to extend later 374 by adding new parameter types and new parameters within a type. 375 In particular, the initial focus is on opaque OLSs. However, 376 the OLS should be extensible for use with all optical networks 377 containing PXCs and transparent OLSs. 379 . The initial focus of the OLI is on SONET and SDH equipment. 380 However, the OLI must be extensible to support other types of 381 equipment such as Ethernet and G.709. 383 . All the intelligence such as data collection, analysis, 384 triggering, routing decisions, etc. should reside in the 385 network control and management plane functions. What and how 386 the OLI-parameters are used is totally up to the control and 387 management plane design. In effect, this will allow OLI to be 388 decoupled from any particular control plane protocol such as 389 GMPLS. 391 . In general, care must be taken to make the OLI implementable on 392 existing OLS hardware, while still being flexible enough to 393 allow enhanced operations with future generations of OLS 394 hardware. This desire may make it necessary to specify some 395 optional OLI features. 397 4.2. General OLI Characteristics 399 . The OLI must be reliable. 401 . The OLI must provide security measures. 403 . The OLI must not assume a one-to-one relationship between OLS 404 and client. I.e., an OLS client will most likely be attached 405 to multiple different OLSs, and a single OLS may have multiple 406 different clients at a single location. 408 4.3. OLI Functionality 410 4.3.1. Neighbor Discovery 411 . It should be possible for adjacent nodes to use the OLI with as 412 little configuration as possible. 414 . The OLI should support discovery and negotiation of optional 415 features. 417 4.3.2. Control Channel Maintenance 419 . The OLI must support the use of out-of-band communications for 420 all messages (except for the specific in-band signals for 421 connectivity discovery described in Section 4.3.4). 422 . The OLI must provide a mechanism to maintain the OLI 423 session/control channel between neighboring nodes. For 424 example, a simple hello or keep-alive protocol could be used. 425 If a session fails it should be reestablished and the 426 information should be resynchronized as described in Section 427 4.3.3. 429 4.3.3. OLI Synchronization 431 . The OLI must specify a process for the OLS and OLS client to 432 resynchronize if the session is disrupted for any reason (such 433 as a reboot or temporary loss of control channel connectivity). 435 . The resynchronization process should be defined such that the 436 OLS does not need to remember the instructions issued by the 437 OLS client. The client should re-issue the 438 instructions/commands to OLS during the resynchronization. 440 4.3.4. Connectivity Discovery 442 . The OLI must provide a protocol including in-band signals for 443 auto discovery of optical connectivity. 445 . The OLI must support control over link transparency. 447 Link transparency control is used by OLS clients to control whether 448 the OLS terminates the in-band messages, or allows them to pass 449 through so that the OLS client can discover its peer at a higher 450 layer. 452 4.3.5. Fault Management 454 . Fault reporting must be both event-driven and available on 455 request (e.g., polling). 457 . The defect notification must be fast enough to support switch 458 times in the range of a few 10�s of milliseconds. 460 Note: The OLS does not participate in end-to-end fault isolation. 462 It is the role of the control plane to determine whether switching 463 is done on the section or path level and to make the protection 464 switching decisions. 466 . The OLI should support the aggregation of fault reporting. For 467 example, the failure of a single fiber could cause the failure 468 of 100�s to 1000�s of ports simultaneously. If possible, it 469 would be better to send a single message to report all 470 failures. 472 4.3.5.1. Fault Notification 474 At a minimum, the following fault granularity must be provided: 476 . Signal Okay (OK): Port is operational. 478 . Signal Fail (SF): A hard signal failure including (but not 479 limited to) loss of signal (LOS), loss of frame (LOF), Line 480 AIS, or a BER (BIP-8 measure through B1/B2) exceeding a 481 specified value. 483 . Signal Degrade (SD): A soft failure caused by a BER exceeding a 484 preselected threshold. The specific BER used to define the 485 threshold is may be configured, but is typically in the range 486 of 10-5 to 10-9. 488 . It should be possible to negotiate a line behavior for the 489 above failures. For example, it may be more advantageous to a 490 PXC for the OLS to turn off its laser than to insert AIS-L when 491 a failure is detected. 493 . It is expected that the thresholds necessary (e.g., BER) for 494 detecting the above failures are provisioned at the OLS. It 495 may also be useful to support the negotiation of some of these 496 thresholds. 498 4.3.5.2. Trace Monitoring 500 Trace monitoring is an important feature, especially for PXCs. The 501 trace monitoring features described in this section, allow the PXC 502 to do basic trace monitoring on circuits by using the capabilities 503 on the attached OLSs 505 . It must be possible for an OLS Client to request the OLS to 506 monitor a link for a specific pattern in the overhead. An 507 example of this overhead is the SONET Section Trace message 508 transmitted in the J0 byte. If the actual trace message does 509 not match the expected trace message, the OLS must report the 510 mismatch condition. 512 . It must be possible for an OLS client to request the value of 513 the current trace message on a given port. 515 . It should be possible for an OLS client to request the OLS to 516 insert a trace message. It is optional for an OLS to provide 517 this service. 519 4.3.5.3. Alarm Suppression 521 . It must be possible to enable a port in an unequipped state on 522 an OLS, but suppress alarms. This allows the OXC to have a 523 port/wavelength ready, but not necessarily operational. 525 4.3.6. Link Property Information 527 The link property advertisement provides information known to 528 transport systems that would otherwise need to be configured at the 529 OLS client. Link properties, in general, constitute the information 530 needed by the control plane for constraint-based routing and 531 connection establishment. Additionally, the information advertised 532 in the Link Property advertisement is intended to be more-or-less 533 static, as opposed to the more dynamic information available in the 534 Performance Information Advertisement described in the next section. 536 The OLI should provide a mechanism for advertising the following 537 information: 539 . Link Descriptor 541 . Signal Type: The overhead termination type (e.g., STM-16 or 542 OC-48). 544 . Bandwidth Encoding: Bandwidth supported on the link. 546 . Shared Risk Link Group Identifier (SRLG): SRLGs to which the 547 link is a member. This information may be manually configured 548 on the OLS by the service providers. It may also be derived 549 based on information known to the OLS (e.g., all circuits 550 sharing a single fiber). The SRLG can be used for diverse path 551 computation. See [GMPLS-OSPF] or [GMPLS-ISIS] for more details 552 on SRLGs. 554 . Span Length: Distance of fiber in the OLS. May be used as a 555 routing metric or to estimate delay. This value may either be 556 estimated by the OLS, or provisioned at the OLS. 558 . Administrative Group (Color). 560 5. References 562 [GMPLS-ARCH] E. Mannie, Editor, �Generalized Multi-Protocol Label 563 Switching (GMPLS) Architecture�, Internet Draft, 564 draft-many-gmpls-architecture-00.txt, (work in 565 progress), February 2001. 567 [GMPLS-ISIS] Kompella, K., Rekhter, Y., Banerjee, A., Drake, J., 568 Bernstein, G., Fedyk, D., Mannie, E., Saha, D., and 569 Sharma, V., �IS-IS Extensions in Support of 570 Generalized MPLS�, Internet Draft, draft-ietf-isis- 571 gmpls-extensions-02.txt, (work in progress), February 572 2001. 574 [GMPLS-LDP] Ashwood-Smith, P. et al, �Generalized MPLS Signaling - 575 CR-LDP Extensions�, Internet Draft, draft-ietf-mpls- 576 generalized-cr-ldp-01.txt, (work in progress), 577 February 2001. 579 [GMPLS-OSPF] Kompella, K., et. al, �OSPF Extensions in Support of 580 Generalized MPLS�, Internet Draft, draft-kompella- 581 ospf-gmpls-extensions-01.txt, (work in progress), 582 February 2001. 584 [GMPLS-SIG] Berger, L., Ashwood-Smith, Peter, editors, 585 �Generalized MPLS - Signaling Functional Description�, 586 Internet Draft, draft-ietf-mpls-generalized-signaling- 587 02.txt, (work in progress), March 2001. 589 [LMP] Lang, J., et. al, �Link Management Protocol (LMP)�, 590 Internet Draft, draft-ietf-mpls-lmp-02.txt, (work in 591 progress), March 2001. 593 [LMP-WDM] A. Fredette, et al., �Link Management Protocol (LMP) 594 for WDM Transmission Systems,� Internet Draft, draft- 595 fredette-lmp-wdm-01.txt, (work in progress), March 596 2001. 598 [NTIP] V. Sahay et al., �Network Transport Interface Protocol 599 (NTIP) for Photonic Cross Connects (PXC),� Internet 600 Draft, draft-sahay-ccamp-ntip-00.txt, (work in 601 progress), February 2001. 603 [OIF2000.254] Drake, J., Blumenthal, D., Ceuppens, L., et al., 604 �Interworking between Photonic (Optical) Switches and 605 Transmission Systems over Optical Link Interface (OLI) 606 using Extensions to LMP�, OIF Contribution 607 oif2000.254, (work in progress), November 2000. 609 [RFC2026] Bradner, S., "The Internet Standards Process -- 610 Revision 3," BCP 9, RFC 2026, October 1996. 612 6. Author Contact Information 614 Osama Aboul-Magd John Labourdette 615 Nortel Networks Tellium 616 osama@nortelnetworks.com jlabourdette@tellium.com 618 Curtis Brownmiller Jonathan Lang 619 WorldCom Calient Networks 620 Curtis.Brownmiller@wcom.com jplang@calient.net 622 Sudheer Dharanikota Eric Mannie 623 Nayna Networks Ebone (GTS) 624 sudheer@nayna.com Eric.Mannie@ebone.com 626 John Drake Babu Narayanan 627 Calient Networks Nortel Networks 628 jdrake@calient.net bon@nortelnetworks.com 630 Naganand Doraswamy Dimitri Papadimitriou 631 PhotonEx Corp. Alcatel IPO-NSG 632 naganand@photonex.com dimitri.papadimitriou@alcatel.be 634 Georgios Ellinas Bala Rajagopalan 635 Tellium Tellium 636 gellinas@tellium.com BRaja@tellium.com 638 Andre Fredette Rajiv Ramaswami 639 PhotonEx Corp. Nortel Networks 640 fredette@photonex.com rajiv@nortelnetworks.com 642 Rohit Goyal Vasant Sahay 643 Axiowave Networks Nortel Networks 644 rgoyal@axiowave.com vasants@nortelnetworks.com 646 Riad Hartani Ed Snyder 647 Caspian Networks PhotonEx Corp. 648 rhartani@caspiannetworks.com esnyder@photonex.com 650 Bilel Jamoussi Yong Xue 651 Nortel Networks UUNET/WorldCom 652 jamoussi@nortelnetworks.com yxue@UU.NET