Marin Bertier

Frédéric Desprez

Gilles Fedak

Adrien Lebre

Anne-Cécile Orgerie

Jonathan Pastor

Flavien Quesnel

Jonathan Rouzaud-Cornabas

Cédric Tedeschi

Beyond The Clouds, How Should Next Generation Utility Computing Infrastructures Be Designed?

Context and Motivations

The success of Cloud Computing has driven the advent of Utility Computing (UC). However, Cloud Computing is a victim of its own success: In order to answer the escalating demand for computing resources, Cloud Computing providers must build data centers (DCs) of ever-increasing size. As a consequence, besides facing the well-known issues of large-scale platforms management, large-scale DCs have now to deal with energy considerations that limit the number of physical resources that one location can host.

Instead of investigating alternative solutions that could tackle the aforementioned concerns, the current trend consists in deploying larger and larger DCs in few strategic locations presenting energy advantages. For example, Western North Carolina, USA, is an attractive area due to its abundant capacity of coal and nuclear power brought about the departure of the textile and furniture industry [START_REF] Gary | How dirty is your data ? Greenpeace International Report[END_REF]. More recently, several proposals suggested building next generation DCs close to the polar circle in order to leverage free cooling techniques, considering that cooling is accounting for a big part of the electricity consumption [START_REF] Greenberg | The Cost of a Cloud: Research Problems in Data Center Networks[END_REF].

Inherent Limitations of Large-scale DCs

Although building large scale DCs enables to cope with the actual demand, it is far from delivering sustainable and efficient UC infrastructures. In addition to requiring the construction and the deployment of a complete network infrastructure to reach each DC, it exacerbates the inherent limitations of the Cloud Computing model:

• The externalization of private applications/data often faces legal issues that restrain companies from outsourcing them on external infrastructures, especially when located in other countries. • The overhead implied by the unavoidable use of the Internet to reach distant platforms is wasteful and costly in several situations: Deploying a broadcasting service of local events or an online service to order pizzas at the edge of the polar circle, for instance, leads to important overheads since most of the users are a priori located in the neighborhood of the event/the pizzeria. • The connectivity to the application/data cannot be ensured by centralized dedicated centers, especially if they are located in a similar geographical zone. The only way to ensure disaster recovery is to leverage distinct sites. 1 The two first points could be partially tackled by hybrid or federated Cloud solutions [START_REF] Armbrust | A View of Cloud Computing[END_REF], that aim at extending the resources available on one Cloud with those of another one; however, the third one requires a disruptive change in the way UC resources are managed.

Another issue is that, according to some projections of a recent IEEE report [START_REF] Group | IEEE 802.3TM Industry Connections Ethernet Bandwidth Assessment[END_REF], the network traffic continues to double roughly every year. Consequently, bringing the IT services closer to the end-users is becoming crucial to limit the energy impact of these exchanges and to save the bandwidth of some links. Similarly, this notion of locality is critical for the adoption of the UC model by applications that need to deal with a large amount of data as getting them in and out actual UC infrastructures may significantly impact the global performance [START_REF] Foster | Globus Online: Accelerating and Democratizing Science Through Cloud-Based Services[END_REF].

The concept of micro/nano DCs at the edge of the backbone [START_REF] Greenberg | The Cost of a Cloud: Research Problems in Data Center Networks[END_REF] may be seen as a complementary solution to hybrid platforms in order to reduce the overhead of network exchanges. However, operating multiple small DCs breaks somehow the idea of mutualization in terms of physical resources and administration simplicity, making this approach questionable.

Ubiquitous and Oversized Network Backbones

One way to partially solve the mutualization concern enlightened by the defenders of large-scale DCs is to directly deploy the concept of micro/nano DCs upon the Internet backbone. People are (and will be) more and more surrounded by computing resources, especially those in charge of interconnecting all IT equipments. Even though these small and medium-sized facilities include resources that are barely used [START_REF] Andrew | Data networks are lightly utilized, and will stay that way[END_REF][START_REF] Benson | Network traffic characteristics of data centers in the wild[END_REF], they can hardly be removed (e.g. routers). Considering this important aspect, we claim that a new generation of UC platforms can be delivered by leveraging existing network centers, starting from the core nodes of the backbone to the different network access points in charge of interconnecting public and private institutions. By such a mean, network and UC providers would be able to mutual-ize resources that are mandatory to operate network/data centers while delivering widely distributed UC platforms able to better match the geographical dispersal of users. Figure 1 allows to better capture the advantages of such a proposal. It shows a snapshot of the network weather map of RENATER2 , the backbone dedicated to universities and research institutes in France. It reveals several important points:

• As mentioned before, most of the resources are underutilized (only two links are used between 45% and 55%, a few between 25% and 40%, and the majority below the threshold of 25%). • The backbone was deployed and is renewed to match the demand: The density of points of presence (PoP, i.e. a small or medium-sized network center) as well as the bandwidth of each link are more important on the edge of large cities such as Paris, Lyon or Marseille. • The backbone was designed to avoid disconnections, since 95% of the PoPs can be reached by at least two distinct routes.

Fig. 1 The RENATER Weather Map on May 2013, the 27th, around 4PM. Each red square corresponds to a particular point of presence (PoP) of the network. The map is available in real-time at: http://www.renater.fr/raccourci

Locality-based Utility Computing

This chapter aims at introducing locality-based UC (LUC) infrastructures, a new generation of UC platforms that solves inherent limitations of the Cloud Computing paradigm relying on large-scale DCs. Although it involves radical changes in the way physical and virtual resources are managed, leveraging network centers is a promising way to deliver highly efficient and sustainable UC services.

From the physical point of view, network backbones provide appropriate infrastructures, i.e., reliable and efficient enough to operate UC resources spread across the different PoPs. Ideally, UC resources would be able to directly take advantage of computation cycles available on network active devices, i.e. those in charge of routing packets. However, leveraging network resources to make external computations may lead to important security concerns. Hence, we propose to extend each PoP with a number of servers dedicated to hosting virtual machines (VMs). Because it is natural to assume that the network traffic and UC demands are proportional, larger network centers will be completed by more UC resources than the smaller ones. Moreover, by deploying UC services on relevant PoPs, a LUC infrastructure will be able to natively confine network exchanges to a minimal scope, minimizing altogether the energy footprint of the network, the impact on latency and the congestion phenomena that may occur on critical paths (for instance Paris and Marseille on RENATER).

From the software point of view, the main challenge is to design a comprehensive distributed system in charge of turning a complex and diverse network of resources into a collection of abstracted computing facilities that is both reliable and easy to operate.

The design of the LUC Operating System (OS), an advanced system being able to unify many UC resources distributed on distinct sites, would enable Internet service providers (ISPs) and other institutions in charge of operating a network backbone to build an extreme-scale LUC infrastructure with a limited additional cost. Instead of redeploying a complete installation, they will be able to leverage IT resources and specific devices such as computer room air conditioning units, inverters or redundant power supplies already present in each center of their backbone.

In addition to considering locality as a primary concern, the novelty of the LUC OS proposal is to consider the VM as the basic object it manipulates. Unlike existing research on distributed operating systems designed around the process concept, a LUC OS will manipulate VMs throughout a federation of widely distributed physical machines. Virtualization technologies abstract out hardware heterogeneity, and allow transparent deployment, preemption, and migration of virtual environments (VEs), i.e. a set of interconnected VMs. By dramatically increasing the flexibility of resource management, virtualization allows to leverage state-of-the-art results from other distributed systems areas such as autonomous and decentralized systems. Our goal is to build a system that allows end-users to launch VEs over a distributed infrastructure as simply as they launch processes on a local machine, i.e. without the burden of dealing with resources availability or location.

Chapter Outline

Section 2 describes the key objectives of a LUC OS and the associated challenges. Section 3 explains why our vision differs from current and previous UC solutions. In Section 4, we present how such a unified system may be designed by delivering the premises of the DISCOVERY system, an agent-based system enabling distributed and cooperative management of virtual environments over a large-scale distributed infrastructure. Future work as well as opportunities are addressed in Section 5. Finally Section 6 concludes this chapter.

Overall Vision and Major Challenges

Similarly to traditional operating systems (OSes), a LUC OS will be composed of many mechanisms. Trying to identify all of them and establishing how they interact is an on-going work (see Section 4). However, we have pointed out the following key objectives to be considered when designing a LUC OS:

• Scalability: A LUC OS must be able to manage hundreds of thousands of virtual machines (VMs) running on thousands of geographically distributed computing resources. These resources are small or medium-sized computing facilities and may become highly volatile according to the network disconnections. • Reactivity: To deal with the dynamicity of the infrastructure, a LUC OS should swiftly handle events that require performing particular operations, either on virtual or on physical resources. This has to be done with the objective of maximizing the system utilization while meeting the quality of service (QoS) expectations of VEs. Some examples of operations that should be performed as fast as possible include (i) the reconfiguration of VEs over distributed resources, sometimes spread across wide area networks, or (ii) the migration of VMs, while preserving their active connections. • Resiliency: In addition to the inherent dynamicity of the infrastructure, failures and faults should be considered as the norm rather than the exception at such a scale. The goal is therefore to transparently leverage the underlying infrastructure redundancy to (i) allow the LUC OS to keep working despite node failures and network disconnections (LUC OS robustness) and to (ii) provide snapshotting as well as high availability mechanisms for VEs (VM robustness). • Sustainability: Although the LUC approach would reduce the energy footprint of UC services by minimizing the cost of the network, it is important to go one step further by considering energy aspects at each level of a LUC OS and propose advanced mechanisms in charge of making an optimal usage of each source of energy. To achieve such an objective, the LUC OS should take account of data related to the energy consumption of the VEs and the computing resources, as well as the environmental conditions (computer room air conditioning unit, location of the site, etc.). • Security and Privacy: Similarly to resiliency, security, and privacy issues affect the LUC OS itself and the VEs running on it. Regarding the LUC OS, the goals are to (i) create trust relationships between different locations, (ii) secure the peer-to-peer layers, (iii) include security and privacy decision and enforcement points in the LUC OS and (iv) make them collaborate through the secured peer-to-peer layers to provide end-to-end security and privacy. Regarding the VEs, users should be able to express their requirements in terms of security and privacy; these requirements would then be enforced by the LUC OS.

In addition to the aforementioned objectives, working on a virtual infrastructure requires to deal with the management of VM images. Managing VM images in a distributed way across a wide area network (WAN) is a real challenge that will require to adapt state-of-the-art techniques related to replication and deduplication. Also, the LUC OS must take into account VM images location, for instance (i) to allocate the right resources to a VE or (ii) to prefetch VM images, to improve deployment performance or VM relocations.

Finally, one last scientific and technical challenge is the lack of a global view of the infrastructure. Maintaining a global view would indeed limit the scalability of the LUC OS, which is inconsistent with our objective to manage large-scale geographically distributed systems. Therefore, we claim that the LUC OS should rely on decentralized and autonomous mechanisms, that can match and adapt to the volatile topology of the infrastructure. Several decentralized mechanisms are already used in production on large-scale systems; for instance, Amazon relies on the Dynamo service [START_REF] Decandia | Dynamo: Amazon's Highly Available Key-Value Store[END_REF] to create distributed indexes and recover from data inconsistencies; moreover, Facebook uses Cassandra [START_REF] Lakshman | Cassandra: A Decentralized Structured Storage System[END_REF], a massive scale structured store that leverages peer-to-peer techniques. In a LUC OS, decentralized and selforganizing overlays will enable to maintain the information about the current state of both virtual and physical resources, their characteristics and availabilities. Such information is mandatory to build higher-level mechanisms ensuring the correct execution of VEs throughout the whole infrastructure.

Background

Several generations of UC infrastructures have been proposed and still co-exist [START_REF] Foster | Advances in Parallel Computing[END_REF]. However, neither Desktop, nor Grid, nor Cloud Computing platforms provide a satisfying UC model. Contrary to the current trends that promotes large offshore centralized DCs as the UC platform of choice, we claim that the only way to achieve sustainable and highly efficient UC services is to target a new infrastructure that better matches the Internet structure. Because it aims at gathering an unprecedented amount of widely distributed computing resources into a single platform providing UC services close to the end-users, a LUC infrastructure is fundamentally different from existing ones. Keeping in mind the aforementioned objectives, recycling UC resource management solutions developed in the past is doomed to failure.

As previously mentioned, our vision significantly differs from hybrid Cloud Computing solutions. Although these research activities address important concerns related to the use of federated Cloud platforms, such as interface standardization for supporting cooperation and resource sharing, their propositions are incremental improvements of existing UC models. Recent investigations on hybrid Clouds and Cloud federation are comparable in some ways to previous works done on Grids, since the purpose of a Grid middleware is to interact with each resource management system composing the Grid [START_REF] Buyya | InterCloud: Utility-Oriented Federation of Cloud Computing Environments for Scaling of Application Services[END_REF][START_REF] Rochwerger | The Reservoir Model and Architecture for Open Federated Cloud Computing[END_REF][START_REF] Zhao | CloudBay: Enabling an Online Resource Market Place for Open Clouds[END_REF].

By taking into account network issues, in addition to traditional computing and storage concerns in Cloud Computing systems, the European SAIL project3 is probably the one which targets the biggest advances with regard to previous works on Grid systems. More concretely, this project investigates new network technologies to provide end-users of hybrid/federated Clouds with the possibility to configure and virtually operate the network backbone interconnecting the different sites they use [START_REF] Murray | Cloud Networking: An Infrastructure Service Architecture for the Wide Area[END_REF].

More recently, the Fog Computing concept has been proposed as a promising solution to applications and services that cannot be put into the Cloud due to locality issues (mainly latency and mobility concerns) [START_REF] Bonomi | Fog Computing and its Role in the Internet of Things[END_REF]. Although it might look similar to our vision as they propose to extend the Cloud Computing paradigm to the edge of the network, Fog Computing does not target a unified system but rather proposes to add a third party layer (i.e. the Fog) between Cloud vendors and end-users.

In our vision, UC resources (i.e. Cloud Computing ones) should be repacked in the different points of presence of backbones and operated through a unified system, the LUC OS. As far as we know, the only system that investigated whether a widely distributed infrastructure can be operated by a single system, was the XtreemOS Project [START_REF] Morin | XtreemOS: A Grid Operating System Making your Computer Ready for Participating in Virtual Organizations[END_REF]. Although this project shared some of the goals of the LUC OS, it did not investigate how the geographical distribution of resources can be leveraged to deliver more efficient and sustainable UC infrastructures.

To sum up, we argue for the design and the implementation of a kind of distributed OS, manipulating VEs instead of processes and considering locality as a primary concern. Referred to as a LUC OS, such a system will include most of the mechanisms that are common to current UC management systems [START_REF] Tedeschi | Open Source Cloud Computing[END_REF][START_REF]Nimbus is Cloud Computing for Science[END_REF][START_REF]Open Source Data Center Virtualization[END_REF][START_REF]The Open Source, Open Standards Cloud[END_REF][START_REF] Lowe | Mastering VMware vSphere 5[END_REF][START_REF] Moreno-Vozmediano | IaaS Cloud Architecture: From Virtualized Datacenters to Federated Cloud Infrastructures[END_REF]. However, each of them will have to be rethought in order to leverage peer-topeer algorithms. While largely unexplored for building operating systems, peerto-peer/decentralized mechanisms have the potential to achieve the scalability required to manage LUC infrastructures. Using this technology for establishing the base mechanisms of a massive-scale LUC OS will be a major breakthrough from current static, centralized or hierarchical management solutions.

Premises of a LUC OS: The DISCOVERY Proposal

In this section, we propose to go one step further by discussing preliminary investigations around the design and the implementation of a first LUC OS proposal: the DISCOVERY system (DIStributed and COoperative framework to manage Virtual EnviRonments autonomouslY). We draw the premises of the DISCOVERY system by emphasizing some of the challenges as well as some research directions to solve them. Finally, we give some details regarding the prototype that is under development and how we are going to evaluate it.

Overview

The DISCOVERY system relies on a multi-agent peer-to-peer system deployed on each physical resource composing the LUC infrastructure. Agents are autonomous entities that collaborate with one another to efficiently use the LUC resources. In our context, efficiency means that a good trade-off is found between users' expectations, reliability, reactivity and availability, while limiting the energy consumption of the system and providing scalability.

In DISCOVERY, each agent has two purposes: (i) maintaining a knowledge base on the composition of the LUC platform and (ii) ensuring the correct execution of VEs. This includes the configuration, deployment and monitoring of VEs as well as the dynamic allocation or relocation of VMs to adapt to changes in VEs requirements and physical resources availability. To this end, agents will rely on dedicated mechanisms related to:

• The localization and monitoring of physical resources, • The management of VEs, • The management of VM images, • Reliability, • Security and privacy.

Resource Localization and Monitoring Mechanisms

Keeping in mind that DISCOVERY should be designed in a fully decentralized fashion, its mechanisms should be built on top of an overlay network able to abstract out changes that occur at the physical level. The specific requirements of this platform will lead to the development of a novel kind of overlay networks, based on locality and a minimalistic design. More concretely, the first step is to design, at the lowest level, an overlay layer intended to hide the details of the physical routes and computing utilities, while satisfying some basic requirements such as locality and availability. This overlay needs to enable the communications between any two nodes in the platform. While overlay computing has been extensively studied over the last decade, we emphasize here on minimalism, and especially on one key feature to implement a LUC OS: retrieving nodes that are geographically close to a given departure node.

Giving Nodes a Position

The initial configuration of the physical network can take an arbitrary shape. We choose to rely on the Vivaldi protocol [START_REF] Dabek | Vivaldi: a decentralized network coordinate system[END_REF]. Vivaldi is a distributed algorithm assigning coordinates in the plane to nodes of a distributed system. Each node is equipped with a view of the network, i.e., a set of nodes it knows. This view is initially assumed as random. Coordinates obtained by a node reflects its position in the network, i.e., close nodes in the network are given close coordinates in the plane. To achieve this, each node periodically checks the round trip time between itself and another node (randomly chosen among nodes in its view) and adapts its distance (by changing its coordinates) with this node in the plane accordingly. See Figure 2 and Figure 3 for an illustration of 4 nodes (A, B, C and D) moving according to the Vivaldi protocol. A globally accurate positioning of nodes can be obtained if nodes have a few long-distance nodes in their view [START_REF] Dabek | Vivaldi: a decentralized network coordinate system[END_REF]. These long distance links can be easily maintained by means of a simple gossip protocol.

Searching for Close Nodes

Once the map is achieved (each node knows its coordinates), we are able to decide whether two nodes are close by calculating their distance. However, the view of each node does not a priori contain its closest nodes. Therefore, we need additional mechanisms to locate a set of nodes that are close to a given initial node -Vivaldi gives a location to each node, but not a neighborhood. To achieve this, we use a modified distributed version of the classic Dijkstra's algorithms used to find the shortest path between two nodes in a graph. The goal is to build a spiral4 interconnecting the nodes in the plane that are the closest ones to a given initial node. Let us consider that our initial point is a node called I. The first step is to find a node to build a two-node spiral with I. Such a node is sought in the view of I by selecting the node, say S, having the smallest distance with I. I then sends its view to S, I stores S as its successor in the spiral, and S adds I as its predecessor in the spiral. Then I forwards its view to S. S creates a new view by keeping the n nodes which are the closest to I in the views of I and S. This last view is then referred to as the spiral view and is intended to contain a set of nodes among which to find the next step of the spiral. Then S restarts the process: Among the spiral view, it chooses the node with the smallest distance to I, say S , and adds it in the spiral -S becomes the predecessor of S and S becomes the successor of S. Then, the spiral view is sent to S which updates it with the nodes it has in its own view. The process is repeated until we consider that enough nodes have been gathered (a parameter sent by the application).

Note that one risk is to be blocked by having a spiral view containing only nodes that are already in the spiral, leading to the impossibility to build the spiral further. However, this problem can be easily addressed by forcing the presence of a few long distance nodes whenever it is updated.

Learning

Applying the protocol described above, the quality of the spiral is questionable in the sense that the nodes that are actually close to the starting node s may not be included. The only property ensured is that one step forward on the built path always takes us further from the initial node.

To improve the quality of the spiral, i.e., reduce the average distance between the nodes it comprises and the initial node, we add a learning mechanism coming with no extra communication cost: when a node is contacted for becoming the next node in one spiral, and receives the associated spiral view, it can also keep the nodes that are the closest to itself, thus potentially increasing the quality of a future spiral construction.

Routing

In the context of a LUC infrastructure, one crucial feature is to be able to locate an existing VM. Having the same strategy consisting in improving the performance of the overlay based on the activity of the application, we envision a routing mechanism which will be improved by past routing requests. By means of the spiral mechanism, a node is able to contact its neighboring nodes to start routing a message.

This initial routing mechanism can be very expensive, as the number of hops can be linear in the size of the network. However, from previous communications, a node is able to memorize long links to different locations of the network. Consequently, from each routing request, the source of the request and each node on the path to the destination are able to learn long links, which will significantly reduce the number of hops of future requests. We are currently studying the amount of requests needed to get close to a logarithmic routing complexity. More generally, we are working on the estimation if the activity of the application required to (i) guarantee the constant efficiency of the overlay and to (ii) converge, starting from a random configuration, to a fully-efficient overlay network.

VEs Management Mechanisms

In the DISCOVERY system, we define a VE as a set of VMs that may have specific requirements in terms of hardware, software and also in terms of placement: For instance, some VMs must be on the same node/site to cope with performance objectives while others should not be collocated to ensure high-availability criteria [START_REF] Hermenier | BtrPlace: A Flexible Consolidation Manager for Highly Available Applications[END_REF]. As operations on a VE may occur in any place from any location, each agent should provide the capability to configure and start a VE, to suspend/resume/stop it, to relocate some of its VMs if need be or simply to retrieve the location of a particular VE. Most of these mechanisms are provided by current UC platforms. However, as mentioned before, they should be revisited and leverage peer-to-peer mechanisms to correctly run on the infrastructure we target (i.e. in terms of scalability, resiliency and reliability).

As a first example, placing the VMs of a VE requires to be able to find available nodes that fulfill the VM needs (in terms of resource requirements as well as placement constraints). Such a placement can start locally, close to the client application requesting it, i.e., in its local group. If no such node is found, a simple navigation ensures that the request will encounter a bridge, leading to the exploration of further nodes. This navigation goes on until an adequate node is found. A similar process is performed by the mechanism in charge of dynamically controlling and adapting the placement of VEs during their lifetime. For instance, to ensure the particular needs of a VM, it can be necessary to relocate other VMs. According to the predefined constraints of VEs, some VMs might be relocated on far nodes while others would prefer to be suspended. Such a mechanism has been deeply studied in the DVMS framework [START_REF]Distributed VM Scheduler[END_REF][START_REF] Quesnel | Cooperative and Reactive Scheduling in Large-Scale Virtualized Platforms with DVMS[END_REF]. DVMS (Distributed Virtual Machine Scheduler) is able to dynamically schedule a significant number of VMs throughout a large-scale distributed infrastructure while guaranteeing VM resource expectations.

A second example regards the networking configuration of VEs. Although it might look simple, assigning the right IP to each VM as well as maintaining the intra-connectivity of a VE becomes a bit more complex than in the case of a single network domain, i.e. a single site deployment. Keeping in mind that a LUC infrastructure is by definition spread WANwide, a VE can be hosted between distinct network domains during its lifetime. No solution has been chosen yet. Our first investigations led us to leverage techniques such as the IP over P2P project [START_REF] Ganguly | IP over P2P: Enabling Self-Configuring Virtual IP Networks for Grid Computing[END_REF]. However, software-defined networking becomes more and more important; investigating proposals such as the Open vSwitch project [START_REF] Pfaff | Extending Networking into the Virtualization Layer[END_REF] looks promising to solve such an issue.

VM Images Management

In a LUC infrastructure, VM images could be deployed in any place from any other location. However, being in a decentralized, large-scale, heterogeneous and widely spread environment makes the management of VM images more difficult than with conventional centralized repositories. At coarse grain, (i) the management of the VM images should be consistent with regard to the location of each VM in the DISCOVERY infrastructure and (ii) each VM image should remain reachable or at least recoverable in case of failures. The envisioned mechanisms to manage VM images have been classified into two categories. First, some mechanisms are required to efficiently upload VM images and replicate them many nodes, to ensure efficiency as well as reliability. Second, other mechanisms are needed to schedule VM image transfers. Advanced policies are important to improve the efficiency of each transfer that may occur either during the first deployment of a VM or during its relocations.

Regarding storage and replication mechanisms, an analysis of an IBM Cloud concludes that a fully distributed approach using peer-to-peer technology is not the best choice to manage VM images, since the number of instances of the same VM image is rather small [START_REF] Peng | VDN: Virtual Machine Image Distribution Network for Cloud Data Centers[END_REF]. However, central or hierarchical solutions are not suited for the infrastructure we target. Consequently, an improved peer-to-peer solution working with replicas and deduplication has to be investigated, to provide more reliability, speed, and scalability to the system. For example, analyzing different VM images shows that at least 30% of the image is shared between different VMs [START_REF] Jin | The effectiveness of deduplication on virtual machine disk images[END_REF]. This 30% can become a 30% reduction in space, or a 30% increase in reliability or in transfer speed. Depending on the situation, we should decide to go from one scenario to another.

Regarding the scheduling mechanisms, a study showed that VM boot time can increase from 10 to 240 seconds when multiple VMs running I/O intensive tasks use the same storage system [START_REF] Tan | Image Management in a Virtualized Data Center[END_REF]. Some actions, like providing the image chunks needed to boot first [START_REF] Tang | FVD: A High-Performance Virtual Machine Image Format for Cloud[END_REF], defining a new image format, and pausing the rest of the I/O operations, can provide a performance boost and limit the overhead that is still observed in commercial Clouds [START_REF] Mao | A Performance Study on the VM Startup Time in the Cloud[END_REF].

More generally, the amount of data linked with VM images is significant. Actions involving data should be aware of consequences on metrics like (but not limited to): energy efficiency, reliability, proximity, bandwidth and hardware usage. The scheduler could also anticipate actions, for instance moving images when the load is low or the energy is cheap.

Reliability Mechanisms

Although we can expect that the frequency of failures on LUC resources should be similar than in current UC platforms, it is noteworthy to mention that the expected mean time to repair failed equipments might be much higher since resources will be highly distributed. For these reasons, specific mechanisms should be designed to manage failures transparently with a minimum downtime.

Ensuring the high availability of the DISCOVERY system requires being able to autonomously relocate and restart any service on a healthy node in case of failure. Moreover, a Cassandra-like framework [START_REF] Lakshman | Cassandra: A Decentralized Structured Storage System[END_REF] is required to avoid losing or corrupting information belonging to stateful services, since it provides a reliable and highly available back-end.

Regarding VEs reliability, a first level of fault tolerance can be provided by leveraging periodical VM snapshotting capabilities. In case of failure, a VE can be restarted from its latest snapshot. Performing VM snapshotting in a large-scale, heterogeneous, and widely spread environment is a challenging task. However, we believe that adapting ideas that were recently proposed in this field [START_REF] Nicolae | Going Back and Forth: Efficient Multideployment and Multisnapshotting on Clouds[END_REF] would allow us to provide such a feature.

Snapshotting is not enough for services that should be made highly available, but a promising solution is to use VM replication [START_REF] Petrovic | Implementing virtual machine replication: A case study using xen and kvm[END_REF]. To implement VM replication in a WAN, solutions to optimize synchronizations between replicas [START_REF] Gerofi | Enhancing TCP Throughput of Highly Available Virtual Machines via Speculative Communication[END_REF][START_REF] Rajagopalan | SecondSite: Disaster Tolerance as a Service[END_REF] should be investigated. Also, we think that a LUC infrastructure has a major advantage over other UC platforms, since it is tightly coupled with the network infrastructure. As such, we can expect low latencies between nodes, that would enable us to provide a strong consistency between replicas while achieving acceptable response time for the replicated services.

Reliability techniques will of course make use of the overlays for resource localization and monitoring. Replicated VMs should be hosted on nodes that have a low probability to fail simultaneously. Following the previously defined overlay structure, this can be done through a navigation scheme where at least one bridge is encountered. Monitoring a replica can then be done by having a watcher in the same local group as the replica.

Security and Privacy Mechanisms

To be successful, DISCOVERY needs to provide mechanisms and methods to construct trust relationships between resource providers. Trust relationships are known to be complex to build [START_REF] Miller | In trust we trust[END_REF]. Providing strong authentication, assurance and certification mechanisms for providers and users is required but it is definitely not enough. Trust covers socio-economic aspects that must be addressed but are out of the scope of this chapter. The challenge is to provide a trusted DISCOVERY base.

As overlays are fundamentals for all DISCOVERY mechanisms, another challenge is to ensure that they are not compromised. Recent advances [START_REF] Castro | Secure Routing for Structured Peer-to-Peer Overlay Networks[END_REF] might enable to tackle such concerns.

The third challenge will consist in (i) providing end-users with a way to define their own security and privacy policies and (ii) ensuring that these policies are enforced. The expression of these policies itself is a complex task, since it requires to improve the current trade-off between security (and privacy) and usability. To ease the expression of these policies, we are currently designing a domain specific language to define high-level security and privacy requirements [START_REF] Blanc | Mandatory Protection within Clouds[END_REF][START_REF] Lefray | Security-Aware Models for Clouds[END_REF]. These policies will be enforced in a decentralized manner, by distributed security and privacy decision and enforcement points (SPDEPs) during the lifetime of the VEs. Implementing such SPDEP mechanisms in a distributed fashion will require to conduct specific research, since currently there are only prospective proposals for classic UC infrastructures [START_REF] Bacon | Enforcing End-to-End Application Security in the Cloud (Big Ideas Paper)[END_REF][START_REF] Sandhu | Towards a Discipline of Mission-Aware Cloud Computing[END_REF]. Therefore, we need to investigate whether such proposals can be adapted to the LUC infrastructure by leveraging appropriate overlays.

Toward a First Proof of Concept

The first prototype is under heavy development. It aims at delivering a simple mockup for integration/collaboration purposes. Following the coarse-grained architecture described in the previous sections, we have started to identify all the components participating in the system, their relationships, as well as the resulting interfaces. Conducting such a work now is mandatory to move towards a more complete as well as more complex system.

To ensure a scalable and reliable design, we chose to rely on the use of high-level programming abstractions; more precisely, we are using distributed complex event programming [START_REF] Janiesch | A Blueprint for Event-Driven Business Activity Management[END_REF] in association with the actors model [START_REF] Agha | Actors: A Model of Concurrent Computation in Distributed Systems[END_REF]. This enables us to easily switch between a push and a pull oriented approach depending on our needs.

Our preliminary studies showed that a common building block is mandatory to handle resiliency concerns in all components. Concretely, it corresponds to a mechanism in charge of throwing notifications that are triggered by the low level network overlay each time a node joins or leaves it. Such a mechanism makes the design and the development of higher building blocks easier as they do not have to provide specific portions of code to monitor infrastructure changes.

This building block has been designed around the Peer Actor concept (see Figure 4 and Figure 5). The Peer Actor serves as an interface between higher services and the communication layer. It provides methods that enable to define the behaviors of a service when a resource joins or leaves a particular peer-to-peer overlay as well as when neighbors change. Considering that several overlays may co-exist in the DISCOVERY system, the association between a Peer Actor and its Overlay Actor is done at runtime and can be changed on the fly if need be. However, it is noteworthy that each Peer Actor takes part to one and only one overlay at the same time. In addition to the Overlay Actor, a Peer Actor is composed of a Notification Actor that processes events and notifies registered actors. As illustrated in Figure 5, a service can use more than one Peer Actor (and reciprocally). Mutualizing a Peer Actor enables for instance to reduce the network overhead implied by the maintenance of the overlays. In the example, the first service relies on a Peer Actor implementing a Chord overlay [START_REF] Stoica | Chord: A Scalable Peerto-Peer Lookup Service for Internet Applications[END_REF], while the second service uses an additional Peer Actor implementing a CAN structure [START_REF] Ratnasamy | A scalable content-addressable network[END_REF]. Fig. 4 The Peer Actor Model. The Supervisor Actor monitors all the actors it encapsulates while the Peer Actor acts as an interface between the services and the overlay. By such a mean, higher-level services can take the advantage of the advanced communication layers without dealing with the burden of managing the different overlays. As an example, when a node disappears, all services that have been registered as dependent on such an event are notified. Service actors can thus react accordingly to the behavior that has been specified.

Regarding the design and the implementation of the DISCOVERY system, each service is executed inside its own actor and communicates by exchanging messages with the other ones. This ensures that each service is isolated from the others: When a service crashes and needs to be restarted, the execution of other services is not affected. As previously mentioned, we consider that at the LUC infrastructure scale, failures are the norm rather than the exception; hence we decided that each actor would be monitored by a Supervisor Actor (see Figure 4). DISCOVERY services are under the supervision of the DISCOVERY agent: This design allows to precisely define a strategy that will be executed in case of service failures. This will be the way to introduce self-healing and self-organizing properties to the DISCOVERY system.

This building block has been fully implemented 5 by leveraging the Akka/Scala framework [START_REF]Build powerful concurrent & distributed applications more easily[END_REF].

As a proof of concept, we are implementing a first high level service in charge of dynamically scheduling VMs across a LUC infrastructure by leveraging the DVMS [START_REF] Quesnel | Cooperative and Reactive Scheduling in Large-Scale Virtualized Platforms with DVMS[END_REF] proposal (see Section 4.3). The low-level overlay that is being currently implemented is a robust ring based on the Chord algorithm combined with the Vivaldi positioning system: It enables services to select nodes that have low latency, so that collaboration will be more efficient.

To validate the behavior, the performance as well as the reliability of our proof of concept (POC), we are performing several experiments on the Grid'5000 testbed 6 that comprises hundreds of nodes distributed on 10 computing sites that are geographically spread across France. To make experiments with DISCOVERY easier, we developed a set of scripts that can deploy thousands of VMs throughout the whole infrastructure in a one-click fashion [START_REF] Balouek | Flauncher and DVMS -Deploying and Scheduling Thousands of Virtual Machines on Hundreds of Nodes Distributed Geographically[END_REF]. By deploying our POC on each node and by leveraging the VM deployment scripts, we can evaluate real scenario by injecting specific workloads in the different VMs. The validation of this first POC is almost completed. The resulting system will be the first to provide reactive, reliable and scalable reconfiguration mechanisms of virtual machines in a fully distributed and autonomous way. This new result will pave the way for a complete proposal of the DISCOVERY system.

5 Future Work/Opportunities

Geo-diversification as a Key Element

The Cloud Computing paradigm is changing the way applications are designed. In order to benefit from elasticity capabilities of Cloud systems, applications integrate or leverage mechanisms to provision resources, i.e. starting or stopping VMs, according to their fluctuating needs. The ConPaaS system [START_REF] Pierre | ConPaaS: A Platform for Hosting Elastic Cloud Applications[END_REF] is one of the promising systems for elastic Cloud applications. At the same time, a few projects have started investigating distributed/collaborative ways of hosting famous applications such as Wikipedia or Facebook-like systems by leveraging volunteer computing techniques. However, considering that resources provided by end-users were not reliable enough, only few contributions have been done yet. By providing a system that will enable to operate widely spread but more reliable resources closer to the end-users, the LUC proposal may strongly benefit to this research area. Investigating the benefit of locality provisioning (i.e. combining elasticity and distributed/collaborative hosting) is a promising direction for all Web services that are embarrassingly distributed [START_REF] Church | On Delivering Embarrassingly Distributed Cloud Services[END_REF]. Image sharing systems, such as Google Picasa or Flickr, are examples of applications where leveraging locality will enable to limit network exchanges: Users could upload their images on a peer that is close to them, and images would be transferred to other locations only when required (pulling vs. pushing model).

LUC infrastructures will allow envisioning a wider range of services that may answer specific SMEs requests such as data archiving or backup solutions, while significantly reducing the network overhead as well as legal concerns. Moreover, it will make the deployment of UC services easier by relieving developers of the burden of dealing with multi-Cloud vendors. Of course, this will require software engineering and middleware advances to easily take advantage of locality. But proposing LUC OS solutions, such as the DISCOVERY project, is the mandatory step before investigating new APIs enabling applications to directly interact with the LUC OS internals.

Energy, a Primary Concern for Modern Societies

The energy footprint of current UC infrastructures, and more generally of the Internet, is a major concern for the society. Although we need to conduct deeper investigations, we clearly expect that by its design and the way to operate it, a LUC infrastructure will have a smaller impact with a better integration in the whole Internet ecosystem.

Moreover, the LUC proposal is an interesting way to deploy the data furnaces proposal [START_REF] Liu | The Data Furnace: Heating up with Cloud Computing[END_REF]. Concretely, following the smart city recommendations (i.e. delivering efficient and sustainable ICT services), the construction of new districts in metropolises may take advantage of each LUC/Network PoP in order to heat buildings while operating UC resources remotely by means of a LUC OS. Finally, this idea might be extended by taking into account recent results about passive data centers, such as solar-powered micro-data centers 7 . The idea behind passive computing facilities is to limit as much as possible the energy footprint of major hubs and DSLAMS by taking advantage of renewable energies to power them and by using the heat they product as a source of energy. Combining such ideas with the LUC approach would allow reaching an unprecedented level of energy efficiency for UC platforms.

Conclusion

Cloud Computing has entered our everyday life at a very high speed and huge scale. From classic high performance computing simulations to the management of huge amounts of data coming from mobile devices and sensors, its impact can no longer be minimized. While a lot of progress has already been made in Cloud technologies, there are several concerns that limit the complete adoption of the Cloud Computing paradigm.

In this paper, we outlined that, in addition to these concerns, the current model of UC is limited by intrinsic issues. Instead of following the current trend by trying to cope with existing platforms and network interfaces, we proposed to take a different direction by promoting the design of a system that will be efficient and sustainable at the same time, putting knowledge and intelligence directly into the network backbone itself.

The innovative approach we introduced will definitely tackle and go beyond Cloud Computing limitations. Our objective is to pave the way for a new generation of Utility Computing that better matches the Internet structure by means of advanced operating mechanisms. By offering the possibility to tightly couple UC servers and network backbones throughout distinct sites and operate them remotely, the LUC OS technology may lead to major changes in the design of UC infrastructures as well as in their environmental impact. The internal mechanisms of the LUC OS should be topology dependent and resources efficient. The natural distribution of the nodes through the different points of presence should be an advantage, which allows to process a request according to its scale: Local requests should be computed locally, while large computations should benefit from a large number of nodes.

Finally, we believe that LUC investigations may contribute to fill the gap between the distributed computing community and the network one. This connection between these two communities has already started with the different activities around Software-defined Networking and Network as a Service. This may result in the long view in a new community dealing with UC challenges where network and computational concerns are fully integrated. Such a new community may leverage the background of both areas to propose new systems that are more suitable to accommodate the needs of our modern societies.

We are of course aware that the design of a complete LUC OS and its adoption by companies and network providers require several big changes in the way UC infrastructures are managed and wide area networks are operated. However we are convinced that such an approach will pave the way towards highly efficient as well as sustainable UC infrastructures, coping with heterogeneity, scale, and faults.

Fig. 2

 2 Fig. 2 Vivaldi plot before updating positions. Each node pings other nodes. Each node maintains a map of distance.

Fig. 3

 3 Fig. 3 Vivaldi plot after updating positions. The computed positions of other nodes have been updated.

Fig. 5 A

 5 Fig. 5 A Peer Actor Instantiation. The first service relies on a Peer Actor implementing a Chord overlay while the second service uses an additional PeerActor implementing a CAN structure.

Supervisor Actor Supervisor Actor Supervisor Actor Supervisor Actor Peer Actor Peer Actor Notification Actor Notification Actor Overlay Actor Overlay Actor

http://www.renater.fr

http://www.sail-project.eu

The term spiral is here a misuse of language, since the graph actually drawn in the plane might contain crossing edges. The only guarantee is that when following the path constructed, the nodes are always further from the initial node.

Code is available at: https://github.com/BeyondTheClouds

https://www.grid5000.fr

http://parasol.cs.rutgers.edu


H Ben Boubaker

Y Ayed

C Mareau

G Germain

On the Formation of Adiabatic Shear Bands in Titanium Alloy Ti17 Under Severe Loading Conditions

Keywords: Ti17, Strain rate sensitivity, Adiabatic shear bands, microstructure evolution

For metallic materials, fabrication processes (e.g. machining and forging) may involve important strain rates and high temperatures. For such severe loading conditions, the development of damage is often associated with the formation of Adiabatic Shear Bands (ASB). In this work, the impact of loading conditions (strain rate, temperature) on the formation of ASB in a beta rich titanium alloy (Ti17) is investigated. In this perspective, uniaxial compression tests have been conducted on cylindrical samples with a Gleeble-3500 thermo-mechanical simulator at temperatures ranging from 25 • C to 800 • C and strain rates ranging from 0.1 to 50 s -1 with axial strains of approximately 50 %. According to the experimental results, the flow curves exhibit hardening from 25 • C to 550 • C and softening from 600 • C to 800 • C. When looking at the evolution of flow stress, the strain rate sensitivity is found to increase significantly with increasing temperatures. Also, adiabatic shear bands are preferably observed for high strain rates and low temperatures. The formation of ASB thus seems to be quite dependent on the evolution of the strain rate sensitivity of Ti17. Finally, metallographic observations have been carried out to better understand the process leading to the formation of ASB. Such observations demonstrate that the average width of ASB increases with increasing temperatures and decreasing strain rates. However, such observations do not allow for identifying whether some specific microstructural transformations (e.g recrystallization or phase transformation) could explain the formation of ASB or not.

Introduction

Titanium alloys are widely used for aerospace applications because of their interesting properties, notably their high strength to weight ratio, good corrosion resistance and high mechanical resistance even at high temperatures. The Ti17 titanium alloy (Ti-5Al-2Sn-4Mo-2Zr-4Cr) is a near-beta alloy that has been designed for compressor blades in aircraft engines and gas turbine applications [START_REF] Delfosse | Forgeage beta du ti17 proprietes en fatigue[END_REF]. It offers higher mechanical properties and creep resistance than many other titanium alloys, such as Ti-6Al-4V [START_REF] Teixeira | Etude experimentale et modelisation des evolutions microstructurales au cours des traitements thermiques post forgeage dans l alliage de titane ti17[END_REF]. However, the thermo-mechanical behavior of the Ti17 alloy under process conditions is quite complex, mostly because many physical phenomena tend to superimpose (e.g. crystallographic slip, phase transformation, recrystallization). As a result, different studies have been carried out to better understand the thermo-mechanical behavior of the Ti17 alloy.

For instance, Ayed et al. [START_REF] Ayed | [END_REF] investigated the behaviour of Ti17 alloy with uniaxial compression tests. According to the experimental results, the behavior of Ti17 is controlled by strain hardening from 25 • C to 500 • C while moderate softening is observed from 600 • C to 800 • C. Ning et al. [4] and Li et al. [5] also studied the deformation behaviour of the Ti17 alloy from uniaxial compression tests at temperatures ranging from 780 • C to 920 • C and strain rates ranging from 10 -3 to 10 1 s -1 . They found that the apparent activation energy of Ti17 decreases with increasing strain but they did not analyze microstructural transformations. To better understand the process driving the formation of adiabatic shear bands (ASBs), Wang et al. [6] studied the dynamic behaviour of Ti17 at strain rates ranging from 2000 to 6000 s -1 and temperatures from 25 • C to 700 • C using a Split Hopkinson Pressure Bar (SHPB). The obtained stressstrain curves exhibit a peak stress followed by a softening which is associated with the formation of ASBs. Yang et al. [7] used Transmission Electron Microscopy (TEM) to observe the microstructure of ASBs. They observed the microstructure of Ti17 to be composed of elongated sub-grains along ASB boundaries while the interior of an ASB is formed with fine equiaxed sub-grains.

The present research aims at investigating the thermo-mechanical behaviour of the Ti17 titanium alloy in a large range of loading conditions with uniaxial compression tests. In this paper, the experimental procedure is first presented and the impact of loading conditions on the mechanical behavior of Ti17 is then discussed. Finally, Optical Microscopy (OM) and Scanning Electron Microscopy (SEM) are used to investigate the conditions governing the formation of ASBs.

Material description and experimental procedure

The initial lamellar microstructure of the as-received Ti17 alloy is shown in Fig 1 . The microstructure is composed of α phase lamellae (with a volume fraction of 67%) being embedded in a β phase matrix (with a volume fraction of 33%). The thickness of α phase lamellae is approximately of 8-10 μm while the size of former β grains is about 700 μm. To investigate the mechanical behavior of Ti17, uniaxial compression tests have been performed on a Gleeble 3500 machine under vacuum condition (10 -5 bar) with cylindrical specimens. The elongation has been measured from an extensometer and temperature has been controlled with a K-type thermocouple. It is necessary to point out that every test has been repeated at least three times. In this work, the imposed strain rate ranges from 10 -1 to 50 s -1 and the test temperature is comprised between 25 • C and 800 • C. For each test, the experimental procedure is as follows. The specimen is first rapidly heated from room temperature to the test temperature with a rate of 100 • C/s. The temperature is maintained for 5 seconds to limit temperature gradients. The compression test is then carried out with a constant nominal strain rate up to an axial strain of 50%. The deformed specimen is finally quenched immediately after the compression test using a compressed-air jet. It should be noticed that, with the above procedure, the total duration of a compression test is low enough to avoid phase transitions.

Experimental results and discussion

The evolution of the true stress σ as a function of the logarithmic strain ε is shown in Fig 2 for different loading conditions. According to experimental results, an increase of the strain rate and/or a decrease of the temperature is generally associated with an augmentation of the flow stress and a reduction of the fracture strain. These effects are classically explained from the impact of short range obstacles, which can be overcome by thermal activation, on dislocation mobility [START_REF]Introduction to Dislocations[END_REF]. Also, whatever the loading conditions are, the Ti17 alloy does not exhibit any steady behavior.

To better understand the impact of loading conditions on the mechanical behavior of Ti17, the strain hardening coefficient n and the strain rate sensitivity coefficient m have been evaluated. For given strain rate ε and temperature T , the hardening coefficient n is given by:

n = ∂ log σ ∂ log ε ε,T (1)
For fixed temperature and fixed strain, the strain rate sensitivity coefficient m is obtained from: The above coefficients have been calculated for an axial plastic strain ε p of 10%. The results are displayed in Fig 3 . Strain hardening is significant for low temperatures (i.e. T < 550 • C) while the high temperature (i.e. T > 550 • C) mechanical behavior is controlled by strain softening. The temperature associated with the transition from strain hardening to strain softening is found to be independent on the strain rate. At this stage, the physical origin of strain softening is unclear. While a significant contribution of dynamic recovery is expected, some other phenomena cannot be excluded. Indeed, because of heat dissipation, compression tests are generally not isothermal. Softening may therefore be partly explained by the temperature increase resulting from heat dissipation. Also, for large strains,

m = ∂ log σ ∂ log ε ε,T (2)

s

-1 1 s -1 10 s -1 50 s -1 25 • C • • • • 450 • C • • • • 550 • C • • • • 600 • C • • • • 650 • C • • • • 700 • C • • • • 750 • C • • • • 800 • C • • • •
According to Fig 3, an important increase of the strain rate sensitivity coefficient is observed from 700 • C. In the temperature range corresponding to low strain rate sensitivity (i.e. T ≤ 600 • C), adiabatic shear bands are quasisystematically detected. As shown in Fig 4, adiabatic shear bands are always oriented with an angle of ±45 • with respect to the compression axis. For higher temperatures (i.e. T ≥ 650 • C), the occurrence of adiabatic shear banding is dependent on the applied strain rate, strain localization being preferably observed for higher strain rates. The loading conditions (strain rate and temperature) upon which adiabatic shear bands are formed are summarized in Table 1.

As shown in Fig 6, the microstructure within an adiabatic shear band is composed of α phase lamellae which have been rotated toward the shear direction. This indicates that shear banding is not a consequence of the α → β phase transformation. Also, the rigid body motion of α phase lamellae suggests that plastic deformation within an adiabatic shear band preferably occurs in the β phase matrix. In the exterior region of a shear band, the microstructure remains quite unchanged. The evolution of the average thickness L AS B of an adiabatic shear band as a function of temperature and strain rate is plotted in Fig 5 . As classically observed [START_REF] Dodd | Adiabatic shear localization Frontiers and Advances[END_REF][START_REF] Grady | [END_REF], the average thickness is significantly reduced when the temperature is decreased and the strain rate is increased.

When the conditions for adiabatic shear banding are not met, plastic deformation concentrates in the central region of compression specimens. As illustrated by Fig 4, this alternative strain localization mode results in the progressive formation of a highly deformed region. According to metallographic observations, the microstructure of a highly deformed region is composed of α phase lamellae being perpendicular to the compression axis. The formation of a such layered microstructure could participate in strain softening. The contribution of α phase lamellae to the overall resistance is indeed limited in this specific microstructural configuration.

Conclusions

The dynamic response of the Ti17 titanium alloy has been investigated at strain rates ranging from 0.1 s -1 to 50 s -1 and temperatures ranging from 25 • C to 800 • C. To this end, different uniaxial compression tests have been performed. The main conclusions of this study are:

• The mechanical behavior of Ti17 is controlled by strain hardening at low temperatures (i.e. < 550 • C) while the high temperature behavior is significantly impacted by strain softening. • Two different types of strain localization phenomena have been observed. At low temperatures and high strain rates, adiabatic shear banding is the favoured localization mode. At high temperatures, highly deformed regions are obtained from the localization of plastic deformation in the middle region of compression specimens. • The thickness of shear bands is reduced when the strain rate is increased or the temperature is decreased.

The mechanical behavior of Ti17 titanium alloy allows the identification of a crystal plasticity model used to simulate machining. The crystal plasticity model will present the ability to simulate the evolution of the material texture under severe loading condition. It allows a better understanding of titanium alloys Ti17 chip formation in orthogonal cutting.

FIGURE 1 :

 1 FIGURE 1: observation of the initial microstructure of the Ti17 alloy: OM (left) and SEM (right).

FIGURE 2 :

 2 FIGURE 2: Stress-strain curves for temperatures ranging from 25 • C to 800 • C and strain rates ranging from 0.1 s -1 to 50 s -1

FIGURE 3 :

 3 FIGURE 3: Evolutions of the hardening coefficient n and the strain rate sensitivity coefficient m as a function of temperature

1 FIGURE 4 :

 14 FIGURE 4: Metallographic observations of Ti17 specimens after deformation at a strain rate of 1 s -1 for different temperatures.

FIGURE 5 :

 5 FIGURE 5: Evolution of the average thickness L AS B of an Adiabatic Shear Band as a function of temperature and strain rate in Ti17 under uniaxial compression.

TABLE 1 :

 1 Summary of the conditions (strain rate

	and temperature) upon which an Adiabatic Shear
	Band (•) or a Highly Deformed Region (•) is ob-
	served in Ti17.