idnits 2.17.00 (12 Aug 2021) /tmp/idnits528/draft-wang-ospf-isis-lambda-te-routing-00.txt: 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? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 11 longer pages, the longest (page 5) being 61 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 12 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([ISIS], [OSPF]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (March 2000) is 8095 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: 'CR-LDP' is mentioned on line 112, but not defined == Missing Reference: 'RSVP' is mentioned on line 112, but not defined == Missing Reference: 'METRIC' is mentioned on line 247, but not defined ** Obsolete normative reference: RFC 1583 (ref. 'OSPF') (Obsoleted by RFC 2178) ** Obsolete normative reference: RFC 2370 (ref. 'OPA') (Obsoleted by RFC 5250) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISIS' -- Possible downref: Non-RFC (?) normative reference: ref. 'OSPFTE' == Outdated reference: draft-ietf-isis-traffic has been published as RFC 3784 ** Downref: Normative reference to an Informational draft: draft-ietf-isis-traffic (ref. 'ISISTE') -- Possible downref: Normative reference to a draft: ref. 'Signal' == Outdated reference: A later version (-06) exists of draft-ietf-mpls-te-feed-00 -- Possible downref: Normative reference to a draft: ref. 'Sigarch' == Outdated reference: A later version (-01) exists of draft-fedyk-isis-ospf-te-metrics-00 -- Possible downref: Normative reference to a draft: ref. 'Metric' -- Possible downref: Normative reference to a draft: ref. 'OLXC' Summary: 9 errors (**), 0 flaws (~~), 8 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Guoqiang Wang, Don Fedyk (Nortel Networks) 2 Internet Draft Vishal Sharma, Ken Owens (Tellabs) 3 Gerald R. Ash (AT&T) 4 Murali Krishnaswamy, Yang Cao (Lucent Technologies) 5 M.K. Girish (SBC Technology Resources, Inc.) 6 Expiration September 2000 Herbert M. Ruck (Packet Network Services) 7 Simon Bernstein, Phuc Nquyen (Global One) 8 Sunil Ahluwalia (Trillium Digital Systems) 9 Lihshin Wang(Qwest Communications) 10 Avri Doria (Nokia Telecommunications) 11 Heinrich Hummel (Siemens AG) 13 March 2000 15 Extensions to OSPF/IS-IS for Optical Routing 17 draft-wang-ospf-isis-lambda-te-routing-00.txt 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. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six 30 months and may be updated, replaced, or obsoleted by other documents 31 at any time. It is inappropriate to use Internet- Drafts as 32 reference material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 Abstract 42 Real-time optical path setup is the fundamental requirement for 43 agile optical networks and dynamic routing is a mechanism to 44 propagate optical state information and calculate the available 45 paths. OSPF/IS-IS are defined in [OSPF][ISIS]as an IGP routing 46 protocol and this draft specifies the extensions to OSPF/IS-IS for 47 support optical path routing computation. 49 Wang et al. draft 1 50 Table of Contents 52 1. Introduction 53 1.1 Agile Optical Networks 54 1.2 Optical Path Granularity 55 2. Optical LSA 56 2.1 Optical LSA Header 57 2.2 Optical LSA Payload 58 3. Significant Change 59 4. Path Selection 60 5. For Further Study 61 6. Security Considerations 62 7. References 63 8. Acknowledgements 64 9. Authors' Addresses 66 1. Introduction 68 Recently, there has been an increasing interest in agile optical 69 networks. An agile optical network is an optical network with fast 70 end-to-end optical path setup and restoration. One way to quickly 71 set up an optical path through an agile optical network is to use 72 dynamic routing together with signaling. The routing is used to 73 collect network resource and connectivity information, pass state 74 information around and compute the paths from one node to the other 75 nodes. The signaling is used to setup, maintain and tear down the 76 paths. OSPF is defined in [OSPF] and has been widely deployed 77 throughout the Internet as an Interior Gateway Protocol (IGP). IS-IS 78 is defined in [ISIS] and has been deployed in many large networks as 79 an IGP. OSPF/IS-IS has been extended to allow for the future 80 extensibility [OPA] and add traffic engineering capability 81 [OSPFTE][ISISTE][Metric]. This draft extends the optical Link State 82 Advertisement (LSA) to OSPF/IS-IS for support optical path routing 83 computation. Note: For the purpose of this document, an LSA is 84 synonymous with an IS-IS Link State Protocol Data Unit or (LSP). 85 Since this acronym is easily confused with a Label Switched Path, we 86 will use the term LSA to mean generically both OSPF and IS-IS 87 advertisements. In the OSPF case the optical LSA makes use of type 88 10 opaque LSA. 90 Wang et al. Expires September 2000 2 91 The components that make up the Optical path selection are 92 illustrated in Figure 1. 94 +--------+ +--------+ +--------+ 95 | |<----->|Path | |OSPF | 96 | CR-LDP | +-->|Selector| | | 97 | | | | | |TE EXT | 98 +--------+ | +---+----+ +---|OPT EXT | 99 | | | +--------+ 100 | v | 101 | +--------+ | +--------+ 102 +--------+ | |TE | | |IS-IS | 103 | | | |Database| | | | 104 | RSVP |<--+ | | | |TE EXT | 105 | | | |<--+---|OPT EXT | 106 +--------+ +--------+ +--------+ 108 Figure 1 Optical Path Routing Functional Diagram 110 The optical path routing system is modeled after the Traffic 111 Engineering systems for MPLS Constraint Based Routing. These systems 112 consist of signaling protocols [CR-LDP][RSVP] that signal MPLS 113 paths. These protocols can source route if they first consult a 114 traffic engineering (TE) database using a path selection algorithm. 115 The TE database can be maintained as an extension of one of the IGP 116 protocols. This database contains information that is transported 117 opaquely by the IGP for the purpose of constraint based routing. 119 This document deals with additional opaque information for the 120 purpose of instantiating optical Lambda paths. A companion draft 121 [Signal] deals with extensions to CR-LDP and RSVP to signal optical 122 Lambda paths. 124 1.1 Agile Optical Networks 126 An optical network consists of Optical Label Switching Routers 127 (OLSR) and point-to-point links. The OLSRs are interconnected by 128 links. Although any topologies of interconnection, mesh, sparse 129 mesh, or ring etc. are supported, we refer to the nodes as being 130 meshed. 132 There are two interfaces in this network: Optical Node-to-Node 133 Interface (ONNI) between two OLSRs and Optical User-Network 134 Interface (OUNI) between customer premise equipment (CPE) and OLSRs. 135 See Figure 2. An agile optical network, all of its OLSRs having a 136 combination of control component, is an 137 optical network with fast Optical Label Switched Path (OLSP) setup 139 Wang et al. Expires September 2000 3 140 and failure recovery. The internal link is a link through an ONNI 141 and an external link is a link cross an OUNI. 143 +--------+ +--------+ +--------+ 144 | | OUNI | | ONNI | | 145 | CPE +-------+ OLSR +-------+ OLSR | 146 | | | | | | 147 +--------+ +--------+ +--------+ 149 Figure 2 Optical Network Interfaces 151 1.2 Optical Path Granularity 153 The granularity of an optical path can be multiple Lambdas, single 154 Lambdas, different levels of sub-Lambda, and groups at all Lambda 155 and sub-Lambda levels. 157 2. Optical LSA 159 The optical Link State Advertisement (LSA) advertises the optical 160 resource information. The resource information, especially the 161 number of available Lambdas and their encoding protocols, are used 162 by each node to compute accurate and consistent optical paths. This 163 LSA is aligned with the traffic engineering LSA in [OSPFTE][ISISTE]. 165 2.1 Optical LSA Header 167 The optical LSA begins with the standard LSA header. The LSA ID is 168 as the following: 170 0 7 15 31 171 +---------------+---------------+-------------------------------+ 172 | 2 | Reserved | Instance ID | 173 +---------------+---------------+-------------------------------+ 175 Instance ID - A maximum of 65536 Resource LSAs may be issued by a 176 system 178 2.2 Optical LSA Payload 180 The optical LSA contains one top-level TLV. There are two top-level 181 TLVs defined: OLSR Address TLV and Link TLV. 183 OLSR Address TLV 185 The OLSR address TLV is the same as Router Address TLV defined in 186 [OSPFTE][ISISTE]. 188 Link TLV 190 Wang et al. Expires September 2000 4 191 The Link TLV describes a single unidirectional link. The Link TLV is 192 a superset of the Link TLV defined in [OSPFTE][ISISTE] except some 193 sub-TLV additions where noted below. The Link TLV contains the 194 following sub-TLVs and there are no order requirements for the sub- 195 TLVs: 197 1. Link type (mandatory) 198 2. Link ID (mandatory) 199 3. Local interface IP address (mandatory) 200 4. Remote interface IP address (mandatory) 201 5. Traffic engineering metric (mandatory) 202 6. Available Link resource (mandatory) 203 7. Resource class/Color (mandatory) 205 The TLVs, Link type, Link ID, Local interface IP address, Remote 206 interface IP address, Traffic engineering metric, Resource 207 class/Color, are defined in the spirit of [OSPFTE][ISISTE][Metric] 208 with the following exceptions. 210 2.2.1 Link type 211 Link type identifies the type of link. There are two new link types 212 introduced by this draft. 214 3. 215 Service transparent 216 A service transparent is a point to point physical optical link. 218 4. 219 Service aware 220 A service aware link is a point-point logical optical link. 222 By using this link type, plus the encoding type, we can represent 223 both physical and logical link and their connection type in optical 224 domain. 226 2.2.2 Link ID 228 Link ID is an identifier. It identifies the optical link exactly as 229 the point to point case for TE extensions. 231 2.2.3 Local interface IP address 233 This interface address may be omitted in which case it defaults to 234 the router address of the local node. 236 2.2.4 Remote interface IP address 238 This address may be specified as an IP address on the remote node or 239 as the router address of the remote node. 241 2.2.5 TE Metric 243 Wang et al. Expires September 2000 5 244 This is a metric value that can be assigned for path selection. The 245 TE metric in the TE extensions is a single value. Extensions to make 246 this metric multiple values have been suggested to allow for more 247 diverse path selection. [METRIC]. 249 2.2.6 Available Link Resource 251 Note: This TLV represents the total classified bandwidth to be 252 available over one link. One way to visualize this resource is the 253 pool of available Lambdas and their associated bandwidth between two 254 nodes. Each resource component represents a group of Lambdas with 255 the same line encoding rate, and total current available bandwidth 256 for all these Lambdas. Encoding rate could be extended to include 257 more types. 259 This TLV specifies all Lambdas that can be used on this link in this 260 direction (from the switch originator the LSA to its neighbour) 261 grouped by the encoding protocol. There is one resource component 262 per encoding type per fiber. If multiple fibers are used per link 263 there will be a resource component per fiber to support fiber 264 bundling. 266 0 15 31 267 +-------------------------------+-------------------------------+ 268 | Type = 6 | Length | 269 +-------------------------------+-------------------------------+ 270 | Resource Component 1 | 271 +---------------------------------------------------------------+ 272 | ... | 273 +---------------------------------------------------------------+ 274 | Resource Component 1 | 275 +---------------------------------------------------------------+ 277 Length - Specifies the length of value field in bytes. 279 Wang et al. Expires September 2000 6 280 The encoding for a resource component is: 282 0 15 31 283 +-------------------------------+-------------------------------+ 284 | Encoding Type | No of Lambda | 285 +-------------------------------+-------------------------------+ 286 | Bandwidth | 287 +---------------------------------------------------------------+ 289 Encoding Type Description 290 --------------- -------------- 291 1 reserved 292 2 Transparent 293 3 GE 294 4 10 GE 295 5 OC-3/STM-1 296 6 OC-3c 297 7 OC-12/STM-4 298 8 OC-12c 299 9 OC-48/STM-16 300 10 OC-48c 301 11 OC-192/STM-64 302 12 OC-192c 303 13 OC-768/STM-256 304 14 OC-768c 306 Encoding Type Specifies the encoding protocol, 308 No. of Lambda Specifies the number of Lambdas with the same 309 encoding type indicated by encoding type. 311 Bandwidth Specifies the total bandwidth of this component in 312 M bits/s. 314 For the encoding type "Transparent", the bandwidth of each Lambda is 315 assumed to be equal and can be determined by dividing the Bandwidth 316 value by the number of Lambdas in this link. 318 2.2.7 Resource Class 320 Resource class is essentially identical to the TE extensions draft. 321 This allows for exclusion/inclusion of a link based on a configured 322 32 bit value. 324 3. Significant Change 326 In addition to normal OSPF/IS-IS operation, OLSRs shall originate 327 optical LSAs when the LSA contents change significantly. 329 Wang et al. Expires September 2000 7 330 One way to control the protocol overhead introduced by optical LSAs 331 is to trigger optical LSAs only when there is a significant change 332 in the value of metrics since the last advertisement. Significant 333 change allows the flexible trade-off between protocol overhead of 334 frequent updates and the accuracy of the network state information 335 that path selection algorithm depends on. A significant change is 336 defined as when the difference between the current available 337 bandwidth and the last advertised available bandwidth crosses a 338 threshold. It could also be defined as a percentage change in the 339 bandwidth used. When the threshold is crossed due to any set-up 340 (tear down) of a new (existing) path, it will trigger an optical LSA 341 for the affected link. The thresholds are configurable. The 342 frequency of these updates can be decreased dramatically using event 343 driven feedback as proposed in [Feedback]. 345 4. Path Selection 347 Upon receipt an optical LSA update, the OLSR should update its 348 optical routing database. No route or path calculation is necessary. 350 The OLSR that receives path set-up request over optical user-network 351 interface computes the complete path from itself to the destination. 352 The path selection will be performed upon receiving a path setup 353 request, since path selection is a constraint-based routing, and the 354 attributes of the optical path are unknown until the path set-up 355 request arrives. The algorithm that will be used for the path 356 selection is normally proprietary and vendor-specific. 358 5. For Further Study 359 In an Optical Transport Network, the signaling network may not be 360 isomorphic with the traffic network. This is partly due to the 361 nature of optical services (e.g., SONET paths) in there is limited 362 "in band" control bandwidth which is not mixed with user data (like 363 IP is). In extending OSPF/IS-IS for optical routing, it is probable 364 that additional modifications are needed to accommodate a separate 365 network for routing control traffic (adjacency discovery, database 366 initialization, and topology updates). This is also suggested in 367 [Sigarch] and [OLXC]. 369 Additional modifications to OSPF/ISIS are needed to support 370 functions for computing physical diversity in path setup. 372 6. Security Considerations 374 This document raises no new security issues for OSPF or IS-IS. 376 7. References 378 [OSPF] Moy, J., _OSPF Version 2,_ RFC 1583, March 1994 380 Wang et al. Expires September 2000 8 382 [OPA] Coltun, R., _The OSPF Opaque LSA Option_, RFC 2370, July 383 1998. 385 [ISIS] ISO 10589, "Intermediate System to Intermediate System Intra- 386 Domain Routing Exchange Protocol for use in Conjunction with the 387 Protocol for Providing the Connectionless-mode Network Service. 389 [OSPFTE] Katz, D. and Yeung, D., _Traffic Engineering Extensions to 390 OSPF_, dtaft-katz-yeung-traffic-01.txt, work in progress, October 391 1999 393 [ISISTE] Henk Smit, Tony Li, "IS-IS extensions for Traffic 394 Engineering", Internet Draft, draft-ietf-isis-traffic-01.txt, work 395 in progress, May 1999. 397 [Signal] Yanhe Fan et al., _Extensions to CR-LDP and RSVP for 398 Optical Path Set-up_, draft-fan-mpls-lambda-signaling-00.txt, work 399 in progress, March 2000 401 [Feedback] Peter Ashwood-Smith et al.,"Improving Topology Database 402 Accuracy With LSP Feedback via CR-LDP", draft-ietf-mpls-te-feed- 403 00.txt, work in progress, Februrary 2000 405 [Sigarch] M. Krishnaswamy et al., "MPLS Control Plane for Switched 406 Optical Networks", draft-krishnaswamy-mpls-son-00.txt, work in 407 progress, March 2000 409 [Metric] _Multiple Metrics for Traffic Engineering with IS-IS and 410 OSPF_ draft-fedyk-isis-ospf-te-metrics-00.txt, work in progress, 411 March 2000 413 [OLXC] Sid Chaudhuri, Gisli Hjalmtysson, Jennifer Yates, "Control of 414 Lightpaths in an Optical Network", draft-chaudhuri-ip-olxc-control- 415 00.txt, work in progress, February 2000 417 8. Acknowledgments 419 The authors would like to thank Peter Ashwood-Smith, Stephen Shew, 420 Yanhe Fan, Loa Andersson Bilel Jamoussi and Stephen Suryaputra for 421 their comments on the draft. 423 Wang et al. Expires September 2000 9 424 9. Author's Addresses 426 Guoqiang Wang Don Fedyk 427 Nortel Networks Corp. Nortel Networks Corp. 428 21 Richardson Side Road, 600 Technology Park Drive 429 Kanata, Ontario, Billerica, MA 01821 430 Canada, K2K 2C1 USA 431 Phone: +1-613-765-4195 Phone: +1-978-288-4506 432 Fax: +1-978-288-0620 433 guogiang@nortelnetworks.com dwfedyk@nortelnetworks.com 435 Gerald R. (Jerry) Ash Murali Krishnaswamy 436 AT&T Labs Lucent Technologies 437 Room MT E3-3C37 3C-512 438 200 Laurel Avenue 101 Crawfords Corner Rd. 439 Middletown, NJ 07748 Holmdel NJ 07733 440 USA USA 441 Phone: 732-420-4578 Voice: +1 732 949 3611 442 Fax: 732-440-6687 443 gash@att.com murali@lucent.com 445 Yang Cao M. K. Girish 446 Lucent Technologies SBC Technology Resources, Inc. 447 21-2A33, 1600 Osgood St 4698 Willow Road, 448 North Andover, MA 01845-1043 Pleasanton, CA 94588 449 USA USA 450 Phone: +1 978 960 6173 Phone: +1 925 598-1263 451 Fax: +1 978 960 6329 Fax: +1 925 598-1322 452 yangcao@lucent.com mgirish@tri.sbc.com 454 Vishal Sharma Ken Owens 455 Tellabs Research Center Tellabs Operations, Inc. 456 One Kendall Square 1106 Fourth Street 457 Bldg. 100, Suite 121 St. Louis, MO 63126 458 Cambridge, MA 02139 USA 459 USA Ph: 314-918-1579 460 Ph: 617-577-8760 Ken.Owens@tellabs.com 461 vishal.sharma@tellabs.com 463 Dr. Simon Bernstein Phuc Nguyen 464 Global One Global One 465 12490 Sunrise Valley Drive 12490 Sunrise Valley Drive 466 Reston, Reston, 467 VA 20196-0001 USA VA 20196-0001 USA 468 Phone: +1 703 689-7109 Phone: +1 703 689-7870 469 Fax: + 1 703 689-6724 Fax: + 1 703 689-6724 470 simon.bernstein@globalone.net Phuc.Nguyen@GlobalOne.net 472 Wang et al. Expires September 2000 10 473 Herbert M. Ruck Lihshin Wang 474 Packet Network Services Qwest Communication. 475 NEC America, Inc. 4250 N Fairfax Drive 476 1525 Walnut Hill Lane Arlington, VA 477 Irving, TX, 75038 USA 478 U.S.A. Phone: 703-363-3986 479 Tel. 972-518-3590 Lihshin.Wang@qwest.com 480 ruck@asl.dl.nec.com 482 Sunil Ahluwalia Heinrich Hummel 483 Trillium Digital Systems Inc, Siemens AG 484 12100 Wilshire Blvd. #1800 Hofmannstrasse 51 485 Los Angeles, CA 90025 81379 Munich, Germany 486 USA Tel: +49 89 722 32057 487 Phone: 310 442 9222 heinrich.hummel@icn.siemens.de 488 sunil@trillium.com 490 Avri Doria 491 Nokia Telecommunications 492 3 Burlington Woods Drive, 493 Suite 250,Burlington, MA 01803 494 Phone: +1 781 359 5131 495 Mobile: +1 617 678 9402 496 avri.doria@nokia.com 498 Full Copyright Statement 500 "Copyright (C) The Internet Society (March 2000). All Rights 501 Reserved. This document and translations of it may be copied and 502 furnished to others, and derivative works that comment on or 503 otherwise explain it or assist in its implmentation may be prepared, 504 copied, published and distributed, in whole or in part, without 506 Wang et al. Expires September 2000 11 507 restriction of any kind, provided that the above copyright notice 508 and this paragraph are included on all such copies and derivative 509 works. However, this document itself may not be modified in any way, 510 such as by removing the copyright notice or references to the 511 Internet Society or other Internet organizations, except as needed 512 for the purpose of developing Internet standards in which case the 513 procedures for copyrights defined in the Internet Standards process 514 must be followed, or as required to translate it into languages 515 other than English. 517 The limited permissions granted above are perpetual and will not be 518 revoked by the Internet Society or its successors or assigns. 520 Wang et al. Expires September 2000 12