Bala Rajagopalan
Internet Draft Tellium, Inc.
draft-many-ip-optical-framework-02.txt
draft-many-ip-optical-framework-03.txt James Luciani
Expires on: 5/14/2001 9/3/2001 Tollbridge Technologies
Daniel Awduche
UUNET (MCI Worldcom)
Brad Cain, Bilel Jamoussi
Nortel Networks
Debanjan Saha
Tellium, Inc.
IP over Optical Networks: A Framework
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 except that the right to
produce derivative works is not granted.
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.
1. Abstract
The Internet transport infrastructure is moving towards a model of
high-speed routers interconnected by optical core networks. A
consensus has emerged in the industry on utilizing IP-based
protocols for the optical control plane. At the same time, there is
ongoing activity in defining architectural models for IP transport
over optical networks, specifically, the routing and signaling
aspects. This draft defines a framework for IP over Optical
networks, considering both the IP-based control plane for optical
networks as well as IP transport over optical networks (together
referred to as "IP over optical networks").
Expires on 5/24/2001 Page 1 of 36
Table of Contents
-----------------
1. Abstract ------------------------------------------------- 1 Abstract...................................................1
2. Conventions Used used in this Document ------------------------- 3 document..........................3
3. Introduction ---------------------------------------------- 3 Introduction...............................................3
4. Terminology and Concepts ---------------------------------- 4 Concepts...................................4
5. The Network Model ----------------------------------------- 7 Model..........................................8
5.1 Network Interconnection -------------------------------- 7 Interconnection................................8
5.2 Control Structure -------------------------------------- 9 Structure.....................................10
6. IP over Optical Service Models ---------------------------- 9 and Requirements...........11
6.1 Domain Services Model ---------------------------------- 10 Model.................................11
6.2 Unified Services Model --------------------------------- 12 Service Model.................................13
6.3 Which Service Model? ----------------------------------- 13 Model?..................................14
6.4 What are the Possible Services? ------------------------ 13 Services?........................14
7. IP Transport transport over Optical Networks ----------------------- 14 Networks........................14
7.1 Interconnection Models --------------------------------- 14 Models.................................15
7.2 Routing Approaches ------------------------------------- 15 Approaches.....................................16
7.3 Signaling Related ------------------------------------- 18 Signaling-Related......................................19
7.4 End-to-End Protection Models --------------------------- 19 Models..........................20
8. IP-Based IP-based Optical Control Plane Issues -------------------- 20 Issues.....................22
8.1 Addressing -------------------------------------------- 21 Addressing............................................22
8.2 Neighbor Discovery ------------------------------------- 22 Discovery....................................23
8.3 Topology Discovery --------------------------------------23 Discovery....................................24
8.4 Restoration Models ------------------------------------- 24 Models....................................25
8.5 Route Computation ------------------------------------- 25 Computation.....................................26
8.6 Signaling Issues -------------------------------------- 27 Issues......................................28
8.7 Optical Internetworking ------------------------------- 29 Internetworking..............................30
9. Other Issues --------------------------------------------- 30 Issues..............................................31
9.1 WDM and TDM in the Same Network ------------------------ 30 Network......................31
9.2 Wavelength Conversion ---------------------------------- 30 Conversion................................31
9.3 Service Provider Peering Points ------------------------ 31 Points......................32
9.4 Rate of Lightpath Set-Up ------------------------------- 31 Set-Up.............................32
9.5 Distributed vs vs. Centralized Provisioning --------------- 32 Provisioning.............33
10. Evolution Path for IP over Optical Architecture --------- 33 Architecture.........34
11. Security Considerations --------------------------------- 33 Considerations..................................34
12. Summary and Conclusions --------------------------------- 34 Conclusions..................................35
13. References ---------------------------------------------- 34 References...............................................35
14. Acknowledgements ---------------------------------------- 35
Expires on 5/24/01 Page 2 of 36 Acknowledgments..........................................36
15. Author's Addresses.......................................37
2. 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.
3. Introduction
Optical network technologies are evolving rapidly in terms of
functions and capabilities. The increasing importance of optical
networks is evidenced by the copious amount of attention focused on
IP over optical networks and related photonic and electronic
interworking issues by all the major network service providers,
telecommunications equipment vendors, and standards organizations.
It has been realized that optical networks must be survivable,
flexible, and controllable. There is, therefore, an ongoing trend to
introduce intelligence in the control plane of optical networks to
make them more versatile [1]. An essential attribute of intelligent
optical networks is the capability to instantiate and route optical
layer connections in real-time or near real-time, and to provide
capabilities that enhance network survivability. Furthermore, there
is a need for multi-vendor optical network interoperability, when an
optical network may consist of interconnected vendor-specific
optical sub-networks.
The OTN must also be versatile because some service providers may
offer generic optical layer services that may not be client-
specific. It would therefore be necessary to have an optical network
control layer that can handle such generic optical services.
There is general consensus in the industry that the optical network
control plane should utilize IP-based protocols for dynamic
provisioning and restoration of lightpaths within and across optical
sub-networks. This is based on the practical view that signaling and
routing mechanisms developed for IP traffic engineering applications
could be re-used in optical networks. Nevertheless, the issues and
requirements that are specific to optical networking must be
understood to suitably adopt the IP-based protocols. This is
especially the case for restoration. Also, there are different
views on the model for interaction between the optical network and
client networks, such as IP networks. Reasonable architectural
alternatives in this regard must be supported, with an understanding
of their pros and cons.
Thus, there are two fundamental issues related to IP over optical
networks. The first is the adaptation and reuse of IP control plane
protocols within the optical network control plane, irrespective of
the types of digital clients that utilize the optical network. The
second is the transport of IP traffic through an optical network
together with the control and coordination issues that arise
therefrom.
Expires on 5/24/01 Page 3 of 36
This draft defines a framework for IP over optical networks covering
the requirements and mechanisms for establishing an IP-centric
optical control plane, and the architectural aspects of IP transport
over optical networks. In this regard, it is recognized that the
specific capabilities required for IP over optical networks would
depend on the services expected at the IP-optical interface as well
as the optical sub-network interfaces. Depending on the specific
operational requirements, a progression of capabilities is possible,
reflecting increasingly sophisticated interactions at these
interfaces. This draft therefore advocates the definition of
"capability sets" that define the evolution of functionality at the
interfaces as more sophisticated operational requirements arise.
This draft is organized as follows. In the next section, terminology
covering certain concepts related to this framework are described.
In Section 5, the network model pertinent to this framework is
described. The service model and requirements for IP-optical, and
multi-vendor optical internetworking are described in Section 6.
This section presently considers certain general requirements.
Specific operational requirements may be accommodated in this
section as they arise. Section 7 considers the architectural models
for IP-optical interworking, describing the pros and cons of each
model. It should be noted that it is not the intent of this draft to
promote any particular model over the others. However, particular
aspects of the models that may make one approach more appropriate
than another in certain circumstances are described. Section 8
describes IP-centric control plane mechanisms for optical networks,
covering signaling and routing issues in support of provisioning and
restoration. Section 9 describes certain specialized issues in
relation to IP over optical networks. The approaches described in
Section 7 and 8 range from the relatively simple to the
sophisticated. Section 10 describes a possible evolution path for IP
over optical networking capabilities in terms of increasingly
sophisticated functionality supported. Section 11 considers security
aspects. Finally, summary and conclusion are presented in Section
12.
4. Terminology and Concepts
This section introduces some the terminology for describing common
concepts in IP over optical networks pertinent to this framework. framework
and some related concepts.
WDM
---
Wavelength Division Multiplexing (WDM) is a technology that allows
multiple optical signals operating at different wavelengths to be
multiplexed onto a single fiber so that they can be transported in
parallel through the fiber. In general, each optical wavelength may
carry digital client payloads at a different data rate (e.g., OC-3c,
Expires on 5/24/01 Page 4 of 36
OC-12c, OC- 48c, OC-192c, etc.) and in a different format (SONET,
Ethernet, ATM, etc.) For example, there are many commercial WDM
networks in existence today that support a mix of SONET signals
operating at OC-48c (approximately 2.5 Gbps) and OC-192
(approximately 10 Gbps) over a single optical fiber. An optical
system with WDM capability can achieve parallel transmission of
multiple wavelengths gracefully while maintaining high system
performance and reliability. In the near future, commercial WDM
systems are expected to concurrently carry more than 160
wavelengths at data rates of OC-192c and above, for a total of 1.6
Tbps or more. The term WDM will be used in this document to refer
to both WDM and DWDM (Dense WDM).
In general, it is worth noting that WDM links are affected by the
following factors, which may introduce impairments into the optical
signal path:
1. The number of wavelengths on a single fiber.
2. The serial bit rate per wavelength.
3. The type of fiber.
4. The amplification mechanism.
5. The number of nodes through which the signal passes before
it reaches the egress node or before regeneration.
All these factors and others not mentioned here constitute domain
specific features of optical transport networks. As noted in [1],
these features should be taken into account in developing standards
based solutions for IP over optical networks.
Optical cross-connect (OXC)
---------------------------
An OXC is a space-division switch that can switch an optical data
stream on an input port to a output port. Such a switch may have
optical-electrical conversion at the input port and electrical-
optical conversion at the output port, or it can be all-optical. An
OXC is assumed to have a control-plane processor that implements
signaling and routing protocols necessary for realizing an optical
network.
Optical channel trail or Lightpath
----------------------------------
An optical channel trail is a point-to-point optical layer
connection between two access points in an optical network. In this
draft, the term "lightpath" is used interchangeably with optical
channel trail.
Optical mesh sub-network
------------------------
An optical sub-network, as considered in this framework, is a
network of OXCs that supports end-to-end networking of optical
channel trails providing functionality like routing, monitoring,
grooming, and protection and restoration of optical channels. The
interconnection of OXCs in this network can be based on a general
topology (also called "mesh" topology) Underlying this network could
be the following:
(a) 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.
(b) An optical transmission section (OTS) layer network : This
provides functionality for transmission of the optical signal on
optical media of different types.
This framework does not address the interaction between the optical
sub-network and the OMS, or between the OMS and OTS layer networks.
Optical mesh network
--------------------
An optical mesh network, as considered in draft, is a mesh-connected
collection of optical sub-networks.
Expires on 5/24/01 Page 5 of 36
Wavelength continuity property
------------------------------
A lightpath is said to satisfy the wavelength continuity property if
it is transported over the same wavelength end-to-end. Wavelength
continuity is required in optical networks with no wavelength
conversion feature.
Wavelength path
---------------
A lightpath that satisfies the wavelength continuity property is
called a wavelength path.
Opaque vs. transparent optical networks
---------------------------------------
A transparent optical network is an optical network in which each
transit node along a path passes optical transmission without
transducing the optical signal into an electrical signal and back
to an optical signal. More generally, all intermediate nodes in a
transparent optical network will pass optical signals without
performing retiming and reshaping and thus such nodes are unaware of
many characteristics of the carried signals. One could, for
example, carry analog signals together with digital signals
(potentially of varying bit rate) on different wavelengths over such
a network.
Note that re-powering of signals at transit nodes is potentially
permitted in transparent optical networks. This is a result of the
availability of all optical amplification devices such as Erbium
Doped Fiber Amplifiers (EDFAs).
In opaque optical networks, by comparison, transit nodes will
perform manipulation of the optical signals which they are carrying.
An example of such manipulation would be 3R (reshaping, retiming,
regeneration/amplification).
Trust domain
------------
A trust domain is a network under a single technical administration
in which most nodes in the network are considered to be secure or
trusted in some fashion. An example of a trust domain is a campus
or corporate network in which all routing protocol packets are
considered to be authentic, without the need for additional security
schemes to prevent unauthorized access to the network
infrastructure. Generally, the "single" administrative control rule
may be relaxed in practice if a set of administrative entities agree
to trust one another to form an enlarged heterogeneous trust domain.
However, to simplify the discussions in this draft, it will assumed,
without loss of generality, that the term trust domain applies to a
single administrative entity.
Flow
----
For the purpose of this document, the term flow will be used to
represent the smallest separable stream of data, as seen by an
endpoint (source or destination node). It is to be noted that the
term flow is heavily overloaded in the networking literature. Within
the context of this document, it may be convenient to consider a
wavelength as a flow under certain circumstances. However, if there
is a method to partition the bandwidth of the wavelength, then each
partition may be considered a flow, for example by quantizing time
into some nicely manageable intervals, it may be feasible to
consider each quanta of time within a given wavelength as a flow.
Traffic Trunk
-------------
A abstraction of traffic flow that follows the same path between two
access points which allows some characteristics and attributes of
the traffic to be parameterized.
Expires on 5/24/01 Page 6 of 36
5. The Network Model
5.1 Network Interconnection
The network model considered in this draft consists of IP routers
attached to an optical core network, and connected to their peers
over dynamically established switched lightpaths. The optical core
itself is assumed to be incapable of processing individual IP
packets.
The optical network is assumed to consist of multiple optical
sub-networks interconnected by optical links in a general topology
(referred to as an optical mesh network). This network may be multi-
vendor. In the near term, it may be expected that each sub-network
will consist of a single vendor switches. In the future, as
standardization efforts mature, each optical sub-network may in fact
contain optical switches from different vendors. In any case, each
sub-network itself is assumed to be mesh-connected. In general, it
can be expected that topologically adjacent OXCs in an optical mesh
network will be connected via multiple, parallel (bi-directional)
optical links. This network model is shown in Figure 1.
Here, an optical sub-network may consist entirely of all-optical
OXCs or OXCs with optical-electrical-optical (OEO) conversion.
Interconnection between sub-networks is assumed to be through
compatible physical interfaces, with suitable optical-electrical
conversions where necessary. The routers that have direct physical
connectivity with the optical network are referred to as "edge
routers". As shown in the figure, other client networks (e.g., ATM)
may connect to the optical network.
The switching function in an OXC is controlled by appropriately
configuring the cross-connect fabric. Conceptually, this may be
viewed as setting up a cross-connect table whose entries are of the
form <input port i, output port j>, indicating that the data stream
entering input port i will be switched to output port j. A
lightpath from an ingress port in an OXC to an egress port in a
remote OXC is established by setting up suitable cross-connects in
the ingress, the egress and a set of intermediate OXCs such that a
continuous physical path exists from the ingress to the egress port.
Optical paths are assumed to be bi-directional, i.e., the return
path from the egress port to the ingress port is routed along the
same set of intermediate ports as the forward path.
Multiple data streams output from an OXC may be multiplexed onto an
optical link using WDM technology. The WDM functionality may exist
outside of the OXC, and be transparent to the OXC. Or, this function
may be built into the OXC. In the latter case, the cross-connect
table (conceptually) consists of pairs of the form, <{input port
i, Lambda(j)}, {output port k, Lambda(l)}>. This indicates that the
data stream received on wavelength Lambda(j) over input port i is
switched to output port k on Lambda(l). Automated establishment of
Expires on 5/24/01 Page 7 of 36
lightpaths involves setting up the cross-connect table entries in
the appropriate OXCs in a coordinated manner such that the desired
physical path is realized.
Optical Network
+---------------------------------------+
| |
+--------------+ | |
| | | +------------+ +------------+ |
| IP | | | | | | |
| Network +--UNI--+ Optical +---NNI--+ Optical | |
| | | Subnetwork | | Subnetwork | |
+--------------+ | | | +-----+ | |
| +------+-----+ | +------+-----+ |
| | | | |
| NNI NNI NNI |
+--------------+ | | | | |
| | | +------+-----+ | +------+-----+ |
| IP +--UNI--| +--+ | | |
| Network | | | Optical | | Optical | |
| | | | Subnetwork +---NNI--+ Subnetwork | |
+--------------+ | | | | | |
| +------+-----+ +------+-----+ |
| | | |
+-------UNI-------------------UNI-------+
| |
| |
+------+-------+ +------------+
| | | |
| Other Client | |Other Client|
| Network | | Network |
| (e.g., ATM) | | |
+--------------+ +------------+
Figure 1: Optical Network Model
Under this network model, a switched lightpath must be established
between a pair of IP routers before they can communicate. This
lightpath might traverse multiple optical sub-networks and be
subject to different provisioning and restoration procedures in each
sub-network. The IP-based control plane issue is that of designing
standard signaling and routing protocols for coherent end-to-end
provisioning and restoration of lightpaths across multiple optical
sub-networks. Similarly, IP transport over such an optical network
involves determining IP reachability and seamless establishment of
paths from one IP endpoint to another over an optical core.
Expires on 5/24/01 Page 8 of 36
5.2 Control Structure
There are two logical control interfaces identified in Figure 1.
These are the client-optical network interface, and the optical sub-
network interface. These interfaces are also referred to as the
User-Network Interface (UNI) and the Network-Network Interface(NNI).
The distinction between these interfaces arises out of the type and
amount of control flow across them. The UNI represents a technology
boundary between the client and optical networks. Thus, the control
flow across the UNI is dependent of the set of services defined
across it and the manner in which the services may be accessed. The
service models are described in Section 7. Here, we merely note that
since the optical network implements an IP-based control plane, it
is possible in principle to harmonize the control flow across the
UNI and the NNI and eliminate the distinction between them. On the
other hand, it may be required to minimize control flow information,
especially routing-related information, over UNI. In this case, UNI
and NNI may look different in some respects. In this draft, these
interfaces are treated as distinct.
Each of these interfaces can also be categorized as public or
private depending upon context and service models. If UNI (or NNI)
is private, then routing information (ie, topology state
information) can be exchanged across it. If UNI (or NNI) is public,
then routing information is not exchanged across it, or such
information may be exchanged across it with very explicit
restrictions (including for example abstraction, filtration, etc).
Thus, different relationships (e.g., peer or over-lay, Section 7)
may occur across private and public logical interfaces.
The physical control structure used to realize these logical
interfaces may vary. For instance, for the UNI, some of the
possibilities are:
1.Direct
1. Direct interface: An in-band or out-of-band IP control channel
(IPCC) may be implemented between an edge router and each OXC
that it connects to. This control channel is used for exchanging
signaling and routing messages between the router and the OXC.
With a direct interface, the edge router and the OXC it connects
to are peers in the control plane. This is shown in Figure 2. The
type of routing and signaling information exchanged across the
direct interface would vary depending on the service definition.
This issue is dealt with in the next section. Some choices for
the routing protocol are OSPF/ISIS (with traffic engineering
extensions) or BGP. Other directory-based routing information
exchanges are also possible. Some of the signaling protocol
choices are adaptations of RSVP-TE or CR-LDP. The details of how
the IP control channel is realized is outside the scope of this
draft.
2.Indirect
2. Indirect interface: An out-of-band IP control channel may be
implemented between the client and a device in the optical network
to signal service requests and responses. For instance, a
Expires on 5/24/01 Page 9 of 36
management system or a server in the optical network may receive
service requests from clients. Similarly, out-of-band signaling
may be used between management systems in client and optical
networks to signal service requests. In these cases, there is no
direct control interaction between clients and respective
OXCs. One reason to have an indirect interface would be that the
OXCs and/or clients do not support a direct signaling interface.
3. Provisioned interface: In this case, the optical network services
are manually provisioned and there is no control interactions
between the client and the optical network.
+-----------------------------+ +-----------------------------+
| | | |
| +---------+ +---------+ | | +---------+ +---------+ |
| | | | | | | | | | | |
| | Routing | |Signaling| | | | Routing | |Signaling| |
| | Protocol| |Protocol | | | | Protocol| |Protocol | |
| | | | | | | | | | | |
| +-----+---+ +---+-----+ | | +-----+---+ +---+-----+ |
| | | | | | | |
| | | | | | | |
| +--+-----------+---+ | | +--+-----------+---+ |
| | | | | | | |
| | IP Layer +......IPCC.......+ IP Layer | |
| | | | | | | |
| +------------------+ | | +------------------+ |
| | | |
| Edge Router | | OXC |
+-----------------------------+ +-----------------------------+
Figure 2: Direct Interface
Although different control structures are possible, further
descriptions in this framework assume direct interfaces for IP-
optical and optical sub-network control interactions.
6. IP over Optical Service Models and Requirements
In this section, the service models and requirements at the IP-
optical UNI and the optical sub-network NNI are considered. Two
general models have emerged for the services at the IP-optical
interface (which can also be applied at the optical sub-network
interface). These models are as follows.
6.1 Domain Services Model
Under this model, the optical network primarily offers high
bandwidth connectivity in the form of lightpaths [2]. Standardized
signaling across the UNI (Figure 1) is used to invoke the following
services:
Expires on 5/24/01 Page 10 of 36
1. Lightpath creation: This service allows a lightpath with the
specified attributes to be created between a pair of termination
points in the optical network. Lightpath creation may be subject
to network-defined policies (e.g., connectivity restrictions) and
security procedures.
2. Lightpath deletion: This service allows an existing lightpath to
be deleted.
3. Lightpath modification: This service allows certain parameters of
the lightpath to be modified.
4. Lightpath status enquiry: This service allows the status of
certain parameters of the lightpath (referenced by its ID) to be
queried by the router that created the lightpath.
Additionally, the following address resolution procedures may be
made available over the UNI (more sophisticated routing information
exchange over the UNI is also possible, as described later and
covered in more detail in [3]):
1. Client Registration: This allows a client to register its
address(es) and user group identifier(s) with the optical
network. The registered address may be of different types, IP,
ATM NSAP, E.164, etc. The optical network associates the client
address and user group ID with an optical-network-administered
address.
2. Client De-Registration: This allows a client to withdraw its
address(es) and user group identifier(s) from the optical
network.
3. Query: This allows a client to supply another clientÆs native
address (e.g., ATM) and user group ID, and get back an optical-
network-administered address that can be used in lightpath create
messages.
An end-system discovery procedure may be used over the UNI to verify
local port connectivity between the optical and client devices, and
allows each device to bootstrap the UNI control channel. Finally, a
"service discovery" procedure may be employed as a precursor to
obtaining UNI services. Service discovery allows a client to
determine the static parameters of the interconnection with the
optical network, including the UNI signaling protocols supported.
The protocols for neighbor and service discovery are different from
the UNI signaling protocol itself (for example, see LMP [4]).
With regard to address resolution, the registration and de-
registration procedures may be implemented using service discovery
mechanisms. The query mechanism may be implemented as an additional
UNI signaling procedure.
Expires on 5/24/01 Page 11 of 36
Because a small set of well-defined services is offered across UNI,
the signaling protocol requirements are minimal. Specifically, the
signaling protocol is required to convey a few messages with certain
attributes point-to-point between the router and the optical
network. Such a protocol may be based on RSVP-TE or LDP, or even a
messaging application over a TCP connection.
The optical domain services model does not deal with the type and
nature of routing protocols within the optical network. Furthermore,
the integration of multiple, optical sub-networks across NNI will
require the specification of a standard routing protocol, say, BGP.
The optical domain services model would result in the establishment
of a lightpath topology between routers at the edge of the optical
network. The resulting overlay model for IP over optical networks
is discussed in Section 7.
6.2 Unified Service Model
Under this model, the IP and optical networks are treated together
as a single integrated network that is managed and traffic
engineered in a unified manner. In this regard, the OXCs are treated
just like any other router as far as the control plane is
considered. Thus, from a routing and signaling point of view, there
is no distinction between UNI, NNI and any other router-to-router
interface. It is assumed that this control plane is MPLS-based, as
described in [1].
Under the unified service model, optical network services are
obtained implicitly during end-to-end MPLS signaling. Specifically,
an edge router can create a lightpath with specified attributes, or
delete and modify lightpaths as it creates label-switched paths
(LSPs). In this regard, the services obtained from the optical
network are similar to the domain services model. These services,
however, may be invoked in a more seamless manner as compared to the
domain services model. For instance, in principle, a remote router
could compute an end-to-end path across the optical network
utilizing, say, OSPF with traffic engineering extensions [5]. It can
then establish an LSP across the optical network. But the edge
routers must still recognize that an LSP across the optical network
is a lightpath, or a conduit for multiple LSPs. The concept of
"forwarding adjacency" can be used to specify virtual links across
optical networks in routing protocols such as OSPF [6]. In essence,
once a lightpath is established across an optical network between
two edge routers, it can be advertised as a forwarding adjacency (a
virtual link) between these routers. Thus, from a data plane point
of view, the lightpaths result in a overlay between edge routers.
The decisions as to when to create such lightpaths, and the
bandwidth management for these lightpaths is identical in both the
domain services model and the unified service model. The routing and
signaling models for unified services is described in Section 7.
Expires on 5/24/01 Page 12 of 36
6.3 Which Service Model?
The pros and cons of the above service models can be debated at
length, but the approach recommended in this framework is to define
routing and signaling mechanisms in support of both. As pointed out
above, signaling for service request can be unified to cover both
models. The developments in GMPLS signaling [7] for the unified
service model and its adoption for UNI signaling under the domain
services model [8] essentially supports this view. The significant
difference between the service models, however, is in routing
protocols, as described in Section 7.
6.4 What are the Possible Services?
Specialized services may be built atop the point-to-point
connectivity service offered by the optical network. For example,
6.4.1 Virtual Private Networks (VPNs)
Given that the data plane between IP routers over an optical network
is an overlay, it is easy to imagine a virtual private network of
lightpaths that interconnect routers (or any other set of clients).
Indeed, in the case where the optical network provides connectivity
for multiple sets of external client networks, there has to be a
way to enforce routing policies that ensure routing separation
between different sets of clients (i.e., VPN service).
7. IP transport over Optical Networks
To examine the architectural alternatives for IP over optical
networks, it is important to distinguish between the data and
control planes over the UNI. As described in Section 6, the optical
network provides a service to external entities in the form of fixed
bandwidth transport pipes (optical paths). IP routers at the edge of
the optical networks must necessarily establish such paths before
communication at the IP layer can begin. Thus, the IP data plane
over optical networks is realized over an overlay network of optical
paths. On the other hand, IP routers and OXCs can have a peer
relation on the control plane, especially for the implementation of
a routing protocol that allows dynamic discovery of IP endpoints
attached to the optical network. The IP over optical network
architecture is defined essentially by the organization of the
control plane. The assumption in this framework is that an MPLS-
based control plane [1] is used. Depending on the service
model(Section 6), however, the control planes in the IP and optical
networks can be loosely or tightly coupled. This coupling determines
o the details of the topology and routing information advertised by
the optical network across UNI;
o Level of control that IP routers can exercise in selecting
specific paths for connections across the optical network; and
Expires on 5/24/01 Page 13 of 36
o Policies regarding the dynamic provisioning of optical paths
between routers. This includes access control, accounting and
security issues.
The following interconnection models are then possible:
7.1 Interconnection Models
7.1.1 The Peer Model
Under the peer model, the IP/MPLS layers act as peers of the optical
transport network, such that a single routing protocol instance runs
over both the IP/MPLS and optical domains. Presumably a common IGP
such as OSPF or IS-IS, with appropriate extensions, can be used to
distribute topology information [3]. In the case of OSPF, opaque
LSAs can be used to advertise topology state information. In the
case of IS-IS, extended TLVs will have to be defined to propagate
topology state information. One tacit assumption here is that a
common addressing scheme will also be used for the optical and IP
networks. A common address space can be trivially realized by using
IP addresses in both IP and optical domains. Thus, the optical
network elements become IP addressable entities as noted in [1].
7.1.2 The Overlay Model
Under the overlay model, the IP/MPLS routing, topology distribution,
and signaling protocols are independent of the routing, topology
distribution, and signaling protocols at the optical layer. This
model is conceptually similar to the classical IP over ATM or MPOA
models, but applied to a optical sub-network directly. In the
overlay model, topology distribution, path computation and signaling
protocols would have to be defined for the optical domain. In
certain circumstances, it may also be feasible to statically
configure the optical channels that provide connectivity in the
overlay model through network management. Static configuration is,
however, unlikely to scale in very large networks.
7.1.3 The Augmented Model
Under the augmented model, there are actually separate routing
instances in the IP and optical domains, but information from one
routing instance is passed through the other routing instance. For
example, external IP addresses could be carried within the optical
routing protocols to allow reachability information to be passed to
IP clients.
The routing approaches corresponding to these interconnection models
are described below.
Expires on 5/24/01 Page 14 of 36
7.2 Routing Approaches
7.2.1 Integrated Routing
This routing approach supports the peer model described above. Under
this approach, the IP and optical networks are assumed to run the
same instance of an IP routing protocol, e.g., OSPF with suitable
"optical" extensions. These extensions must capture optical link
parameters, and any constraints that are specific to optical
networks. The topology and link state information maintained by all
nodes (OXCs and routers) is identical. This permits a router to
compute an end-to-end path to another router across the optical
network. Suppose the path computation is triggered by the need to
route a label switched path (LSP). Such an LSP can be established
using MPLS signaling, e.g., RSVP-TE or CR-LDP. When the LSP is
routed over the optical network, a lightpath must be established
between two edge routers. This lightpath is in essence a tunnel
across the optical network, and may have capacity much larger than
that required to route the first LSP. Thus, it is essential that
other routers in the network realize the availability of resources
in the lightpath for other LSPs to be routed over it. The lightpath
must therefore be advertised as a virtual link in the topology.
The notion of "forwarding adjacency" (FA) described in [6] is
essential in propagating lightpath information to routers. An FA is
essentially a virtual link advertised into a link state routing
protocol. Thus, an FA could be described by the same parameters that
define resources in any regular link. While it is necessary to
specify the mechanism for creating an FA, it is not necessary to
specify how an FA is used by the routing scheme. Once an FA is
advertised in a link state protocol, its usage for routing LSPs is
defined by the route computation and traffic engineering algorithms
implemented.
It should be noted that at the IP-optical interface, the physical
ports over which routers are connected to OXCs define the
connectivity and resource availability. Suppose a router R1 is
connected to OXC O1 over two ports, P1 and P2. Under integrated
routing, the connectivity between R1 and O1 over the two ports would
have been captured in the link state representation of the network.
Now, suppose an FA at full port bandwidth is created from R1 to
another router R2 over port P1. While this FA is advertised as a
virtual link between R1 and R2, it is also necessary to remove the
link R1-O1 (over P1) from the link state representation since that
port is no longer available for creating a lightpath. Thus, as FAs
are created, an overlaid set of virtual links is introduced into the
link state representation, replacing the links previously advertised
at the IP-Optical interface. Finally, the details of the optical
network captured in the link state representation is replaced by a
network of FAs. In this regard, there is a great deal of similarity
between integrated routing and domain-specific routing (described
next). Both ultimately deal with the creation of the overlaid
lightpath topology to meet the traffic engineering objectives.
Expires on 5/24/01 Page 15 of 36
7.2.2 Domain-Specific Routing
This routing approach supports the augmented interconnection model.
Under this approach, routing within the optical and IP domains are
separated, with a standard routing protocol running between domains.
This is similar to the IP inter-domain routing model. Two choices
for this are considered.
7.2.2.1 Domain-Specific Routing using BGP
The inter-domain IP routing protocol, BGP [9], may be adapted for
exchanging routing information between IP and optical domains. This
would allow the routers to advertise IP address prefixes within
their network to the optical network and to receive external IP
address prefixes from the optical network. The optical network
transports the reachability information from one IP network to
others. For instance, edge routers and OXCs can run exterior BGP
(EBGP). Within the optical network, interior BGP (IBGP) is used
between border OXCs within the same sub-network, and EBGP is used
between sub-networks (over NNI, Figure 1).
Under this scheme, it is necessary to identify the egress points in
the optical network corresponding to externally reachable IP
addresses. This is due to the following. Suppose an edge router
desires to establish an LSP to a destination reachable across the
optical network. It could directly request a lightpath to that
destination, without explicitly specifying the egress optical port
for the lightpath as the optical network has knowledge of
externally reachable IP addresses. However, if the same edge router
has to establish another LSP to a different external destination, it
must first determine whether there is a lightpath already available
(with sufficient residual capacity) that leads to that destination.
To identify this, it is necessary for edge routers to keep track of
which egress ports in the optical network lead to which external
destinations. Thus, a border OXC receiving external IP prefixes from
an edge router through EBGP must include its own IP address as the
egress point before propagating these prefixes to other border OXCs
or edge routers. An edge router receiving this information need
not propagate the egress address further, but it must keep the
association between external IP addresses and egress OXC
addresses. Specific BGP mechanisms for propagating egress OXC
addresses are to be determined, considering prior examples
described in [10]. When VPNs are implemented, the address prefixes
advertised by the border OXCs must be accompanied by some VPN
identification (for example, VPN IPv4 addresses, as defined in [10],
may be used).
7.2.2.2 Domain Specific Routing using OSPF/ISIS
The routing information exchanged across the IP-optical UNI could be
summarized using a hierarchical routing protocol such as OSPF/ISIS.
The following description is based on OSPF.
Expires on 5/24/01 Page 16 of 36
OSPF supports a two-level hierarchical routing scheme through the
use of OSPF areas. Routing within each area is flat, while detailed
knowledge of an areaÆs topology is hidden from all other areas.
Routers attached to two or more areas are called Area Border Routers
(ABRs). ABRs propagate IP addressing information from one area to
another using summary LSAs. Within an OSPF routing domain, all areas
are attached directly to a special area called the OSPF backbone
area. The exchange of information between areas can be controlled
to implement domain specific routing in each area. For instance, the
optical network can be a collection of one or more areas in which
certain link parameters and information specific to optical networks
is incorporated into a version of OSPF. The client network (e.g.,
IP) could be separate OSPF area(s), running OSPF with TE extensions.
The summary LSAs exchanged between the optical and client areas can
be designed such that optical domain specific information is hidden
from client networks while providing adequate routing information
for end-to-end routing of lightpaths.
While the use of BGP or OSPF/ISIS allows edge routers to learn about
reachability of destinations across the optical network, the
determination of how many lightpaths to establish and to what egress
points are traffic engineering decisions.
7.2.3 Overlay Routing
This routing approach supports the overlay interconnection model.
Under this approach, overlay mechanism that allows edge routers to
register and query for external addresses is implemented. This is
similar to address resolution for IP over ATM. Under this approach,
the optical network could implement a registry that allows edge
routers to register IP addresses and VPN identifiers. An edge router
may be allowed to query for external addresses belonging to the same
set of VPNs it belongs to. A successful query would return the
address of the egress optical port through which the external
destination can be reached.
Because IP-optical interface connectivity is limited, the
determination of how many lightpaths must be established and to what
endpoints are traffic engineering decisions. Furthermore, after an
initial set of such lightpaths are established, these may be used as
adjacencies within VPNs for a VPN-wide routing scheme, for example,
OSPF. With this approach, an edge router could first determine other
edge routers of interest by querying the registry. After it obtains
the appropriate addresses, an initial overlay lightpath topology may
be formed. Routing adjacencies may then be established across the
lightpaths and further routing information may be exchanged to
establish VPN-wide routing.
Routing approaches in optical networks are further described in [3].
Expires on 5/24/01 Page 17 of 36
7.3 Signaling-Related
7.3.1 The Role of MPLS
It is possible to model wavelengths, and potentially TDM channels
within a wavelength as "labels". This concept was proposed in [1],
and ôgeneralizedö "Generalized" MPLS (GMPLS) mechanisms for realizing this are
described in [7]. MPLS signaling protocols with traffic engineering
extensions, such as RSVP-TE and CR-LDP can be used for signaling
lightpath requests. In the case of the domain services model, these
protocols can be adapted for UNI signaling [11, 12]. In the case of
the unified services model, lightpath establishment occurs to
support end-to-end LSP establishment using these protocols (with
suitable GMPLS enhancements [13, 14]).
7.3.2 Signaling Models
With the domain-services model, the signaling control plane in the
IP and optical network are completely separate as shown in Figure 3
below. This separation also implies the separation of IP and optical
address spaces (even though the optical network would be using
internal IP addressing). While RSVP-TE and LDP can be adapted for
UNI signaling, the full functionality of these protocols will not be
used. For example, UNI signaling does not require the specification
of explicit routes [8]. On the other hand, based on the service
attributes, new objects need to be signaled using these protocols as
described in [11, 12].
MPLS Signaling UNI Signaling MPLS or other signaling
|
+-----------------------------+ | +-----------------------------+
| IP Network | | | Optical Network |
| +---------+ +---------+ | | | +---------+ +---------+ |
| | | | | | | | | | | | |
| | Router +---+ Router +-----+------+ OXC +---+ OXC | |
| | | | | | | | | | | | |
| +-----+---+ +---+-----+ | | | +-----+---+ +---+-----+ |
+-----------------------------+ | +-----------------------------+
|
|
Completely Separated Addressing and Control Planes
Figure 3: Domain Services Signaling Model
With the unified services model, the addressing is common in the IP
and optical networks and the respective signaling control are
related, as shown in Figure 4. It is understood that GMPLS signaling
is implemented in the IP and optical networks, using suitably
enhanced RSVP-TE and CR-LDP protocols. But the semantics of services
within the optical network may be different from that in the IP
network. As an example, the protection services offered in the
optical network may be different from that end-to-end protection
Expires on 5/24/01 Page 18 of 36
services offered by the IP network. Another example is with regard
to bandwidth. While the IP network may offer a continuum of
bandwidths, the optical network will offer only discrete bandwidths.
Thus, the signaling attributes and services are defined
independently for IP and optical networks. The routers at the edge
of the optical network must therefore identify service boundaries
and perform suitable translations in the signaling messages crossing
the IP-optical boundary. This must occur even though the signaling
control plane in both networks are GMPLS-based and there is tighter
coupling of the control plane as compared to the domain services
model.
Service Boundary Service Boundary
| |
IP Layer GMPLS Signaling | Optical Layer GMPLS | IP Layer GMPLS
| |
+--------+ +--------+ | +-------+ +-------+ | +--------+
| | | | | | | | | | | |
| IP LSR +--+ IP LSR +--+--+Optical+--+Optical+-+--+ IP LSR +---
| | | | | | LSR | | LSR | | | |
+-----+--+ +---+----+ | +-----+-+ +---+---+ | +--------+
Common Address Space, Service Translation
Figure 4: Unified Services Signaling Model
Thus, as illustrated in Figure 4, the signaling in the case of
unified services is actually multi-layered. The layering is based on
the technology and functionality. As an example, the specific
adaptations of GMPLS signaling for SONET layer (whose functionality
is transport) are described in [15]. [7].
7.4 End-to-End Protection Models
Suppose an LSP is established from an ingress IP router to an egress
router across an ingress IP network, a transit optical network and
an egress IP network. If this LSP is to be afforded protection in
the IP layer, how is the service coordinated between the IP and
optical layers?
Under this scenario, there are two approaches to end-to-end
protection:
7.4.1 Segment-Wise Protection
The protection services in the IP layer could utilize optical layer
protection services for the LSP segment that traverses the optical
network. Thus, the end-to-end LSP would be treated as a
concatenation of three LSP segments from the protection point of
view: a segment in the ingress IP network, a segment in the optical
Expires on 5/24/01 Page 19 of 36
network and a segment in the egress IP network. The protection
services at the IP layer for an end-to-end LSP must be mapped onto
suitable protection services offered by the optical network. Suppose
that 1+1 protection is offered to LSPs at the IP layer, i.e., each
protected LSP has a pre-established hot stand-by. In case of a
failure of the primary LSP, traffic can be immediately switched to
the stand-by. This type of protection can be realized end-to-end as
follows. With reference to Figure 5, let an LSP originate at
(ingress) router interface A and terminate at (egress) router
interface F. Under the first protection option, a primary path for
the LSP must be established first. Let this path be as shown in the
figure, traversing router interface B in the ingress network,
optical ports C (ingress) and D (egress), and router interface E in
the egress network. Next, 1+1 protection is realized separately in
each network by establishing a protection path between points A and
B, C and D and E and F. Furthermore, the segments B-C and D-E must
themselves be 1+1 protected, using drop-side protection. For the
segment between C and D, the optical network must offer a 1+1
service similar to that offered in the IP networks.
+----------------+ +-----------------+ +---------------+
| | | | | |
A Ingress IP Net B----C Optical Network D----E Egress IP Net F
| | | | | |
+----------------+ +-----------------+ +---------------+
Figure 5: End-to-End Protection Example
7.4.2 Single-Layer Protection
The protection services in the IP layer do not rely on any
protection services offered in the optical network. Thus, with
reference to Figure 5, two SRLG-disjoint LSPs are established
between A and F. The corresponding segments in the optical network
are treated as independent lightpaths in the optical network. These
lightpaths may be unprotected in the optical network.
7.4.3 Differences
A distinction between these two choices is as follows. Under the
first choice, the optical network is actively involved in end-to-end
protection, whereas under the second choice, any protection service
offered in the optical network is not utilized. Also, under the
first choice, the protection in the optical network may apply
collectively to a number of IP LSPs. That is, with reference to
Figure 5, many LSPs may be aggregated into a single lightpath
between C and D. The optical network protection may then be applied
to all of them at once leading to some scalability. Under the second
choice, each IP LSP must be separately protected. Finally, the first
choice allows different restoration signaling to be implemented in
the IP and optical network. These restoration protocols are "patched
Expires on 5/24/01 Page 20 of 36
up" at the service boundaries to realize end-to-end protection. A
further advantage of this is that restoration is entirely contained
within the network where the failure occurs, thereby improving the
restoration latency. For instance, if there is a failure in the
optical network, optical network protocols restore the segment
within. Under the second choice, restoration signaling is always
end-to-end between IP routers, essentially by-passing the optical
network. A result of this is that restoration latency could be
higher. In addition, restoration protocol in the IP layer must run
transparently over the optical network in the overlay mode.
8. IP-based Optical Control Plane Issues
Provisioning and restoring lightpaths end-to-end between IP networks
requires protocol and signaling support within optical sub-networks
and across the interface NNI. In this regard, a distinction is made
between control procedures within an optical sub-network (Figure 1)
and those between sub-networks. The general guideline followed in
this framework is to separate these two cases, and allow the
possibility that different control procedures are followed inside
different sub-networks, while a common set of procedures are
followed across sub-networks (over interface NNI). Clearly, it is
possible to follow the same control procedures inside a sub-network
as defined for control across sub-networks. But this is left as a
choice as per this framework, rather than a mandate. In the
following, signaling and routing within and across sub-networks are
considered.
8.1 Addressing
For interoperability across optical sub-networks using an IP-centric
control plane, the fundamental issue is that of addressing. What
entities should be identifiable from a signaling and routing point
of view? How should they be addressed? This section presents some
guidelines on this.
Identifiable entities in optical networks includes OXCs, optical
links, optical channels and sub-channels, Shared Risk Link Groups
(SRLGs), etc. An issue here is how granular the identification
should be as far as the establishment of optical trails are
concerned. The scheme for identification must accommodate the
specification of the termination points in the optical network with
adequate granularity when establishing optical trails. For instance,
an OXC could have many ports, each of which may in turn terminate
many optical channels, each of which contain many subchannels etc.
It is perhaps not reasonable to assume that every sub-channel or
channel termination, or even OXC ports could be assigned a unique IP
address. Also, the routing of an optical trail within the network
does not depend on the precise termination point information, but
rather only on the terminating OXC. Thus, finer granularity
identification of termination points is of relevance only to the
terminating OXC and not to intermediate OXCs (of course, resource
Expires on 5/24/01 Page 21 of 36
allocation at each intermediate point would depend on the
granularity of resources requested). This suggests an identification
scheme whereby OXCs are identified by a unique IP address and a
"selector" identifies further fine-grain information of relevance at
an OXC. This, of course, does not preclude the identification of
these termination points directly with IP addresses(with a null
selector). The selector can be formatted to have adequate number of
bits and a structure that expresses port, channel, sub-channel, etc,
identification.
Within the optical network, the establishment of trail segments
between adjacent OXCs require the identification of specific port,
channel, sub-channel, etc. With an MPLS-based control plane, a label
serves this function. The structure of the "optical label" must be
such that it can encode the required information [7].
Another entity that must be identified is the SRLG [16]. [15]. An
SRLG is an identifier assigned to a group of optical links that
share a physical resource. For instance, all optical channels routed
over the same fiber could belong to the same SRLG. Similarly, all
fibers routed over a conduit could belong to the same SRLG. The
notable characteristic of SRLGs is that a given link could belong to
more than one SRLG, and two links belonging to a given SRLG may
individually belong to two other SRLGs. This is illustrated in
Figure 6. Here, the links 1,2,3 and 4 may belong to SRLG 1, links
1,2 and 3 could belong to SRLG 2 and link 4 could belong to SRLG 3.
Similarly, links 5 and 6 could belong to SRLG 1, and links 7 and 8
could belong to SRLG 4. (In this example, the same SRLG, i.e., 1,
contains links from two different adjacencies).
While the classification of physical resources into SRLGs is a
manual operation, the assignment of unique identifiers to these
SRLGs within an optical network is essential to ensure correct
SRLG-disjoint path computation for protection. SRLGs could be
identified with a flat identifier (e.g., 32 bit integer).
Finally, optical links between adjacent OXCs may be bundled for
advertisementinto a link state protocol [16]. [15]. A bundled interface
may be numbered or unnumbered. In either case, the component links
within the bundle must be identifiable. In concert with SRLG
identification, this information is necessary for correct path
computation [16]. [15].
8.2 Neighbor Discovery
Routing within the optical network relies on knowledge of network
topology and resource availability. This information may be gathered
and used by a centralized system, or by a distributed link state
routing protocol. In either case, the first step towards network-
wide link state determination is the discovery of the status of
local links to all neighbors by each OXC. Specifically, each OXC
must determine the up/down status of each optical link, the
Expires on 5/24/01 Page 22 of 36
bandwidth and other parameters of the link, and the identity of the
remote end of the link (e.g., remote port number). The last piece of
information is used to specify an appropriate label when signaling
for lightpath provisioning. The determination of these parameters
could be based on a combination of manual configuration and an
automated protocol running between adjacent OXCs. The
characteristics of such a protocol would depend on the type of OXCs
that are adjacent (e.g., transparent or opaque). Generically, the
protocol may be refered to as the "Neighbor Discovery Protocol
(NDP)" although other functions such as link management and fault
isolation may be performed as part of the protocol (e.g., LMP [4]).
NDP would typically require in-band communication on the bearer
channels to determine local connectivity and link status. In the
case of opaque OXCs with SONET termination, one instance of NDP
would run on each OXC port, communicating with the corresponding NDP
instance at the neighboring OXC. The protocol would utilize the
SONET overhead bytes to transmit the (configured) local attributes
periodically to the neighbor. Thus, two neighboring switches can
automatically determine the identities of each other and the local
connectivity,and also keep track of the up/down status of local
links. Neighbor discovery with transparent OXCs is described in [4].
+--------------+ +------------+ +------------+
| +-1:OC48---+ +-5:OC192-+ |
| +-2:OC48---+ +-6:OC192-+ |
| OXC1 +-3:OC48---+ OXC2 +-7:OC48--+ OXC3 |
| +-4:OC192--+ +-8:OC48--+ |
| | | | +------+ |
+--------------+ +----+-+-----+ | +----+------+-----+
| | | | |
| | | | |
+--------------+ | | | | |
| | +----+-+-----+ | | +------+-----+
| +----------+ +--+ | | |
| OXC4 +----------+ +----+ | |
| +----------+ OXC5 +--------+ OXC6 |
| | | +--------+ |
+--------------+ | | | |
+------+-----+ +------+-----+
Figure 6: Mesh Optical Network with SRLGs
8.3 Topology Discovery
Topology discovery is the procedure by which the topology and
resource state of all the links in a sub-network are determined.
Topology discovery may be done using a link state routing protocol
(e.g., OSPF, ISIS), or it can be through a management protocol (in
Expires on 5/24/01 Page 23 of 36
the case of centralized path computation). The focus in this
framework is on fully distributed route computation using an IP link
state protocol.
In general, most of the link state routing functionality is
maintained when applied to optical networks. However, the
representation of optical links, as well as some link parameters,
are changed in this setting. Specifically,
o The link state information may consist of link bundles [16]. [15].
Each link bundle is represented as an abstract link in the network
topology. Different bundling representations are possible. For
instance, the parameters of the abstract link may include the
number, bandwidth and the type of optical links contained in the
underlying link bundle [16]. [15]. Also, the SRLGs corresponding to each
optical link in the bundle may be included as a parameter.
o The link state information should capture restoration-related
parameters for optical links. Specifically, with shared protection
(Section 8.5), the link state updates must have information that
allows the computation of shared protection paths.
o A single routing adjacency could be maintained between neighbors
which may have multiple optical links (or even multiple link
bundles) between them. This reduces the protocol messaging
overhead.
o Since link availability information changes dynamically, a
flexible policy for triggering link state updates based on
availability thresholds may be implemented. For instance, changes
in availability of links of a given bandwidth (e.g., OC-48) may
trigger updates only after the availability figure changes by a
certain percentage.
These concepts are relatively well-understood. On the other hand,
the resource representation models and the topology discovery
process for hierarchical routing (e.g., OSPF with multiple areas)
are areas that need further work.
8.4 Restoration Models
Automatic restoration of lightpaths is a service offered by optical
networks. There could be local and end-to-end mechanisms for
restoration of lightpaths within a sub-network. Local mechanisms are
used to select an alternate link between two adjacent OXCs when a
failure affects the primary link over which the (protected)
lightpath is being routed. Local restoration does not affect the
end-to-end route of the lightpath. When local restoration is not
possible (e.g., no alternate link is available between the adjacent
OXCs in question), end-to-end restoration may be performed. With
this, the affected lightpath may be rerouted over an alternate path
that completely avoids the OXCs or the link segment where the
Expires on 5/24/01 Page 24 of 36
failure occurred. For end-to-end restoration, alternate paths are
typically pre-computed. Such back-up paths may have to be physically
diverse from the corresponding primary paths.
End-to-end restoration may be based on two types of protection
schemes; "1 + 1" protection or shared protection. Under 1 + 1
protection, a back-up path is established for the protected primary
path along a physically diverse route. Both paths are active and the
failure along the primary path results in an immediate switch-over
to the back-up path. Under shared protection, back-up paths
corresponding to physically diverse primary paths may share the same
network resources. When a failure affects a primary path, it is
assumed that the same failure will not affect the other primary
paths whose back-ups share resources.
8.5 Route Computation
The computation of a primary route for a lightpath within an optical
sub-network is essentially a constraint-based routing problem. The
constraint is typically the bandwidth required for the lightpath,
perhaps along with administrative and policy constraints. The
objective of path computation could be to minimize the total
capacity required for routing lightpaths [17]. [16].
Route computation with constraints may be accomplished using a
number of algorithms [18]. [17]. When 1+1 protection is used, a back-up
path that does not traverse on any link which is part of the same
SRLG as links in the primary path must be computed. Thus, it is
essential that the SRLGs in the primary path be known during
alternate path computation, along with the availability of
resources in links that belong to other SRLGs. This requirement has
certain implications on optical link bundling. Specifically, a
bundled LSA must include adequate information such that a remote OXC
can determine the resource availability under each SRLG that the
bundled link refers to, and the relationship between links
belonging to different SRLGs in the bundle. For example,
considering Figure 3, if links 1,2,3 and 4 are bundled
together in an LSA, the bundled LSA must indicate that there are
three SRLGs which are part of the bundle (i.e., 1, 2 and 3), and
that links in SRLGs 2 and 3 are also part of SRLG 1.
It is somewhat complex to encode the SRLG relationships in a link
bundle LSA. This information, however, is naturally captured if the
link bundle is encoded as a set of "link groups", each specifying
the links that belong to exactly the same set of SRLGs. Within the
link group, it is possible to specify the number of links of a
particular type, for example, OC-48. With reference to Figure 3,
for example, a bundle LSA can be advertised for the entire set of
links between OXC1 and OXC2, with the following information:
Expires on 5/24/01 Page 25 of 36
Link Group ID SRLGs Link Type Number Other Info
------------- ----- --------- ------ ----------
1 1,2 OC-48 3 ---
2 1,3 OC-192 1 ---
Assuming that the above information is available for each bundle at
every node, there are several approaches possible for path
computation. For instance,
1. The primary path can be computed first, and the (exclusive
or shared) back-up is computed next based on the SRLGs chosen
for the primary path. In this regard,
o The primary path itself can be computed by taking into account
specific link groups in a bundle. That is, the primary path
computation procedure can output a series of link groups the
path is routed over. Since a link group is uniquely identified
with a set of SRLGs, the alternate path can be computed right
away based on this knowledge. In this case, if the primary path
set up does not succeed for lack of resources in a chosen link
group, the primary and backup paths muse be recomputed.
o It might be desirable to compute primary paths using bundle-
level information (i.e., resource availability in all link
groups in a bundle) rather than specific link group level
information. In this case, the primary path computation
procedure would output a series of bundles the path traverses.
Each OXC in the path would have the freedom to choose the
particular link group to route that segment of the primary
path. This procedure would increase the chances of successfully
setting up the primary path when link state information is not
up to date everywhere. But the specific link group chosen, and
hence the SRLGs in the primary path, must be captured during
primary path set-up, for example, using the RSVP-TE Route
Record Object [19]. [18]. This SRLG information is then used for
computing the back-up path. The back-up path may also be
established specifying only which SRLGs to AVOID in a given
segment, rather than which link groups to use. This would
maximize the chances of establishing the back-up.
2. The primary path and the back-up path are comptuted together in
one step, for example, using Suurbaale's algorithm [20]. [19]. In this
case, the paths must be computed using specific link group
information.
To summarize, it is essential to capture sufficient information in
link bundle LSAs to accommodate different path computation
procedures and to maximize the chances of successful path
establishment. Depending on the path computation procedure used,
the type of support needed during path establishment (e.g., the
recording of link group or SRLG information during path
establishment) may differ.
Expires on 5/24/01 Page 26 of 36
When shared protection is used, the route computation algorithm must
take into account the possibility of sharing links among multiple
back-up paths. Under shared protection, the back-up paths
corresponding to SRLG-disjoint primary paths can be assigned the
same links. The assumption here is that since the primary paths
are not routed over links that have the same SRLG, a given failure
will affect only one of them. Furthermore, it is assumed that
multiple failure events affecting links belonging to more than one
SRLG will not occur concurrently. Unlike the case of 1+1
protection, the back-up paths are not established apriori. Rather, a
failure event triggers the establishment of a single back-up path
corresponding to the affected primary path.
The distributed implementation of route computation for shared back-
up paths require knowledge about the routing of all primary and
back-up paths at every node. This raises scalability concerns. For
this reason, it may be practical to consider the centralization of
the route computation algorithm in a route server that has complete
knowledge of the link state and path routes. Heuristics for fully
distributed route computation without complete knowledge of path
routes are to be determined. Path computation for restoration is
further described in [17, 21]. [16, 20].
8.6 Signaling Issues
Signaling within an optical sub-network for lightpath provisioning
is a relatively simple operation. After a route is determined for a
lightpath, each OXC in the path must establish appropriate cross-
connects in a coordinated fashion. This coordination is akin to
selecting incoming and outgoing labels in a label-switched
environment. Thus, protocols like RSVP-TE [14] and CR-LDP [13] can
be used for this. A few new concerns, however, must be addressed.
8.6.1 Bi-Directional Lightpath Establishment
Lightpaths are typically bi-directional. That is, the output port
selected at an OXC for the forward direction is also the input port
for the reverse direction of the path. Since signaling for optical
paths may be autonomously initiated by different nodes, it is
possible that two path set-up attempts are in progress at the same
time. Specifically, while setting up an optical path, an OXC A may
select output port i which is connected to input port j of the
"next" OXC B. Concurrently, OXC B may select output port j for
setting up a different optical path, where the "next" OXC is A. This
results in a "collision". Similarly, when WDM functionality is built
into OXCs, a collision occurs when adjacent OXCs choose directly
connected output ports and the same wavelength for two different
optical paths. There are two ways to deal with such collisions.
First, collisions may be detected and the involved paths may be torn
down and re-established. Or, collisions may be avoided altogether.
Expires on 5/24/01 Page 27 of 36
8.6.2 Failure Recovery
The impact of transient partial failures must be minimized in an
optical network. Specifically, optical paths that are not directly
affected by a failure must not be torn down due to the failure. For
example, the control processor in an OXC may fail, affecting
signaling and other internodal control communication. Similarly,
the control channel between OXCs may be affected temporarily by a
failure. These failure may not affect already established optical
paths passing through the OXC fabric. The detection of such failures
by adjacent nodes, for example, through a keepalive mechanism
between signaling peers, must not result in these optical paths
being torn down.
It is likely that when the above failures occur, a backup processor
or a backup control channel will be activated. The signaling
protocol must be designed such that it is resilient to transient
failures. During failure recovery, it is desirable to recover local
state at the concerned OXC with least disruption to existing optical
paths.
8.6.3 Restoration
Signaling for restoration has two distict phases. There is a
reservation phase in which capacity for the protection path is
established. Then, there is an activation phase in which the
back-up path is actually put in service. The former phase typically
is not subject to strict time constraints, while the latter is.
Signaling to establish a "1+1" back-up path is relatively straight-
forward. This signaling is very similar to signaling used for
establishing the primary path. Signaling to establish a shared back-
up path is a little bit different. Here, each OXC must understand
which back-up paths can share resources. The signaling message must
itself indicate shared reservation. The sharing rule is as described
in Section 8.4: back-up paths corresponding to physically diverse
primary paths may share the same network resources. It is
therefore necessary for the signaling message to carry adequate
information that allows an OXC to verify that back-up paths that
share a certain resources are allowed to do so.
Under both 1+1 and shared protection, the activation phase has two
parts: propagation of failure information to the source OXC from the
point of failure, and activation of the back-up path. The signaling
for these two phases must be very fast in order to realize response
times in the order of tens of milliseconds. When optical links are
SONET-based, in-band signals may be used, resulting in quick
response. With out-of-band control, it is necessary to consider
fast signaling over the control channel using very short IP packets
and prioritized processing. While it is possible to use RSVP or CR-
LDP for activating protection paths, these protocols do not provide
any means to give priority to restoration signaling as opposed to
signaling for provisioning. For instance, it is possible for a
Expires on 5/24/01 Page 28 of 36
restoration-related RSVP message to be queued behind a number of
provisioning messages thereby delaying restoration. It is therefore
necessary to develop a definition of QoS for restoration signaling
and incorporate mechanisms in existing signaling protocols to
achieve this. Or, a new signaling protocol may be developed
exclusively for activating protection paths during restoration.
8.7 Optical Internetworking
Ideally, a set of interconnected optical sub-networks must be
functionally similar to a single optical sub-network. Thus, it must
be possible to dynamically provision and restore lightpaths across
optical sub-networks. Therefore:
o A standard scheme for uniquely identifying lightpath end-points in
different sub-networks is required.
o A protocol is required for determining reachability of end-points
across sub-networks.
o A standard signaling protocol is required for provisioning
lightpaths across sub-networks.
o A standard procedure is required for the restoration of lightpaths
across sub-networks.
o It should be possible to apply proprietary provisioning and
restoration procedures for the segment of a lightpath passing
through a given sub-net.
The IP-centric control architecture for optical sub-networks can be
extended to satisfy the functional requirements of optical
internetworking. Routing and signaling interaction between optical
sub-networks can be standardized across the interface NNI (Figure
1). For the joint control and management of the network, an
integration of the sub-network management systems is required. The
functionality provided across NNI is as follows.
8.7.1 Neighbor Discovery
NDP, as described in Section 8.2, can be used for this. Indeed, a
single protocol should be standardized for neighbor discovery within
and across sub-networks.
8.7.2 Addressing and Routing Model
The addressing mechanisms described in Section 8.1 can be used to
identify OXCs, ports, channels and sub-channels in each sub-network.
It is essential that the OXC IP addresses are unique network-wide.
Provisioning an end-to-end lightpath across multiple sub-networks
involves the establishment of path segments in each sub-network
Expires on 5/24/01 Page 29 of 36
sequentially. Thus, a path segment is established from the source
OXC to a border OXC in the source sub-network. From this border OXC,
signaling across NNI is used to establish a path segment to a border
OXC in the next sub-network. Provisioning then continues in the next
sub-network and so on until the destination OXC is reached.
A version of BGP may be used to determine the routes to destinations
across sub-networks. Using exterior BGP, adjacent border OXCs in
different sub-networks can exchange reachability of OXCs and other
external IP endpoints (border routers). Using interior BGP, the same
information is propagated from one border OXC to others in the same
sub-network. Thus, every border OXC eventually learns of all IP
addresses reachable across different neighboring sub-networks. These
addresses may be propagated to other OXCs within the sub-network
thereby allowing them to select appropriate border OXCs as exit
points for external destinations. To support VPNs, the external
reachability information should include VPN identifiers.
8.7.3 Restoration
It is likely that proprietary restoration schemes may be implemented
within optical sub-networks. It is therefore necessary to consider a
two-level restoration mechanism. Path failures within an optical
sub-network should be handled using procedures specific to the
sub-network. If this fails, end-to-end restoration across sub-
networks should be invoked. The border OXC that is the ingress to a
sub-network can act as the source for restoration procedures within
a sub-network. The signaling for invoking end-to-end restoration
across NNI is similar to the signaling described in Section 8.6.3.
The computation of the back-up path for end-to-end restoration may
be based on various criteria. It is assumed that the back-up path is
computed by the source OXC, and signaled using standard methods.
9. Other Issues
9.1 WDM and TDM in the Same Network
A practical assumption would be that if SONET (or some other TDM
mechanism that is capable partitioning the bandwidth of a
wavelength) is used, then TDM is leveraged as an additional method
to differentiate between "flows." In such cases, wavelengths and
time intervals (sub-channels) within a wavelength become analogous
to labels (as noted in [1]) which can be used to make switching
decisions. This would be somewhat akin to using VPI (e.g.,
wavelength) and VCI (e.g., TDM sub-channel) in ATM networks. More
generally, this will be akin to label stacking and to LSP nesting
within the context of Multi-Protocol Lambda Switching [1]. GMPLS
signaling [7] supports this type of multiplexing.
9.2 Wavelength Conversion
Some form of wavelength conversion may exist at some switching
elements. This however may not be case in some pure optical
Expires on 5/24/01 Page 30 of 36
switching elements. A switching element is essentially anything
more sophisticated than a simple repeater, that is capable of
switching and converting a wavelength Lambda(k) from an input port
to a wavelength Lambda(l) on an output port. In this display, it
is not necessarily the case that Lambda(k) = Lambda(l), nor is it
necessarily the case that the data carried on Lambda(k) is switched
through the device without being examined or modified.
It is not necessary to have a wavelength converter at every
switching element. A number of studies have attempted to address
the issue of the value of wavelength conversion in an optical
network. Such studies typically use the blocking probability (the
probability that a lightpath cannot be established because the
requisite wavelengths are not available) as a metric to adjudicate
the effectiveness of wavelength conversion. The IP over optical
architecture must take into account hybrid networks with some OXCs
capable of wavelength conversion and others incapable of this. The
GMPLS "label set" mechanism [7] supports the selection of the same
label (i.e., wavelength) across an optical sub-network.
9.3 Service Provider Peering Points
There are proposed inter-network interconnect models which allow
certain types of peering relationships to occur at the optical
layer. This is consistent with the need to support optical layer
services independent of higher layers payloads. In the context of IP
over optical networks, peering relationships between different trust
domains will eventually have to occur at the IP layer, on IP routing
elements, even though non-IP paths may exist between the peering
routers.
9.4 Rate of Lightpath Set-Up
Dynamic establishment of optical channel trails and lightpaths is
quite desirable in IP over optical networks, especially when such
instantiations are driven by a stable traffic engineering control
system, or in response to authenticated and authorized requests from
client.
However, there are many proposals suggesting the use of dynamic,
data-driven shortcut-lightpath setups in IP over optical networks.
The arguments put forth in such proposals are quite reminiscent of
similar discussions regarding ATM deployment in the core of IP
networks. Deployment of highly dynamic data driven shortcuts within
core networks has not been widely adopted by carriers and ISPs for a
number of reasons: possible CPU overhead in core network elements,
complexity of proposed solutions, stability concerns, and lack of
true economic drivers for this type of service. This draft assumes
that this paradigm will not change and that highly dynamic, data-
driven shortcut lightpath setups are for future investigation.
Instead, the optical channel trails and lightpaths that are expected
to be widely used at the initial phases in the evolution of IP over
optical networks will include the following:
Expires on 5/24/01 Page 31 of 36
o Dynamic connections for control plane traffic and default path
routed data traffic,
o Establishment and re-arrangement of arbitrary virtual topologies
over rings and other physical layer topologies.
o Use of stable traffic engineering control systems to engineer
lightpath connections to enhance network performance, either for
explicit demand based QoS reasons or for load balancing).
Other issues surrounding dynamic connection setup within the core
center around resource usage at the edge of the optical domain.
One potential issue pertains to the number of flows that can be
processed by an ingress or egress network element either because of
aggregate bandwidth limitations or because of a limitation on the
number of flows (e.g., lightpaths) that can be processed
concurrently.
Another possible short term reason for dynamic shortcut lightpath
setup would be to quickly pre-provisioned paths based on some
criteria (TOD, CEO wants a high BW reliable connection, etc.). In
this scenario, a set of paths is pre-provisioned, but not actually
instantiated until the customer initiates an authenticated and
authorized setup requests, which is consistent with existing
agreements between the provider and the customer. In a sense, the
provider may have already agreed to supply this service, but will
only instantiate it by setting up a lightpath when the customer
submits an explicit request.
9.5 Distributed vs. Centralized Provisioning
This draft has mainly dealt with a distributed model for lightpath
provisioning, in which all nodes maintain a synchronized topology
database, and advertise topology state information to maintain and
refresh the database. A constraint-based routing entity in each node
then uses the information in the topology database and other
relevant details to compute appropriate paths through the optical
domain. Once a path is computed, a signaling protocol (e.g., [14])
is used to instantiate the lightpath.
Another provisioning model is to have a centralized server which has
complete knowledge of the physical topology, the available
wavelengths, and where applicable, relevant time domain information.
A corresponding client will reside on each network element that can
source or sink a lightpath. The source client would query the
server in order to set up a lightpath from the source to the
destination. The server would then check to see if such a lightpath
can be established based on prevailing conditions. Furthermore,
depending on the specifics of the model, the server may either setup
the lightpath on behalf of the client or provide the necessary
Expires on 5/24/01 Page 32 of 36
information to the client or to some other entity to allow the
lightpath to be instantiated.
Centralization aids in implementing complex capacity optimization
schemes, and may be the near-term provisioning solution in optical
networks with interconnected multi-vendor optical sub-networks. In
the long term, however, the distributed solution with centralization
of some control procedures (e.g., traffic engineering) is likely to
be the approach followed.
10. Evolution Path for IP over Optical Architecture
The architectural models described in Section 7 imply a certain
degree of implementation complexity. Specifically, the overlay
model was described as the least complex for near term deployment
and the peer model the most complex. Nevertheless, each model has
certain advantages and this raises the question as to the evolution
path for IP over optical network architectures.
The evolution approach recommended in this framework is the
definition of capability sets that start with simpler functionality
in the beginning and include more complex functionality later. In
this regard, it is realistic to expect that initial IP over optical
deployments will be based on the domain services model (with overlay
interconnection), with no routing exchange between the IP and
optical domains. Under this model, direct signaling between IP
routers and optical networks is likely to be triggered by offline
traffic engineering decisions. The next step in the evolution of IP-
optical interaction is the introduction of reachability information
exchange between the two domains. This would potentially allow
lightpaths to be established as part of end-to-end LSP set-up. The
final phase is the support for the full peer model with more
sophisticated routing interaction between IP and optical domains.
Using a common signaling framework (based on GMPLS) from the
beginning facilitates this type of evolution. For the domain
services model, implementation agreement based on GMPLS UNI
signaling is being developed in the Optical Interworking Forum (OIF)
[8, 11, 12]. This agreement is aimed at near term deployment and
this could be the precursor to a future peer model architecture. In
this evolution, the signaling capability and semantics at the IP-
optical boundary would become more sophisticated, but the basic
structure of signaling would remain. This would allow incremental
developments as the interconnection model becomes more
sophisticated, rather than complete re-development of signaling
capabilities.
11. Security Considerations
TBD.
Expires on 5/24/01 Page 33 of 36
12. Summary and Conclusions
The objective of this draft was to define a framework for IP over
optical networks, considering the service models, routing and
signaling issues. There are a diversity of choices, as described
in this draft, for IP-optical interconnection, service models
and protocol mechanisms. The approach advocated in this draft
was to allow different service models and proprietary enhancements
in optical networks, and define complementary signaling and
routing mechanisms that would support these. An evolution scenario,
based on a common GMPLS-based signaling framework with increasing
interworking functionality was suggested. Under this scenario, the
IP-optical interaction is first based on the domain services model
with overlay interconnection that eventually evolves to support full
peer interaction.
13. References
1. D. Awduche, Y. Rekhter, J. Drake, R. Coltun, "Multi-Protocol
Lambda Switching: Combining MPLS Traffic Engineering Control
With Optical Crossconnects," draft-awduche-mpls-te-optical-
02.txt, Work in Progress, July, 2000.
2. K. Arvind, et. al, "Optical Domain Services Interconnect (ODSI)
Signaling Control Specification, Version 1.4.5" www.odsi-
coalition.com, March, 2000.
3. D. Pendarakis, B. Rajagopalan and D. Saha, "Routing Information
Exchange in Optical Networks," draft-prs-optical-routing-01.ps, draft-prs-optical-routing-02.ps,
Internet Draft, Work in Progress, November, 2000. March, 2001.
4. J. P. Lang, et. al., "Link Management Protocol," draft-ietf-mpls-
lmp-01.txt,
lmp-02.txt, Internet Draft, Work in progress, November, 2000. March, 2001.
5. K. Kompella et al, "OSPF Extensions in Support of Generalized
MPLS," draft-kompella-ospf-gmpls-extensions-00.txt, Work in
Progress, November, 2000.
6. K. Kompella and Y. Rekhter, "LSP Hierarchy with MPLS TE," draft-
ietf-mpls-lsp-hierarchy-01.txt, Work in Progress, November, 2000.
7. P. Ashwood-Smith et. al, "Generalized MPLS - Signaling Functional
Description", draft-ietf-mpls-generalized-signaling-00.txt, draft-ietf-mpls-generalized-signaling-02.txt,
Internet Draft, Work in Progress, November, 2000. March, 2001.
8. O. Abul-Magd, et. al., "Signaling Requirements at the Optical
UNI," draft-bala-mpls-optical-uni-signaling-01.txt, Internet
Draft, Work in Progress, November, 2000.
9. Y. Rekhter and T. Li, "A Border Gateway Protocol 4 (BGP4)",RFC
1771, March, 1995.
Expires on 5/24/01 Page 34 of 36
10. E. Rosen and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March,
1999.
11. E. Gray, et. al., "RSVP Extensions in Support of OIF Optical
UNI Signaling," draft-gray-mpls-rsvp-oif-uni-ext-00.txt, Internet
Draft, Work in Progress, October, 2000.
12. O. Abul-Magd, et. al., "LDP Extensions for Optical UNI
Signaling," draft-ietf-mpls-ldp-optical-uni-00.txt, Internet
Draft, Work in Progress, October, 2000.
13. P. Ashwood-Smith, et. al., "Generalized MPLS - CR-LDP Signaling
Functional Description," draft-ietf-mpls-generalized-cr-ldp-
00.txt, Internet Draft, Work in Progress, November, 2000.
14. P. Ashwood-Smith, et. al., "Generalized MPLS - RSVP-TE
Signaling Functional Description," draft-ietf-mpls-generalized-
rsvp-te-00.txt, Internet Draft, Work in Progress, November, 2000.
15. B. Mack-Crane, et. al., "Enhancements to GMPLS Signaling for
Optical Technologies," draft-mack-crane-gmpls-signaling-
enchancements-00.txt, Internet Draft, Work in Progress, November,
2000.
16. B. Rajagopalan and D. Saha, "Link Bundling in Optical
Networks," draft-rs-optical-bundling-01.txt, Internet Draft, Work
in Progress, October, 2000.
17.
16. B. Doshi, S. Dravida, P. Harshavardhana, et. al, "Optical
Network Design and Restoration," Bell Labs Technical Journal,
Jan-March, 1999.
18.
17. E. Crawley, R. Nair, B. Rajagopalan and H. Sandick, "A
Framework for QoS-based Routing in the Internet," RFC 2386,
August, 1998.
19.
18. D. Awduche, L. Berger, Der-Hwa Gan, T. Li, G. Swallow, V.
Srinivasan, "RSVP-TE: Extensions to RSVP for LSP Tunnels,"draft-
ietf-mpls-rsvp-lsp-tunnel-07.txt,
ietf-mpls-rsvp-lsp-tunnel-08.txt, Internet Draft, Work in
progress, October, 2000.
20. March, 2001.
19. J. Suurballe, "Disjoint Paths in a Network," Networks, vol. 4,
1974.
21.
20. S. Ramamurthy, Z. Bogdanowicz, S. Samieian, et al., "Capacity
Performance of Dynamic Provisioning in Optical Networks", to
appear in J. of Lightwave Technology.
14. Acknowledgments
We would like to thank Zouheir Mansourati and Ian Duncan of Nortel
Networks for their comments on this draft.
Expires on 5/24/01 Page 35 of 36
15. Author's Addresses
Bala Rajagopalan James V. Luciani
Debanjan Saha TollBridge Technologies
Tellium, Inc. P,O. Box 1010
2 Crescent Place Concord, MA 01742
P.O. Box 901 Email: james_luciani@mindspring.com
Oceanport, NJ 07757-0901
Email: {braja, dsaha}@tellium.com
Daniel O. Awduche Brad Cain, Bilel Jamoussi
UUNET (MCI Worldcom) Nortel Networks
Loudoun County Parkway 600 Tech Park
Ashburn, VA 20247 Billerica, MA 01821
Phone: 703-886-5277 Phone: 978-288-4734
Email: awduche@uu.net Email: bcain@nortelnetworks.com
jamoussi@nortelnetworks.com
******** This draft expires on May, 24, 2001 ***********
Expires on 5/24/01 Page 36 of 36