Internet Engineering Task Force Guoqiang Wang, Don Fedyk (Nortel Networks) Internet Draft Vishal Sharma, Ken Owens (Tellabs) Gerald R. Ash (AT&T) Murali Krishnaswamy, Yang Cao (Lucent Technologies) M.K. Girish (SBC Technology Resources, Inc.) Expiration September 2000 Herbert M. Ruck (Packet Network Services) Simon Bernstein, Phuc Nquyen (Global One) Sunil Ahluwalia (Trillium Digital Systems) Lihshin Wang(Qwest Communications) Avri Doria (Nokia Telecommunications) Heinrich Hummel (Siemens AG) March 2000 Extensions to OSPF/IS-IS for Optical Routing draft-wang-ospf-isis-lambda-te-routing-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract Real-time optical path setup is the fundamental requirement for agile optical networks and dynamic routing is a mechanism to propagate optical state information and calculate the available paths. OSPF/IS-IS are defined in [OSPF][ISIS]as an IGP routing protocol and this draft specifies the extensions to OSPF/IS-IS for support optical path routing computation. Wang et al. draft 1 Internet Draft draft-wang-lambda-te-routing-00.txt March 2000 Table of Contents 1. Introduction 1.1 Agile Optical Networks 1.2 Optical Path Granularity 2. Optical LSA 2.1 Optical LSA Header 2.2 Optical LSA Payload 3. Significant Change 4. Path Selection 5. For Further Study 6. Security Considerations 7. References 8. Acknowledgements 9. Authors' Addresses 1. Introduction Recently, there has been an increasing interest in agile optical networks. An agile optical network is an optical network with fast end-to-end optical path setup and restoration. One way to quickly set up an optical path through an agile optical network is to use dynamic routing together with signaling. The routing is used to collect network resource and connectivity information, pass state information around and compute the paths from one node to the other nodes. The signaling is used to setup, maintain and tear down the paths. OSPF is defined in [OSPF] and has been widely deployed throughout the Internet as an Interior Gateway Protocol (IGP). IS-IS is defined in [ISIS] and has been deployed in many large networks as an IGP. OSPF/IS-IS has been extended to allow for the future extensibility [OPA] and add traffic engineering capability [OSPFTE][ISISTE][Metric]. This draft extends the optical Link State Advertisement (LSA) to OSPF/IS-IS for support optical path routing computation. Note: For the purpose of this document, an LSA is synonymous with an IS-IS Link State Protocol Data Unit or (LSP). Since this acronym is easily confused with a Label Switched Path, we will use the term LSA to mean generically both OSPF and IS-IS advertisements. In the OSPF case the optical LSA makes use of type 10 opaque LSA. Wang et al. Expires September 2000 2 Internet Draft draft-wang-lambda-te-routing-00.txt March 2000 The components that make up the Optical path selection are illustrated in Figure 1. +--------+ +--------+ +--------+ | |<----->|Path | |OSPF | | CR-LDP | +-->|Selector| | | | | | | | |TE EXT | +--------+ | +---+----+ +---|OPT EXT | | | | +--------+ | v | | +--------+ | +--------+ +--------+ | |TE | | |IS-IS | | | | |Database| | | | | RSVP |<--+ | | | |TE EXT | | | | |<--+---|OPT EXT | +--------+ +--------+ +--------+ Figure 1 Optical Path Routing Functional Diagram The optical path routing system is modeled after the Traffic Engineering systems for MPLS Constraint Based Routing. These systems consist of signaling protocols [CR-LDP][RSVP] that signal MPLS paths. These protocols can source route if they first consult a traffic engineering (TE) database using a path selection algorithm. The TE database can be maintained as an extension of one of the IGP protocols. This database contains information that is transported opaquely by the IGP for the purpose of constraint based routing. This document deals with additional opaque information for the purpose of instantiating optical Lambda paths. A companion draft [Signal] deals with extensions to CR-LDP and RSVP to signal optical Lambda paths. 1.1 Agile Optical Networks An optical network consists of Optical Label Switching Routers (OLSR) and point-to-point links. The OLSRs are interconnected by links. Although any topologies of interconnection, mesh, sparse mesh, or ring etc. are supported, we refer to the nodes as being meshed. There are two interfaces in this network: Optical Node-to-Node Interface (ONNI) between two OLSRs and Optical User-Network Interface (OUNI) between customer premise equipment (CPE) and OLSRs. See Figure 2. An agile optical network, all of its OLSRs having a combination of control component, is an optical network with fast Optical Label Switched Path (OLSP) setup Wang et al. Expires September 2000 3 Internet Draft draft-wang-lambda-te-routing-00.txt March 2000 and failure recovery. The internal link is a link through an ONNI and an external link is a link cross an OUNI. +--------+ +--------+ +--------+ | | OUNI | | ONNI | | | CPE +-------+ OLSR +-------+ OLSR | | | | | | | +--------+ +--------+ +--------+ Figure 2 Optical Network Interfaces 1.2 Optical Path Granularity The granularity of an optical path can be multiple Lambdas, single Lambdas, different levels of sub-Lambda, and groups at all Lambda and sub-Lambda levels. 2. Optical LSA The optical Link State Advertisement (LSA) advertises the optical resource information. The resource information, especially the number of available Lambdas and their encoding protocols, are used by each node to compute accurate and consistent optical paths. This LSA is aligned with the traffic engineering LSA in [OSPFTE][ISISTE]. 2.1 Optical LSA Header The optical LSA begins with the standard LSA header. The LSA ID is as the following: 0 7 15 31 +---------------+---------------+-------------------------------+ | 2 | Reserved | Instance ID | +---------------+---------------+-------------------------------+ Instance ID - A maximum of 65536 Resource LSAs may be issued by a system 2.2 Optical LSA Payload The optical LSA contains one top-level TLV. There are two top-level TLVs defined: OLSR Address TLV and Link TLV. OLSR Address TLV The OLSR address TLV is the same as Router Address TLV defined in [OSPFTE][ISISTE]. Link TLV Wang et al. Expires September 2000 4 Internet Draft draft-wang-lambda-te-routing-00.txt March 2000 The Link TLV describes a single unidirectional link. The Link TLV is a superset of the Link TLV defined in [OSPFTE][ISISTE] except some sub-TLV additions where noted below. The Link TLV contains the following sub-TLVs and there are no order requirements for the sub- TLVs: 1. Link type (mandatory) 2. Link ID (mandatory) 3. Local interface IP address (mandatory) 4. Remote interface IP address (mandatory) 5. Traffic engineering metric (mandatory) 6. Available Link resource (mandatory) 7. Resource class/Color (mandatory) The TLVs, Link type, Link ID, Local interface IP address, Remote interface IP address, Traffic engineering metric, Resource class/Color, are defined in the spirit of [OSPFTE][ISISTE][Metric] with the following exceptions. 2.2.1 Link type Link type identifies the type of link. There are two new link types introduced by this draft. 3. Service transparent A service transparent is a point to point physical optical link. 4. Service aware A service aware link is a point-point logical optical link. By using this link type, plus the encoding type, we can represent both physical and logical link and their connection type in optical domain. 2.2.2 Link ID Link ID is an identifier. It identifies the optical link exactly as the point to point case for TE extensions. 2.2.3 Local interface IP address This interface address may be omitted in which case it defaults to the router address of the local node. 2.2.4 Remote interface IP address This address may be specified as an IP address on the remote node or as the router address of the remote node. 2.2.5 TE Metric Wang et al. Expires September 2000 5 Internet Draft draft-wang-lambda-te-routing-00.txt March 2000 This is a metric value that can be assigned for path selection. The TE metric in the TE extensions is a single value. Extensions to make this metric multiple values have been suggested to allow for more diverse path selection. [METRIC]. 2.2.6 Available Link Resource Note: This TLV represents the total classified bandwidth to be available over one link. One way to visualize this resource is the pool of available Lambdas and their associated bandwidth between two nodes. Each resource component represents a group of Lambdas with the same line encoding rate, and total current available bandwidth for all these Lambdas. Encoding rate could be extended to include more types. This TLV specifies all Lambdas that can be used on this link in this direction (from the switch originator the LSA to its neighbour) grouped by the encoding protocol. There is one resource component per encoding type per fiber. If multiple fibers are used per link there will be a resource component per fiber to support fiber bundling. 0 15 31 +-------------------------------+-------------------------------+ | Type = 6 | Length | +-------------------------------+-------------------------------+ | Resource Component 1 | +---------------------------------------------------------------+ | ... | +---------------------------------------------------------------+ | Resource Component 1 | +---------------------------------------------------------------+ Length - Specifies the length of value field in bytes. Wang et al. Expires September 2000 6 Internet Draft draft-wang-lambda-te-routing-00.txt March 2000 The encoding for a resource component is: 0 15 31 +-------------------------------+-------------------------------+ | Encoding Type | No of Lambda | +-------------------------------+-------------------------------+ | Bandwidth | +---------------------------------------------------------------+ Encoding Type Description --------------- -------------- 1 reserved 2 Transparent 3 GE 4 10 GE 5 OC-3/STM-1 6 OC-3c 7 OC-12/STM-4 8 OC-12c 9 OC-48/STM-16 10 OC-48c 11 OC-192/STM-64 12 OC-192c 13 OC-768/STM-256 14 OC-768c Encoding Type Specifies the encoding protocol, No. of Lambda Specifies the number of Lambdas with the same encoding type indicated by encoding type. Bandwidth Specifies the total bandwidth of this component in M bits/s. For the encoding type "Transparent", the bandwidth of each Lambda is assumed to be equal and can be determined by dividing the Bandwidth value by the number of Lambdas in this link. 2.2.7 Resource Class Resource class is essentially identical to the TE extensions draft. This allows for exclusion/inclusion of a link based on a configured 32 bit value. 3. Significant Change In addition to normal OSPF/IS-IS operation, OLSRs shall originate optical LSAs when the LSA contents change significantly. Wang et al. Expires September 2000 7 Internet Draft draft-wang-lambda-te-routing-00.txt March 2000 One way to control the protocol overhead introduced by optical LSAs is to trigger optical LSAs only when there is a significant change in the value of metrics since the last advertisement. Significant change allows the flexible trade-off between protocol overhead of frequent updates and the accuracy of the network state information that path selection algorithm depends on. A significant change is defined as when the difference between the current available bandwidth and the last advertised available bandwidth crosses a threshold. It could also be defined as a percentage change in the bandwidth used. When the threshold is crossed due to any set-up (tear down) of a new (existing) path, it will trigger an optical LSA for the affected link. The thresholds are configurable. The frequency of these updates can be decreased dramatically using event driven feedback as proposed in [Feedback]. 4. Path Selection Upon receipt an optical LSA update, the OLSR should update its optical routing database. No route or path calculation is necessary. The OLSR that receives path set-up request over optical user-network interface computes the complete path from itself to the destination. The path selection will be performed upon receiving a path setup request, since path selection is a constraint-based routing, and the attributes of the optical path are unknown until the path set-up request arrives. The algorithm that will be used for the path selection is normally proprietary and vendor-specific. 5. For Further Study In an Optical Transport Network, the signaling network may not be isomorphic with the traffic network. This is partly due to the nature of optical services (e.g., SONET paths) in there is limited "in band" control bandwidth which is not mixed with user data (like IP is). In extending OSPF/IS-IS for optical routing, it is probable that additional modifications are needed to accommodate a separate network for routing control traffic (adjacency discovery, database initialization, and topology updates). This is also suggested in [Sigarch] and [OLXC]. Additional modifications to OSPF/ISIS are needed to support functions for computing physical diversity in path setup. 6. Security Considerations This document raises no new security issues for OSPF or IS-IS. 7. References [OSPF] Moy, J., _OSPF Version 2,_ RFC 1583, March 1994 Wang et al. Expires September 2000 8 Internet Draft draft-wang-lambda-te-routing-00.txt March 2000 [OPA] Coltun, R., _The OSPF Opaque LSA Option_, RFC 2370, July 1998. [ISIS] ISO 10589, "Intermediate System to Intermediate System Intra- Domain Routing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service. [OSPFTE] Katz, D. and Yeung, D., _Traffic Engineering Extensions to OSPF_, dtaft-katz-yeung-traffic-01.txt, work in progress, October 1999 [ISISTE] Henk Smit, Tony Li, "IS-IS extensions for Traffic Engineering", Internet Draft, draft-ietf-isis-traffic-01.txt, work in progress, May 1999. [Signal] Yanhe Fan et al., _Extensions to CR-LDP and RSVP for Optical Path Set-up_, draft-fan-mpls-lambda-signaling-00.txt, work in progress, March 2000 [Feedback] Peter Ashwood-Smith et al.,"Improving Topology Database Accuracy With LSP Feedback via CR-LDP", draft-ietf-mpls-te-feed- 00.txt, work in progress, Februrary 2000 [Sigarch] M. Krishnaswamy et al., "MPLS Control Plane for Switched Optical Networks", draft-krishnaswamy-mpls-son-00.txt, work in progress, March 2000 [Metric] _Multiple Metrics for Traffic Engineering with IS-IS and OSPF_ draft-fedyk-isis-ospf-te-metrics-00.txt, work in progress, March 2000 [OLXC] Sid Chaudhuri, Gisli Hjalmtysson, Jennifer Yates, "Control of Lightpaths in an Optical Network", draft-chaudhuri-ip-olxc-control- 00.txt, work in progress, February 2000 8. Acknowledgments The authors would like to thank Peter Ashwood-Smith, Stephen Shew, Yanhe Fan, Loa Andersson Bilel Jamoussi and Stephen Suryaputra for their comments on the draft. Wang et al. Expires September 2000 9 Internet Draft draft-wang-lambda-te-routing-00.txt March 2000 9. Author's Addresses Guoqiang Wang Don Fedyk Nortel Networks Corp. Nortel Networks Corp. 21 Richardson Side Road, 600 Technology Park Drive Kanata, Ontario, Billerica, MA 01821 Canada, K2K 2C1 USA Phone: +1-613-765-4195 Phone: +1-978-288-4506 Fax: +1-978-288-0620 guogiang@nortelnetworks.com dwfedyk@nortelnetworks.com Gerald R. (Jerry) Ash Murali Krishnaswamy AT&T Labs Lucent Technologies Room MT E3-3C37 3C-512 200 Laurel Avenue 101 Crawfords Corner Rd. Middletown, NJ 07748 Holmdel NJ 07733 USA USA Phone: 732-420-4578 Voice: +1 732 949 3611 Fax: 732-440-6687 gash@att.com murali@lucent.com Yang Cao M. K. Girish Lucent Technologies SBC Technology Resources, Inc. 21-2A33, 1600 Osgood St 4698 Willow Road, North Andover, MA 01845-1043 Pleasanton, CA 94588 USA USA Phone: +1 978 960 6173 Phone: +1 925 598-1263 Fax: +1 978 960 6329 Fax: +1 925 598-1322 yangcao@lucent.com mgirish@tri.sbc.com Vishal Sharma Ken Owens Tellabs Research Center Tellabs Operations, Inc. One Kendall Square 1106 Fourth Street Bldg. 100, Suite 121 St. Louis, MO 63126 Cambridge, MA 02139 USA USA Ph: 314-918-1579 Ph: 617-577-8760 Ken.Owens@tellabs.com vishal.sharma@tellabs.com Dr. Simon Bernstein Phuc Nguyen Global One Global One 12490 Sunrise Valley Drive 12490 Sunrise Valley Drive Reston, Reston, VA 20196-0001 USA VA 20196-0001 USA Phone: +1 703 689-7109 Phone: +1 703 689-7870 Fax: + 1 703 689-6724 Fax: + 1 703 689-6724 simon.bernstein@globalone.net Phuc.Nguyen@GlobalOne.net Wang et al. Expires September 2000 10 Internet Draft draft-wang-lambda-te-routing-00.txt March 2000 Herbert M. Ruck Lihshin Wang Packet Network Services Qwest Communication. NEC America, Inc. 4250 N Fairfax Drive 1525 Walnut Hill Lane Arlington, VA Irving, TX, 75038 USA U.S.A. Phone: 703-363-3986 Tel. 972-518-3590 Lihshin.Wang@qwest.com ruck@asl.dl.nec.com Sunil Ahluwalia Heinrich Hummel Trillium Digital Systems Inc, Siemens AG 12100 Wilshire Blvd. #1800 Hofmannstrasse 51 Los Angeles, CA 90025 81379 Munich, Germany USA Tel: +49 89 722 32057 Phone: 310 442 9222 heinrich.hummel@icn.siemens.de sunil@trillium.com Avri Doria Nokia Telecommunications 3 Burlington Woods Drive, Suite 250,Burlington, MA 01803 Phone: +1 781 359 5131 Mobile: +1 617 678 9402 avri.doria@nokia.com Full Copyright Statement "Copyright (C) The Internet Society (March 2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without Wang et al. Expires September 2000 11 Internet Draft draft-wang-lambda-te-routing-00.txt March 2000 restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. Wang et al. Expires September 2000 12