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 <OSPF/ISIS, CR-LDP/RSVP> 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