Convergence of Cloud Computing and Network
Virtualization: Towards a Zero-Carbon Network
Mathieu Lemay, Kim-Khoa Nguyen, Bill St. Arnaud, Mohamed Cheriet
Abstract
Nowadays, reducing greenhouse gas (GHG) emissions is becoming one of the most challenging research topics in Information and Communication Technologies (ICT) because of the overwhelming utilization of electronic devices. Current solutions mainly focus on energy efficiency for saving power consumption at the micro level. Large-scale energy management strategies are still hardly taken into account. In this paper, we present a low-carbon nation-wide network built in Canada, and then expanded over the world. Based on an assumption that energy efficiency at the micro level will likely lead to an over consumption at the macro level, the proposed network is powered exclusively by renewable energy sources. Using network and server virtualization techniques, data centers services are migrated around network nodes according to renewable energy availabilities. A “follow the sun, follow the wind” optimization policy is deployed as a virtual infrastructure management technique. GHG reductions are evaluated as a result of our research.
Introduction
During the past ten years, annual mean temperature increases and sea-level rise and transition have happened as a result of global warming. Most of research agrees that the main reason of the climate changes is the greenhouse effect caused by greenhouse gases (GHG) where carbon dioxide is a key factor. It is a challenge that not only jeopardizes the sustainability of our planet; it poses significant, long-term threats to the global economy. Among the main power consumption industries, Information and Communication Technology (ICT), with its annually growing rate of 9% [1], contributes approximately two per cent to the global GHG emissions, and this amount will almost double by 2020 [2]. Fortunately, the ICT industry has the potential to reduce its current GHG emissions. The SMART 2020 report [2] showed that ICT's unique ability to monitor and maximize energy efficiency both within and outside of its own sector can lead to emission reductions five times the size of the sector’s own footprint. This represents a saving of 7.8 Giga-tons of CO2 equivalent by 2020 - greater than the current annual emissions of either the US or China. Using new network and distributed computing architectures to reduce or to eliminate indirect GHG emissions caused by ICT through zero-carbon data centers is one of the most promising ICT strategies to mitigate Global Warming progression.
As ICT is increasingly provided by data centers as a service, including evolving forms such cloud, grid, utility computing, storage, and networking, the urgent need to reduce GHG emissions will affect both providers and customers of ICT services. Cap & trade or carbon tax will increase service provision
This article has been accepted for publication in IEEE Internet Computing but has not yet been fully edited. Some content may change prior to final publication.
costs as most of data center activities are carbon-dependent. That explains why large ICT companies, like Microsoft which consumes up to 27 megawatts of electricity at any given time [1], have built their data centers near renewable power sources. Unfortunately, many computing centers are not so close to the renewable energy sources. Thus, renewable energy distributed networks and the way they can be related to current Grid systems using Smart Grid technologies are emerging technology. A key assumption to make is that losses incurred in energy transmission over power utility infrastructures are much higher than those caused by data transmission, which makes relocating a datacenter near a renewable energy source a more efficient solution than trying to bring the energy to an existing location. Note that renewable energy and green energy may be interchangeably used. Other types of energy, like nuclear which is not renewable, are not considered green.
The current approach when dealing with the ICT GHG problem is improving energy efficiency, which attempts to reduce energy consumption at the micro level. Numerous research projects have been conducted following this direction. They focused on micro-processor design, computer design, power-on-demand architectures and virtual machine consolidation techniques. However, a micro-level energy efficiency approach will likely lead to an overall increase in energy consumption due to the Khazzoom–Brookes postulate (also known as Jevon’s paradox) which states that energy efficiency improvements that, on the broadest considerations, are economically justified at the micro level, lead to higher levels of energy consumption at the macro level [4]. Consequently, this increases GHG emissions. Some research concluded that energy efficiency is therefore an irrelevant network design approach and the objective should be to make networks carbon neutral [2][3].
In this paper, we present one of the first nation-wide networks, so called GreenStar Network (GSN) [6], which is powered entirely by green energy. This research is inspired from the carbon neutral approach proposed in [5] and from the emerging need of a green energy distribution wide area network model for establishing a standard carbon protocol for the ICT industry. The main objective of the GSN project is to create a pilot and a testbed environment from which to derive best practices and guidelines to follow when building low carbon networks. Although the ISO 14064 standard - used to measure GHG emissions in traditionally heavily polluting industries and upon which the protocol is based - is straightforward, its specialization to ICT will require synergistic solutions relating to power and performance measurement, as well as network and system operation. Therefore, the GSN project focuses on two principal activities: i) Creation of a ISO14064 compliant protocol and enactment of a GHG reduction project based on utilization of green data centers; and ii) Development of management and technical policies that leverage virtualization’s mobility to facilitate the use of renewable energy, e.g. solar and wind, within the GSN.
A Zero-Carbon Network
The GSN project was initiated by a Canadian consortium of industry, universities and government agencies with the common goal of reducing GHG emissions arising from ICT services. The project
This article has been accepted for publication in IEEE Internet Computing but has not yet been fully edited. Some content may change prior to final publication.
focuses on the relationship between networks and green data centers in order to provide green ICT services. The idea behind the project is that a carbon neutral network must consist of data centers built in proximity to clean power sources and user applications will be moved to be executed in data centers. Such a network must provide an ability to migrate entire virtual machines to alternate data centers locations. Regarding research recently proposed in [3], the GSN goes one step further. Whilst the former focuses on allocating physical data centers close to cheap energy sources, we are actively and dynamically migrating virtual data centers around green nodes while maintaining user services. This is supported by a highspeed optical layer having up to 1,000 Gbps bandwidth capacity. Note that optical networks have modest increase in power consumption, especially with new 100G and 1,000G waves, compared to electronic equipments such as routers and aggregators [5]. The GSN includes small and medium size data centers, which allows the network to be flexible and cost-effective regarding construction costs. Relocating small data centers can also be achieved in a timely manner, which is appropriate for online services. Indeed, advantages of small or even tiny data centers over large-scale data centers in terms of energy consumption and management have been discussed in [14][15].
Figure 1: The GreenStar Nework
This article has been accepted for publication in IEEE Internet Computing but has not yet been fully edited. Some content may change prior to final publication.
In this paper, we focus on the design and management of the GSN which provides zero-carbon ICT services. The cost of producing and maintaining network elements, such as routers and servers, is not considered, because no special hardware equipment is used in the GSN. The only difference between a regular network and the GSN and is that the latter one is able to transport ICT services to data centers powered by green energy. Such a feature is implemented at software level as described throughout this paper.
As shown in Figure 1, the core GSN built in Canada includes six nodes powered by sun, wind and hydroelectricity. Solar power is used at Cybera (Calgary, AB) and CRC (Ottawa, ON). Wind power is generated at BastionHost (Truro, NS). Three nodes at Rackforce (Kelowna, BC) and ETS-UQAM (Montreal, QC) are powered by hydro energy. Since BC and QC provinces have a large capacity of hydroelectricity, there is no risk of service interruption in the network due to power outages. However, using renewable energy like wind and solar ones is considered a higher priority because hydroelectricity is unlikely considered renewable sources of energy. Therefore, applications are forced to run in solar and wind powered nodes whenever it is possible.
Figure 2: Node architectures (hydro, wind and solar types)
Figure 2 illustrates architectures of a hydroelectricity and two green nodes, one is powered by solar energy and the other is powered by wind. The solar panels are grouped in bundles of 9 or 10 panels,
This article has been accepted for publication in IEEE Internet Computing but has not yet been fully edited. Some content may change prior to final publication.
each panel generates a power of 220-230W. The wind turbine system is a 15kW generator. After being accumulated in a battery bank, electrical energy is treated by an inverter/charger in order to produce an appropriate output current for electrical devices. User applications are running on multiple Dell PowerEdge R710 systems, hosted by a rack mount structure in an outdoor climate-controlled enclosure. Air conditioning and heating elements are powered by green energy at solar and wind nodes; they are connected to the regular power grid at hydro nodes. The PDUs (Power Distribution Unit), provided with power monitoring features, control electrical current and voltage. A local network links servers within each node, which is then connected to a core network through GbE transceivers. Data flows are transferred among GSN nodes over 9 optical core switches of the CANARIE network spreading across Canada.
The GSN node at Montreal plays a role of manager (so called the hub node) that opportunistically sets up required connectivity for Layer 1 and Layer 2 using dynamic services, then pushes virtual machines (VMs) or software virtual routers from the hub to sun and wind nodes (spoke nodes) when power is available. VMs will be pulled back to the hub node when power dwindles. In such a case, the spoke node may switch over grid power for running other services if it is required. However, GSN services are powered entirely by green energy. The VMs are used to run user applications, particularly heavy-computing services. Based on this testbed network, research experiments are performed targeting cloud management algorithms and optimization of intermittently-available renewable energy sources. The GSN is also incorporating green nodes in Ireland (HeaNET), Belgium (IBBT), Spain (i2Cat), China (WiCo), Egypt (Smart-Village) and USA (ESNet).
Cloud Management & Data Center Migration
Converging server and network virtualization techniques, the GSN is an environment consisting of a set of clouds, each cloud represents a data center with its power and network accessories. Therefore, the key challenge is how to manage, connect, and coordinate elements within the environment in order to achieve specific tasks, while maintaining the required power level and minimizing GHG emissions. The web based management solution we propose below allows cloud users to transport their services over network to green energy sources.
Cloud Management
The proposed cloud management solution is based on the IaaS (Infrastructure as a Service) concept, which is considered a new technology dealing with the delivery of computing infrastructure [8]. IaaS allows clients to fully outsource services, such as servers, software, data center space or network equipments, without a need of purchasing these physical resources or dealing with some of the difficulties the equipment owners face. The key notion of IaaS is Cloud Architecture, which addresses key difficulties of large-scale data processing.
This article has been accepted for publication in IEEE Internet Computing but has not yet been fully edited. Some content may change prior to final publication.
Figure 3: Layered GSN and Cloud Computing Architectures
Figure 3 compares the layered architecture of the GSN with a general architecture of a cloud comprising four layers. The GSN Data plane corresponds to the System level, including massive physical resources, such as storage servers and application servers linked by controlled lightpaths. The Platform Control plane corresponds to the Core Middleware layer, implementing the platform level services that provide running environment enabling cloud computing and networking capabilities to GSN services. The Cloud Middleware plane corresponds to the User-level Middleware, providing Platform as a Service capabilities based on IaaS Framework components [8]. The top Management plane or User level focuses on application services by making use of services provided by the lower layer services.
Data center migration
In the GSN project, we are interested in moving a virtual data center from one node to another. Such a migration is required for large-scale applications running on multiple servers with a high density connection local network. The migration involves four steps: i) Setting up a new environment (i.e., a new data center) for hosting the application with required configurations, ii) Configuring network connection, iii) Moving VMs and their running state information through this high speed connection to the new location, and iv) Turning off computing resources at the original node. Indeed, solutions for the migration of simple applications have been provided by many ICT operators in the market. However, large-scale data centers require arbitrarily setting their complex working environments when being moved. This results in the reconfiguration of a large number of servers and network devices.
In our experiments with the online interactive application Geochronos [11], each VM migration requires 32Mbps bandwidth in order to keep the service live during the migration, thus a 10Gbps link between two data centers can transport 312 VMs in parallel. Given that each VM occupies one processor and that each server has up to 16 processors, 20 servers can be moved in parallel. If each VM
This article has been accepted for publication in IEEE Internet Computing but has not yet been fully edited. Some content may change prior to final publication.
consumes 4GB memory space, the time required for such a migration is 1000s.
Figure 4: IaaS Framework Architecture Overview
Currently, the GSN runs a simple energy distribution algorithm: When green energy source is available at a spoke site, perform data processing, otherwise, run applications at the hub. Each site is a location containing computing and storage resources. Each spoke site is associated with an energy broker responsible for monitoring power and triggering migration events. Other energy distribution strategies will be taken into account in our future work, such as maximizing the utilization of renewable energy sources or sharing of supported devices among different users and different data centers.
The migration of data centers among GSN nodes is based on cloud management supports. The whole network is considered as a set of clouds of computing resources, which is managed using the IaaS Framework [8]. The IaaS Framework includes four main components: i) IaaS Engine used to create model and devices interactions abstractions, ii) IaaS Resource used to build web services interfaces for manageable resources, iii) IaaS Service serves as a broker which controls and assigns tasks to each VM, and iv) IaaS Tool provides various tools and utilities that can be used by the three aforementioned components (Figure 4).
The Engine component is positioned at the lowest level of the architecture and maintains interfaces with physical devices. It uses services provided by protocols and transport layers in order to achieve communications. Each engine has a state machine, which parses commands and decides to perform appropriate actions. The GSN management is achieved by three types of engines: i) Computing engine is responsible for managing VMs, ii) Power engine takes care of power monitoring and control and iii) Network engine controls network devices. The engines allow GSN users to quantify the power consumption of their service. Engines notify upper layers by triggering events. The Resource
This article has been accepted for publication in IEEE Internet Computing but has not yet been fully edited. Some content may change prior to final publication.
component serves as an intermediate layer between Engine and Service. It provides Service with different capabilities. Capabilities can contribute to a resource’s Business, Presentation or Data Access Tier. The Tool component provides additional services, such as persistence shared by other components.
Based on the J2EE/OSGi platform, the IaaS Framework is designed in such a modular manner that each module can be used independently from others. OSGi (Open Services Gateway initiative) is a Java framework for remotely deployed service applications, which provides high reliability, collaboration, large scale distribution and wide-range of device usage. With an IaaS Framework based solution, the GSN can easily be extended to cover different layers and technologies.
Through Web interfaces, users may determine GHG emission boundaries based on information providing VM power and energy sources, and then take actions to reduce GHG emissions. The project is therefore ISO 14064 compliant. Indeed, cloud management is not a new topic; however, the IaaS Framework is developed for the GSN because the project requires an open platform converging server and network virtualizations. Whilst most of cloud management solutions in the market focus particularly on computing resources, IaaS Framework components can be used to build network virtualized tools [9], allowing to flexibly set up data flows among data centers. The ability of incorporating third-party power control components is also an advantage of the IaaS Framework.
Indeed, the GSN is built on top of CANARIE network, and links multiple data centers with different network architectures and paradigms, such as IP, Ethernet, MPLS (Multiprotocol Label Switching), optical. It is also required that new protocols and architectures be deployed independently without disruptions when the GSN grows. Network virtualization is therefore an appropriate solution because it allows the coexistence of different network architectures, including legacy systems.
At the physical layer, we use Argia [9], a commercial version of UCLP (User Controlled Light Paths) [10]. Argia is a network virtualizer allowing end-users (people or applications) to treat network resources as software objects and provision and reconfigure optical lightpaths within a single domain or across multiple, independently managed domains. Users can join or divide lightpaths, as well as hand off control and management of their private sub-networks to other users or organizations. With a focus on optical switches, Argia enables the virtualization of a network that can be reconfigured by end-users without any interaction by the optical network manager.
Layer 2 virtualization is achieved by Ether [9], which is similarly in concept to Argia, except that is designed for LAN environments. With a focus on Ethernet and MPLS networks, Ether allows users to acquire ports on Enterprise Switch and manage VLANs or MPLS configurations on their own.
At the network layer, a network virtualizer created by the MANTICORE project [12] is deployed. MANTICORE is specifically designed for IP networks with an ability to define and configure physical and/or logical IP networks. It allows infrastructure owners to manage their physical as well as logical routers and to enable third parties to control them. MANTICORE also provides tools to assist infrastructure users in the creation and management of IP networks using router resources of one or
This article has been accepted for publication in IEEE Internet Computing but has not yet been fully edited. Some content may change prior to final publication.
more infrastructure owners.
GHG Reduction: Estimation and Discussion
Key power consuming elements in a network are data centers, core network and access network. As data centers are connected directly to the core network in the GSN, access network is not considered. In each GSN node, servers are installed in outdoor enclosures where the associated climate control is powered by green energy. So, GHG emissions from these accessories can be ignored.
Current experiments are performed in data centers using an application named GeoChronos [11]. It is an infrastructure enabling the earth observation community to share data, scientific applications and to collaborate effectively. The application runs on a multi-processor server system with 48 cores in total. As a core processor consumes about 78W, the whole system consumes annually about 32.8MWh of non-renewable electricity. Prior to the GSN project, the system was powered by the power grid of Alberta fueled mostly by fossil energy, where the electricity emission factor is 930x10-6 ton/KWh [13]. Thus, the system’s emission is more than 30 tons of CO2 annually. This number does not account for emissions of local switches and routers.
The GHG emission of core network when migrating the data center hosting Geochronos towards a green energy source is estimated as follows. Since the GSN is an optical based network, a power consumption model for core routers proposed in [7] can be used, with a note that data centers are connected directly to the core network by optical links. Assuming the current network with 9 core nodes, the capacity of each core router is 640Gbps, the power of a router is 10.9kW, the size of each VM is 4GB (live data), the bandwidth required for each VM migration is 32Mbps, a link between two data centers is 10Gbps, and a data center is migrated in average twice a day, the power consumed by the core network for the migration of a data center is therefore 2kW/day, which is equivalent to 0.7 tons of CO2 emission annually [13]. If core nodes are all powered by fossil energy, the carbon credit saved by the GSN is 30 – 0.7 = 29.3. Our result remains conservative (i.e. under estimated) because an optical switch consumes less energy than a core router. In other words, we may effectively save more carbon credits.
When the network grows, the amount of CO2 emitted during migrations is still very small compared to the total emission of data centers. According to our calculation model, the GSN may save up to 986 carbon credits when data centers include 1560 CPUs, assuming that the core network has 9 nodes.
The GSN data centers, however, would not scale up to mega size, like Google or Microsoft ones, due to construction and energy provision costs. Moving large-scale data centers is costly in terms of network bandwidth and time. Moreover, leaving a large data center non-operational in some periods of time is not a cost-effective solution. Therefore, an appropriate solution addressing the carbon footprint of large data centers is two-folds: i) Virtualizing the data center, and then ii) Spanning it over multiple smaller physical data centers, each powered by renewable energy sources. That way, mega scale service would be powered entirely by renewable energy.
This article has been accepted for publication in IEEE Internet Computing but has not yet been fully edited. Some content may change prior to final publication.
As shown throughout the GSN project, having highspeed optical network is essential for providing neutral carbon services. As migrations could be realized frequently as a result of environmental change, bandwidth consumed by migrations would be huge. Thus, highly scalable networking infrastructure, such as CANARIE or Internet2 is required, leading to cost considerations. However, it is clear that data network is much cheaper than power transmission network. In addition, energy losses in optical network are very small compared to electrical grid. This makes neutral carbon network a realistic solution both for environment and economy, particularly when carbon tax is imposed.
Conclusion
In this paper, a first nation-wide network powered entirely by green energy sources in Canada is presented. Virtualization techniques are shown to be the most appropriate solution to manage the network and to migrate data centers following green energy source availabilities, such as solar and wind. With an increase in power consumption for ICT, the GSN is a promising model to deal with GHG reporting and carbon tax problems for ICT organizations, especially small and medium ones.
Acknowledgement
This research is funded by CANARIE Inc. The authors thank all Canadian and international partners for their contribution in the GSN project.
References
[1] P. Kurp, “Green Computing, Are You Ready For A Personal Energy Meter ?,” Communication of ACM, 51(10), 2008.
[2] The Climate Group, “SMART2020: Enabling the low carbon economy in the information age,” Report on behalf of the Global eSustainability Initiative, 2008.
[3] Qureshi A. et al., "Cutting the electric bill for internet-scale systems," ACM Computer Communication Review, 39(4), 2009.
[4] HD. Saunders, "The Khazzoom-Brookes Postulate and Neoclassical Growth," The Energy J., 13(4), 1992.
[5] S. Figuerola et al., "Converged Optical Network Infrastructures in Support of Future Internet and Grid Services Using IaaS to Reduce GHG Emissions," J. of Lightwave Technology, 27(12), 2009. [6] The GreenStar Network Project. http://greenstarnetwork.com.
[7] J. Baliga et al., “Energy consumption in optical IP networks,” J. Lightwave Technology, 27(13), 2009.
[8] M. Lemay, “An Introduction to IaaS Framework,” 8/2008. http://www.iaasframework.com/
This article has been accepted for publication in IEEE Internet Computing but has not yet been fully edited. Some content may change prior to final publication.
[9] S. Figuerola, M. Lemay, "Infrastructure Services for Optical Networks [Invited]," J. Optical Communications and Networking, 1(2), 2009.
[10] J. Wu et al., “Layer 1 Virtual Private Network Management by Users,” Communications Magazine, 44(12), 2006.
[11] C. Kiddle, “GeoChronos: A Platform for Earth Observation Scientists,” OpenGridForum 28, 3/2010.
[12] E Grasa, et al., “The MANTICORE Project: Providing users with a Logical IP Network Service,” TERENA Networking Conference, 5/2008.
[13] LivClean Carbon Offset Solution, “How is this Calculated?,”. http://www.livclean.ca. [14] V Valancius, et al., “Greening the internet with nano data centers,” CoNEXT'09, 2009.
[15] K. Church, et al., “On delivering embarrassingly distributed cloud services,” HotNets-VII, 2008.
This article has been accepted for publication in IEEE Internet Computing but has not yet been fully edited. Some content may change prior to final publication.
This page intentionally left blank
This page intentionally left blank
Enabling Infrastructure as a Service (IaaS) on IP Networks: From Distributed
to Virtualized Control Plane
Kim Khoa Nguyen
1, Mathieu Lemay
2, Mohamed Cheriet
11
Ecole de Technologie Superieure, University of Quebec, Canada, 2Inocybe Inc., Canada
Abstract
Infrastructure as a Service (IaaS) is considered a prominent model for IP based service delivery. As grid and cloud computing have become a stringent demand for today's Internet services, IaaS is required for providing services, particularly “private cloud”, regardless of physical infrastructure locations. However, enabling IaaS on traditional Internet Service Provider (ISP) network infrastructures is challenging because IaaS requires a high abstraction level of network architectures, protocols, and devices. Network control plane architecture plays therefore an essential role in this transition, particularly with respect to new requirements of scalability, reliability and flexibility. In this paper, we review the evolutionary trend of network element control planes from monolithic to distributed architectures according to the network growth, and then present a new virtualization oriented architecture which allows infrastructure providers and service providers to achieve service delivery independently and transparently to end users based on virtualized network control planes. As a result, current ISP infrastructures will be able to support new services, such as heavy resource consuming data center applications. We also show how to use network virtualization for providing cloud computing and data center services in a flexible manner on the nation-wide CANARIE network infrastructure.
Introduction
Nowadays, converged communications is considered the main evolutionary stream in the telecommunications industry, allowing underlying infrastructure to run multiple services and accessible over multiple devices. As more services are enabled on communication equipments, the line between software applications and communications applications is blurring. Traditional communications applications such as point-to-point conference or multi-cast are now requirements of business or entertainment software [1].
The aforementioned situation has an important impact on network and software solutions. Architects of network solutions will be required to understand the underlying network architectures, devices and protocols that will be used to access services. Additional frameworks and tools will be required to abstract details of the network environment. Application developers will also need to understand the
convergence of network control plane architectures and software solutions.
In addition, the deployment of new services entailed the introduction of new protocols and link bandwidth has upgraded from megabit to gigabit rates on the Internet. New devices and protocols also increase the number of interfaces in network elements. Additional overhead resulted from more control traffic among an increasing number of peers results in difficulty of scalability, highly availability, and robustness to control plane. It appears that traditional network elements (e.g., IP routers) with centralized control plane architectures will not be able to meet new control requirements. Distributed control plane (DCP) architectures [2] are emerging solutions and have been widely used in core networks. However, the complexity and flexibility of new services, such as cloud computing and smart grids, impose new challenges on the design of network control plane architectures.
In order to satisfy tremendous demands of resources from new applications, cloud computing is used to power next generation data centers and to enable service providers to lease data center capabilities for deploying applications depending on user requirements. As cloud applications have various configurations, deployment requirements, description and finding, quantifying and allocating resources are essential in order to deliver on-demand services, particularly in large scale systems.
Today, ISPs are faced with an increased competition in the "bit-pipe" [1], a business model based purely on connectivity as a utility, with both lower revenue and lower margins. The bit-pipe model, rather than emphasizing content and services, is driven by operational excellence. Infrastructure consolidation, process automation, operational outsourcing are key mechanisms to reduce ISPs operating costs, driven by IP technology. New services, such as cloud computing with a huge number of resources to be managed, have placed the ISPs on the way of a new control plane evolution from current distributed architectures [3].
We witnessed that virtualization, a new paradigm being explored by the research and education community dealing with highly complex distributed environments, is an emerging technology for next generation network control plane architectures. Regarding current trends of virtualizing practically every aspect of computing (e.g., operating systems, servers, and data centers), it is necessary to have a virtualized network to interconnect all other virtualized appliances to give each of the virtual entities a complete semblance of their counterparts. Main characteristics of a network virtualization technique include: i) A warping of network elements, such as connectivity resources and traffic processing resources, ii) Dynamic establishment capability, such as flexible and efficient mechanisms to trigger and tear down service, iii) End-to-end across multiple domains, and iv) Control by the end-user, e.g., the end-user is able to operate the virtual infrastructure as if it was a dedicated physical infrastructure. This paper discusses the need of a transition from current network element’s DCP architectures to network virtualization techniques in order to support new services. The rest of the paper is organized as follows. In the next section, we review network control plane architectures and focus on the currently
Network virtualization tools are then presented with a proposed integrated control plane architecture and business and deployment models. A case study shows the deployment of network virtualization to provide cloud computing and data center services in a nation-wide network. Finally, we conclude the paper and present future work.
Network Control Plane Architectures
One of the key factors that enable of the extraordinary growth of the Internet is the evolution of network element architectures. As essential element of Internet, the IP router has developed from simplistic packet manipulating software implemented on a general purpose computer to a sophisticated network equipment that fully utilizes the capabilities of specialized hardware and integrates a set of functionalities, ranging from raw packet forwarding through traffic shaping, packet queuing, access control, with connection tracking all the way to distributed network protocols. Lately, it has been proposed to modularize these interspersed functions and organize them into administratively and physically distinct modules, yielding what is called the distributed router. Such distributed routers are expected to improve scalability of IP routers, open up new markets for device vendors and foster rapid innovation in the area.
Control Plane Evolution
The first IP networks were made with first generation routers (Figure 1-A) which contain a single central processor (CPU) and multiple interface cards interconnected through a shared bus. The CPU runs a commodity real-time operating system and implements the functional modules, including the forwarding engine, the queue manager, the traffic manager, and some parts of the network interface, especially Layer 2/Layer 3 processing logic in software. The central CPU capacity is shared among packet forwarding, running routing protocols, updating routing tables and achieving management functions.
Figure 1: Router generations
When routers are upgraded to the second generation (Figure 1-B), more intelligence is added to the line cards, with processor, memory and forwarding caches, allowing them to perform locally some packet forwarding operations. However, control and forwarding planes still remain on the same processing unit.
The third generation routers (Figure 1-C) were introduced with the concept of strict separation of control plane (software based) and data plane (hardware based), allowing the growth of service provider networks. As the shared bus is replaced by a switch fabric, which allows multiple packets to be simultaneously transferred across, data forwarding performance is significantly increased.
Distributed Control Plane Architecture
Due to the growing expansion of ISP networks, a network element may have to exchange control messages with hundred of peers. Such a growth in bandwidth, network traffic and network element
of traditional communication networks into multi-service networks requires control planes to be highly scalable, reliable and flexible. The monolithic architecture, where software and hardware are intertwined into a single, complex system has many limitations, which made it difficult to meet new requirements, and which has hold back the introduction of new services and applications. For example, a change in one of its subsystems may affect many other subsystems; the flexibility and performance is also limited due to its inherent complexity.
Although third generation routers are still used in many of today's core networks, large ISPs are transforming their network equipments into optical based where data plane will includes optical cross-connects which provide services for IP layer through MPLS or similar technologies. This results in the development of DCP architectures, which are entirely separated from the data plane (Figure 2).
Figure 2: Distributed control plane
A DCP architecture [3][12] is based on the physical separation between control functions and forwarding functions. Control functions are reduced to the minimum in line cards, such as Hello protocols, neighbor discovery, and switch-over in case of failures. Control elements (CE) and forwarding elements (FE) are interconnected using an internal network, which carries control and data traffic between the elements. The internal network can be designed in various ways, using often high-speed optical network or high performance switches. Such an architecture involves three types of communications: CE-CE, CE-FE and FE-FE. ForCES [11] was introduced by IETF as a protocol for communications between elements. However, many network operators and equipment providers developed their own version of internal protocols, which seem similar to ForCES with specific features [3]. The separation of control elements from forwarding elements enables the control plane to handle complex tasks such as traffic engineering, QoS, VPN, in large scale networks. Challenges of a distributed architecture include determining function to be distributed and network element that will host that function. Solutions result in two ways of distributing control plane functionalities: functional and layered distribution [2].
Today, most of network operators have upgraded their control planes to distributed architectures, composed of multiple separate elements communicating through open, well-defined interfaces. The control plane and data plane are completely decoupled, running on two different devices, with a 1:N relationship, a control plane handling multiple forwarding planes. Several distributed schemes have been proposed in order to increase significantly scalability, flexibility and availability [3].
However, regarding the rapid growth of the number of network devices and VPNs needed for new cloud computing services, DCP will unlikely meet new requirements, particularly as it is related to high flexibility. Since control plane is linked to data plane by an internal network, handling change is difficult because each change to the physical infrastructure requires a corresponding modification to the control plane, such as reconfiguring the tunable parameters in the routing protocols.
Infrastructure as a Service (IaaS) for Internet Provider
The growing utilization of real-time services such as network telephony, video conference, has resulted in a higher need for constant connectivity, which requires more scalable management. Infrastructure as a Service (IaaS) has been introduced to meet new management requirements. Offered by Amazon, BlueLock and other companies as a renting hardware service using proprietary solutions, IaaS scales service delivery as the physical location of the infrastructure can be determined in a flexible way. This is the base of cloud architecture, where complex underlying services remain hidden inside the infrastructure provider. Resources are allocated according to users need, hence highest utilization and optimization levels can be achieved. During the duration of the service, the user owns and controls the infrastructure as if he was the owner.
To ISPs perspectives, an IaaS solution allows:
(i) Scaling cloud service. Since network is extensively used in cloud-based services, IaaS allows
organizations to build a separate network dedicated to services they provide, given the flexibility and expected easy way of creating virtual infrastructures. IaaS opens new ways of building a backbone, particularly for “private cloud” customers, leading to converge routing capabilities in more centralized locations.
(ii) Slicing packet-based infrastructure: If a physical device is sliced in virtual elements, it might be
desirable to run different software versions on each slice. This concept already implemented in computers is now being deployable in routing systems. The virtualization allows also the upgradability of a software version to be achieved without disruption of services.
(iii) Programmable network systems: a trend we observe in the industry is to integrate in the
infrastructure new services up to the application level, increasing the value of the network that can be exposed to end-users. It requires more flexible ways of implementing extension of
of programmable infrastructure systems, such as via an operating system SDK on routers, or a standard protocol such as OpenFlow [13], will open a new dimension of innovation in communications industry.
(iv) Scaling the management and service delivery: this is undoubtedly the most important concern
for ISPs, in particular related to mobility in a multi-domain environment. The service delivery model used by current ISPs, which tightly couples services to the underlying transport network, fails to deliver the flexibility needed by ISPs for service innovations. ISPs need an IaaS framework that deals with service and transport independently. In addition, they want to reduce costs through service automation and streamlining of regulatory compliance.
Network Virtualization
The deployment of the IaaS model on current networks requires involving multiple network solutions and architectures and enables multiple networks to function as a whole. The DCP approach, which links control planes to data planes within a network element, is unable to meet this requirement. Virtualization is therefore a natural evolution from DCP architectures, since it allows the coexistence of different network architectures, including legacy systems.
Network virtualization divides traditional Internet Service Providers (ISPs) into two independent entities: Infrastructure Provider, who manages the physical infrastructure, and Service Provider, who creates virtual networks by aggregating resources from multiple infrastructure providers and offer end-to-end services [4]. Each service provider leases resources from one or more infrastructure providers to create virtual networks and deploys customized protocols and services, taking into account performance, topology and cost of each infrastructure.
A virtual control plane (VCP) contains a network slice formed by virtual instances hosted by the physical networks. As virtualization instances are managed on a different system, the control plane scaling and resource allocation can evolve considerably and independently of the data plane. Adopting hybrid optical/packet based approach for the transport layer, the lightpath paradigm is key technology. However, we have also recognized a trend in communications industry that is to move from point-to-point deterministic pipes into the packet based transport infrastructure, such as MPLS over Ethernet. This move, from circuit oriented technologies to packet based technologies, requires also better cooperation between the packet based systems and optical cross connect systems. When the coexistence between these two trends remains, an integrated control solution based on virtualization is in need.
A traditional ISP network will therefore be virtualized as in Figure 3. The Physical layer includes forwarding elements, which can be optical switches or IP routers. Each forwarding element, or a set of forwarding elements of the same kind, is managed by a VCP instance. For IP routers, the VCP contacts
with the routers’ control plane in order to setup entries in routing tables. Networking services are provided to users through the Service layer of VCPs.
Figure 3: Virtualized control plane network
The challenges for a virtualization solution include: i) Virtualization of network devices, such as physical equipments from different vendors, routing software, multiple configuration protocols, APIs, etc., ii) Virtualization of routing policies, in order to provide users with the ability to express potentially complex requests in a simple way, iii) Federation of user-defined autonomous systems, that allows users to create their own IP domains and choose to what other IP domains they want to peer with, and iv) Integrate lower layer resources in a converged management fashion.
Virtual network solution by its nature gives full advantages for cloud-based systems. Although most of known VCP products are still developed in research projects [4][9], some commercial cloud systems, e.g., Flexiscale [14], are seen having virtual network features allowing users to rent VPNs together with virtual servers regardless of the locations of their physical servers. Nevertheless, large-scale providers, e.g., Amazon or Google, might still be concerned of performance issues when expanding their services to public utilization, resulting in no network virtualization feature has yet been present in their public cloud products. Thus, we believe that at the time-being, virtual network is more appropriate for medium-and-small enterprise customers. Incoming products from hardware providers, like Juniper Networks Control System (JSC1200) or Cisco IOS XR, fully support virtualization features. However, they focus on hardware virtualization of the point of presence (POP), while a cloud-based system needs a more flexible solution at the software level.
e.g., Amazon EC2, do not allow users to reconfigure their networks of virtual servers because of performance and security issues. However, private cloud services will potentially be provided with virtual network solutions. For example, Amazon Virtual Private Cloud will allow users to have complete control over their virtual networking environment [15].
Virtualized Network Control Plane Architecture
A VCP architecture for network element is shown in Figure 4. It is built on top of network elements (e.g., optical cross-connect) used as data plane. The proposed architecture has been used to develop a set of VCP software, including UCLP (User-Controlled LightPaths) [5]. The Lookup Service is used to find the different instances of network elements in the network. Network Service Access Point (NSAP) advertises its service instantiation through a well-known process described by OSGi implementation such as a Web Services Description Language (WSDL) pointer or Universal Description, Discovery and Integration (UDDI) database. When a client application wants to use a NSAP service, it sends user requests to the NSAP using the Simple Object Access Protocol (SOAP) adopted for Web Services. The requests are then converted into procedure calls within the NSAP which then performs the calls on its local Service Access Point where commands are executed with the help of the other components within the system. The Traffic Engineering Service implements a set of methods to create end-to-end connections. It supports concatenating, partitioning, receiving request, using and releasing paths. There are two types of users. Normal users may invoke a connection request to create a new end-to-end connection, and the administrator may perform administrative functions, such as adding new paths, deleting paths according to changes in the physical layer and the allocating new resources (i.e., network elements). Finally, the Network Element Service encapsulates the communication protocol required to communicate with the managed network device.
Figure 4: Virtual control plane architecture
In a traditional networking environment, routing protocols assemble routing tables used to find available resources for routing a new connection through a given network. However, no standard is available for inter-domain routing in optical networks and full knowledge of network topology as normally used for intra-domain routing is not appropriate for customer-managed networking. Therefore, when the control plane is implemented for optical network, an ad-hoc path searching mechanism can be used based on a static database, which is updated by the Lookup Service.
In order to provide interfaces to upper layers, the NSAP defines management services in the context of Web Services standards, based on XML and SOAP. The XML-based SOAP protocol is used for remote method invocation. There is also a service directory where VCPs can register their list of services specified in terms of XML schemas. Client applications search this directory to find desired services and corresponding VCPs.
Such a VCP can be hosted by a server separately from the network element it manages. This allows the control plane to be implemented using robust software platforms, e.g., J2EE/OSGi.
Comparison of distributed and virtual control plane
Regarding the complexity in management of DCP due to command line interfaces, VCP offers a clear advantage as it allows both end-user and administrator to configure network through a user-friendly
scalability of distributed model depends on the capacity of devices, whilst a VCP running on a dedicated server is able to manager many devices or even multiple networks. This significantly reduces the capital and operational expenditures (CAPEX/OPEX) of network providers. In addition, a DCP based on hardware components is more costly than a VCP, which is software-based.
As VCP is programmable, drivers can easily be added in order to control a wide range of devices and support traffic engineering features, which is inextensible in DCP model. Similarly, security mechanisms can be implemented in a VCP for authentication, access control and user management, while security features in DCP focus mainly on protocol level. Another advantage of virtual control model is that it is by nature very flexible and easily customized.
However, whilst DCPs have widely been adopted and standardized by many equipment providers, most of VCPs are still in research and finalizing phases.
The aforementioned discussions are summarized in Table I.
Control Distributed control plane Virtual control plane
Management role Hard and error prone
Administrator only
Easy and user friendly with GUI End-user / Administrator Scalability Scale with device capacity Scale with network and server capacity
One control plane can manage multiple devices Price Expensive, due to hardware components “Cheap”, as software-based component Traffic
engineering/QoS
Limited by operators and device features. QoS is based on routing protocol extensions
(e.g., RSVP-TE or NSIS)
Very flexible and easily compatible with a wide range of devices. QoS is based on bandwidth
broker and load balancing
Security Protocol level Cover from underlying protocol level to
application level
Flexibility Hardware can be changed or upgraded Very flexible, customizable by end-users Standardization Standardized by many equipment providers No standard has yet been defined
Table I. A comparison of distributed and virtual control planes
Service delivery model
The proposed IaaS service delivery model based on VCPs, as shown in Figure 5, consists of four layers. The Infrastructure layer includes physical network devices owned by infrastructure providers. These devices are usually linked within provider networks. The Virtualization layer includes servers running VCP software used to control the physical devices, such as setup and tear down on-demand paths. Bandwidth Broker is also implemented in this layer to enable traffic engineering services. The Service layer provides VCP service capabilities based on IaaSFramework components [6]. It also authenticates and handles access authorization to VCPs, enforces policy and generates usage record. The top Management plane or User level focuses on application services by making use of services provided by the lower layer services.
Figure 5: Layers of IaaS service delivery model
In such a model, the Resource Lists Service provides the means of exchanging resources between services providers (SPs). Each SP has a resource list populated with VCPs that represent the physical network elements that the SP can access. The list of SP (A) will be sent to SP (B) when A wants to give B permission to access some of A’s resources. B may then assign the network resources it receives to the network application services that B are deploying. A resource broker site, such as V-Infrastructures [6], can be used to provide SPs with resource listing, defining, browsing, and bargaining functionalities. In a typical system configuration, each SP has a set of services supported by the V-Infrastructure, including web service bundles. Although the sharing of resources among different SPs is enabled, it is important to keep administrative boundaries between SPs to avoid confusion about the ownership of assets and administrative privileges.
data center services on top of a nation-wide optical network infrastructure.
Figure 6-A shows CANARIE (previously named CA*net 4), a shared network used by all the
provincial Optical Regional Advanced Networks (ORANs) across Canada. It links each provincial
ORAN by a set of wavelengths that can be shared among them. CANARIE provides 10Gbps optical
lightpaths for research and education through multiple optical cross-connects.
Based on CANARIE infrastructures, the GreenStar Network (GSN) project aims at reducing
greenhouse gas emissions (GHG) arising from ICT services [7]. The GSN is made of a set of data centers linked by CANARIE, and connected to USA, Europe and Asia Pacific. The data centers are powered entirely by green energy sources, such as sun, wind, geothermal and hydroelectricity. The idea behind the GSN project is that a zero carbon network must consist of data centers built in proximity to green power sources and user applications will be moved to be executed in data centers, assume that losses incurred in energy transmission over power utility infrastructures are much higher than those caused by data transmission [8]. Such a network must be highly flexible in order to migrate an entire virtual data center (including virtual routers and servers) to alternate locations because green energy sources, like solar and wind are intermittent. Thus, the key challenge of the GSN is that the network has to move virtual servers around its nodes according to green power availability. Unfortunately, hypervisors (e.g, KVM, XEN) running virtual servers can only migrate virtual servers within a flat network. As the GSN spans multiple domains, VPNs must dynamically be reconfigured when a migration is triggered. Without VCPs, this task is very costly in terms of management as migration events are not predictable.
C) Delay (IP traffic) between Montreal and Calgary measured during 24 hours in a regular IP routing network and on a GSN lightpath setup by a Layer 1 virtual control plane
Figure 6: The Green Star Network and traffic characteristics
In such a network model, CANARIE is infrastructure layer. Virtualization layer consists of VCP
software. Service layer is a middleware we have implemented based on IaaSFramework, which brings services offered by VCPs to GSN users. Each VCP is considered as a resource in the middleware. The management layer handles user policies of network slices. Service provider is GSN operator, and end-users are data center service consumers.
Service delivery is achieved in the GSN by VCPs for network elements at three layers. At the physical layer, we use Argia [9], a commercial version of UCLP [5]. Argia is a VCP that allows end-users (humans or applications) to treat optical cross-connects as software objects and provision and reconfigure optical lightpaths within a single domain or across multiple, independently managed domains. Users can join or divide lightpaths, as well as hand off control and management of their private sub-networks to other users or organizations. With a focus on optical switches, Argia enables the virtualization of a network element that can be reconfigured by the end-user without any interaction by the optical network manager.
In order to establish Layer 2 VLAN, a network virtualization tool, named Ether [9], is used. Ether is similarly in concept to Argia, except that is designed for LAN environment. With a focus on Ethernet and MPLS networks, Ether allows users to acquire ports on an Enterprise Switch and manage VLANs
or MPLS configurations on their own. At the network layer, a VCP created by the MANTICORE project [10] is deployed. MANTICORE is specifically designed for IP networks with an ability to define and configure physical and/or logical IP networks. It allows infrastructure owners to manage their physical as well as logical routers and to enable third parties to control the routers. MANTICORE also provides tools to assist infrastructure users in the creation and management of IP networks using router resources of one or more infrastructure owners.
As shown in Figure 6-B, data centers of the GSN is linked by several types of equipments, including optical cross-connects in the core CANARIE network, Layer 2 switch of local networks and IP routers. Therefore, reconfiguring and setting up a VPN within such a network is very challenging. In addition, the VPN needs to be flexible, i.e., its topology can be changed dynamically. VCPs allow GSN operators to enable user-controlled traffic engineering. So, networks within a single domain or across multiple independent domains can be self-provisioned and dynamically reconfigured. For example, an optical connection is setup as follows. When a path is requested between Montreal and Calgary as shown in Figure 6-B, resource objects representing ports on each switch is defined. Next, a VCP (i.e., Argia) creates a link object representing an optical connection between two switches. Then, a path is allocated.
When the path is required on a SONET network (e.g., CANARIEcore network), VCP deals with 10GE
WAN PHY protocol. After the 10GE WAN PHY signal is converted to 10GW LAN PHY signal in Calgary, it goes to the Allied Telesis switch. The path allows virtual servers to be migrated from Calgary to Montreal as on the same LAN environment.
Figure 6-C compares the delay of IP traffic between Montreal and Calgary nodes in the GSN when regular IP routing and VCP are used to establish connection. Data is collected during a period of 24 hours. In the regular IP routing service, data packets going through each intermediate switch need to be processed and sometimes converted by OEO (optical-electrical-optical) modules. This results in high delay that, in peak load periods, does not meet requirements for live migrations. VCP offers a more stable lightpath between two nodes compared to regular IP routing.
As the CANARIE network is composed of multiple federated domains, each domain includes a set of
network devices, VCPs are implemented on each domain to export available Resource Lists. Since the VCPs cover three underlying layers, GSN users get full control of all network elements. Network topology can therefore be reconfigured according to user requirements in a very flexible manner (e.g., changed at least two times a day) in order to move data centers following green power availabilities.
Conclusion
Along with the growing demand for new services on Internet, the network control plane has evolved in ISP networks through many generations. Distributed control plane architectures are being widely used.
services. Therefore, we believe that network virtualization is a more appropriate solution, particularly in cases of very elastic networks as shown in this paper. The virtualized control plane architecture we presented have been used in a number of research and educational projects and proven to be flexible and efficient tools.
Our future work will address evolving such network virtualization tools, driven by need of new complex networks, and implementing advanced optimization techniques for traffic management.
References
[1] A. Cuevas et al., “The IMS Service Platform: A Solution for Next Generation Network Operators to
Be More Than Bit Pipes,” IEEE Commun. Mag., vol. 44, no. 8, 2006, pp. 75-81.
[2] K.-K. Nguyen et al., “Towards a Distributed Control Plane Architecture for Next Generation
Routers,” Proc. of ECUMN'2007, 2007, pp. 173-182.
[3] K.-K. Nguyen, B. Jaumard, A. Agarwal, “A Distributed and Scalable Routing Table Manager for
Next Generation IP Router,” IEEE Network Mag., vol. 22, no. 2, Mar. 2008, pp. 6-14.
[4] N. M. Mosharaf Kabir Chowdhury, Raouf Boutaba, “Network Virtualization: State of the Art and
Research Challenges,” IEEE Commun. Mag., vol. 47, no. 7, 2009, pp. 20-26.
[5] E. Grasa et al., “UCLPv2: A Network Virtualization Framework Built on Web Services,” IEEE
Commun. Mag., vol. 46, no. 3, 2008, pp. 126-134.
[6] M. Lemay, “An Introduction to IaaS Framework,” 8/2008. http://www.iaasframework.com/
[7] The GreenStar Network Project. http://greenstarnetwork.com
[8] S. Figuerola et al., “Converged Optical Network Infrastructures in Support of Future Internet and
Grid Services Using IaaS to Reduce GHG Emissions,” J. of Lightwave Technology, vol. 27, no. 12,
2009, pp. 1941-1946.
[9] S. Figuerola, M. Lemay, "Infrastructure Services for Optical Networks [Invited]," J. of Optical
Communications and Networking, vol. 1, no. 2, 2009, pp. A247-A257.
[10] E Grasa et al., “The MANTICORE Project: Providing users with a Logical IP Network
Service,” Proc. of TERENA Networking Conference, 5/2008.
[11] A. Doria et al., “RFC 5810: Forwarding and Control Element Separation (ForCES) Protocol
Specification”, IETF Draft, IETF - Network Working Group, 2010.
[12] Császár et al., “Converging the evolution of router architectures and IP networks”, IEEE
Network Mag., vol. 21, no. 4, 2007, pp. 8-14.
[13] N. McKeown et al., “OpenFlow: enabling innovation in campus networks,” ACM SIGCOMM
[14] FlexiScale Inc., “Flexiscale cloud computing,” http://www.flexiscale.com.
Bibliography
KIM KHOA NGUYEN ([email protected]) is a Research Fellow in the Automation Engineering Department at the École de Technologie Supérieure (University of Quebec). He is key architect of the GreenStar Network project and a member of the Synchromedia Consortium. Since 2008 he has been with the Optimization of Communication Networks Research Laboratory at Concordia University. His research includes green ICT, cloud computing, smart grid, router architectures and wireless networks. He holds a PhD in Electrical and Computer Engineering from Concordia University. MATHIEU LEMAY holds a degree in electrical engineering from the École de Technologies Supérieure (2005) and a master’s in optical networks (2007). He is currently a Ph.D. candidate at the Synchromedia Consortium of ETS. He is the Founder, President, and CEO of Inocybe Technologies Inc. He is currently involved in Green IT and he is leading the IaaS Framework Open Source initiative. His main research themes are virtualization, network segmentation, service-oriented architectures and distributed systems.
MOHAMED CHERIET is a Full Professor in the Automation Engineering Department at the École de Technologie Supérieure (University of Quebec). He is co-founder of the Laboratory for Imagery, Vision and Artificial Intelligence (LIVIA), and founder and director of the Synchromedia Consortium since 1998. Dr. Cheriet serves on the editorial boards of Pattern Recognition (PR), the International Journal of Document Analysis and Recognition (IJDAR), and the International Journal of Pattern Recognition and Artificial Intelligence (IJPRAI). He is a member of IAPR, a senior member of the IEEE and the Founder and Premier Chair of the IEEE Montreal Chapter of Computational Intelligent Systems (CIS).
This page intentionally left blank
This page intentionally left blank
January 12
Estimating Emission Reductions from Low Carbon Information Technology: The GeoChronos Relocation Project
Paul Steenhof ([email protected], tel: 613 565 5151 ex 233, fax: (613) 565-5743) Chris Weber ([email protected])
David Aikema Randall Robinson
Rob Simmonds Cameron Kiddle
Abstract
In this article we present an information and communications technology (ICT) project that involved moving virtualized applications between data centres in order reduce greenhouse gas emissions. The emission reductions have been accounted for according to a protocol that is conformant with ISO 14064-2, an international standard for quantifying and reporting
emission reduction projects. While the total amount of emission reductions attributable to the project were relatively small, the results of the article are important and illustrative as this may be one of the first examples of trying to quantify a specific project that aims to reduce emissions through the provision of low carbon ICT services. With rapid growth being
experienced in the ICT services sector generally and rising energy and environmental impacts of the industry as data management related electricity consumption increases, the topic of low or zero carbon ICT services is of increasing importance from a number of perspectives. Two are subsequently discussed in this article, including the possible place of ICT within carbon
markets and also the role of such ICT projects for helping large users of data management services reduce the environmental impact of the services that they require.
Key words
Green ICT, virtualization and cloud computing, emission reductions
Acknowledgements
The project and protocol described in this article were part of a larger project called the GreenStar Network and were supported by funding received from Canada’s Advanced Research and Innovation Network (CANARIE).
1 Introduction
Over the last two decades the global economy has been transformed by the increasing role of data across nearly every sphere of civil society, in turn contributing to rapid growth in the data centre industry as a provider of data processing, data storage, and other data services. With this growth, there has also been a parallel increase in the power requirements associated with the millions of servers and thousands of data centres now in existence. In the United States for example, the Environmental Protection Agency estimated power requirements from data centres doubled from 2000 to 2006 to equal about 61 billion kilowatt-hours (kWh), or 1.5 percent of the country’s total electricity consumption (Energy Star, 2007). It was estimated then that by 2011 this figure would likely nearly double. Global estimates of electricity usage from data centres are similar. Kommey (2008) concluded that worldwide data center power
demand in 2005 was equivalent (in capacity terms) to about seventeen 1,000 MW power plants.
The rapid growth of the data centre industry and the subsequent increases in electrical requirements are also contributing to increases in the greenhouse gas emissions (GHG) associated with the electricity required by the data facilities. In 2002, the ICT sector in its entirety had an estimated global carbon footprint of 0.53 gigatonnes of carbon dioxide
equivalent (Gt CO2e), representing about 1.25 percent of global emissions, while by 2007, this equalled about 0.83 GT CO2e, or about 2 percent of global emissions (Benowitz and Samuel, 2010). By 2020, it is projected that the global ICT footprint, of which datacentres contribute significantly, will equal 1.43 Gt CO2e, representing 2.7 percent of the global total. Put another way, this represents a 170 percent increase in emissions in the 2002 to 2020 period, or 9 percent annual growth.
There are a number of major technical changes which could help lower the energy and emissions footprint of ICT services in future years, particularly in terms of moving towards location-independent cloud computing and the benefits achieved through improving the energy and carbon performance of the data centre itself. The GeoChronos Relocation Project is an example of such activity where emission reductions have been achieved by moving computing services from a data centre located in Calgary, Alberta, situated in a carbon-intensive grid, to a data centre in Kelowna, British Columbia, situated in a low carbon grid.
1.1 Article purpose
This article presents a case study of an ICT project that has been implemented to reduce emissions where we apply a protocol developed for quantifying and reporting emission reductions from ICT projects. The specific protocol used was developed to be conformant
with the requirements of the international standard ISO 14064-2: “Specification with guidance at the project level for quantification, monitoring and reporting of greenhouse gas emission reductions or removal enhancements”, and is entitled The ICT GHG Reduction Protocol (referenced to as the Protocol throughout) (CSA, 2011). The use of an ISO conformant protocol for quantifying and reporting emission reductions is important since most carbon markets and players within these require the use of accepted best practices or methodologies. ISO 14064-2 is widely viewed as one the preeminent international standards that provides guidance for GHG quantification and reporting. We conclude the article by discussing the role of similar projects in reducing GHG emissions and the relevance of this activity in respect to both carbon trading and improving the environmental footprint of companies, institutions, or other organizations that are large users of ICT services.
1.2 Article structure
The remainder of this article is structured as follows. Sections 2 through 8 largely reflect the specific requirements of the Protocol and of ISO 14064-2 for quantifying and reporting carbon reduction projects. Specifically, in section 2 we describe the GeoChronos Project in detail, including the applicability of the Protocol to the project, the technologies involved, and the chronological plan of the project. In sections 3 through 6 we then present an assessment of the relevant emission sources, sinks and reservoirs (SSRs) that must be quantified for both the project and in baseline, including discussion of the selection and justification of the project baseline. Sections 7 and 8 then present the methodology and quantification results, while section 9 concludes.
2 Project description