4.4.8 Control Architectures and Controllers

In this section, we examine the various architectures of the controller function. Thus, the main controller for large nodes is always duplex (an active controller and a standby controller), the shelf controller may be simplex or duplex, and the unit controller is always simplex. Similarly, the processing power, power dissipation, number of interfaces, and physical size of the main controller is much more than the controller of a lower level. For example, a unit controller may consist of a microprocessor/microcontroller at few MHz and few mW supporting one interface port, and a main controller may be at the THz level, consuming several watts and supporting many interface ports.

Depending on node bandwidth capacity and architecture philosophy, the control architecture may be centralized, distributed, or hierarchical.

4.4.8.1 Centralized Control

Centralized control is more pervasive in small systems. In this case, the star control architecture is used where a central controller polls several peripheral units (Fig. 4.29). The peripheral units may have a local controller (typically a microprocessor), or they may have a stack of registers, a multiplexer, and an interface driver. The bit rate between the central controller and the peripheral units depends on the number of units polled and on the real-time requirements of the system. Typically, it is a standard Ethernet rate, 10/100Base-T and does not exceed the 1 GbE.

4.4.8.2 Distributed Control

Distributed control is more suitable to a mesh LAN that collectively executes a function (such as parallel processing, route finding, neighborhood discovery, automatic restoration, and shelf-healing). In this case, each node requires knowledge of the node type and performance parameters of all nodes in the network (Fig. 4.30). One or two (for redundancy) nodes in the mesh network have been assigned the responsibility to communicate with the network operating system for provisioning and performance monitoring. The control channel is either embedded in the information channel or is carried in a supervisory optical channel at a rate under 100 Mb/s.

Figure 4.29 A typical centralized control architecture.

Figure 4.30 A typical distributed control architecture.

4.4.8.3 Hierarchical Control

In large systems, functional units are partitioned into logical groups with a hierarchical structure for system scalability and growability, fast provisioning, efficient performance monitoring, effective fault management, and fast protection. In such systems, each unit may have its own local microcontroller (if required), each group has its own shelf controller that may be duplex or simplex, and a main system controller (typically duplex) that communicates with all shelf controllers and with the network. Communication interfaces among the layered-structured controllers takes place over a separate Ethernet link, with a tree or ring topology and using either a standard protocol or a modified standard protocol to meet special system needs; however, modified standard interfaces come at a premium as new devices must be designed and manufactured (and not low-cost off-the-shelf (OTS)). Typically, the bit rate between system and shelf controllers is high (1 GbE) and the bit rate between shelf and unit controllers is low (10-100 Mb/s); Figure 4.31 depicts a control hierarchical architecture.

Figure 4.31 A typical hierarchical control architecture for a large DWDM system.

4.4.8.4 Software Domains

Regardless of control architecture, there is an "unseen" layer of software architecture that works in concert with the hardware. Software is organized into domains, each corresponding to a major system function (domain), and manages performance, equipment self-discovery and provisioning, faults, equipment protection, power, cross-connection, synchronization, transmission protection; it also executes communications protocols, both internal and external. The software strategy may be distributed or centralized. Distributed software implies that each unit executes one or more appropriate domains and process collected raw data pertaining to performance, fault, statistics, and so on. It may exchange some high-level information and all together encompass the system software control; this case is more suitable in the distributed control architecture. Centralized software implies that performance, fault, statistical and so on raw data are sent, by various distributed and specialized agents that reside on each functional unit, to a main (or master) software where processing (filtering, correlation, and action) takes place. This architecture is most suitable for distributed control.

Systems/nodes are designed with different requirements and specifications, the complexity of which depends on supported service(s), network architecture, topology and layer (see previous Chapter), and engineering specifications determined by standards. As an example, the switching fabric may be small or large; it may be relatively slow (msec) or very fast (μsec or faster); it may be simple (16 x 16) or complex (1,000 x 1,000); it may cross-connect OC-Ns (e.g., OC-3 at 155.52 Mb/s), or DS-Ns (e.g., DS1 at 1.5 Mb/s or DS0 at 64 Kb/s), or it may cross-connect packets (e.g., Frame Relay, ATM, IP). In data systems, the ports (input and output) are very similar, the controller is similar in functionality but different in terms of protocols as well as performance and O&AM requirements and switching is achieved with a large (memory) buffer. Moreover, the cross-connecting fabric may be static or dynamic, it may be simplex (a single fabric) or duplex (a duplicated fabric) and it may be blocking or nonblocking. Although a simplex fabric provides lower cost of operation, it should be highly reliable with fewer expected mean failures; simplex fabrics are used in low to medium capacity systems. Duplex fabrics are more complex and they are designed such that when one fabric fails the other continues service without interruption; duplex fabrics are used in medium and high capacity systems that require high reliability of service (some examples are systems that cross-connect stock market data, airport traffic control, and so on). In general, blocking was used in legacy statistical switches engineered to handle an average traffic without service interruption; however, the bandwidth per service was in the order of DS3 rates. In DWDM optical systems where the order is more than 100 times that, blocking is highly undesirable. However, in dynamically wavelength configurable DWDM networks, blocking may have merit in the sense that as wavelengths are switched from one fiber to another, under certain circumstances this may not be possible.

As another example, a system may execute a "call processing" (TDM, telephony) or a "call admission control" (ATM) algorithm according to which a connection is established (in connectionless architectures such as IP the path establishing mechanism is distributed). For example, each time a telephone handset is lifted and a number is dialed, a call initiation timed-protocol is executed (e.g., TR-08, TR-303, and SS7). Similarly, in certain local area networks when a request to transmit is sent a timed-protocol may be executed; timed-protocols are those that execute message requests and responses the interval of which is timed. In "connection-full" network architectures, systems that execute such protocols are typically at the "edge" of the network, that is, at the point where the communications network receives subscriber requests and where routing decisions as well as service level agreement (SLA) verifications are made. In "connection-less" network architectures with distributed control, each node in the network executes an input-output connecting algorithm individually to establish a path between origin and destination; in this case, all nodes on the path are involved in this process and this is one of the reasons that such networks cannot match the real-time aspects of the "connection" network. Thus, the complexity of each node/system depends on many factors; among them the type(s) of supported services, bandwidth capacity, number of ports, real-time requirements, and which network (layer) the system belongs to.

In the following sections, we look into some variations of DWDM system architectures, their complexities, and related issues. In particular, we describe the architecture of a Metro-node and of a point-to-point long haul-node and their issues. This description by no means should be interpreted as a detailed guideline for system design, as such guidelines do not publicly exist, but as a foundation that enhances understanding and on which system developers and others can build. A complete description would require a lengthy engineering specification compliant to many standards and recommendations that is far beyond the scope of this book.