Today's SONET/SDH-based networks provide high levels of reliability founded on mature and stable technologies. However, these networks are not poised to meet the demands of the impending bandwidth revolution. Deployment of high-speed last mile access technologies such as xDSL, passive optical networking (PON), and cable modems has placed pressure on access routers. Improvements in speed and density of access routers, in turn, place pressure on Internet backbone elements including core IP routers and long-haul optical backbone networks.
This oscillating cycle has made it difficult for communication systems designers to create any kind of equilibrium. When problems are solved in the core, pressure is again applied to develop higher speed and higher density access technologies.
Today's optical network architectures based on SONET/SDH consist of access and aggregation facilities that provide connectivity from a customer's local premises into a high-speed transport backbone (see Figure 1). This backbone is built on SONET/SDH rings, linking metropolitan nodes, and also interconnecting metropolitan regions. A typical trans-continental communication link may consist of many SONET/SDH segments, each a segment of a local ring, all joined to form an end-to-end path.
While technologies such as dense wavelength division multiplexing (DWDM) have relieved immediate bandwidth shortages, issues related to today's SONET/SDH architecture, management, and efficiency are growing increasingly problematic. Provisioning paths through SONET/SDH networks, currently a manual and time-consuming process, is a slow and costly process for carriers. The increasing growth of the Internet and related applications is placing new pressures on optical transport networks, creating path provisioning and management challenges, and bringing with it an increased need for sophisticated protocols that provide the intelligence for fast, scalable and self managed networks.
Provisioning paths for short-duration use (for example, for a several-hour Webcast) is virtually impossible. Adding or increasing levels of service in a network involves high-level coordination of the many changes required to the SONET/SDH add/drop multiplexers (ADM) and digital cross connect (DCS) switches along the path. These changes aretypically made manually, and require trained service personnel to be present at the equipment site. Despite this unwieldy process, these change are analogous to simply patching signals from one fiber to another.
Today's networks are highly resilient, yet rigid. The automatic protection switching features of SONET/SDH have provided a reliable, consistent method of restoring transmission faults. However, they require valuable bandwidth resources to be reserved as idle standby, regardless of the application.
The new generation of optical transport networks incorporate high capacity switching fabrics with modified versions of routing and signaling protocols traditionally used for data networking. By comparison, SONET/SDH networks are cumbersome to install and manage, inefficient in their use of fiber resources, and do not scale well to support large random topologies. Intelligent optical mesh networks hold promise to become more scalable, manageable and efficient.
Overlay vs. integrated
Two of the most common architectures used in today's mesh optical networks are the overlay model and the integrated model. Much of the work of today's standards and interoperability bodies focuses on these two models, particularly in defining how client devices, such as routers, interact with the optical network.
The overlay model allows an optical network client, such as a router, to signal a request for a connection using a simple signaling interface called the user to network interface (UNI) ( see Figure 2). The UNI generally provides several primitive functions including discovery of port connectivity to neighbor, service level capability of neighbor, creating, deleting, and modifying a connection.
Topology information is hidden from the client, and only reachable client addresses are exchanged at the time the connection is created. Routing decisions are made within the domain of the optical network, usually by the ingress optical network element. UNI protocols currently under development are either based upon existing IP protocols, such as resource reservation protocol with traffic engineering (RSVP-TE) or label distribution protocol with constraint based routing (CR-LDP) in the case of the Optical Internetworking Forum (OIF), or new IP protocols such as those developed by the optical domain services coalition (ODSI). It is important to note that the overlay model does not support the use of explicit routing by the client.
The integrated model, (see Figure 3), as proposed by the generalized multiprotocol label switching (GMPLS), takes advantage of topology information provided by modified routing protocol, such as OSPF, ISIS, or BGP-4. Signaling is performed using GMPLS variants of RSVP-TE or CR-LDP similar to the overlay model, but including an explicit route object (ERO). Client devices, such as routers, are able to explicitly specify the complete route for a connection by including the address of each node that a connection should traverse within the ERO. Applications which do not have concerns about exposing topology to clients may favor the integrated model, as it allows for tighter integration with existing MPLS-based traffic management techniques.
Both the overlay and integrated model require the deployment of a set of signaling, routing, and restoration protocols within the optical network, over the network node interface (NNI) as indicated in Figure 4. In some cases, these protocols have been adapted from MPLS or private network-network interface (PNNI) protocols used for traffic management in IP and ATM networks.
Use of these protocols allows the network itself to be responsible for inventory management, resource allocations and fault management. Each optical cross connect (OXC) becomes aware of network resources, their utilization, and any faults that may have occurred. In turn, any node is able to respond to resource requests, route new or reroute failed
connections, and make efficient use of network resources. Because these protocols are distributed in nature, they are resilient to failure. A single CPU failure does not result in loss of topology information, as might occur in a centralized system.
Control plane message transport
Optical network clients produce a variety of payload types, including IP, ATM, voice, video, and tributaries of legacy services. Because of this variety, it is not possible to carry network control information within the payload of the transport service. Control plane messages for the optical network must be transported through unused overhead bytes,
separate dedicated wavelengths, or a completely separate network.
Out-of-band, out-of-fiber (OOB-OOF) uses a completely independent network to carry control plane messages for the optical network. This usually consists of a simple IP-over-Ethernet network for connections within a central office. When equipment is not co-located in such an environment, a WAN infrastructure must be deployed to transport
these IP-based messages between central offices.
OOB-OOF is usually a popular choice for development environments, allowing easy prototyping of control plane software on PCs or workstations. Caution must be used when employing out-of-band, out-of-fiber in a live network, as failure of the control plane network could cause outages within the transport network. The control plane network must be
at least as reliable as the transport network it manages.
Out-of-band, in-fiber (OOB-IF) employs a separate wavelength dedicated to the transport of signaling messages. This wavelength is usually located in an unused waveband to simplify muxing and demuxing. Often, this separate wavelength carries IP control messages via Fast Ethernet, OC-3 packet over SONET (POS), or OC-3 ATM. Each implementation, however, is usually different, and there is little interoperability between vendors. OOB-IF is most suitable for highly transparent optical networks that switch using opticalswitching fabrics, such as micro electro-mechanical systems (MEMS) or bubbles.
Up to 80 Mbps of an OC-48/STM-16 signal's overhead is unused. In-band, in-fiber (IB-IF) makes use of unused SONET/SDH overhead for control plane transport. SONET and SDH standards already define the use of the first column of D bytes for transport of management information. Section DCC uses bytes D1 through D3 and provides up to 192 kbps. Line DCC uses bytes D4 through D12 providing up to 576 kbps. ITU-T Q.921 defines the layer 2 protocol for transport of these messages as link access protocol-D channel (LAP-D). LAP-D uses bit-oriented (HDLC) to encode messages onto the synchronous transport channel.
An alternative to LAP-D is the point-to-point protocol (PPP) defined by IETF RFC 1662. When PPP is applied to SONET/SDH overhead it also deploys bit-oriented HDLC and FCS16, but defines a header different to that of LAP-D. Both LAP-D and PPP can carry a wide variety of IETF or OSI protocols.
Resource and topology discovery
Optical networks employ neighbor discovery, service discovery, and routing protocols to realize plug and play networks. Neighbor and service discovery protocols based upon the link management protocol (LMP) allow the discovery of interconnections to directly connected nodes. Topology discovery protocols allow the advertisement of these connections throughout the network.
While neighbor and service discovery occurs, peers will attempt to establish an adjacency for the routing protocol employed. For OSPF, this involves sending a routing hello message to the neighbor, and expecting a hello message in return. Once a hello adjacency has been established, and all of the links have been discovered, links are advertised in a link state advertisement (LSA). LSAs are eventually flooded to all nodes in the network, thus allowing each node to build a complete and identical link state database or network map.
Once synchronized, traffic engineering extensions allow routing instances to share resource utilization information. The information could be in the form of occupied or reserved links within the network and their relative importance. Sharing this information allows routing decisions to take into account the available resource within the network, and
provide the ability to pre-empt low-priority users with high-priority users.
Of course, optical extensions need to be applied to routing protocols to take into account optical concepts instead of MPLS concepts. For example, a label-switched path is replaced with an optical connection, and an MPLS label is replaced with a generalized label. IETF drafts on generalized MPLS define these new parameters.
Once a complete map of the network has been determined through discovery and adjacency establishment, OXCs can begin establishing connections through the network. These connections can be requested by client devices through the UNI, or they can be initiated through a network management system (NMS) request.
In the case of RSVP, a path message may be sent via the UNI to an ingress OXC. This message contains information including destination address, required bandwidth, transparency and other connection requirements. The ingress OXC examines this request, computes a path from information available in the link state database, and initiates a connection request within the network.
This interior connection request may also consist of an RSVP message or may be based upon another signaling protocol. It will contain much of the original information of the UNI request but will also include an explicit route object (ERO) which describes the path, as determined through path computation. If the request is acceptable, the far-end device responds with a ResV message that flows back to the originator. In addition, a failover path may also be pre-computed and reserved using the same mechanisms.
Upon reservation of resources, the change in available resources is flooded through the network via the routing protocol, allowing future route computations to consider this new level of available bandwidth.
New testing horizons
Testing and verification of networking devices can typically be broken down into a series of stages. Each stage involves building a level of confidence that allows progression to the next stage. This is no different for optical networking devices; only a higher level of confidence is required. These stages are not normally sequential, but usually take place
concurrently, with results feeding back down the chain. For example, a failure identified during an alpha trial can result in further stress testing.
All stages in this test regime are essential to improving network reliability and confidence. For high reliability, optical network conformance testing should be considered one of the most significant stages.
Ensuring functional conformance to standards is a crucial step to achieving interoperability and reliability. Protocol specifications are never perfect and are always open to interpretation. Many network failures can be attributed to differences in the implementation of a control plane protocol that causes two network elements to interoperate in an
unpredictable way and, in some cases, to spread this unpredictable operation throughout an entire network. A conformance test suite provides a means of aligning the interpretations of protocol specification and of testing responses to both positive and negative stimuli.
A conformance test suite consists of a series of test groups, with each group containing many test cases. Test groups may focus on aspects or subsets of a protocol, while each test case is targeted at a particular parameter or action of the protocol. Conformance tests begin with the simplest operation and gradually build test complexity by exercising protocol
functions in a positive manner.
When testing an edge device, a single test port is usually sufficient for basic conformance testing. How-ever, client devices supporting multi-homing for redundancy will require multiport testing. Topology emulation is required when a client device implements the integrated model. The test port must simultaneously exercise both the routing and signaling
functions of an optical client. The test port would first advertise a topology via a routing protocol, and then use a signaling protocol to observe that routes selected by the system under test match available resources. The test port may also reject explicit route requests and observe whether the client correctly recalculates an alternate path, otherwise known as crank-back testing.
Optical network elements, devices that form part of the core optical network, require three or more test ports to sufficiently exercise routing and signaling protocols. A test manager coordinates stimuli, and then collects and displays results. Initial tests focus on exercising routing functions to ensure that topology advertisement and discovery operate
correctly. Routing functions require testing in conjunction with link management to ensure that all links are learned correctly.
Once topologies are established, testing can focus on signaling protocols by passing resource requests into a port and expecting the request at another port. Scenarios that are more complex can then be developed to exercise crank-back or failed circuit re-routing through the signaling protocol. Finally, positive testing should involve observing the routing
protocol that is flooding resource usage information through the network, as the signaling protocol reserves and releases resources.
Negative test cases
Once positive actions have been verified, the test suite's focus shifts to negative test cases. Negative test cases are intended to simulate error conditions that may be experienced in a live network. These negative test cases are the key to proving robustness by representing real-world events that may corrupt, confuse, or crash the optical control plane. To
emulate this negative stimulus, the tester must be capable of generating illegal states, corrupt or malformed messages, or failures to respond.
Optical designers will face these complex testing scenarios repeatedly when making choices regarding core network architectures, signaling transport models, and implementation of key signaling protocols. While standards and interoperability models are still emerging, designers who participate in early-stage education will reap the benefits of bringing their products to market earlier.
Cary Wright is the R&D project manager at Agilent Technologies' Advanced Networks Division. He is a participant in both the OIF and IETF organizations. He can be reached at
cary_wright@agilent.com.
