Internet Draft

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