Despite the fact that optical fiber communications has been an active area of research since the early 1970s and optical transmission facilities have been widely deployed since the 1980s, serious activity in optical networking did not reach beyond the laboratory until the 1990s. It was in the early 1990s that a number of ambitious optical network testbed projects were initiated in the United States, Europe, and Japan. Although the testbeds were largely government financed, they planted the seeds for subsequent commercial developments, many of which were spin-offs of the testbed activities. The commercial ventures benefited from the knowledge accumulated from the testbeds as well as from the burgeoning worldwide demand for bandwidth. As a result, multiwavelength optical networks are deployed today in metropolitan area as well as wide area applications with increasing current activity in local access as well. In this chapter we give an overview of current developments in metropolitan and wide area networks. Recent developments in access networks were discussed in detail in Chapter 5. The chapter begins with a brief discussion of the role of business drivers and relative costs in creating the current trends. This is followed by a summary of the early testbed projects in the United States and Europe, which provides the context for a description of current commercial activity in multiwavelength metro and long-haul networks. We continue with a discussion of new applications and services made possible by the unique features of intelligent optical networks, and conclude with some thoughts for the future.

In this chapter we explore the structure, design, and performance of purely optical networks with electronically switched overlays. These are the logically-routed networks (LRNs) that were introduced in Section 3.5. Typical examples of LRNs are networks of SONET digital cross-connects (DCSs), networks of IP/MPLS routers, and ATM networks carried on a SONET DCS layer. To provide maximum flexibility, the LRN should be carried on top of a reconfigurable optical network. Although we generally refer to the underlying infrastructure as “purely optical” (that is, transparent), we shall, from time to time, relax that requirement to include optical networks having some degree of opacity on their transmission links.

Introduction: Why Logically-Routed Networks?

The rationale for using logical switching on top of a purely optical infrastructure has been discussed at various points throughout the book. The number of stations in a purely optical network cannot be increased indefinitely without running into a connectivity bottleneck. The sources of the bottleneck are the resource limitations within the network (fibers and optical spectrum) and within the access stations (optical transceivers).

Figure 7.1(a) illustrates the bottleneck in a purely optical network. Network access station (NAS) A has established logical connections (LCs), shown as dashed lines in the figure, that fan out to stations B, C, and D. If this is a wavelength-routed network (WRN), each LC is carried on a separate point-to-point optical connection; that is, three optical transceivers and three distinct wavelengths are required (assuming that the stations have single fiber pair access links).

The multiwavelength network architecture described in Section 2.1 contains several layers of connections. By exploiting the various alternatives in each layer, it is possible to produce a rich set of transport network configurations. This chapter explores how a desired connectivity pattern can be established using the combined functionality contained in the various layers. The approach is to examine the properties of different classes of networks through a sequence of simple illustrative examples. The design objective in each example is to provide a prescribed connectivity to a set of end systems. Each of the network classes illustrated in this chapter is discussed in more detail in later chapters, as is the issue of optical network control.

Our first example is shown in Figure 3.1. Five geographically dispersed end systems are to be fully interconnected by a transport network, which is to be specified. The end systems might correspond to physical devices such as supercomputers that interact with each other, or they may be gateways (interfaces) to local access subnets (LASs) serving industrial sites, university campuses, or residential neighborhoods.

In all of these cases, a dedicated set of connections is desired (shown as dashed lines in the figure), providing full connectivity among all the sites. Figure 3.2(a) shows one possible transport network, whose physical topology (PT) is a star, in which the central node is a star coupler of the type shown in Figure 2.7(a). Each end system is connected to the star through its own network access station.

In Chapter 2 we proposed a layered view of the connections in an optical network, focusing primarily on issues associated with optical layer transport but including a discussion of transport in logical network (e.g., IP network) overlays as well. Then in Section 3.1 we encountered a different way of “slicing” the functionality of an optical network, distinguishing three planes: transport, control, and management. In general terms, the transport plane is responsible for the physical transfer of data across an optical network, the control plane provides the intelligence required for the provisioning and maintenance (e.g., failure recovery operations) of a connection, and the management plane provides management services such as performance monitoring, fault and configuration management, accounting and security management. This chapter provides a summary of the current state of optical network control, which is a broad and rapidly evolving subject. The reader is referred to texts completely devoted to the subject of control (e.g., [Bernstein+04] for a more comprehensive treatment).

The line between management and control is not clearly defined. But roughly speaking, management functions deal with long-term issues and operate on slow timescales, whereas control functions are associated with rapid changes in network configurations and operate on short timescales. For example, the repair of a network fault such as a cut cable would be a management function. It might require days or weeks. On the other hand, “point-and-click” provisioning, where a network user controls the provisioning and configuration of a connection, is a control function.

Graph and hypergraph terminology has evolved over the years. The following definitions are adapted from [Berge89, Bermond+97, Chartrand+96]. Some of the material in this appendix is found in other parts of the book. It is repeated here for convenience.

Graphs

A graph G consists of a set of vertices V(G) and a set of edges E(G), where each edge e is a pair of distinct vertices (u, v). (If the two vertices are the same, then the edge is a loop. We rule out these cases.) A graph with vertex set V and edge set E is typically denoted by G(V, E). If e = (u, v), then u and v are adjacent vertices and e is incident on u and v. Two edges are adjacent if they are incident on the same vertex. Nonadjacent edges or nonadjacent vertices are called independent. A set of pairwise independent vertices of a graph G, which is of maximal cardinality, is called a maximal independent set. Figure A.1 shows an example of a maximal independent set of vertices (outlined in dashed circles).

A graph in which every two vertices are adjacent is called a complete or fully connected graph. The complete graph with n vertices is denoted by Kn. Figure A.2 shows K5.

A graph G is called bipartite if its vertices can be partitioned into two subsets, V1 and V2, (called partite sets) such that every edge of G joins a vertex in V1 to one in V2.

The Internet has become an integral part of our society. It not only supports financial transactions and access to knowledge, but also cultivates relationships and allows people to participate in communities that were hard to find before its existence. From reading the news, to shopping, to making phone calls and watching videos, the Internet has certainly surpassed the expectations of its creators.

This vital organ in today's society comprises a large number of networks, administered by different authorities and spanning the entire globe. In this book, we will take a deep look into what constitutes those entities and how they form the skeleton of the Internet. Going beyond the physical infrastructure, the wires and boxes that make up the building blocks of today's Internet, we will study the procedures that allow a network to make optimal use of those building blocks.

As in traditional telecommunication networks, the Internet constituents rely on a team of network designers and managers, for their design, operation and maintenance. While such functions are well studied within the traditional telecommunication theory literature, the Internet imposes constraints that necessitate a whole new array of methods and techniques for the efficient operation of a network. Departing from the traditional circuit-switched paradigm, every unit of information flows independently across the network, from the source to the destination, and thus is much harder to account for.

Since the late 1990s, the research community has been devising techniques that allow the operators of this new kind of network to allocate and manage their networks' resources optimally.

The Internet is made of many separate routing domains called Autonomous Systems (ASs), each of which runs an IGP such as IS–IS or OSPF. The IGP handles routes to destinations within the AS, but does not calculate routes beyond the AS boundary. Internet Gateway Protocol engineering (or traffic engineering or IGP optimization) is the tuning of local IS–IS or OSPF metrics to improve performance within the AS. Today, IGP engineering is an ad-hoc process where metric tuning is performed by each AS in isolation. That is, each AS optimizes paths within its local network for traffic traversing it without coordinating these changes with neighboring ASs. The primary assumption behind such an assertion is that there is sufficient separation between intra-domain and inter-domain routing.

Beyond the AS boundary, the choice of AS hops is determined by the BGP,; BGP engineering is a less developed and less understood process compared to IGP engineering. In addition to whether there is a physical link between two ASs over which routes and traffic can flow, there are several BGP policies that determine which inter-domain paths are exposed to a neighboring AS. Business peering policies can directly translate into which routes are exported to each AS. After all these policies are applied, the remaining feasible paths are subjected to the “hot-potato” routing policy. Hot-potato routing occurs when there are multiple egress points to reach a destination.

In order to compile flow statistics, each router maintains a table of records indexed by flow key, e.g. 5-tuple of the flow. A flow is said to be active at a given time if there exists a record for its key. When a packet arrives at the router, the router determines if a flow is active for that key. If not, it instantiates a new record for that key. The statistics for the flow are updated for the packet, typically including counters for packets and bytes and arrival times of the first and most recent packet of the flow. Due to the fact that the router does not have knowledge of application-level flow structure, it must terminate the flow according to some criteria. The most commonly used criteria are the following: (i) inter-packet timeout, e.g. the time since the last packet observed for the flow exceeds some threshold; (ii) protocol syntax, e.g. observation of a FIN or RST packet of the TCP flow; (iii) aging, e.g. flows are terminated after a given elapsed time since the arrival of the first packet of the flow; (iv) memory management, e.g. flows might be terminated at any point in time to release memory. When a flow is terminated, its statistics are flushed for export and the associated memory is released for use by new flows.

Before embarking on the exploration of techniques to assist operators in the management and design of IP networks, this chapter lays the foundation of the terms and concepts that will be used in the rest of the book. We describe the Internet architecture and the elements and protocols guiding its behavior. We then outline issues associated with the design, management, optimization and security of such a complex infrastructure, topics that will be the focal points in the following chapters.

What is the Internet?

The Internet is a diverse collection of independent networks, interlinked to provide its users with the appearance of a single, uniform network. Two factors shield the user from the complex realities that lie behind the illusion of seamlessness: (i) the use of a standard set of protocols to communicate across networks and (ii) the efforts of the companies and organizations that operate the Internet's different networks to keep its elements interconnected.

The networks that comprise the Internet share a common architecture (how the components of the networks inter-relate) and software protocols (standards governing the exchange of data), which enable communication within and among the constituent networks. The nature of these two abstract elements – architecture and protocols – is driven by the set of fundamental design principles adopted by the early builders of the Internet. It is important to distinguish between the public Internet and the Internet's core technology (standard protocols and routers), which are frequently called “IP technology.”

Classifying traffic flows according to the application that generates them is an important task for (a) effective network planning and design and (b) monitoring the trends of the applications in operational networks. However, an accurate method that can reliably identify the generating application of a flow is still to be developed. In this chapter and the next, we look into the problem of traffic classification; the ultimate goal is to provide network operators with algorithms that will provide a meaningful classification per application, and, if this is infeasible, with useful insight into the traffic behavior. The latter may facilitate the detection of abnormalities in the traffic, malicious behavior or the identification of novel applications.

State of the art and context

Currently, application classification practices rely to a large extent on the use of transport-layer port numbers. While this practice may have been effective in the early days of the Internet, port numbers currently provide limited information. Often, applications and users are not cooperative and, intentionally or not, use inconsistent ports. Thus, “reliable” traffic classification requires packet-payload examination, which is scarcely an option due to: (a) hardware and complexity limitations, (b) privacy and legal issues, (c) payload encryption by the applications.

Taking into account empirical application trends and the increasing use of encryption, we conjecture that traffic classifiers of the future will need to classify traffic “in the dark.”

As networks continue to grow rapidly in size and complexity, it has become increasingly clear that their evolution is closely tied to a detailed understanding of network traffic. Large IP networks are designed with the goal of providing high availability and low delay/loss while keeping operational complexity and cost low. Meeting these goals is a highly challenging task and can only be achieved through a detailed knowledge of the network and its dynamics.

No matter how surprising this may seem, IP network management today is primarily reactive in nature and relies on trial and error when problems arise. Network operators have limited visibility into the traffic that flows on top of their network, the operational state of the network elements and the behavior of the protocols responsible for the routing of traffic and the reliable transmission of packets from end to end. Furthermore, design and planning decisions only partially rely on actual usage patterns. There are a few reasons behind such a phenomenon.

First, the designers of IP networks have traditionally attached less importance to network monitoring and resource accounting than to issues such as distributed management, robustness to failures and support for diverse services and protocols. Thus, IP network elements (routers and end hosts) have not been designed to retain detailed information about the traffic flowing through them, and IP protocols typically do not provide detailed information about the state of the underlying network.

The traffic matrix (TM) of a telecommunications network measures the total amount of traffic entering the network from any ingress point and destined to any egress point. The knowledge captured in the TM constitutes an essential input for optimal network design, traffic engineering and capacity planning. Despite its importance, however, the TM for an IP network is a quantity that has remained elusive to capture via direct measurement. The reasons for this are multiple. First, the computation of the TM requires the collection of flow statistics across the entire edge of the network, which may not be supported by all the network elements. Second, these statistics need to be shipped to a central location for appropriate processing. The shipping costs, coupled with the frequency with which such data would be shipped, translate to communications overhead, while the processing cost at the central location translates to computational overhead. Lastly, given the granularity at which flow statistics are collected with today's technology on a router, the construction of the TM requires explicit information on the state of the routing protocols, as well as the configuration of the network elements. The storage overhead at the central location thus includes routing state and configuration information. It has been widely believed that these overheads would be so significant as to render computation of backbone TMs, through measurement alone, not viable using today's flow monitors.