Architecture for an Optical Network Layer - CiteSeerX

29 downloads 2825 Views 232KB Size Report
Feb 16, 1996 - cerned with such non-real time matters as load monitoring, fault .... the current status of backup wavelengths (used, free, down). ... with a network management center using standard protocols such as SNMP or CMIP. The.
Architecture for an Optical Network Layer Ori Gerstel, Paul Green and Rajiv Ramaswami Optical Networking Department, IBM T. J. Watson Research Center P. O. Box 704, Yorktown Heights, NY 10598, USA http://www.research.ibm.com/wdm

February 16, 1996 Abstract The purpose of this document is to de ne the architecture of an optical layer, realized by deploying a multiwavelength mesh-connected optical network. The network o ers lightpaths between pairs of network nodes. A lightpath is simply a high bandwidth pipe, carrying data at up to several gigabits/second. It is realized by using a wavelength on each link in a path between the two nodes in the network. Each link can carry several wavelengths, using optical wavelength division multiplexing (WDM). The new optical layer de ned by these exibly switchable lightpaths o ers at least three bene ts: (1) reduced processing load at the intermediate nodes by handling through trac within the optical layer thus avoiding processing by the higher layers, for example ATM switches, (2) cost savings by creating many independent \virtual bers" over one real ber using WDM, and (3) providing paths that are just as protocol insensitive as if they were so many pure ber paths. The architecture provides ways of making these lightpaths available through the upper layers of some preexisting protocol stack (e.g. ATM or TCP/IP) or directly to the user.

This work was supported in part by grant MDA 972-95-C-0001 from ARPA. The latest version of this document may be found on our web page. 

1

Contents 1 Introduction

4

2 Assumptions

7

3 Interface between Optical Layer and Higher Layer

9

4 Quality of Service

9

1.1 Network Model : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 1.2 Reference Model of the Layers : : : : : : : : : : : : : : : : : : : : : : : : : : 1.3 Outline of this Document : : : : : : : : : : : : : : : : : : : : : : : : : : : :

4 4 7

5 Functional Model of a Node

10

6 Topology Database

11

7 Network Control

12

8 Network Management

13

7.1 Control/Supervisory Channel Options : : : : : : : : : : : : : : : : : : : : : : 12 7.2 Route and Wavelength Computation : : : : : : : : : : : : : : : : : : : : : : 13 7.3 Lightpath Setup and Takedown : : : : : : : : : : : : : : : : : : : : : : : : : 13 8.1 8.2 8.3 8.4 8.5 8.6 8.7 8.8

Introduction : : : : : : : : : : : : : : : : : : Interface between Management and Control Lightpath Design Subsystem : : : : : : : : : Optical ampli ers : : : : : : : : : : : : : : : WDM Crossconnects : : : : : : : : : : : : : Transmitters and Receivers : : : : : : : : : : Passive Components : : : : : : : : : : : : : Associated Node Electronic Functions : : : :

: : : : : : : :

: : : : : : : :

: : : : : : : :

: : : : : : : :

: : : : : : : :

: : : : : : : :

: : : : : : : :

: : : : : : : :

: : : : : : : :

: : : : : : : :

: : : : : : : :

: : : : : : : :

: : : : : : : :

: : : : : : : :

: : : : : : : :

: : : : : : : :

: : : : : : : :

: : : : : : : :

13 15 16 17 18 18 18 18

9 Internetworking

18

A Design of Virtual Topologies

19

B Distributed Control Protocols

19 2

References

19

3

1 Introduction Wavelength-division-multiplexed (WDM) optical networks [1] using wavelength routing are considered to be potential candidates for the next generation of wide-area backbone networks. A WDM all-optical network can use the large bandwidth available in optical ber to realize many channels, each at a di erent optical wavelength, and each of these channels can be operated at moderate bit rates. Networks using 20{100 wavelengths will be feasible in the next few years. The purpose of this document is to attempt to de ne the framework of an architecture for WDM optical networks. It attempts to de ne terminology and bring up the issues to be standardized to ensure seamless operation of network equipment from di erent vendors as well as interconnected subnetworks. Related work appears in [2, 3].

1.1 Network Model The physical topology of the network consists of WDM crossconnect nodes interconnected by pairs of point-to-point ber links in an arbitrary mesh topology as shown in Figure 1. Each pair of links is represented by an undirected edge between nodes in this gure. On this physical topology, one sets up lightpaths between nodes. A lightpath consists of a path through the network between nodes and a wavelength on each link in that path. Lightpaths are set up by con guring the nodes in the network. Some or all of the crossconnect nodes have the ability to terminate lightpaths. Two lightpaths that share a link going in the same direction in the network must use di erent wavelengths. A lightpath provides a pipe between nodes with a bandwidth equal to that of one channel. The set of all lightpaths that have been set up between nodes constitutes the virtual topology. An example virtual topology for the physical topology of Figure 1 is shown in Figure 2. This logical topology corresponds to the set of lightpaths shown in Figure 1. The virtual topology is a graph with the nodes corresponding to the nodes in the network with an edge from node A to node B if a lightpath has been set up from node A to node B .

1.2 Reference Model of the Layers One may think of the WDM network as constituting an optical layer that lies between the physical layer and the higher layers. For instance, a conventional ATM network consists of point-to-point links between ATM switches. By using the optical layer underneath the ATM layer, the links between the ATM switches are actually carried on lightpaths, which in turn use the physical links in the network. The network architecture envisioned here is to be useful for both private and public networks. Figure 3 shows the layer structure as used by several network standards as well as proprietary protocols. Each layer communicates with its peer (at the same level in some other node) by means of Protocol Data Units (PDUs) that are actually visible in the data 4

2 Lightpath

w 1 w 1

1

3

WDM Crossconnect

w 1

w 2 4

PHYSICAL TOPOLOGY

Figure 1: A WDM network consisting of crossconnect nodes interconnected by pairs of point-to-point ber-optic links. 2

3

1

4

Figure 2: The virtual topology for the WDM network of Figure 1. The directed edges in this topology represent the corresponding lightpaths between the nodes in Figure 1.

5

Flow of NM PDUs to/from central site

Network Mgt. Agent

Control Point Flow of PDUs between CPs Flow of User PDUs (cells)

e.g. ATM Layer LAYER 1.3

Flow of SDUs LAYER 1.2 Optical Layer Flow of SDUs LAYER 1.1 Physical Medium

Figure 3: Abstract representation of a protocol layer, its control and its inputs into the network management function. For our purposes the optical layer resides between the physical medium and the higher layer that uses this medium, for example ATM.

ow between nodes. Meanwhile, each layer communicates with its immediate neighbor above or below in the protocol stack by means of Service Data Units (SDUs) that are not usually physically visible but are conceived to be owing physically in a vertical direction in the stack. The optical layer lies between the physical layer and the conventional layer 2 in the hierarchy, namely the ATM layer or a data link layer (usually absent in high-speed networks). In this sense it may be thought of as providing for example, SONET pipes. Following the practice in commercial networking, the activations, deactivations and parameter settings within each layer reach that layer by a direct connection between the layer and a Control Point (CP), rather than traveling vertically from some higher layer. This CP is usually realized as an application in the sense of the protocol stack, whereas from the point of view of the operating system it may not be a true application, but may reside in very fast code within the kernel of the operating system. It is customary to distinguish between Network Control (NC) and Network Management (NM). Network control consists of a set of functions that are invoked frequently and must often be very fast acting. In our context, network control would include protocols for setting up, and taking down lightpaths, as well as protocols to handle failure scenarios where rapid restoration is required. Typically in high-speed networks, network control is a decentralized function, implemented in a distributed fashion by the control points at the nodes. This enables it to be fast acting, scalable and more robust in the presence of failures. Network management is much less time-sensitive than network control, since it is con6

cerned with such non-real time matters as load monitoring, fault monitoring, deriving billing information, keeping track of changes and updates in the hardware of the network, and so forth. Because of this lack of time sensitivity, and also because of the fact a single network usually has one administrator, it is common for the consumer of the network management information (who also originates commands for non-real time con guration changes) to be a single centralized network management site. The control points must communicate with each other using PDU streams chosen for their high performance (e.g. datagrams or cells), while the network management agents can use a less performance-sensitive ow in communicating with the central network management site. Figure 3 shows at the very bottom of the stack the usual physical medium, in this case the web of ber strands, with diagnostic hooks feeding such information into the NM Agent as the state of active components such as erbium doped ber ampli ers (EDFAs), and also passive components such as star couplers, patch panels, splitters, and so forth. Appropriate other information supplied the NM Agent comes from higher layers, e.g. the state of wavelength routing components in the Optical Layer. Currently there is an e ort underway in ITU-T SG 15 [15] (see also [3]) to de ne a layered view of the optical layer itself, see Figure 4. The optical layer consists of three sublayers: an optical channel (OC)layer, an optical multiplex section (OMSn) layer, and an optical ampli er section (OASn) layer. The OC layer corresponds to lightpaths, the OMSn layer to links, and the OASn layer to link segments between optical ampli ers. The notion is that a lightpath, or optical channel, is carried on a sequence of multiplex sections, or links. Each link in turn consists of multiple optical ampli er sections (or link segments). While this view attempts to provide a hierarchical de nition of the logical organization of the optical layer it does not at all deal with standardization of control and management aspects. The latter is the main focus of this document.

1.3 Outline of this Document The rest of this document is organized as follows. Sec. 2 lays down some underlying assumptions. Sec. 3 describes the interface between the optical layer and the higher layer. Sec. 4 describes the quality-of-service (QOS) parameters relevant to the optical layer. Sec. 5 provides a functional model of a WDM crossconnect node. Sec. 6 attempts to provide a concise view of the topology of the network. Sec. 7 deals with network control and Sec. 8 with network management. Sec. 9 deals with some of the issues to be tackled in controlling and managing independent subnetworks administered separately.

2 Assumptions This section outlines some speci c assumptions for WDM networks. Using these assumptions would simplify standards as well as implementation. 7

Higher Layer/OC adapt Optical Channel (Lightpath) Trail

Optical Channel Layer OCLC OC/OMS adapt Optical Multiplex Section Trail

Optical Multiplex Section Layer OMSnLC OMS/OAS adapt Optical Amplifier Section Trail

Optical Amplifier Section Layer OASnLC

Figure 4: Hierarchical representation of the optical layer, as proposed in ITU-T SG 15.

Low setup rate: It is assumed that lightpaths will be set up and taken down somewhat

infrequently (currently in the order of hours), since they are used as a physical layer by higher level protocols (e.g., ATM,IP), which allow for higher rate connection setup. As a result, network control can be substantially simpli ed. For example, it is reasonable to have centralized network control | even for large networks | which is much easier to implement and standardize. In addition, fast reservation protocols, which seem important for connection-oriented networks with high setup rates, are unnecessary here. However we may not want to rule out the option of implementing distributed protocols, since the frequency of lightpath setup and takedown may increase in future networks. Isolation from physical layer constraints: In order to enable the network to guarantee certain end-to-end characteristics (such as bit error rate), it is necessary to consider physical-layer constraints such as crosstalk and SNR along the links of the lightpath. An important question to be resolved is whether it is possible to take these link-bylink constraints and come up with a simpler set of constraints to be passed on to the optical layer. For instance, most routing and wavelength computation (RWC) algorithms proposed for the optical layer [4, 5] do not take physical layer constraints into account. However if the physical layer constraints can be translated into certain limitations such as a set of allowed routes or the maximum number of hops on a route, this would considerably simplify the RWC algorithm. An even further simpli cation would result if the optical layer were to assume simply that the network be designed so that all possible lightpaths have certain guaranteed characteristics, such as end-to-end bit error rates. Routing of Bidirectional lightpaths: Bidirectional lightpaths can be generally realized by a pair of unidirectional lightpaths on di erent routes, with common endpoints. A 8

more restricted option is to require that these unidirectional lightpaths be established along the same physical route and possibly the same set of wavelengths, in counterpropagating directions. Experience shows that this restriction substantially simpli es connection management, particularly while handling failures. A similar design choice was made by the ATM Forum.

3 Interface between Optical Layer and Higher Layer The optical layer provides lightpaths to the higher layer. To support lightpaths, the optical layer must provide the following services to the higher layer: 

Addressing. Nodes in the network must have an address in the optical layer that the higher layer can use to request lightpaths.



Quality-of-service (QOS) parameters, as described in Sec. 4 Multicast capability (optional) Unidirectional or bidirectional lightpaths. Depending on trac requirements, the optical layer may be required to set up either of these. In the case of bidirectional lightpaths, network control is considerably simpli ed if both directions are established on the same route in the network and the same wavelengths on each link in that route.

 

Service data units (SDUs) must be de ned for the following primitives: 



From higher layer to optical layer: { Lightpath request (source address, source local port (optional), destination address(es), destination local ports (optional), QOS, directionality). { Lightpath terminate(lightpath label). The label provides a unique identi er for the lightpath. { Lightpath status inquiry(lightpath label). From optical layer to higher layer: { Lightpath con rm (source address, source local port (optional), destination address(es), destination local ports (optional), QOS). { Lightpath status update(lightpath label).

4 Quality of Service Each layer in the protocol stack provides its higher layer with certain guarantees on the provided quality of service (QOS). At the time of establishment of a lightpath, the higher 9

layer determines (or negotiates) with the optical layer to establish the QOS parameters for the lightpath. The QOS parameters relevant to the lightpaths provided by the optical layer include the following: 

Degree of transparency. This includes:

{ xed or variable bit rate, { xed or variable modulation format (OOK, PSK etc.) { digital and/or analog. 

Level of backup required/provided.

{ Mandatory backup { Best-e ort backup, with backup priorities { Backup not required 

Maximum bit rate/bandwidth,



Required bit error rate/signal-to-noise ratio,



End-to-end delay on the lightpath and its backup lightpath (if any),



Jitter requirements, particularly for SONET/SDH,



Security issues.

5 Functional Model of a Node Figure 5 shows a block diagram view of a WDM crossconnect node. The node has trunk ports that connect it to other nodes. These are optical ber pairs. We assume that all ports are bidirectional. It also has tributary ports, or local ports. These ports form a local source and sink of trac. Local ports may be electrical or optical. Lightpaths start and end at a local port. In addition there is a control point and a network management agent associated with the node. For the case where there are exactly two trunk ports (excluding protection bers), the node is called an add/drop multiplexer (ADM) node. There are several possible implementations of such a node with di erent characteristics, see [6, 7, 4, 8, 9]. In all cases however, two signals cannot be switched to a single wavelength on a given port (in the same direction). 1. The node may vary in its capabilities to perform wavelength conversion:  With no wavelength conversion a signal entering the node at (port x, wavelength  ) must leave the node at (port y, wavelength  ). i

i

10

Control Point

Trunk Ports

NM Agent

Trunk Ports

WDM Crossconnect

Local (Tributary) Ports

Figure 5: Block diagram representation of a WDM crossconnect node. With full wavelength conversion a signal entering the node at (x,  ) can leave the node at (y,  ), i.e., any port and any wavelength.  With limited wavelength conversion a signal entering the node at (x,  ) may leave the node at any wavelength (y,  2 S ( )), where S ( ) is the subset of wavelengths that it can be converted to. 2. The node may or may not o er multicast capability. 3. The level of transparency o ered by the node may vary. A fully optical implementation as in [6, 7] may yield a high-degree of transparency, namely insensitivity to digital/analog data, bit rate, and modulation format. At the other extreme an implementation consisting of an electronic SONET digital crossconnect switch may o er no transparency at all. In the middle an implementation using an electronic crossconnect with regeneration of the optical signal without retiming (2R) may o er transparency to bit rate, without supporting analog data or di erent modulation format [8]. 4. Further constraints may be imposed by the node. For instance in the the ONTC node [7], two local ports cannot simultaneously use the same wavelength. 

i

j

i

xy

i

xy

i

6 Topology Database The topology database (DB) of the network is used for two purposes: (1) for network management, to provide the network administrator with a view of the components in the network and their state, and (2) for network control, to enable route computations algorithms to determine the route for a new lightpath request. Items marked with \NM only" are expected to be used for network management only, while items marked with \NC only" are expected to be used for network control only. Other items are expected to be used by both entities. This topology DB consists of the following elements: 

the network topology, being a graph consisting of the nodes and links in the network, 11

 

 

a data structure containing the characteristics of each node, along with its current status (up/down), a data structure containing the characteristics of each link, namely: { the total number of wavelengths on the link, { the number of wavelengths allocated for backup purposes, or held in reserve by network management, { the link delay, { (NM only) the link segments, each segment representing the portion of the link between two optical ampli ers, or between the end of the link and the closest ampli er, and their status (up/down), { (NC only) end-to-end characteristics of each link, such as bit error rates, crosstalk, SNR etc. if needed (see Sec 2). the current set of established lightpaths (including their wavelength assignment per link), the current status of backup wavelengths (used, free, down).

7 Network Control Network control would be responsible for setting up, taking down and keeping track of lightpaths in the network, as well as handling rerouting of lightpaths in the event of failures. In most large networks today, for example ATM and the Internet, network control is a decentralized function, performed by the control points within each node. This is particularly needed when connections across the network have to be set up and taken down rapidly. In the case of the optical layer however, it is likely that initially, lightpaths have to be set up and taken down somewhat infrequently Thus it may be possible to centralize the setup/takedown function. Later evolution could, however, produce situations in which this frequency is increased and distributed control may be a better choice. An exception to this rule is internetworking between domains (or subnets) belonging to di erent organizations. In this case, it may be desirable to con ne the topology data to a domain, and to perform distributed setup protocols between the domains. Another exception is failure recovery, in which case we may want to reroute lightpaths rapidly. It may thus be preferable to implement this function in a decentralized manner.

7.1 Control/Supervisory Channel Options There are several possibilities for establishing communication between the control points at the nodes: 12

 



We could use a separate out-of-band network, say a TCP/IP network. We could dedicate a wavelength in the network to be a supervisory wavelength and use this wavelength for all communication. Such a wavelength is likely to be required for supervising links with optical ampli ers anyway. We could embed the control PDUs in higher-layer PDUs that use the lightpaths provided by the network, for instance SONET frames or ATM cells. This requires that all nodes in the network be \connected" through a sequence of lightpaths that carry these higher-layer PDUs.

7.2 Route and Wavelength Computation Upon reception of a Lightpath Request from the higher layer, the control point must rst nd a route using a route and wavelength computation (RWC) procedure. for the lightpath that meet the QOS requirements. This will require the topology DB of the network (see Sec. 6).

7.3 Lightpath Setup and Takedown Once the RWC is over, the protocols proposed in [10] can be used to set up and take down lightpaths in a distributed manner. These protocols are message ecient and are proven to be correct. It is also necessary to consider a more simpli ed setup/takedown protocol for centrally managed networks, in which various timing and synchronization issues which occur in the distributed case, are trivially resolved.

8 Network Management 8.1 Introduction Network management is typically a centralized function. Each subnetwork or domain has its own network manager. It is not really necessary for managers of di erent subnetworks to communicate with each other, unless there is a desire to monitor or optimize functions related to multiple subnetworks jointly. Fig. 6 provides an overview of how network management is performed on a typical network (see [12]). The individual components to be managed are the network elements. Each element is managed by its network element manager. The element managers communicate with a network management center using standard protocols such as SNMP or CMIP. The actual communication may use an out-of-band network, or use one of the wavelengths in the network, just as in Sec. 7.1. 13

Network Management Center (NMC)

Inband or out−of−band network CMIP or SNMP Network Element Manager

NEM

NEM

NEM

Fiber Link Segment Optical Amplifier

WDM Crossconnect

NETWORK ELEMENTS

Figure 6: Overview of network management in a typical optical network. Network Management issues can be sorted in a two-dimensional matrix representation of \what are the component Network Management processes" vs. \what are the objects that get subjected to these processes". Breaking the overal NM process down into component subprocesses results in the following well-accepted list [12]: 







Performance management, the process of monitoring the state of health of a reasonably healthy network. Even if there is nothing wrong in the network, it is still desirable to keep track of signal levels, noise levels, crosstalk levels, SNRs, and wavelength drifts, if for no other reason than to anticipate trouble before it happens. Con guration management is the management of orderly scheduled changes in a healthy network, including keeping up with component upgrades the history of which can easily be lost track of in a complex system. Con guration management also includes putting in place longer-term recon gurations necessitated by faults. Fault management is a more dynamic process, consisting of fault monitoring, isolation of the location and nature of the fault, and managing its repair on a timely basis. The latter is often referred to as protection switching. Fault management is a function that may be distributed between network control and management. Rapid and local recovery may be e ected by the control points while in other cases, recovery may be e ected by the network management center. Safety management is particularly important is optical networks due to the high level of optical power involved, A situation that may not be strictly a fault (in the sense that

14

 

network performance is a ected) nor one that requires a permanent recon guration, by nonetheless require attention and quick reaction when eye safety considerations are taken into account. Accounting management involves the collection of statistics on usage for billing and for developing lifetime histories of the network components. Security management involves protection of the users of the system from wiretapping and other unauthorized intrusions that are a consequence of the optical nature of the network. For example, broadcast and select networks are intrinsically vulnerable, so that special measures such as encryption are speci cally indicated for this form of network.

Protocol transparency in optical networks imposes a new requirement on the network management framework since the management mechanism (agent) may have no prior knowledge of the the protocols being used in the network. Furthermore, the agent may no longer have access to the overhead bits that are previously used to transport supervisory information between repeaters or switching sites to perform its management functions. The di erent physical elements that must be the objects of Network Management attention, in all of the above respects, include:  Optical ampli ers, usually EDFAs today.  WDM crossconnects and add/drop multiplexers (ADMs) Particularly exposed to performance and reliability problems are the optical switch subcomponents.  Transmitters and receivers  Passive components such as star couplers, splitters patch panels, and so forth. Since these may fail or may, by their very presence, obscure the ability of the NM process to isolate what is going on, even passive components must be subjected to NM processes. Perhaps the classic example of a passive component that must be monitored is the ber itself, from which we conclude that Optical Time Domain Re ectometers (OTDRs) must be included as part of the Network Management function. Patch panels may be manually con gured or electrically actuated equivalents.  Associated node electronic functions. These include the state of health of NC Control Points, NM Agents and also Subagents (which are usually realized in microprocessors within the physical element) and in general anything about the end nodes and the electronic portions of the intervening nodes that are a consequence of the photonic nature of the Optical Layer.

8.2 Interface between Management and Control As mentioned in Sec. 1.2, network management and control are di erent functions performed within the same network. However the two functions interact with each other in several cases, necessitating the need to standardize an interface between them. 15

The following functions are requested by management from the control points:  

Lightpath setup and takedown, using the primitives de ned in Sec. 3. Rerouting existing lightpaths.

In addition network management updates the topology DB of Sec. 6 when nodes/links are added/deleted, or when their parameters change, for example number of wavelengths provisioned on a link. Network control informs network management of faulty events and any action taken thereof. Network control also updates the topology DB when lightpaths are setup or taken down. We now proceed toward de ning a Network Management architecture for each of these physical element types in such a way that the needs of all the functional subprocesses making up the overall NM process are adequately served.

8.3 Lightpath Design Subsystem The optical layer provides its client networks (ATM, IP) with a exibility to modify their \physical" topology (based on lightpaths) dynamically, according to their changing needs, based on changes in the trac pattern, growth in the network usage, addition of facilities etc. To exploit this exibility, each client network must have the ability to redesign its topology based on changes in the utilization pattern in the network. It is desirable to separate the lightpath design subsystem from the proprietary WDM control layer on one hand, and from the upper layer (client network) control on the other hand, for the following reasons. 



The problem of designing lightpaths based on trac statistics is a hard problem, which has not been yet fully studied (e.g., [11]). Standardizing the interface between the client networks to a subsystem which determines which lightpaths should be set up, will enable WDM network providers to choose a tool from companies who specialize in this design issue, and easily add it to their system. While the optimization of lightpath allocation and its modi cation based on the dynamics of trac, is a subject of emerging reserach, it is already clear that solving the problem for each network separately produces less optimal results than solving the problem jointly, for all the networks that use the same WDM infrastructure. Thus, it is desirable that a single system receives trac statistics data from the multiple higher level networks, and designs lightpaths that optimize their trac requirements, while preserving the scarce resource of wavelengths.

The interface between higher level networks and the lightpath design subsystem (LPDS) includes the following data. A pictorial demonstration of the role of LPDS may be found in Figure 7. 16

ATM

ATM

Higher level network

IP

Traffic Matrix & Design constraints Topology update

Lightpath Design Subsystem Optimize wavelength utilization, subject to client net constraints

Setup/Takedown/Reroute lightpath

Fiber

Optical node

Optical network

lightpath

Figure 7: Functional role of LPDS 1. Current trac matrix, 2. Current virtual topology (in case the client network does not want LPDS to change it), 3. Virtual topology constraints (in case such changes are permitted): number of ports at each higher level node, end-to-end delay constraints etc. After computing a set of required modi cations from the previous con guration to the one re ecting the current trac, LPDS issues lightpath setup, reroute and takedown requests to the WDM control, and informs client networks on changes in the logical topology (in case such changes are permitted by the client network).

8.4 Optical ampli ers References [2, 13] present informative lists of the parameters whose monitoring is being standardized, as well as a list of the emerging standards [14, 15]. Add MIB de nitions for each element.

17

8.5 WDM Crossconnects Discuss protocols proposed by Li and Ramaswami [16].

8.6 Transmitters and Receivers 8.7 Passive Components Discuss protocols proposed by Li and Ramaswami [16].

8.8 Associated Node Electronic Functions

9 Internetworking It is anticipated that WDM networks belonging to di erent organizations, such as carriers and private organizations, will be interconnected optically to form a large WDM network. Such a network will impose additional constraints that do not exist in a network that is entirely owned by a single organization. The main di erence between the cases is that networks belonging to di erent organizations will need separate control mechanisms that do not rely on each other, and may employ di erent considerations and strategies. It is thus important to have a hierarchical view of the network, which does not contain all the topology details at each level. This is similar to the architecture suggested for ATM networks for their Private Network-to-Network Interface (PNNI) [17]. The ATM Forum de nes a multiple-level hierarchy. However it recognizes that implementing multiple hierarchies is complex. In most cases, a two-level hierarchy is likely to suce, and this is what we use for our WDM interworking architecture, shown in Figure 8. In the low level of the hierarchy, each node represents a physical node, and each link a physical ber. This view represents a single subnet, and ignores the rest of the network. At the high level each node represents a subnet, and each link a physical ber that connects nodes in di erent subnets. The address of a physical node must re ect this hierarchy, and will be composed of two parts, the rst of which is to the subnet ID, and the second is the node ID within a subnet. Thus, node \C.4" is in subnet \C", and is the unique node in this subnet with ID \4". Refer to Figure 8 for an example. During lightpath setup, the initiating node examines the destination address. If it lies within the same subnet (by the pre x), it computes the desired route and wavelength(s) and sets up the lightpath as described earlier (centrally or in a distributed manner, depending on the control mechanism in the subnet). If the address has a pre x of another subnet, the initiator consults a speci c node in its subnet (termed the subnet leader) which has the high level topology DB as well (which is unknown to a non-leader node). The leader selects a high level route based on aggregate parameters for each subnet. 18

B A

High level view

C

B.1

B

A.3

C

A.2 C.1 A.4

Low level view C.3

C.2 A.1 A.5

A

Figure 8: A hierarchical topology DB of a WDM network After the RWC is done, and the setup phase begins, each hop in the high level view (through some high level node), is translated into a setup request between the entry point and exit point of subnet represented by the high level node. The full route is composed of these route segments. The topology DB must therefore contain additional data, concerning some aggregate properties of a high level node, for exchange between subnet leaders. For example, this data must contain the current set of available wavelengths between each pair of ports and the aggregate propagation delay. The necessary data to represent a high level node is for further research.

A Design of Virtual Topologies [11]

B Distributed Control Protocols [10]

References [1] P. E. Green, Fiber-Optic Networks. Prentice Hall, 1992. [2] L. Clark, \Standards activities toward WDM networking," in First IEEE COMSOC workshop on WDM Optical Network Management and Control, June 18 1995. 19

[3] A. McGuire et al., \Functional architecture for optical networks," BT Technol. J., vol. 13, April 1995. [4] R. Ramaswami and K. N. Sivarajan, \Routing and wavelength assignment in all-optical networks," IEEE/ACM Trans. on Networking, pp. 489{500, Oct. 1995. An earlier version appeared in Infocom'94. [5] I. Chlamtac, A. Ganz, and G. Karmi, \Lightpath communications: an approach to high-bandwidth optical WAN's," IEEE Trans. on Commun., vol. 40, pp. 1171{1182, July 1992. [6] G. R. Hill et al., \A transport network layer based on optical network elements," IEEE/OSA J. Lightwave Tech., vol. 11, pp. 667{679, May/June 1993. [7] C. A. Brackett et al., \A scalable multiwavelength multihop optical network: a proposal for research on all-optical networks," IEEE/OSA J. Lightwave Tech., vol. 11, pp. 736{ 753, May/June 1993. [8] P. E. Green, F. J. Janniello, and R. Ramaswami, \Multichannel protocol-transparent wdm distance extension using remodulation," IEEE JSAC/JLT Special Issue on Optical Networks, June 1996. [9] K. Bala, R. R. Cordell, and E. L. Goldstein, \The case for opaque multiwavelength optical networks," in IEEE LEOS Summer Topical Meetings, August 1995. [10] R. Ramaswami and A. Segall, \Distributed network control for wavelength-routed optical networks," in Proc. Infocom'96, 1996. To appear. [11] R. Ramaswami and K. N. Sivarajan, \Design of logical topologies for wavelength-routed optical networks," IEEE JSAC/JLT Special Issue on Optical Networks, June 1996. Also appeared in Proc. Infocom'95. [12] S. Aidarus and T. Plevyak, eds., Telecommunications Network Management into the 21st Century. IEEE Press, 1994. [13] R. E. Tench, \Control, telemetry and performance monitoring in wdm lightwave systems using oas," in First IEEE COMSOC workshop on WDM Optical Network Management and Control, June 18 1995. [14] ITU, Draft Rec. G.mcs: Optical interfaces for multichannel systems with optical ampli ers, 1995. [15] ITU SG15/WP 4, Draft Rec. G.lon: Functional characteristics of interoce and longhaul line systems using optical ampli ers, including optical multiplexing, Nov. 1995. [16] C.-S. Li and R. Ramaswami, \Fault detection and isolation in transparent all-optical networks," in Submitted to Globecom'96. [17] ATM Forum 94-0471R15, PNNI Draft Speci cation, 1995. Available from http://isscw3.raleigh.ibm.com/netstd/ le/standard/Subject/pnni/Documents/documents.html. 20