are labelled at the ingress depending on the FEC they belong to. Here, the FEC concept clearly resembles that of a point-to-point or multipoint dedicated logical connection or virtual circuit. Each of the intermediate nodes uses the label (or the incoming transport wavelength in the optical core) of each incoming packet to determine its next hop. Labels can be pushed, swapped, and popped by the LSRs and a specific label distribution protocol (such as LDP [5] or RSVP [6]) is used for label information exchange between all the nodes. All the network intelligence is located in the edge nodes, where the virtual connection originates and terminates, and where all the necessary tunnels are set up to connect to all the other NSP nodes. The main advantage of such a circuit-switching paradigm is that it enables performance isolation between traffic streams that belong to different virtual connections – something that packet switching alone cannot guarantee. By performance isolation, we mean that we can prevent the performance of a virtual connection from being affected by a traffic stream belonging to another one. All the above-mentioned facilities need pre-determined “conduits” or label switched paths (LSPs) to be established to specific destinations. Traffic is steadily mapped onto them according to the dynamic needs of the involved users and their capabilities. More precisely, LSPs can be characterized by optional properties, such as the amount of bandwidth, type of packet treatment, or class of service. The former parameter is used at a setup time in a traffic engineering capable network to select LSP routes with an amount of available bandwidth sufficient to satisfy the LSP request. This attribute can also be used for subsequent LSP route optimizations. On the other hand, the class of service can be used to identify the MPLS packets that belong to the same traffic aggregate and have to be forwarded according to the same behaviour. In this way, the LSP can be regarded as a Differentiated Service Path. The LSPs can thus be used to implement explicit virtual connections on the underlying transport network, supporting precise reservations on a service-level basis and obeying trafficisolation constraints. Such virtual connections are long-lived ones, possibly lasting for several months at a stretch. At the network control plane level, for each virtual connection between two CE nodes, at least a couple of reserved LSPs must be set up through the underlying network to carry a service-guaranteed traffic stream from the ingress router to the egress one where the CE nodes are attached.

8.4.2  Service Plane and Interfaces

In the proposed scenario, the network turns out to be a resource as important as computation and/or storage. As such, the cloud operating system requires the same level of control towards the subsets of well-defined amounts of network resources for the entire execution of a specific task. A chief goal of this control is to turn the network into a virtualized resource that can be acted upon and controlled by other layers of software, realizing a service plane available to applications and virtual machines. Such a service plane is typically concerned with dedicated end-to-end optical channel/circuit allocation, optimization, monitoring, and restoration across the network that becomes the fundamental architectural “glue” unifying all the distributed

resources into a “virtual site” and “virtual computing system” abstraction, so that they can be made available to the applications as if they were in the same Server Farm/data center and LAN. The service plane must be designed to be extensible from the ground up. It should allow adaptation of the above-mentioned control plane interfaces and abstract their network view, or element set, into its service portfolio. In other words, the network becomes a resource managed by the cloud as much as computation or storage, and the service virtualization is layered upon the available network control plane technology in the IP/optical environment.

8.4.2.1  Providing Network Services to Cloud-Computing Infrastructures

When network connections are considered as resources to be managed and shared within the cloud framework, one needs to exactly specify what is meant by network resources, how to encapsulate them into the cloud-services paradigm, and how to manage these services. A specific cloud service is a self-contained, self-described application that can be published, located, and invoked over a network. By this definition, capacities offered by a network endpoint do not constitute a service offered by the cloud. Multiple endpoints must co-operate to establish a network service for the cloud. By comparison, other resources, such as storage capacity or processing capacity, can be offered by a node without co-operation with other nodes. For this reason, we believe that a different abstraction is required to model network resources as a cloud service.

8.4.2.2  The Cloud Operating System–Network Interface

A natural choice for modeling this interface is the Web Service Resource Framework (WSRF) [7] aiming at providing specialized web services enhanced for cloud users and applications. Implementing each high-level system component as a stand-alone web service has the following benefits: first, each web service exposes a welldefined language-agnostic API in the form of a WSDL document containing both operations that the service can perform and I/O data structures. Second, we can leverage the existing web-service features such as WS Security policies for secure communication between the components. The Interface’s WS service can advertise a single multiprotocol endpoint for authenticating and consuming user requests, while also translating the request to an internal protocol. Communication with the top-level service interface may take place via SOAP/http eventually secured by SSL and some authentication mechanisms, such as X509 or HMAC signatures. This can be achieved through the introduction and utilization of pluggable request-handling interfaces in the supporting web services stack software. All the offered web service interfaces need to be stateless and persistent, where data is not retained among invocations and services outlive their clients. The internal services must be unconcerned with the details of the outward-facing interfaces utilized by users while benefitting from enforcement of message-validation requirements. The network control logic must support these basic service functions within the cloud middleware