Internet Draft
IPO and MPLS N. Chandhok
Ohio State University
A. Durresi
Ohio State University
R. Jagannathan,
Ohio State University
R. Jain
Nayna Networks
S. Seetharaman
Ohio State University
K. Vinodkrishnan
Ohio State University
Internet Draft
Document: draft-osu-ipo-mpls-issues-00 .txt July 2000
Category: Informational
IP over Optical Networks: A Summary of Issues
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
This draft presents a summary of issues related to transmission of
IP packets over optical networks. This is a compilation of many
drafts presented so far in IETF. The goal is to create a common
document, which by including all the views and proposals will serve
as a better reference point for further discussion. The novelty of
this draft is that we try to cover all the main areas of integration
and deployment of IP and optical networks including architecture,
routing, signaling, management, and survivability.
Many Authors Informational _ Expires January 2001 Page 1 of 51
IP over Optical Networks: Summary of Issues July 2000
Several existing and proposed network architectures are discussed.
The two-layer model, which aims at a tighter integration between IP
and optical layers, offers a series of important advantages over the
current multi-layer architecture. The benefits include more
flexibility in handling higher capacity networks, better network
scalability, more efficient operations and better traffic
engineering.
Multiprotocol Label Switching (MPLS) has been proposed as the
integrating structure between IP and optical layers. Routing in the
non-optical and optical parts of the hybrid IP network needs to be
coordinated. Several models have been proposed including overlay,
augmented, and peer-to-peer models. These models and the required
enhancements to IP routing protocols, such as, OSPF and IS-IS are
provided.
Control in the IP over Optical networks is facilitated by MPLS
control plane. Each node consists of an integrated IP router and
optical layer crossconnect (OLXC). The interaction between the
router and OLXC layers is defined. Signaling among various nodes is
achieved using CR-LDP and RSVP protocols.
The management functionality in optical networks is still being
developed. The issues of link initialization and performance
monitoring are summarized in this document.
With the introduction of IP in telecommunications networks, there is
tremendous focus on reliability and availability of the new IP-
optical hybrid infrastructures. Automated establishment and
restoration of end to end paths in such networks require
standardized signaling and routing mechanisms. Layering models that
facilitate fault restoration are discussed. A better integration
between IP and optical will provide opportunities to implement a
better fault restoration.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 .
Contents:
1. Overview
1.1 Introduction
1.2 Network Models
2. Optical Switch Architecture
2.1 Isomorphic Relations Between OXCs And LSRs
2.2 Distinctions Between OXCs And LSRs
2.3 Isomorphic Relations between LSPs And Lightpaths
2.4 Distinction Between LSPs And Lightpaths
Various Authors Informational _ Expires January 2001 2
IP over Optical Networks: Summary of Issues July 2000
2.5 General Requirements For The OXC Control Plane
2.5.1 Overview of The MPLS Traffic Engineering Control
2.5.2 OXC Enhancements to Support MPLS Control Plane
2.5.3 MPLS Control Plane Enhancements
2.6 MPLS Traffic Engineering Control Plane With OXCs
3. Routing in Optical Networks
3.1 Models for IP-Optical Network Interaction
3.1.1 Overlay model
3.1.2 Integrated/Augmented model
3.1.3 Peer model
3.2 The Lightpath routing solution
3.2.1 What is an IGP?
3.2.2 How does MPLS come into the picture?
3.2.3 Lightpath Selection
3.3 IS-IS/OSPF enhancements
3.3.1 Link Type
3.3.2 Link Media Type (LMT)
3.3.3 Link ID
3.3.4 Local Interface IP address
3.3.5 Remote Interface IP address.
3.3.6 TE Metric
3.3.7 Path TLV
3.3.8 Shared Risk Link Group TLV
3.4 Control Channels, Data Channels and IP links
3.4.1 Excluding Data Traffic from Control Channels
3.4.2 Forwarding Adjacencies
3.4.3 Two way Connectivity
3.4.4 Optical LSAs
3.5 Open Questions
4. Control
4.1 MPLS Control Plane
4.2 Addressing
4.3 Path Setup
4.3.1 Basic Path Setup Procedure
4.3.2 CR-LDP Extensions for Path Setup
4.3.3 RSVP Extensions for Path Setup
4.4 Resource Discovery and Maintenance
4.5 Configuration Control Using GSMP
4.6 Resource Discovery Using NHRP
5. Optical Network Management
5.1 Link Initialization
5.1.1 Control Channel Management
5.1.2 Verifying Link Connectivity
5.1.3 Fault Localization
5.2 Optical Performance Monitoring (OPM)
6. Fault restoration in Optical networks
6.1 Layering
6.1.1 Layer 1 Protection
6.1.2 Layer 0 Protection
6.2 MPLS in Protection
Various Authors Informational _ Expires January 2001 3
IP over Optical Networks: Summary of Issues July 2000
6.2.1 Motivations
6.2.2 Goals
6.3 Protection options
6.3.1 Dynamic Protection
6.3.2 Pre-negotiated Protection
6.3.3 End to end repair
6.3.4 Local repair
6.3.5 Link protection
6.3.6 Path protection
6.3.7 Revertive Mode
6.3.8 Non-revertive Mode
6.3.9 1+1 Protection
6.3.10 1:1, 1:n, and n:m Protection
6.3.11 Recovery Granularity
6.4. Failure detection
6.5 Failure Notification
6.5.1 Reverse Notification Tree (RNT)
6.6. Timing
6.6.1 Protection Switching Interval Timer
6.6.2 Inter-FIS Packet Timer
6.6.3 Maximum FIS Duration Timer
6.6.4 Protection switching Dampening Timer
6.6.5 Liveness Message Send interval
6.6.6 Failure Indication Hold-off Timer
6.6.7 Lost Liveness Message Threshold
6.7 Signaling Requirements related to restoration
6.8 RSVP/CR-LDP Support for Restoration
6.8.1 Proposed Extensions for Protection Paths
6.9 Fast restoration of MPLS LSPs
6.9.1 L1/L2/L3 Integration
6.9.2 An example
6.10 LMP's Fault localization mechanism
7. Security Considerations
8. Acronyms
9. Terminology
10. References
11. Author's Addresses
1. Overview
1.1. Introduction
Challenges presented by the exponential growth of the Internet have
resulted in the intense demand for broadband services. In
satisfying the increasing demand for bandwidth, optical network
technologies represent an unique opportunity because of their almost
unlimited potential bandwidth.
Recent developments in wavelength-division multiplexing (WDM)
technology have dramatically increased the traffic capacities of
optical networks. Research is ongoing to introduce more intelligence
in the control plane of the optical transport systems, which will
Various Authors Informational _ Expires January 2001 4
IP over Optical Networks: Summary of Issues July 2000
make them more survivable, flexible, controllable and open for
traffic engineering. Some of the essential desirable attributes of
optical transport networks include real-time provisioning of optical
channel trails, providing capabilities that enhance network
survivability, providing interoperability functionality between
vendor-specific optical sub-networks, and enabling protection and
restoration capabilities in operational contexts. The research
efforts now are focusing on the efficient internetworking of higher
layers, primarily IP with WDM layer.
Along with this WDM network, IP networks, SONET networks, ATM
backbones shall all coexist. Various standardization bodies have
been involved in determining an architectural framework for the
interoperability of all these systems.
One approach for sending IP traffic on WDM networks would use a
multi-layered architecture comprising of IP/MPLS layer over ATM over
SONET over WDM. If an appropriate interface is designed to provide
access to the optical network, multiple higher layer protocols can
request lightpaths to peers connected across the optical network.
This architecture has 4 management layers. One can also use a
packet over SONET approach, doing away with the ATM layer, by
putting IP/PPP/HDLC into SONET framing. This architecture has 3
management layers. A few problems of such multi layered
architectures have been studied.
+---------------+
| |
| IP / MPLS |
| |
+---------------+ +---------------+
| | | |
| ATM | | IP/ MPLS |
| | | |
+---------------+ +---------------+ +-------------+
| | | | | |
| SONET | | SONET | | IP / MPLS |
| | | | | |
+---------------+ +---------------+ +-------------+
| | | | | |
| WDM | | WDM | | WDM |
| | | | | |
+---------------+ +---------------+ +-------------+
(4 LAYERS) (3 LAYERS) (2 LAYERS)
Fig.1: Layering Architectures Possible
The fact that it supports multiple protocols, will increase
complexity for IP-WDM integration because of various edge-
Various Authors Informational _ Expires January 2001 5
IP over Optical Networks: Summary of Issues July 2000
interworkings required to route, map and protect client signals
across WDM subnetworks. The existence of separate optical layer
protocols will increase management costs for service providers.
One of the main goals of the integration architecture is to make
optical channel provisioning driven by IP data paths and traffic
engineering mechanisms. This will require a tight cooperation of
routing and resource management protocols at the two layers. The
multi-layered protocols architecture can complicate the timely flow
of the possibly large amount of topological and resource
information.
Another problem is with respect to survivability. There are various
proposals stating that the optical layer itself should provide
restoration/protection capabilities of some form. This will require
careful coordination with the mechanisms of the higher layers such
as the SONET Automatic Protection Switching (APS) and the IP re-
routing strategies. Hold-off timers have been proposed to inhibit
higher layers backup mechanisms.
Problems can also arise from the high level of multiplexing done.
The optical fiber links contain a large number of higher layer flows
such as SONET / SDH, IP flows or ATM VCs. Since these have their
own mechanisms, a flooding of alarm messages can take place.
Hence, a much closer IP/WDM integration is required. The
discussions, henceforth in this document, shall be of such an
architecture. There exist, clouds of IP networks, clouds of WDM
networks. Transfer of packets from a source IP router to a
destination is required. How the combination does signaling to find
an optimal path, route the packet, and ensure survivability are the
topics of discussion.
Multi-Protocol Label Switching (MPLS) for IP packets is believed to
be the best integrating structure between IP and WDM. MPLS brings
two main advantages. First, it can be used as a powerful instrument
for traffic engineering. Second, it fits naturally to WDM when
wavelengths are used as labels. This extension of the MPLS is
called the Multi-protocol lambda switching.
This document starts off with a description of the optical network
model. Section 2 describes the correspondence between the optical
network model and the MPLS architecture and how it can bring about
the inter-working. Section 3 is on routing in this architecture.
It also describes 3 models for looking at the IP cloud and the
Optical cloud namely the Overlay model, the augmented model and the
peer model. Sections 4 and 5 are on control, signaling and
management, respectively. Section 6 is on restoration. Acronyms and
glossary are defined in Sections 8 and 9.
1.2 Network Model
Various Authors Informational _ Expires January 2001 6
IP over Optical Networks: Summary of Issues July 2000
The network model consists of IP routers attached to an optical core
network. The optical network consists of multiple optical
crossconnects (OXCs) interconnected by optical links. Each OXC is
capable of switching a data stream using a switching function,
controlled by appropriately configuring a crossconnect table. Thus,
in this document, the term OXC is used to denote the hybrid node
consisting of switching element referred to as optical layer
crossconnect (OLXC) and a control plane. The switching within the
OXC can be accomplished either in the electrical domain, or in the
optical domain. In this network model, a switched lightpath is
established between IP routers. Designing an IP-based control plane
should include designing standard signaling and routing protocols
for coherent end-to-end provisioning and restoration of lightpaths
across multiple optical sub-networks, and determining IP
reachability and seamless establishment of paths from one IP end-
point to another over an optical core network.
Several standards organizations and interoperability forums have
initiated work items to study the requirements and architectures for
reconfigurable optical networks, under-scoring the importance of
versatile networking capabilities in the optical domain. ITU-T
recommendation G.872, for example, defines a functional architecture
for an optical transport network (OTN) that supports the transport
of digital client signals. It defines OTN as "a transport network
bounded by optical channel access points". The architecture of
G.872's OTN is based on a layered structure, which includes:
(a) an optical channel (OCh) layer network : The optical channel
layer network supports end-to-end networking of optical channel
trails providing functionalities like routing, monitoring, grooming,
and protection and restoration of optical channels.
(b) an optical multiplex section (OMS) layer network : The optical
multiplex section layer provides the transport of the optical
channels. The information contained in this layer is a data stream
comprising a set of n optical channels, which have a defined
aggregate bandwidth.
(c) an optical transmission section (OTS) layer network : This
provides functionality for transmission of the optical signals on
optical media of different types.
To realize the functions in the OCh layer, an optical crossconnect
with rearrangeable switch fabrics and a control plane will be
critical. In the existing IP-centric data network domain, the
functionalities of the OCh layer are performed by the MPLS traffic
engineering control plane. Thus, there is a similarity between the
IP/MPLS over WDM and the ITU recommendation.
In the following section, we stress on the relations that exist
between the all-optical crossconnects of the optical networks and
the label switch routers of the MPLS networks and identify how the
control plane model of MPLS traffic engineering (TE) can be applied
to that of optical transport networks. Before we propose a control
Various Authors Informational _ Expires January 2001 7
IP over Optical Networks: Summary of Issues July 2000
plane model for the optical networks based on the MPLS control plane
traffic engineering, we discuss how the similarities can help to
expose the reusable software artifacts from the MPLS traffic
engineering control plane model. Consider an IP-centric hybrid
optical internetworking environment, which consist of both LSRs and
OXCs. Let us assume that OXCs are programmable and support
wavelength conversion.
2. Optical Switch Architecture
Multiprotocol Label Switching is a switching method in which a label
field in the incoming packets is used to determine the next hop. At
each hop, the incoming label is replaced by another label that is
used at the next hop. The path thus realized is called a Label
Switched Path (LSP). Each LSP has a set of criteria associated with
it, which describes the traffic that traverses the LSP. This set of
criteria groups the incoming traffic into classed called _Forwarding
Equivalence Classes (FECs)._ LSPs are setup using signaling
protocols like RSVP or CR-LDP. A device that can classify traffic
into FECs is called a label edge router (LER) while the devices
which base their forwarding decision only on the basis of the
incoming labels (and ports) are called Label Switched Routers
(LSRs).
Here we consider a hybrid, IP-centric optical internetworking
environment consisting of both label switching routers (LSRs) and
OXCs. The OXCs are programmable and support wavelength conversion
and translation. It is important here to enumerate the relations
and distinctions between OXCs and LSRs to expose the reusable
software artifacts from the MPLS traffic engineering control plane
model. Both OXCs and LSRs emphasize problem decomposition by
architecturally decoupling the control plane from the data plane.
2.1 Isomorphic Relations between OXCs And LSRs
While an LSR's data plane uses the label swapping paradigm to
transfer a labeled packet from an input port to an output port, the
data plane of an OXC uses a switch matrix to provision an optical
channel trail from an input port to an output port. An LSR performs
label switching by establishing a relation between an tuple.
Similarly, OXC provisions optical channel trail by establishing a
relation between an tuple. The functions of the
control plane of both LSRs and OXCs include resource discovery,
distributed routing control, and connection management. LSR's
control plane is used to discover, distribute, and maintain relevant
state information related to the MPLS network, and to instantiate
and maintain label switched paths (LSPs) under various MPLS traffic
engineering rules and policies. OXC's control plane is used to
discover, distribute, and maintain relevant state information
associated with the OTN, and to establish and maintain optical
Various Authors Informational _ Expires January 2001 8
IP over Optical Networks: Summary of Issues July 2000
channel trails under various optical internetworking traffic
engineering rules and policies [Awuduche99].
2.2 Distinctions Between OXCs And LSRs
Current generation of OXCs and LSRs differ in certain
characteristics. While LSRs are datagram devices which can perform
certain packet level operations in the data plane, OXCs cannot. It
cannot perform packet level processing in the data plane.
Conceptually another difference is there, which is that the
forwarding information is carried explicitly in LSRs as part of the
labels appended to the data packets, while in the OXCs switching
information is not appended to the data packet, rather it is implied
from the wavelength or the optical channel.
2.3 Isomorphic Relations Between Explicit LSPs And Optical Channel
Trails
Both the explicit LSPs and optical channel trails (OCTs) exhibit
certain commonalties. For example, both of them are the
abstractions of unidirectional, point-to-point virtual path
connections. An explicit LSP provides a parameterized packet
forwarding path (traffic-trunk) between an ingress LSR and an
egress LSR, while an optical channel trail provides a optical
channel between two endpoints for the transport of digital client
signals [Awuduche99]. Another commonality is that the payload
carried by both LSPs and optical trails are transparent along their
respective paths. They can be parameterized to stipulate their
performance, behavioral, and survivability requirements from the
network. Paths that satisfy some demands and policy requirements
subject to some constraints imposed by the operational environment
can be selected using constraint-based routing scheme. There are
certain similarities in the allocation of labels to LSPs and in the
allocation of wavelengths to optical trails.
2.4 Distinction between LSPs and Optical Channel Trails
There is one major distinction between LSPs and OCTs in that LSPs
support label stacking, but the concept similar to label stacking,
ie, wavelength stacking doesn't exist in the optical domain at this
time.
2.5 General Requirements for the OXC Control Plane
This section has some of the requirements for the OXC control plane
emphasizing on the routing components of these requirements. Some
of the key aspects to these requirements are:(a) to expedite the
capability to establish optical channel trails.(b) to support
traffic engineering functions.(c) to support various protection and
restoration schemes. Since the historical implementation of the
"control plane" of optical transport networks via network management
has detrimental effects like slow restoration, preclusion of
Various Authors Informational _ Expires January 2001 9
IP over Optical Networks: Summary of Issues July 2000
distributed dynamic routing control, etc., motivation is to improve
the responsiveness of the optical transport network and to increase
the level of interoperability within and between service provider
networks.
In the following sections, we summarize the enhancements that are
required in the OXCs to support the MPLS TE as well as the changes
required in the MPLS control plane to adapt to the OXCs. The next
section gives a brief overview of MPLS traffic engineering.
2.5.1 Overview Of The MPLS Traffic Engineering Control
In this section, we discuss the components of the MPLS traffic
engineering control plane model, which include the following modules
[Awuduche99]:
(a) Resource discovery.
(b) State information dissemination to distribute relevant
information concerning the state of the network. The state of the
network includes topology and resource availability information.
This can be accomplished by extending conventional interior gateway
protocols (IGPs) to carry additional information in their link state
advertisements.
(c) Path selection that is used to select an appropriate route
through the MPLS network for explicit routing. It is implemented by
introducing the concept of constraint-based routing which is used to
compute paths that satisfy certain constraints, including
constraints imposed by the operational environment.
(d) Path management, which includes label distribution, path
placement, path maintenance, and path revocation. These functions
are implemented through a signaling protocol, such as the RSVP
extensions or through CR-LDP.The above components of the MPLS
traffic engineering control plane are separable, and independent of
each other, and hence it allows an MPLS control plane to be
implemented using a composition of best of breed modules.
2.5.2 Required Enhancements To OXCs To Support MPLS Control Plane
This section discusses some of the enhancements to OXCs to support
MPL(ambda)S.(a) There should be a mechanism to exchange control
information between OXCs, and between OXCs and other LSRs. This can
be accomplished in-band or quasi-in-band using the same links that
are used to carry data-plane traffic, or out-of-band via a separate
network.(b) An OXC must be able to provide the MPLS traffic
engineering control plane with pertinent information regarding the
state of individual fibers attached to that OXC, as well the state
of individual lightpaths or optical channel trails within each
fiber.(c) Even when an edge LSR does not have WDM capabilities, it
should still have the capability to exchange control information
with the OXCs in the domain.
Various Authors Informational _ Expires January 2001 10
IP over Optical Networks: Summary of Issues July 2000
2.5.3 Required Enhancements To Current MPLS Control Plane
This section discusses the enhancements that are to be made in the
MPLS control plane to support MPL(ambda)S [Basak99].
An MPLS domain may consist of links with different properties
depending upon the type of network elements at the endpoints of the
links. Within the context of MPL(ambda)S, the properties of a link
consisting of a fiber with WDM that interconnects two OXCs are
different form that of a SONET link that interconnects two LSRs. As
an example, a conventional LSP cannot be terminated on a link
connected to a pure OXC. However, a conventional LSP can be
certainly be terminated on a link connected to a frame-based LSR.
These differences should be taken into account when performing path
computations to determine an explicit route for an LSP. It is also
feasible to have the capability to restrict the path of some LSPs to
links with certain characteristics. Path computation algorithms may
then take this information into account when computing paths LSPs.
There must be procedures to associate control channels to bearer
channels between a pair of adjacent OXCs, if there exists multiple
control channels and bearer channels between them. Procedures are
required to demultiplex the control traffic for different bearer
channels if a control channel is associated with multiple bearer
channels. Procedures are also needed to activate and deactivate
bearer channels, to identify the bearer channels associated with any
given physical link, to identify spare bearer channels for
protection purposes, and to identify impaired bearer channels,
particularly, in the situation where the physical links carrying the
bearer channel are not impaired.
Signaling protocols (RSVP and CR-LDP) need to be extended with
objects that can provide sufficient details to establish
reconfiguration parameters for OXC switch elements. IGP should be
extended to carry information about the physical diversity of the
fibers. IGP should be able to distribute information regarding the
allocatable bandwidth granularity of any particular link.
2.6 Synthesizing The MPLS Traffic Engineering Control Plane With OXCs
In IP-centric optical interworking systems, given that both OXCs and
LSRs require control planes, one option would be to have two
separate and independent control planes [Awuduche99]. Another
option is to develop a uniform control plane that can be used for
both LSRs and OXCs. This option of having a uniform control plane
will eliminate the administrative complexity of managing hybrid
optical internetworking systems with separate, dissimilar control
and operational semantics. Specialization may be introduced in the
control plane, as necessary, to account for inherent peculiarities
of the underlying technologies and networking contexts. A single
control plane would be able to span both routers and OXCs. In such
an environment a LSP could traverse an intermix of routers and OXCs,
Various Authors Informational _ Expires January 2001 11
IP over Optical Networks: Summary of Issues July 2000
or could span just routers, or just OXCs. This offers the potential
for real bandwidth-on-demand networking, in which an IP router may
dynamically request bandwidth services from the optical transport
network.
To bootstrap the system, OXCs must be able to exchange control
information. One way to support this is to pre-configure a
dedicated control wavelength between each pair of adjacent OXCs, or
between an OXC and a router, and to use this wavelength as a
supervisory channel for exchange of control traffic. Another
possibility would be to construct a dedicated out-of-band IP network
for the distribution of control traffic.
Though an OXC equipped with an MPLS traffic engineering control
plane would resemble a Label Switching Router, there are some
important distinctions and limitations. The distinction concerns
the fact that there are no analogs of label merging in the optical
domain, which implies that an OXC cannot merge several wavelengths
into one wavelength. Another major distinction is that an OXC
cannot perform the equivalent of label push and pop operation in the
optical domain. This is due to lack of the concept of pushing and
popping wavelengths is infeasible with contemporary commercial
optical technologies. Finally, there is another important
distinction, which is concerned with the granularity of resource
allocation. An MPLS router operating in the electrical domain can
potentially support an arbitrary number of LSPs with arbitrary
bandwidth reservation granularities, whereas an OXC can only support
a relatively small number of optical channel trails, each of which
will have coarse discrete bandwidth granularities.
3. Routing in Optical Networks
The optical network model considered in this draft consists of
multiple Optical Crossconnects (OXCs) interconnected by optical
links in a general topology (referred to as an "optical mesh
network"). Each OXC is assumed to be capable of switching a data
stream from a given input port to a given output port. This
switching function is controlled by appropriately configuring a
crossconnect table. Conceptually, the crossconnect table consists
of entries of the form draft-basak-mpls-oxc-issues-01 .txt, Work in Progress, February 2000.
[Ceuppens00] L. Ceuppens, et. al. "Performance Monitoring in
Photonic Networks in support of MPL(ambda)S," Internet Draft draft-
ceuppens-mpls-optical-00.txt, March 2000.
[Chaudhuri00] S. Chaudhuri, et. al. "Control of Lightpaths in an
Optical Network," Internet Draft draft-chaudhuri-ip-olxc-control-
00.txt, February 2000.
[CRLDP] B. Jamoussi, et. al. "Constraint-Based LSP Setup using
LDP," Internet Draft draft-ietf-mpls-cr-ldp-03 .txt, February 1999.
[GSMP] A. Doria, et. al. "General Switch Management Protocol
V3,"Internet Draft draft-ietf-gsmp-05 .txt, April 2000.
[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".
[ISISTE] Henk Smit, Tony Li, "IS-IS extensions for Traffic
Engineering," Internet Draft, draft-ietf-isis-traffic-01 .txt, work
Various Authors Informational _ Expires January 2001 49
IP over Optical Networks: Summary of Issues July 2000
in progress, May 1999
[Jonathan00] J.P. Lang, K. Mitra, J. Drake,, "Extensions to RSVP
for Optical Networking", Internet Draft draft-lang-mpls-rsvp-oxc-
00.txt, Work in Progress, March 2000.
[Jamoussi99] L. Andersson, A. Fredette, B. Jamoussi, et al.,
"Constraint- Based LSP Setup using LDP", Internet Draft draft-tang-
crldp-optical-00.txt, Work in Progress, January 1999.
[Katz99] Katz, D. and Yeung, D., "Traffic Engineering Extensions to
OSPF," Internet Draft dtaft-katz-yeung-traffic-01.txt, Work in
progress, October 1999.
[KOMPELLA00-a] K. Kompella et. al., "Extensions to IS-IS/OSPF and
RSVP in support of MPL(ambda)S", Internet Draft draft-kompella-
mpls-optical-00.txt, Work in Progress, February 2000 .
[Kompella00-b] Kompella, K., Rekhter, Y., "Link Bundling in MPLS
Traffic Engineering", draft-kompella-mpls-bundle-00 .txt, February
2000.
[Lang00] J.P. Lang, "Link Management Protocol (LMP)," Internet
Draft draft-lang- mpls-lmp-00.txt, March 2000.
[Luciani00] J. Luciani, B. Rajagopalan, D. Awuduche, B. Cain,
Bilel Jamoussi, "IP Over Optical Networks - A Framework", Internet
Draft draft-ip-optical-framework-00 .txt, Work in Progress, March
2000.
[NHRP] Luciani, et. al. "NBMA Next Hop Resolution Protocol
(NHRP)," RFC 2332 , April 1998.
[ODSI00] G.Bernstein et. al., " Optical Domain Service Interconnect
(ODSI) Functional Specification", ODSI Coalition, April 2000.
[OSPF] Moy, J., _OSPF Version 2, RFC 1583 , March 1994
[Tang00] Z.B. Tang et. al. "Extensions to CR-LDP for Path
Establishment in Optical Networks," Internet Draft draft-tang-crldp-
optical-00.txt, March 2000
[WANG] G.Wang et. al., "Extensions to OSPF/IS-IS for Optical
Routing", Internet Draft draft-wang-ospf-isis-lambda-te-routing-
00.txt, Work in Progress, March 2000.
11. Author's Addresses
Various Authors Informational _ Expires January 2001 50
IP over Optical Networks: Summary of Issues July 2000
N. Chandhok, A. Durresi, R. Jagannathan, S. Seetharaman, K.
vinodkrishnan
Department of Computer and Information Science
The Ohio State University
2015 Neil Avenue, Columbus, OH 43210-1277, USA
Phone: (614)-292-3989
Email: {chandhok, durresi, rjaganna, seethara, vinodkri}@cis.ohio-
state.edu
Raj Jain
Nayna Networks, Inc.
157 Topaz Street
Milpitas, CA 95035
Phone: (408)-956-8000X309
Email: raj@nayna.com
Full Copyright Statement
"Copyright (C) The Internet Society (date). 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 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.
Various Authors Informational _ Expires January 2001 51