next up previous
Next: 6.3 Packet switching in Up: 6. Related work Previous: 6.1 Introduction

Subsections


6.2 Circuit switching in the Internet

As mentioned in Chapter 1, it is becoming increasingly difficult to build high-performance packet-switched routers. This is due to several reasons, but the primary reason is because traffic is growing faster than electronic technology in general, and memory access speeds in particular. This calls for research into alternatives to packet switching. One of these alternatives, which has also been explored by other researchers, is to integrate very high-capacity optical circuit switches in the core of an otherwise packet-switched Internet. Four main dynamic signaling mechanisms have been proposed to manage circuits in SONET/SDH and DWDM networks: Generalized Multiprotocol Label Switching -- GMPLS -- (Section 6.2.1), Automatic Switched Transport Network -- ASTN -- (Section 6.2.2), Optical Internetworking Forum -- OIF -- (Section 6.2.3), and Optical Domain Service Interconnect -- ODSI -- (Section 6.2.4). For each of these four approaches, a working group has defined signaling mechanisms for managing circuits, but leave it to vendors to define how to monitor traffic, when to trigger a new circuit establishment, and how much bandwidth to allocate.

Two architectures have been proposed to help decide when to create a circuit and how much bandwidth to give to it. The first is Optical Burst Switching -- OBS -- (Section 6.3), in which a router at the edge of the network queues packets up to a threshold and then establishes a circuit with an explicit or implicit connection release time (also known as a burst). The second technique, proposed by Veeraraghavan et al. (Section 6.2.6), defines an end-to-end, circuit-switched network that is parallel to the packet-switched Internet. In their scheme only large files are transmitted across the circuit-switched network.

The approach proposed in Chapter 4, TCP Switching, differs from both approaches above in that it (usually) piggybacks the creation of a circuit on the setup phase of a TCP connection. In this respect, TCP Switching is similar to IP Switching (Section 6.2.7), in which flows trigger the establishment of ATM virtual circuits. In contrast, Chapter 5 focuses on the coarse circuits that interconnect boundary routers around the core. It monitors user flows to estimate the required capacity for those circuits.


6.2.1 Generalized Multi-Protocol Label Switching (GMPLS)

Multi-Protocol Label Switching (MPLS) [165] is a packet-switching technique proposed by the Internet Engineering Task Force (IETF) for traffic engineering that uses labels to identify flows. These flows may be of any granularity, ranging from fine user flows to coarse inter-router flows. Each flow follows a different label-switched path. Labels are identifiers that are local to each link, and so a flow label has to be swapped at each node with the local label for the next link.

GMPLS [7,8] has been proposed within the Common Control and Measurement Plane (ccamp) work group in IETF as a way to extend MPLS to incorporate circuit switching in the time, frequency and space domains. Label-switched paths now may consist of a chain of SONET/SDH channels, wavelengths or fibers with a minimum capacity of at least 51 Mbit/s. The extensions of GMPLS define the signaling for the establishment, routing, protection, restoration, deletion and management of coarse label-switched paths that are circuit switched. As of April 2003, there are three published Requests For Comments (RFC's) on the standards track (one for the signaling functional description and two for the signaling protocols -- CR-LDP and RSVP-TE --, which will be briefly described below). In addition, there are 20 Internet Drafts in progress.

GMPLS uses the same mechanisms as MPLS to decide when to create or destroy a circuit. GMPLS relies on either a User-to-Network Interface (UNI) or an MPLS traffic-engineering server (TE server) to issue requests for new label-switched paths (LSP's) or to modify the characteristics of existing LSP's. This traffic-engineering server is vendor specific, and it is usually at the ingress of the packet-switched MPLS network, where it collects traffic information to make its decisions. Alternatively, one could use an approach similar to the one described in Chapter 5 to manage the LSP's.

The differences between pure MPLS and the extensions of GMPLS come from the nature of the circuit-switched channels that GMPLS uses. The two major differences are, first, that in GMPLS the channel ID of the circuit-switched channels (e.g., the slot number in a TDM frame or the wavelength ID) can be used as an explicit path label, and, second, that the data and control channels may be completely decoupled in GMPLS (control information may be sent out-of-band, as opposed to an in-band MPLS shim header). In addition, GMPLS can only allocate bandwidth in discrete and coarse amounts, and there are usually many parallel data channels between two adjacent nodes (which was not originally considered in the IP or MPLS control planes). Finally, in GMPLS, nodes may have restrictions on what labels can be chosen (e.g., because of limited wavelength conversion capabilities).

The GMPLS extensions take all these differences into account. More precisely, these extensions consist of:

When a GMPLS node decides to establish a new LSP, it sends downstream an RSVP-TE PATH message (or a Label Request message if it uses CR-LDP) towards the destination. This message contains a generalized-label request with the desired bandwidth and (optionally) the desired protection level. The message is routed using a constrained-based shortest-path-first algorithm that uses the link state information flooded using OSPF or IS-IS, unless the PATH/Label Request message contains an explicit route. The downstream node sends back an RSVP-TE Resv message (or a Label Mapping message for CR-LDP) that includes the generalized label6.1 that identifies the LSP.

GMPLS does not specify whether RSVP-TE or CR-LDP should be used, and it leaves to the vendors and carriers to decide. The main difference between RSVP-TE and CR-LDP is that RSVP-TE uses ``soft state'' to manage the paths (circuits are timed out unless the reservation is refreshed periodically), whereas CR-LDP uses ``hard state'' (an explicit message is required to destroy active circuits). Soft state has a higher signaling overhead and a looser control over resources, but it has a simpler recovery strategy under complex failure scenarios. GMPLS has also extended RSVP-TE to provide prompt notification of faults in the path.

Let us compare the signaling of GMPLS with that of TCP Switching (Chapter 4). In both RSVP-TE and CR-LDP, the ingress has to wait for the round-trip time of a two-way handshake to start sending data. In TCP Switching, the first packet in the flow is used to establish the circuit, and, consequently, there is no delay in sending the data. In addition, TCP Switching uses soft state without paying a penalty in signaling overhead since any activity in the data channel automatically refreshes the state of the circuit. In a sense, TCP Switching assumes semitransparent switches that can understand whether a channel is being used or not. This hardware support is not assumed to be present in GMPLS because many of its nodes switch information transparently.

GMPLS can create both uni- and bi-directional LSP's with a single PATH/Label Request message. In contrast, TCP Switching (like traditional MPLS) only works with purely unidirectional circuits. These bidirectional LSP's are useful for several important applications, such as telephony and private lines, and they also simplify path protection by having the two directions share their fate.

Figure 6.1: Hierarchy of label-switched paths in GMPLS.

In GMPLS, like in MPLS, LSP's can be nested, and so a hierarchy of LSP's can be built to exploit the higher capacity of optical circuit switches, which have coarse channel granularities. The hierarchy is composed of packet-switched LSP's, TDM circuits, wavelengths and fibers, as shown in Figure 6.1. This use of a hierarchy of circuits is similar to the one proposed in Chapter 5.

Failure recovery is a very important requirement for carriers in GMPLS. GMPLS can specify a different level of protection and restoration6.2 for each LSP. There are different levels of failure recovery depending on the provisioning of additional resources (these resources can be pre-computed, pre-allocated or allocated on demand) and on the level of overbooking (protection resources can be dedicated, shared or best effort).

In summary, GMPLS proposes another way of integrating circuit switching in the core and packet switching in the edges. It focuses on the management of coarse circuits between core routers (like Chapter 5). However, its scope is slightly different than the contents of this thesis because it does not specify a control algorithm to decide when to create circuits and with what capacity. GMPLS also deals with many aspects, such as routing and path protection, that are out of the scope of this thesis.


6.2.2 ASTN: Automatic Switched Transport Network

ASTN (Automatic Switched Transport Network) [168] and ASON (Automatic Switched Optical Network) [167] are a set of Recommendations by Study Group 15 of the International Telecommunications Union -- Telecommunication Standardization Sector (ITU-T) that specify the network architecture and the requirements for the signaling and routing in automatic switched transport networks. The network architecture is shown in Figure 6.2. The optical network has three planes: management, control and data transport.

Figure 6.2: Network architecture of the Automatic Switched Transport Network (ASTN). UNI = User-to-Network Interface. I/E-NNI = Internal/External Network-to-Network Interface.

ASTN and ASON define the requirements in the control plane for the dynamic circuit provisioning (within minutes) and for the network survivability, protection and restoration. The goal is to specify a common control plane across multiple transport technologies that provides quality of service and equipment interoperability across domains and carriers.

ASTN and ASON do not develop new protocols when existing ones will do. Consequently, ASTN and ASON can either make use of GMPLS or PNNI [50,117] as the signaling protocol. Although eleven standards have already been produced (detailing the architecture and the signaling requirements), the work of ASTN/ASON has not been completed except for the general framework.


6.2.3 OIF: Optical Internetworking Forum

The Optical Internetworking Forum (OIF) [13] is an industry forum composed of over 250 service providers and equipment vendors. It has defined a User-to-Network Interface (UNI) that allows user devices (i.e. edge routers and ATM switches) to dynamically request circuits between boundary devices through the circuit-switched optical network core. These circuits are provisioned rapidly with various levels of circuit protection and restoration. The OIF UNI also specifies signaling for automatic neighbor and service discovery, and for fault detection, localization and notification. For the moment, the work on OIF's UNI and IETF's GMPLS remain very complementary. In the future, OIF plans to specify a Network-to-Network Interface (NNI) that allows the direct interconnection of optical switches and networks from different vendors. OIF has already produced version 1.0 of its UNI and also several specifications for the electrical and very-short-reach optical interfaces between chips and between system elements. The OIF is not a formal standards body, but produces detailed specifications that are presented to traditional standards bodies (IETF and ITU-T) for adoption.


6.2.4 ODSI: Optical Domain Service Interconnect

The Optical Domain Service Interconnect (ODSI) is another industry forum that was started by several startups almost at the same time as OIF. However, ODSI lacked the participation by the large, established networking vendors and carriers, and so after merging its efforts with the OIF signaling workgroup, ODSI ceased to exist in late 2000. Like OIF, ODSI had also defined an optical UNI for edge routers and switches to request circuits from the core. The key difference between the two specifications was that ODSI developed a TCP-based signaling protocol, whereas OIF uses RSVP-TE or CR-LDP.

GMPLS, ASTN, OIF and ODSI share the same goal: to allow more dynamic, automated and standardized optical networks. However, they address different issues: ASTN has a top-down approach and focuses on the network architecture and requirements. The other three proposals define the components of the architecture: GMPLS specifies the routing, the topology and link state dissemination, and the NNI signaling, and OIF and ODSI define the UNI signaling and work on the equipment interoperability. The four efforts are aware of each other work and try to coordinate their efforts. For more information, Clavenna [44] has written a good overview of the differences between GMPLS, ASTN, OIF and ODSI.

6.2.5 Grid computing and CA*Net 4

Grid computing is a network of computation; i.e., a set of tools and protocols for coordinated problem solving and resource sharing among pooled assets. These pooled assets are known as virtual organizations, and they can be distributed around the world. The shared resources are heterogeneous and autonomous (they may belong different organizations), and their relation is temporary. The Global Grid Forum is a research forum in distributed computing that mirrors IETF and that is trying to standardize the grid-computing protocols and architectures under the Open Grid Services Architecture (OGSA) [76]. Globus Toolkit [80] is an open-source reference implementation of OGSA based on open standards from the web services world.

An example of a network designed for grid computing is CA*Net 4 [5]. It is part of the Canadian national research network, and it is targeted towards universities, research institutes and companies that need to exchange a good amount of data among different locations either regularly (e.g., a company with multiple sites) or for limited periods of time (e.g., for the duration of a joint project). CA*Net 4 is composed of a set of unorganized, point-to-point wavelengths6.3 that are forwarded transparently by DWDM circuit switches. The network clients are big and sophisticated; they either lease or own a subset of the unorganized wavelengths, and they operate the equipment that interconnects, translates and grooms those wavelengths to create their own private network. The network client has complete control over its own wavelengths and its network equipment, and it decides what gets added/dropped at the different exchange points.

The most interesting part of CA*Net 4 design is the business model. Clients only have to pay the capital cost of the dark fiber or wavelengths and the switching equipment, instead of the usual monthly service charge paid to traditional ISPs. Network connectivity is treated as a capital asset rather than a service as it is today. In addition, clients can sublease part of the bandwidth (at the STS-1 or Gbit-Ethernet granularity) in its own private circuit network through automated procedures.

In contrast, the proposals of Chapters 4 and 5 are for a public Internet infrastructure where resources are shared by all users. In addition, these two proposals are geared towards the unsophisticated end user who wants a service similar to the current public Internet without having to worry about the internals of the network, or having to hold a lease on parts of the network.


6.2.6 Proposal by Veeraraghavan et al.

Veeraraghavan et al. [181] define a circuit-switched network that reaches the end hosts and that runs in parallel to the packet-switched Internet. All traffic is sent through the packet-switched network, except when a long file needs to be transferred. Then, the end host creates a new end-to-end circuit in the circuit-switched network that is used for the long trasfer. Since this end-to-end circuit is a constant bandwidth channel that is solely reserved for that transfer, the transmission sees no losses due to queueing or contention, no packet reordering, and no delay jitter. As a result, a new transport protocol, called Zing, is proposed. This protocol has very simple error and flow control mechanisms. Another characteristic of the system is that the circuit-switching signaling is simple enough to be implemented in hardware.

The use of an end-to-end circuit-switched network has two problems: first and most importantly, as shown in Chapter 3, circuit switching in the access network yields very bad response times for end users since large file transfers eventually monopolize the link for long periods of time. Second, the cost of a second network with the corresponding links and switches is very large, and so it is unlikely that this solution will be widely deployed in the near future. This barrier to its deployment limits its attractiveness, since one can only use Zing to exchange files with the few nodes that are connected to the circuit-switched network. In contrast, the two approaches presented in Chapters 4 and 5 do not require any flag days, in which all network elements have to be upgraded or changed. Consequently, these two approaches can be deployed incrementally without any changes in either the access networks or the end hosts.


6.2.7 IP Switching

TCP Switching is most similar to IP Switching [129], in which user flows trigger the establishment of ATM virtual circuits. The main difference is that TCP Switching uses true circuits, as opposed to the use of the connection-oriented packet switching of ATM [117]. Consequently, TCP Switching can benefit from the much higher capacity of circuit switches.

IP Switching uses ATM virtual circuits, which is a packet-switching technique. With virtual circuits, resources are not necessarily reserved as with true circuits. Consequently, bandwidth is not wasted if the ATM virtual circuit remains active after the associated flow has ended. With TCP Switching, bandwidth is reserved, and it is wasted when unused. This wastage of bandwidth is relevant since typical flows in the Internet last only a few seconds. For this reason, the recommended inactivity timeouts of IP switching are above 30 seconds [108]; in contrast, TCP Switching uses a timeout that is only slightly larger than the RTT (0.25-1 s).


next up previous
Next: 6.3 Packet switching in Up: 6. Related work Previous: 6.1 Introduction
Copyright © Pablo Molinero-Fernández 2002-3