Piyush Harsh
email: piyush.harsh@inria.fr

Florian Dudouet
email: florian.dudouet@inria.fr

Roberto G Cascella
email: roberto.cascella@inria.fr

Yvon Jegou
email: yvon.jegou@inria.fr

Christine Morin
email: christine.morin@inria.fr

Using Open Standards for Interoperability Issues, Solutions, and Challenges facing Cloud Computing

Virtualization offers several benefits for optimal resource utilization over traditional non-virtualized server farms. With improvements in internetworking technologies and increase in network bandwidth speeds, a new era of computing has been ushered in, that of grids and clouds. With several commercial cloud providers coming up, each with their own APIs, application description formats, and varying support for SLAs, vendor lockin has become a serious issue for end users. This article attempts to describe the problem, issues, possible solutions and challenges in achieving cloud interoperability. These issues will be analyzed in the ambit of the European project Contrail that is trying to adopt open standards with available virtualization solutions to enhance users' trust in the clouds by attempting to prevent vendor lock-ins, supporting and enforcing SLAs together with adequate data protection for sensitive data.

I. INTRODUCTION

With the improvements in network bandwidth, more interesting uses of the Internet have emerged in recent times. One such use is remote execution of tasks on distant physical machines. The tremendous body of work in grid computing paved the way for better commercial utilization of the technology for general purpose computing tasks such as web hosting, data aggregators using map-reduce, scientific and commercial work loads within the ambit of cloud computing.

Cloud computing has come as a blessing for small-midscale enterprises, SMEs.It has allowed companies to lease computing infrastructures at economical rates and has reduced the infrastructure entry barrier for new companies significantly. As more and more uses of cloud computing are being explored, the technology faces new challenges that need timely intervention for the pace of adoption of cloud computing to be sustained and even improved.

Many traditional software and services companies have already jumped on the cloud computing bandwagon. Notable among them are public Cloud offerings from Amazon [START_REF]Amazon Web Services[END_REF], Google [START_REF]Google App Engine[END_REF], and Microsoft [START_REF]Windows Azure[END_REF]. In addition service bigwigs such as IBM [START_REF]IBM Smart Cloud[END_REF] and HP [START_REF]HP Cloud[END_REF] are not far behind either. There is tremendous activity in improving the hypervisor technology going on in both commercial as well as in the realm of open source software development. A hypervisor is a hardware virtualization software that allows multiple operating systems to run on the same physical machine. The term hypervisor is in a sense superlative of the term supervisor. It is the central element in any cloud computing offering. With the multitude of virtualization solution available from both commercial vendors such as VMWare and Citrix, as well as reasonably mature open source free technologies such as KVM [START_REF]Kernel Based Virtual Machine[END_REF], XEN [START_REF]Xen R hypervisor[END_REF], VirtualBox [START_REF]VirtualBox[END_REF], etc, the pace of research exploring value addition on top of such technologies has picked up tremendously in recent years.

But with the ease of movement of computation and data in the clouds, comes numerous challenges that must be addressed promptly. Some of the challenges belong in the realm of traditional network security research, but many more new challenges are coming up, some that are beyond the realm of computer science to solve and require a new and radical scrutiny of international data and privacy laws and legal jurisdiction in this interconnected world that is no longer bound by physical boundaries. This paper will try to touch upon few of these issues. It will try to explore possible solutions and analyze the challenges in the remaining issues which are bound to plague the world of cloud computing sooner or later. Cloud interoperability has emerged as a major issue. The prospect of vendor lock-ins may be keeping big customers including governments, healthcare, and banking away from the clouds. Hence addressing the issue of interoperability and portability is both timely and necessary.

In order to better define the problem of interoperability, it is important to understand what is interoperability. Typically it means the ability of different heterogenous systems to be able to function/interact together. For clouds, interoperability could be defined as the ability to understand each others application formats, Service Level Agreement (SLA) templates, authentication and authorization token formats and attribute data. Although this paper will identify several challenges in this field, the main focus will be limited to investigating the problem of cloud interoperability.

II. POTENTIAL AND CHALLENGES

With cloud computing, a person can lease a large number of compute nodes made available by an Infrastructure as a Service (IaaS) provider. The user can then create virtual machines configured to run the desired application and deploy them over the leased compute nodes. Another scenario, a user could request the services from Platform as a Service (PaaS) provider that already hosts services required by the end user to execute her application. It could be a simple PHP code requiring the services of a simple SQL database. In this scenario, the user just needs to focus her energy on service development and not worry about where and how to setup the virtual machine to host and execute her services. In a more complex example, the user can combine services from different kind of providers, use a PaaS provider in conjunction with a Storage as a Service (SaaS) provider to lease a chunk of online data space to hold the data, log files, configurations, etc. There are even attempts to provide Service as a Service to the end user where they can use service composition to create a more complex service. The scope of innovation with cloud computing seems limitless today.

For big enterprises, the biggest asset is the intellectual property and the knowledge they have in the data they own. They are rightly reluctant in putting and hosting such data in an environment where they do not maintain absolute control.

Another constraint comes from the data protection and privacy laws enforced by different governments. Such laws call for strict geo-location restriction of data hosting and movement.

Then there comes the problem of SLAs between the end users and the provider. How does one verify that the agreed SLAs were honored in the first place, and if violated how can such violations be proved for possible claims and settlements?

Another concern is disparity in cloud APIs provided by different vendors to the end users. Such disparity results in vendor lock-in situations where a user is unable to migrate her cloud deployment over to another cloud provider because of interface incompatibilities between the two.

There can be security issues arising from colocation of multiple applications in the same physical local area network (LAN). How does one enforce traffic isolation between different applications. How does one provide VM protection from a malicious cloud application being hosted inside the same cluster and LAN?

While there are many more challenges that needs addressing, the one we will focus in this article is achieving interoperability between multiple cloud providers. The interoperability is an important aspect from the perspective of an end user which to some extent addresses the problem of vendor lockins. We will point out challenges to true interoperability and present the current landscape of the community and industry efforts in this direction.

III. ESSENTIAL ELEMENTS OF A DISTRIBUTED CLOUD

APPLICATION

Before beginning to address the problem of interoperability, it is important to first understand the key components making up a typical cloud application. It makes sense to look at IaaS services to get the true picture as other forms of cloud services such as PaaS and SaaS are value addition on top of IaaS services.

A cloud application to be hosted over IaaS clouds comprise of sets of VMs possibly linked with each other in a private LAN with access to/from external Internet through a gateway or a proxy. Therefore the critical elements of an IaaS cloud application are:

• Virtual Machines description;

• Virtual Network elements linking VMs;

• OS image files to run inside the VMs;

• Data Stores to be attached to the VMs. Apart from the bare-minimum requirements that has been listed above, the user would also require some formalism in the agreement between herself and the provider. These would include such elements as:

• Service Level Agreements (SLAs);

• Placement restrictions and data protection agreements (QoP); • Billing and auditing provisions for compliance tests and verification; • Monitoring mechanisms for the user to infer the health of the deployed application. With the pieces in the puzzle identified, one can start to look into how to achieve interoperability between different cloud providers. For full interoperability, each of the above identified piece must be easily portable between different providers, at least in the format and the processes involved.

IV. STANDARDS LANDSCAPE

Open standards are the main proponents of interoperability. An inclusive standardization process has more milage in getting accepted by the stakeholders than a process that is exclusive. A question may be raised regarding the adoption of cloud standards by well entrenched providers. Why is being interoperable good for them? Critics always point that being able to vendor-lock-in a customer is good for the business as it may reduce customer churn, but in our opinion this may not be true. Brand loyalty can be achieved by providing superior services at attractive prices. Further being interoperable could bring in big government, banks, and health-care providers' businesses into clouds thus vastly increasing the customer base.

Many organizations are involved in various standardization efforts on the common theme of clouds. Notable among them are the working groups operating within the Open Grid Forum (OGF) [START_REF]OpenGridForum[END_REF] umbrella. Other prominent industry consortiums active in cloud standardization effort are Distributed Management Task Force, Inc. (DMTF) [START_REF]Distributed Management Task Force, Inc[END_REF], and the Storage Networking Industry Association (SNIA) [START_REF]Storage Networking Industry Association[END_REF]. In this section we will summarize key open cloud standards that have emerged and point out the cloud component they try to standardize.

The following open standards do help build bridges towards the goal of achieving user applications and cloud providers interoperability. A significant progress has been made for pivotal elements such as storage, infrastructure management, and application description formats, but there still remains much work to be done to reach the final destination.

A. OGF OCCI

Open Cloud Computing Interface (OCCI) [START_REF] Metsch | Open Cloud Computing Interface -Core[END_REF] [13] [START_REF]Open Cloud Computing Interface -RESTful HTTP Rendering[END_REF] proposed standard from the OGF OCCI-Working Group (WG) attempts to standardize the RESTful protocol and API for management tasks. Initially it was intended for management of IaaS clouds including deployment, autonomic scaling, and monitoring, but the standard is quite extensible and can be used for PaaS and SaaS services. The standard is made of three categories namely OCCI Core, OCCI Renderings, and OCCI Extensions. In the current release (version 1.1), it supports HTTP rendering and provides infrastructure extensions to deal with IaaS clouds.

B. OGF WS-Agreement

Web

Services Agreement Specification (WS-Agreement) [START_REF] Andrieux | Web Services Agreement Specification (WS-Agreement)[END_REF] is the standard specification for web services protocol needed for service level agreement between the two parties, i.e., the customer and the provider. This specification uses XML for specifying the agreement and the agreement templates. It consists of three composable parts that describe agreement, schema for describing an agreement template, and operation for managing the lifecycle of the service including monitoring of agreement states.

C. DMTF CIMI

Cloud Infrastructure Management Interface (CIMI) [START_REF] Davis | Cloud Infrastructure Management Interface (CIMI) Model and REST Interface over HTTP[END_REF] is a work-in-progress standardization effort within the DMTF consortium that targets management of resources within the IaaS domain. It implements a REST interface over HTTP and defines the REST APIs for both XML as well as JSON rendering. CIMI attempts to provide first-class support to Open Virtualization Format standard. This work attempts to provide a RESTful management interface for common IaaS components including machines, networks, volumes, etc.

D. DMTF OVF

OVF stands for Open Virtualization Format [START_REF] Crosby | Open Virtualization Format Specification[END_REF] and aims to completely describe a virtual appliance comprised of any number of virtual machines in a standard and portable format. DMTF advertises this format as vendor-neutral as it contains no reference to any current vendor-specific information. Written as an XML file, it features descriptions of most of the components of such an appliance:

• VMs' hardware (CPU, Memory...) and contextualisation informations; • Disks and images used;

• Networking; • Startup order of the different VMs. This format is portable, being platform neutral, and is extensible by the end-users if needed. DMTF is working towards the next version of this standard with better support for VM contextualization [START_REF] Kowalski | Open Virtualization Format Specification[END_REF].

E. SNIA CDMI

Cloud Data Management Interface (CDMI) [START_REF] Slik | Cloud Data Management Interface[END_REF] defines a RESTful interface that allows cloud applications and users to retrieve and perform operations on the data from the cloud. The interface allows capability discovery of storage elements of the cloud. It also allows administrators to manage the containers, i.e., metadata, and user accounts and credentials pertaining to the cloud storage.

V. CONTRAIL: STRIVING TOWARDS INTEROPERABILITY

European project Contrail [20] [21] is developing a complete cloud platform which integrates a feature-rich PaaS offering on top of a federated IaaS cloud providers. An end user of Contrail Cloud Federation (CCF) will have the ability to do live migration of her applications from one provider to another. The CCF will have an extensive SLA support along with required monitoring mechanisms to enforce and manage the negotiated SLAs between the customers and the providers. The CCF will incorporate an extensive set of dedicated security suites to manage the authentication, authorization, VM isolation, and other security needs of the federation and end users. The CCF is being developed as an open source project with periodic public releases of the software suite [START_REF]Contrail Wiki[END_REF].

The CCF supports DMTF's OVF standard without introducing non-standard extensions. The project currently supports OpenNebula IaaS clouds but plans to provide support for OpenStack clouds along with commercial public cloud providers such as Amazon EC2. Thus CCF facilitates cloud application portability between providers by translating the standard OVF descriptor into native VM templates as understood by the various supported IaaS clouds. The CCF comes with its own virtual infrastructure network (VIN) [START_REF] Van Reeuwijk | Design of the Virtual Infrastructure Network[END_REF] module that allows cloud applications to be deployed across multiple providers in a split manner and still maintaining secure communication channels between different VMs in the application through IPSec tunnels. If the user's VM needs to be deployed over a public (non-Contrail) cloud, the VM is prepared with a VIN agent inside to enable safe networking with the rest of the VMs inside the Contrail federation.

The CCF authentication modules are incorporating several widely use protocol such as OAuth and Shibboleth [START_REF]Shibboleth[END_REF] and the attributes repository is being designed to be easily extensible in order to provide support for easy incorporation of 3rd party attribute repositories so as to ease migration of user accounts and attributes into CCF.

Figure 1 shows the classification of CCF software suites released as public release 1.0 into four major categories namely federation, provider-common, provider-ONE-head and provider-ONE-node category. The security components will be fully integrated with the rest of the modules in subsequent releases.

A. Virtual Execution Platform

Virtual Execution Platform software is installed at the cloud service provider end and it enables the participation of the cloud in the CCF. It does proper VM contextualization and OVF application lifecycle management. Additionally it provides application metrics periodically to the federation modules to help with SLA monitoring and enforcement. VEP component is being developed so as to enable non-contrail cloud application developers use VEP in their software roadmap. In order to be interoperable, a REST interface based on the upcoming DMTF's CIMI [START_REF] Davis | Cloud Infrastructure Management Interface (CIMI) Model and REST Interface over HTTP[END_REF] standard is being designed and developed additionally to the native REST interface VEP already exposes for integration with rest of the CCF modules. Figure 3 shows the OVF centric VEP application deployment task-flow. Contrail and VEP supports only standard OVF descriptions without any extensions. When an application VEP implements a two-tier access control on incoming REST requests, one using internal access-control rules, and an optional entry authorization check using an external authorization module which can be the one provided by Contrail or any compatible one providing the same kind of service. In the subsequent VEP releases, a certificate delegation module will be incorporated that will allow for a better VM security by including time-limited role-specific deletegated X.509 certificates to be passed in the VMs during contextualization phase.

In the above couple of paragraphs we have highlighted key modules and features of the CCF that helps improve interoperability and portability. Description of all the modules is beyond the scope of this paper. An interested reader is encouraged to read the published deliverables and technical reports [START_REF] Kruk | Requirements on Federation Management, Identity and Policy Management in Federations[END_REF] [25] [START_REF] Morin | Requirements and Specification of Computational Rresource Management Functionalities for Virtual Cluster Platforms[END_REF] [27] [START_REF] Mori | Security Requirements, Specification and Architecture for Virtual Infrastructures[END_REF] [29] from respective consortium partners.

Contrail project is embracing open standards namely DMTF's OVF specification and DMTF's upcoming CIMI specification for enabling independently developed cloud services to interact with the federation services. An end user will have the capability of her checkpointed application to be exported as an OVF thereby allowing her to migrate her application to any provider that supports OVF.

The provision of supporting multiple authentication standards including OAuth standard, OpenID and Shibboleth and further using an attribute server that can be updated with 3rd party attributes will allow for an easy integration / migration of other cloud services with Contrail.

Contrail project will include OVF translation modules for several cloud technologies, including OpenNebula, OpenStatck and public clouds. This will enable deployment of OVF applications over Contrail supported cloud technologies even if the such providers themselves may not support OVF standard. At the moment Contrail only supports OpenNebula 2.2.1 and OpenNebula 3.4.1 clouds.

VI. INTEROPERABILITY: MISSING PIECES

While using platform independent application description formats such as OVF, and a standard cloud management API such as OCCI and application management API such as CIMI have contributed to improvements in the interoperability scene, there is a lot more to be done before we achieve seamless interoperability and portability of cloud resources and end user applications.

A. Credentials Standardization

Security is a big concern in cloud computing. Various approaches are being undertaken to limit the exposure of virtual application to threats. Securing network communication using virtual LANs (vLAN), SSH tunnels, X.509 certificate based user access, etc. are a few measures being adopted towards this goal. Still there is a lack of procedural standards in this field.

User attributes at one provider can not be easily transferred to another provider because of lack of standards for attributes based access control.

B. Network Standardization

Each cloud suite uses their internal network element representation making it difficult to port an application descriptor tailored for one cloud to another completely different cloud. It is agreed that each application has specific networking needs, but for a case where a simple inter-VM communication is desired, there should a standard way of describing such a requirement that would work across all cloud providers. Standardization of common use cases for virtual networks would help a lot in achieving true interoperability among cloud and portability to the end user applications.

VII. CONCLUSION

In this paper we have tried to identify some of the challenges facing cloud computing. We have surveyed the ongoing standardization efforts for management of cloud services and infrastructure. We have presented a brief description about the European software project Contrail, and how it aims to improve portability of cloud applications and achieve interoperability with other cloud services and management tools. We have also provided a few challenges that should be addressed if any practical interoperability of services and portability of end users' cloud applications are to be achieved.

ACKNOWLEDGMENT

Contrail is a European Commission funded project under FP7 program and is funded by grant 257438. The authors would like to acknowledge the work done by all Contrail Consortium members and teams.

Fig. 1 .

 1 Fig. 1. Module Level View of the Contrail Software Architecture (source: Contrail Release 1.0 Administrator Guide)

Fig. 3 .

 3 Fig. 3. OVF Centric VEP Deployment Taskflow


Mehdi Ahmed-Nacer

Stéphane Martin

Pascal Urso

File system on CRDT *

Keywords: Distributed System, CRDT, Optimistic Replication, Data Consistency, File system

In this report we show how to manage a distributed hierarchical structure representing a file system. This structure is optimistically replicated, each user work on his local replica, and updates are sent to other replica. The different replicas eventually observe same view of file systems. At this stage, conflicts between updates are very common. We claim that conflict resolution should rely as little as possible on users. In this report we propose a simple and modular solution to resolve these problems and maintain data consistency.

Les systéme de fichier comme graphe en CRDT2 Résumé : Dans ce rapport nous allons montrer comment gérer une structure hiérarchique structuré représentant un système de fichier. Cette structure est basé sur la réplication optimiste, chaque utilisateur travaille sur une copie local et les mises à jour sont envoyées aux autres réplica. Les différentes répliques observent éventuellement la même vu du système de fichier. Á ce stade, des conflits entre les mises à jour peuvent avoir lieu. Nous demandons l'intervention des utilisateurs pour résoudre les conflits aussi peu que possible. Dans ce rapport, nous proposons une solution simple et modulaire pour résoudre ces problèmes en maintenant la cohérence des données.

Mots-clés : Système distribué, Système de fichier, CRDT, Réplication optimiste

Introduction

Distributed file systems allows different users to work collaboratively on largesize projects, such as the collaborative development on the Linux kernel. When a file system is distributed, many technical and usage issues should be considered and addressed. As such issues, we can cite all the issues relative to local file system plus other due to distribution: network communication, privacy insurance, distributed access control, fault tolerance, replica distribution, user coordination, etc. In this report, we only consider the problem managing concurrent updates on the file system.

Indeed, when multiple people share and modify the same file system concurrently, the updates can interfere with each other in such a way that the file becomes useless and contains conflicts. Some traditional distributed file systems recommend file locks to ensure that the file is protected. Unfortunately, this method cannot ensure high responsiveness for real-time collaboration or disconnected work, because the initiator of an update should acquire an exclusive access. On the other hand, optimistic replication [START_REF] Saito | Optimistic replication[END_REF] allows availability, performance and supports work in disconnected mode. In an optimistically replicated file system, data is replicated on each replica, and any replica can independently modify its own state. However, optimistic mechanisms gain this availability by trading off linear consistency.

Anyway, all modifications are sent to other replicas and some consistency must be ensured. Strong eventual consistency (SEC) ensures that as soon as replicas have received the same updates, the replicas host the same data value [START_REF] Shapiro | Conflict-free replicated data types[END_REF]. Depending of approach used, these modifications can be sent as a set of update operations (aka operation-based), or sent as a whole new state (aka state-based). Most of version control systems (VCS) such as Subversion [START_REF] Collins-Sussman | Version Control with Subversion[END_REF] or Git [15] adopt state-based approaches, while distributed file systems described in the literature [START_REF] Kistler | Disconnected operation in the coda file system[END_REF][START_REF] Guy | The ficus replicated file system[END_REF] are mostly operation-based.

In eventual consistency, since any replica can be updated, two modifications applied independently may lead to conflicts. For instance, the addition of a file in a directory conflicts with the removing of this directory. To maintain a correct hierarchical data type, a system with optimistic replication must either avoid such conflicts or recover automatically from them. Conflict-free Replicated Data Types (CRDT) [START_REF] Shapiro | Conflict-free replicated data types[END_REF] can be a solution.

This report is structured as fellows. Firstly, we give a state of art to talk about an existing file systems. The next section presents an overview of the Conflict-free Replicated Data Types (CRDT). After that, we begin a definition of CRDTs generally and describe more precisely the different solutions to build CRDT based on set structure. The next section 4 shows a new data structure based on layers that ensure consistency. Section 2 discusses about file system and a conflicts that can arise in an optimistic replication system, we describe briefly how conflicts are detected and cover. The next section 4.2 describes the solution using CRDTs to manage conflicts. Finally, we close with a conclusion.

File System

In this section we present the data type corresponding to a hierarchical file system. We define the structure of this data type and the update operations that can be applied on it. Finally we describe the possible conflicts that can arise in with such a replicated data structure.

We consider the data structure of file system as a tree containing elements with a typed content. A content type can be a directory -that contains other element elements -or file types. We consider that file types are automatically detected by the replicated system. For instance, version control systems consider text and binary file types. For shake of simplicity, and as many of heavily used replicated file systems [START_REF] Ghemawat | The google file system[END_REF][START_REF] Kistler | Disconnected operation in the coda file system[END_REF], an element in only present once in the tree. I.e., we do not manage soft or hard links. Definition 1. A file system element is couple (n, c) where n is the name of the element and c is its content. There exists a function type(c) that returns the type of the element according to its content. The content of a directory is a collection of elements where each name is unique. A file system is a root directory with an empty name.

We consider the basic operations add, remove of files and directories, and update of files. Operations are defined according absolute paths. Definition 2. A path is a list of element names n.n .n . • • • . The predicate exists(p, S) for a path p and a file system S is defined recursively as follow:

exists(∅, c) = true type(c) = directory ∧ ∃(n , c ) ∈ c =⇒ exists(n .p, (n, c)) = exists(p, c ) else =⇒ exists(n .p, (n, c)) = f alse
The function content(p, S) returns the content of the element at path p in S. The predicate pref ix(p , p) is true if and only if the list p is a non-strict prefix of the list p.

The operation add(p, n, t) adds an element with name n and an empty content of type t under the path p. The operation remove(p) (or rmv(p)) deletes the last object (file or directory) of path p. 2 Whereas update(p, u) apply modification u on the file located at path p. 3 We consider that each file content is managed by a conflict-free replicated data type (CRDT) [START_REF] Shapiro | Conflict-free replicated data types[END_REF] corresponding to the type of file. For instance text files can be managed using sequence CRDT algorithms such as WOOT [START_REF] Oster | Data Consistency for P2P Collaborative Editing[END_REF], Treedoc [START_REF] Preguiça | A commutative replicated data type for cooperative editing[END_REF], Logoot [START_REF] Weiss | Logoot: A scalable optimistic replication algorithm for collaborative editing on p2p networks[END_REF], or RGA [START_REF] Roh | Replicated abstract data types: Building blocks for collaborative applications[END_REF]. Binary files can be managed using a Thomas-write-rule [START_REF] Thomas | A majority consensus approach to concurrency control for multiple copy databases[END_REF]. Moreover, any kind of file type can be managed such as sets, graphs [START_REF] Shapiro | A comprehensive study of Convergent and Commutative Replicated Data Types[END_REF] -or more usefully -XML files [START_REF] Martin | Scalable xml collaborative editing with undo[END_REF].

The usage of all the above operations must follow some pre and post conditions. The pre and post conditions are local, i.e. they must be ensured when a local modification is done atomically on a replica. When applied remotely, if the precondition is not respected, a conflict occurs. The respect of the post condition depends on how the conflict is resolved.

• pre(add(p, n, t), S) ≡ exists(p, S) and type(content(p, S)) = directory and ¬exists(p.n, S)

• post(add(p, n, t), S) ≡ exists(p.n, S) and type(content(p.n, S)) = t and isEmpty(content(p.n, S))

• pre(remove(p), S) ≡ exists(p, S)

• post(remove(p), S) ≡ ¬exists(p, S)

• pre(update(p, u), S) ≡ exists(p, S) and u is applicable on type content(p, S)

• post(update(p, u), S) ≡ exists(p, S) and content(p, S) = content(p, S) • u

With such pre conditions, in case of a concurrent modifications, some conflicts occurs: conflict since file contents are CRDT. Thus, concurrent updates operation can be applied in any order while obtaining eventual consistency. The remainder of this section will discuss the conflicts occurrence in more detail. The next section describes how we manage these conflicts. Even a simple collaboration of two replica can result in a conflict. Figure 3 illustrates this situation. Directory T oto appears on two replicas. Replica 1 creates a file prog.c under directory T oto when replica 2 removes T oto. Then, when the replicas merge, the pre-condition of add(T oto, "prog.c", t) is no-longer true since the directory T oto is not present. This is an add(a)||remove(b) conflict. The last type of conflict is update(a)||remove(b). This conflict occurs when a replica updates a file content while another removes the file or a directory in the path to the file. In this case the precondition of the update operation (the path is present) is violated. Our goal is to design a conflict-free replicated data type (CRDT) for file system. So we need one or more replicated data structure where such conflicts either cannot occurs or a resolved in a automated manner. Of course, the obtained data structure must ensure strong eventual consistency.

• add(p,

Ficus

Ficus file system [START_REF] Guy | The ficus replicated file system[END_REF] is developped for peer-to-peer optimistic file replication systems. The conflict possible in Ficus are : -Update/update conflicts : It moves the file into a special directory called an orphanage. Each volume has its own orphanage directory located under its root directory -Name conflicts : It occurs when user insert two file with same name under same directory. Ficus appends unique suffixes to each file name. Remove/update conflicts : Ficus allows users to resolve conflict.

Ficus propose also a mechanism to resolve a conflicts automatically except for name conflicts.

Version Control Systems

Version Control Systems manage files that can be accessed and updated by multiple user. Today, there are several types of these systems used such as CVS, SVN, GIT ... ect. These systems allows multiple users to work concurrently on a file while ensuring that their work is safe and not will be lost. Most of these systems are state-based and merge can be only done manually by a user. When a user wants to merge concurrent modification, he obtains a "best effort merge" where some of the conflict (depending on the system) are resolved automatically, while other have to be resolved by the user before it commits the merge. The committed merge is a new state in the graph history of the repository, so no conflict occurs on the repository.

Types of conflicts presented to the user depend on the structure and data management by the system. For instance, Git [15], does not take into account the directories, it considers the file system as a hierarchical set of files, while CVS and SVN consider the directories.

On the other hand, a case of divergence can occur depending of data management. In Git [15], the directories are considered only locally. When user create locally an empty directory, git does not take it into account in the repository. When users make an update as in figure5, two replica may observe a divergence while there are both up-to-date. 3 Conflict-free Replicated Data Types (CRDT)

To achieve high responsiveness, data replication is necessary. When the replicated data is mutable, the consistency between the replicas must be ensured. The CAP theorem [START_REF] Shapiro | Conflict-free replicated data types[END_REF] states that a replicated system cannot ensure strong Consistency together with Availability and Partition tolerance. In many applications, such as collaborative application, where availability is required by users and partitions are unavoidable, a solution is to allow replicas to diverge temporarily and when system is idle, all users observe the same data.

This kind of consistency model is called "eventual consistency" which guarantees that if no new update is made to the object, eventually all accesses will return the same value. The "strong eventual consistency" (SEC) model guarantees that all accesses return the same value as soon as all update are delivered. To ensure SEC, a particular merge procedure is required that handles possibly conflicting concurrent modifications.

In what follows you exemplify the CRDT principle by describing some replicated set designs.

Set

For a CRDT set, we consider two operations: a process can add an element with operation add(a) and can delete it with operation remove(a) . In a sequential execution, the "traditional" definition of the pre-and post-conditions are Figure 6: Set with concurrent addition and remove [START_REF] Shapiro | A comprehensive study of Convergent and Commutative Replicated Data Types[END_REF] Thus, a set CRDT has different global post-conditions in order to take into account the concurrent updates while ensuring eventual consistency. Each CRDT has a payload which is an internal data structure not exposed to the client application, and lookup, a function on the payload that returns a set to the client application. For a set CRDT, the pre-conditions must be locally true on the lookup of the set.

In [START_REF] Shapiro | A comprehensive study of Convergent and Commutative Replicated Data Types[END_REF] different CRDT sets are described.

G-Set

In a Grow Only Set (G-Set), elements can only be added and not removed.

2P-Set In a Two Phases Set (2P-Set), an element may be added and removed, but never added again thereafter.

LWW-Set In a Last Writer Wins Set (LWW-Set), each element is associated to a timestamp and a visibility flag. When two concurrent operations occur, an operation with a higher timestamp is executed. 4 Layer structure

To be able to control and manage conflicts simply, the structure of the system is managed by layers. Conflict resolving is invisible to the user application. A layer is represented by a component with the following interfaces:

lookup the method allows to see the data state; this method represents what users observe.

update the method allows to perform modifications on the data.

replication the lower layer (and only it) performs communication between replica.

Only the lower layer ensure replication and eventual consistency. The other layers computes a view from the lookup result of their above layer. Each layer is responsible for a particular constraint : replication This first layer ensure communication between replica and eventual consistency. It ensure the constraint that a unique element identified by a path and a type is associated to a unique content. It encapsulates a set CRDT such as described previously, Section 3.1 and thus, resolves the conflict add(a)||remove(a). The encapsulated managed set contains elements, i.e. couples (path, type). Beside this set, the replication layer maps each file to its content, a CRDT, and resolves the remove(a)||update(b) conflict. The lookup method of the layer returns a map (path, type) → content. For directory, the content is empty, the children of a directory is determined using paths of other elements. However, a set of path is not a file system data structure since other constraints must be ensured.

hierarchical The second layer is in charge to produce a connected tree view from the set of elements provided by the replication layer. To produce this tree view, the lookup method of this layer has to resolve the conflict add(a)||remove(b) which creates orphan nodes. When the update is invoked, it transforms an element in the view into a path for updating the set. To obtain this path it must take into account how conflicts were resolved by the lookup method. To resolve the conflict several type of policies can be defined (see Section 4.2). In a tree view returned by this layer, a directory may contains several element with the same name (but different types and/or different original path).

naming The third layer ensure uniqueness of element names in directories.

The lookup method of this layer return the file system data structure. In Section 4.2, we present two mechanisms to obtain unique names, either by avoiding conflict, either by returning a view where original names are changed in case of conflict. The advantage of this layered management is twofold. First, eventual consistency is ensured by well-known existing CRDTs. Since the other layers lookup methods only compute a view, without affecting the inner replicated state, SEC is ensured. Secondly, such a layered management allows to combine different solutions for conflict management in order to obtain a replicated file system. Since each conflict resolution has its own behavior, and its own computational cost, we give to the distributed application developer the entire control on the replicated data structure.

Replication Layer

As described above, the replication layer ensure strong eventual consistency. The update interface of the layer accept three operation add(a), remove(a) and update(a, u) with a a couple (path, type) and u and update compatible with the file type of a. The lookup interface return a map (path, type) → content with empty content for directories.

The layer encapsulates a set CRDT that contains couples (path, type) to manage the add(a)||remove(a) conflict. Beside this set, the replication layer maps each element to its content, a CRDT. The layer keeps content of deleted files. If the content is not kept, the data would diverge when the element is readded, See Figure 11. Since the couple (path, type) is invariant during time, every update is applied on the content of the element, and eventual consistency of the file content is ensured. This strategy also resolves the remove(a)||update(b) conflict since both the file is removed and the content is updated.

Hierarchical Layer

This layer is in charge to produce a tree from the set of paths obtained with the replication layer. It is in charge to manage the add(a)||remove(b) conflict where b is an ancestor of a. To manage this conflicts we propose two kind of solution. The first kind ignores directory and consider only files, ans thus avoid such a conflict. The second kind resolve the conflict by treating with different possible policies the orphan elements that result from such a conflict.

In both kind of solutions the lookup interface of the layer returns a tree which labels are tuple (name, type, path, content): the name of the element with its type and its original path (the path appearing in the set). The update interface allows to apply the following operations: add(p, n, t), remove(p, t) and update(p, t, p , u) with p a path in the lookup tree, n a name, t a type, p the original path and u a content update.

Consider only leaf

The first kind of hierarchical layer, consider only the leaf of the file system. The type "directory" no longer appears in the inner replication layer. To avoid RR n°8027 the conflict add(a)||remove(b) we change a pre and post condition described previously (Section 2).

• pre(add(p, n, t), S) ≡ exists(p, S) and type(content(p, S)) = directory and ¬exists(p.n, S)

• post(add(p, n, t), S) ≡ exists(p.n, S) and type(content(p.n, S)) = t and isEmpty(content(p.n, S))

• pre(remove(p, t), S) ≡ exists(p, S).

• post(remove(p, t), S) ≡ ¬exists(p, S).

• pre(update(p, t, p , u), S) ≡ exists(p, S) and u is applicable on type content(p, S)

• post(update(p, t, p , u), S) ≡ exists(p, S) and content(p, S) = content(p, S) • u

This solution has an impact on the inner layer. Indeed, the inner layer "replication" contains a set of couple (p, t) with p is a path directed to files and t is a type such that type(content(p, S)) = directory. Also, the lookup method of the layer returns a map (path, type) → content = ∅. The "hierarchical" layer can computes a result tree by using two methods. First, is an incremental method. In this method, a layer stores the state of the data type that will be returned to the upper layer and it modifies this data type each time its inner layer state is modified. The case of non-incremental method, the lookup recomputes the tree each time its inner layer state is modified. In both methods, the tree view returned by this layer is not ready to represente a right file system since a directory may contains several element with the same name.

The update interface transforms the elements in the view into a path to invoke an update of the inner layer.

GIT [15] is based on tree where each file is defined by unique path started by root. The directories are created on the fly and they represent just a logical representation to the users. Unlike in our method proposed, in git we can observe a small divergence. Indeed, if user located in replica 1 creates an empty directory and commit, a file system as git does not take into account this empty directory, then, when user 2 makes an update, the two replica does not observe the same content.

Treat orphan nodes

Another kind of solution to manage the add(a)||remove(b) conflict is to treat the orphan elements produced by the conflict. An orphan element is a path in the replication set which its father (its longest strict prefix) is not in the set. To treat orphans, several policies are described in [START_REF] Martin | Abstract unordered and ordered trees crdt[END_REF].

The lookup interface obtained by these policies are the following.

skip This behaviour does not return orphan element; it gives priority to remove. reappear This behaviour returns an orphan element at its original path; it give priority to add. All required ancestors are recreated in the view. However, when recreated directories are empty they are removed. This solution has a behavior similar than "Consider only leaf " solution, except than it allows the tree to contains empty directories. root This behaviour places orphan elements under the root. This behavior can also be used to place the orphan elements under some special "lost-andfound" directory as in Ficus replicated file system (see Section 2.1).

Figure 15: root policy.

compact This behaviour places an orphan element under the longest connected prefix path. In figure 16 when the file system receives a remove directory2 and, concurrently, the addition of a file prog.class under directory2, this file is placed under the father of the deleted directory, i.e. user. Each of these policies has a non-incremental version, where the view is entirely re-computed form the set and an incremental version, where the view is only updated when a change is made on the inner set. The update interface adapt path in the tree into path for the set. Due to choices made by the policies, these paths can be different. For instance, in Figure 16, remove(/user/prog.class, binary) will be adapted into remove(/user/directory2/pog.class, binary). For details, see [START_REF] Martin | Abstract unordered and ordered trees crdt[END_REF].

Until now, this mechanism returns a hierarchical structure, but it does not represent yet the file system. If two replicas add the same name under the same directory, this structure may confuse. To avoid this problem and construct a valid file system, we add a layer called resolve name that treats this type of conflict add(a)||add (a). In what follows we present this layer and how it treats the conflicts. This layer also treat the case where several elements with same name and type (but different original paths) where placed in a directory by the "root" or "compact" policy.

Naming layer

The naming layer ensures that each directory contains only one instance one file with a given name. We consider that two files with the same type created twice concurrently at the same place is only one file and the content is merged. For elements with different types or origin, we propose two kind of solutions.

The first method avoid the conflict by altering preconditions of operation, i.e. it enforces some properties on elements names. The second method renames on-the-fly conflicting files, so it let users to resolve the conflict.

First method :

We associate to each file type a specially algorithm. When a conflict occur, a file system merge two files since they implements the same algorithm.

• pre(add(p, n, t), S) ≡ exists(p, S) and ¬exists(p.n, S) RR n°8027

• pre(remove(p, t), S) ≡ exists(p, S).

• pre(update(p, t, p , u), S) ≡ exists(p, S)

In addition, the directories must not have an extension and text type are not permitted as an extension for binary files. In figure17 a tree observed by user is : root/directory/movie.java and root/directory/movie.avi. When user makes modification in the file movie.java, an algorithm used is automatically Logoot. This method is not permitted for root and compact policies. Indeed, when a root or compact policies are applied, a file may located with another under same directory that was not in the same directory before. In this case, a merge is not permitted since we cannot merge two file with different origins. Second method : This solution is applied only when conflict occur. To distinguish between files, we add at the last of file name the name of the algorithm used or the origin path as an extensions. Finally we propose to users to choose one of the two files or merge them. In both case we keep only one file and we remove the extension added from the file name. So, users can observe a stange behavior of files since it changes name when conflict disappear (small glish).

In both methods, a lookup interface returns a tree to user application without conflicts and with unique name. This tree is computed with incremental or nonincremental versionss. In case of incremental version, the layer keep a state of the data structure and the conflict is detected directly when a method update is invoked. While, in case of non-incremental version, the layer recomputes all tree each time the users make modifications. The update interface adapt operations in the tree to detecte and resolve conflicts names.

Conclusion

In this report, we have proposed a solution to represent optimistically replicated file systems. Our solution ensure strong eventual consistency. We use a CRDT tree to bypass the different conflicts using a layer structure. Using a layered approach, each conflict is managed separately. Thus, we give the choice the developer to choose a specific policy to resolve a specific conflict automatically. Nonetheless, the final solution concerning unique names have some drawbacks, first, it changes a name of files in case of conflict which is not desirable to users, and second the conflict in some cases is resolved manually by users. However, this method gives more alternatives to developers compared to other methods.

Finally, our approach produce a best effort merge that may satisfy the application developer but not all the final user of the application. So such solution have to be coupled to an awareness mechanism [START_REF] Dourish | Awareness and coordination in shared workspaces[END_REF] that allows the user to be conscious of the choice made automatically by the system and to produce updates that correspond to another choice.

Figure 1 :

 1 Figure 1: Conflict add(a)||remove(b)

Figure 2

 2 Figure2illustrates a different kind of conflict where two users create a same document with same name. In figure2replica 1 creates a document f ile under directory T oto, with the same type. Replica 2 also creates f ile under directory T oto. During the integration of the remote update, the pre-condition of the second add operation (added path is not present in the file system) is violated. If the types of the concurrent add are the same, the system trivially ensures SEC. We term this add(a)||add(a) conflict name conflict.

Figure 2 :

 2 Figure 2: Conflict add(a)||add(a)

Figure 3 :

 3 Figure 3: Conflict add(a)||remove(a)

Figure 4 :

 4 Figure 4: Conflict update(a)||remove(b)

Figure 5 :

 5 Figure 5: Divergence on git[15]

•

  pre(add(a), S) ≡ a / ∈ S • post(add(a), S) ≡ a ∈ S RR n°8027 • pre(remove(a), S) ≡ a ∈ S • post(remove(a), S) ≡ a / ∈ S In case of concurrent updates, the preconditions of add(a)||remove(a) conflict.

Figure 7 :

 7 Figure 7: Last Writer Wins Set : LWW-Set [12]

Figure 8 :

 8 Figure 8: Counter Set : C-Set[START_REF] Shapiro | A comprehensive study of Convergent and Commutative Replicated Data Types[END_REF]

Figure 9 :

 9 Figure9: Observed-Remove Set : OR-Set[START_REF] Shapiro | A comprehensive study of Convergent and Commutative Replicated Data Types[END_REF]

Figure 10 :

 10 Figure 10: Layer structure

Figure 11 :

 11 Figure 11: Layer structure

Figure 12 :

 12 Figure 12: file system with binary file, text files and directories

Figure 13 :

 13 Figure 13: skip policy.

Figure 14 :

 14 Figure 14: reappear policy.

Figure 16 :

 16 Figure 16: compact policy.

Figure 17 :

 17 Figure 17: Different algorithm to each extension

Figure 18 :

 18 Figure 18: Two fies conflict after root/compact

Ce travail est aussi un délivrable de l'ANR ConcRDanT (ANR-10-BLAN-0208).

RR n°8027

We consider the more general case where any path, including non-empty directory can be removed.

As some existing distributed file systems or VCS, we may restrict the set of operation to only remove and update. However, for shake of clarity in conflict presentation, we kept the add operation.RR n°8027

rue du Jardin Botanique CS20101 54603 Villers-lès-Nancy Cedex Publisher Inria Domaine de Voluceau -Rocquencourt BP 105 -78153 Le Chesnay Cedex inria.fr ISSN 0249-6399

* This work is a delivrable of french national research programs ConcRDanT (ANR-10-BLAN-0208).


R Marder

R Chaim
email: rchaim@technion.ac.il

G Chevallier

C Estournes

Densification and polymorphic transition of multiphase Y 2 O 3 nanoparticles during spark plasma sintering

Keywords:

a b s t r a c t Multiphase (MP) monoclinic and cubic Y 2 O 3 nanoparticles, 40 nm in diameter, were densified by spark plasma sintering for 5-15 min and100 MPa at 1000 • C, 1100 • C, and 1500 • C. Densification started with pressure increase at room temperature. Densification stagnated during heating compared to the high shrinkage rate in cubic single-phase reference nanopowder. The limited densification of the MP nanopowder originated from the vermicular structure (skeleton) formed during the heating. Interface controlled monoclinic to cubic polymorphic transformation above 980 • C led to the formation of large spherical cubic grains within the vermicular matrix. This resulted in the loss of the nanocrystalline character and low final density.

Introduction

Rapid sintering and densification of ceramic powders to full density are nowadays a routine procedure, using the spark plasma sintering (SPS) method. As was noted in many hot-press studies including SPS, the main densification shrinkage of the powder aggregate takes place during the heating by particle sliding, to the close-packed arrangement [START_REF] Kang | Sintering, Densification, Grain Growth & Microstructure[END_REF][START_REF] Liu | [END_REF][3][4]. Further densification of the powder compact may be accomplished either by plastic deformation or by diffusional processes, at the particle necks. Nevertheless, diffusional processes are inevitable during the final stage sintering, when isolated pores form and can be eliminated via bulk or grain boundary diffusion [5,6]. Consequently, microstructure evolution during the SPS process, due to the change in the process parameters, such as temperature, pressure, time, atmosphere, vacuum level, etc. may affect the densification mechanism. Many types of phase transformations and transitions associated with crystal symmetry changes involve changes in the microstructure and morphology [START_REF] Porter | Phase Transformations in Metals and Alloys[END_REF]. Therefore, effects of the phase transformations during the densification by SPS may be of prime importance to the densification process, as well as to the final phase assemblage in the dense compact. The phase content and assemblage often have a considerable impact on the final properties of the sintered ceramic [START_REF] Li | [END_REF]. In this respect, Takeuchi et al. [9] investigated the densification of submicrometer size tetragonal BaTiO 3 powders and found SPS to be effective for preservation of the submicrometer size metastable cubic BaTiO 3 at room temperature. The preserved nanometric grain size by SPS was also found to be a cause for the cubic phase stabilization at lower temperatures [10,11].

Kumar et al. [12] took advantage of the higher atomic mobility near the Anatase to Rutile phase transformation temperature to enhance the densification of the TiO 2 nanoparticles. SPS of multiphase TiO 2 (70% Anatase and 30% Rutile) with 20-nm particle size at 62 MPa for 5 min and 600 • C resulted in complete phase transformation to Rutile [13]. For comparison, only annealing of the same precursor powder for 5 min at 600 • C preserved the multiphase character of the powder. This exhibits the effect of the applied pressure and possibly the electric field on the phase transformation during the SPS. Fundamental investigation of the current effect on solid-state reactivity during SPS was performed on stacked Mo-Si-Mo layers [14]. No change in the reaction mechanism was observed, albeit the enhanced growth rate of the reaction product layer (MoSi 2 ), which was related to the enhanced mobility or the change in the defect concentration.

The present paper focuses on the effect of the polymorphic phase transition on the microstructure and densification behavior of multiphase Y 2 O 3 nanoparticles during the SPS.

Experimental

Commercial pure (99%) multiphase (MP) Y 2 O 3 nanopowder (Neomat Co., Riga, Latvia) with average particle diameter of 40 nm doi:10.1016/j.msea.2011.06.044 was used. A second highly pure (99.99%) nc-Y 2 O 3 powder (Cathay Advanced Materials, China) with 100% cubic phase, designated as single phase (SP), was also used as a reference specimen [15]. Constant amount of the powder sample was poured into the graphite die using graphite foils (Grafoil) to separate between the powder, the die walls and the plunger surfaces. The powders were sintered (Dr. Sinter, SPS 2080) at different conditions for 5-15 min and 100 MPa at 1000 • C, 1100 • C, and 1500 • C. The starting temperature was room temperature for the 1000 • C treatment (designated 'cold compaction'), but 600 • C for the 1100 • C and 1500 • C treatments (designated 'hot compaction'). The uniaxial pressure was applied either a few second after the process started or when the SPS temperature was reached. In both cases, the pressure was increased linearly with time, and held constant during the isothermal treatment at the SPS temperature. The process duration refers to the isothermal SPS treatment. A heating rate of 100 • C/min and vacuum level of 3 Pa has been used; the pulse duration was 3.3 ms. The SPS parameters were recorded during the process. The temperature was controlled by a thermocouple for 'cold compaction', while an optical pyrometer was used above 600 • C for 'hot compaction' and at higher temperatures. The final specimen dimensions were 8 mm in diameter and 1.7-2.5 mm thick. The ram displacements were expressed in terms of the linear shrinkage and the temporary relative density, following the specimen thickness versus time, taking into account the thermal expansion/shrinkage behavior of the specimen and the graphite plungers [15].

The phase content of the as-received nano-powders and the sintered specimens were characterized by X-ray diffraction using a diffractometer (Philips PW 3710) with monochromatic Cu K ␣ radiation (XRD), operated at 40 kV and 30 mA. A scanning speed of 0.5 • /min has been used. The microstructures were characterized using transmission (TEM, FEI Tecnai G2 T20, operated at 200 kV) and scanning (FEI E-SEM Quanta 200, operated at 20 kV) electron microscopes. The specimens for the electron microscopy observations were prepared by the conventional methods. The thermal stability of the nanopowders was characterized using differential scanning calorimetry (Labsys 1600, Setaram) up to 1400 • C in Argon atmosphere, at a heating rate of 5 • C/min. The final density of the specimens was determined by the Archimedes method following ASTM standard C 20-92 (±0.5% accuracy).

Results

X-ray diffraction spectra from the as-received nanopowders are shown in Fig. 1. The single phase (SP) Y 2 O 3 nanopowder with cubic symmetry (JCPDS 41-1105) was characterized in detail elsewhere [16] (Fig. 1a), whereas the multiphase (MP) nanopowder revealed polymorphs with cubic and monoclinic (JCPDS 39-1063) symmetries (Fig. 1b). Quantitative analysis of the spectrum in Fig. 1b, assuming a powder mixture [START_REF] Suryanarayana | X-ray Diffraction, A Practical Approach[END_REF], resulted in 30% cubic and 70% monoclinic phase in the nanopowder. These results were in agreement with the 25:75 cubic to monoclinic phase ratio determined by others [START_REF] Halevy | [END_REF].

TEM observation of the two powders (not shown here) exhibited spherical morphology for the multiphase powder, compared to the equiaxed polyhedral shape for the cubic, single phase powder [16]. Both powders exhibited log-normal grain size distributions, with average grain size of 18 ± 8 nm and 41 ± 22 nm for the single phase and the multiphase powders, respectively.

XRD spectra from the MP nanopowder compacts, subjected to SPS for 5 min at 100 MPa and at different temperatures (Fig. 2a), showed the transformation of the metastable monoclinic polymorph to the stable cubic phase to occur at 1100 • C. However, further XRD characterization of the MP nanopowders sintered for different durations at 1000 • C and 100 MPa (Fig. 2b) revealed the continuous nature of the phase transformation kinetics already at this temperature. The monoclinic to cubic polymorphic phase transformation was not completed, even after 15 min SPS duration.

Following the above phase transformation in the sintered specimens, the thermal stability of both nanopowders were characterized by DSC (Fig. 3). At the stage where the finer, cubic SP nanopowder was relatively stable, the corresponding curve from the MP nanopowder exhibited a strong exothermic peak starting at ∼980 • C, with the maximum around 1200 • C. This is in agreement with the expected monoclinic to cubic phase transformation reported at ∼950 • C [19], and in agreement with the XRD results. Therefore, special attention was paid to this phase transformation during the densification by SPS.

Following the densification behavior of the two nano-powders, several important features were observed. First, a very rapid compaction of the MP powder was directly associated with the pressure when applied at room temperature (Fig. 4a); this room temperature compaction with the pressure increase persisted for all SPS temperatures investigated. However, further densification at elevated temperatures depended on the final SPS temperature. In the 1000 • C 'cold compaction' treatment (Fig. 4a), the density increased simultaneously with the pressure increase from room temperature (i.e. SPS starting time), and leveled at 67% within 2 min,when the pressure reached its maximum value (100 MPa). Since the temperature was increased only after 5 min from the SPS start (Fig. 4a), the observed densification at room temperature can be related to particle sliding with negligible contribution from the diffusional processes. However, negative ram displacement was recorded at ∼600 • C during heating at a constant pressure. This displacement could be associated with a certain decrease in density, but as it is ceased when the SPS temperature of 1000 • C was reached, it can be related to the thermal expansion mismatches between that of the graphite plungers and the close packed nano-particle network. Apparently, the close packed nano-particles undergo surface diffusion during the heating to form a rigid skeleton. In such a case, the rigid skeleton may oppose further shrinkage under the constant pressure; if the thermal expansion of this skeleton is higher than that of the graphite plunger, negative ram displacement may occur. (Negative displacement due to thermal expansion of the graphite mold, plungers and spacers is usually observed with the increasing temperature using blank specimens.) This aspect will be discussed later in detail. The density did not change significantly during the SPS isotherm. In addition, increase in the SPS duration to 10 and 15 min resulted in higher densities of 74.6 and 76.0%, respectively.

Densification of the SP reference Y 2 O 3 nanopowder was recently investigated in detail under similar SPS conditions [20]. Some of the results will be used here for comparison. The density of the SP reference specimen at 1000 • C treatment increased with the pressure increase at room temperature (Fig. 4b), although it leveled off at a much lower density of 42%. However, in contrast to the MP nano-powder, further increase in the density was observed during the heating process. Densification was accelerated around ∼680 • C and reached its maximum value of 93% around ∼880 • C, before the final SPS temperature of 1000 • C was reached.

The heating rate to the SPS temperature of 1100 • C was of 'hot compaction' and differed from that at 1000 • C. In this respect, a heating pulse was used to reach 600 • C within 3 min under the holding pressure of 2 MPa (Fig. 5a). This was followed by heating to 1100 • C for additional 5 min. Then the pressure was linearly increased to 100 MPa, resulting in simultaneous increase in the density to its final value of 66%; no further densification was observed at the SPS isotherm. Similar densities (i.e. 63.4 and 62.8%) were reached with further increase of the SPS duration to 10 and 15 min, respectively. Comparison between the densities measured at two SPS regimes, i.e. at 1000 • C and 1100 • C, revealed that the application of pressure at the beginning ('cold compaction') resulted in higher densities.

The corresponding SP specimen exhibited significant increase in the density during the heating process between 800 • C and ∼1050 • C, under the 2 MPa holding pressure only (Fig. 5b) [20]. The maximum displacement/(shrinkage) rate was 10 -2 mm s -1 . This indicated the high capillary forces in the SP to drive densification, in contrast to the MP powder, where no densification was recorded during the heating up. A higher densification rate (1.5 × 10 -2 mm s -1 ) was measured when the pressure was increased to its maximum value. A final density of 93%, which is higher than that of the MP specimen, was reached.

The densification behavior in the MP specimen at 1500 • C is shown in Fig. 6, as in the other experiments, a very fast densification rate (1.5 × 10 -2 mm s -1 ) was recorded simultaneously with the pressure increase. However, in this 'hot compaction' experiment (i.e., a heating pulse to 600 • C was applied before the pressure was increased), densification ceased when the maximum pressure was reached. Density was stagnated during further heating up to 1350 • C, where an additional rapid densification rate (5 × 10 -3 mm s -1 ) up to the final density was recorded. During the period of density stagnation (i.e., between 200 and 650 s in Fig. 6), the pressure experienced two disturbances expressed by a decrease of 8-10 MPa in the recorded pressure. These decreases in pressure occurred around 1030 • C and 1280 • C, and were recovered at 1130 • C and 1350 • C, respectively. The second pressure recovery (increase) was responsible for the repeated increase in densification at 1350 • C, as was mentioned above. These pressure disturbances are associated with increase in the resistance of the nano-particles to undergo sliding, whether due to the formation of a rigid skeleton or jamming of the agglomerated nano-particles. In either case, thermal expansions of both the graphite plungers and the specimen together with the lack of plasticity in the specimen, introduce internal compressive stresses. Since the external pressure applied in the system is regulated to remain constant, its actual value should decrease in order to balance the internal SEM images from the specimens sintered at 1100 • C for different durations (i.e. 5 min, Fig. 7) showed homogeneous distribution of many spherical shape grains throughout the matrix of the MP Y 2 O 3 nanoparticles. The largest diameter of the spherical grains was ∼15 m after 5 min, and ∼60 m after 10 min durations, with very wide grain size distributions. These spherical grains exhibited a low volume fraction of the specimens even after 15 min of sintering at 1100 • C. These spherical grains were absent after sintering at 1500 • C; a regular polyhedral shape grain microstructure was observed.

TEM images from the specimens sintered at different temperatures clearly revealed the microstructure evolution during the SPS. First, at 1000 • C and 1100 • C, close to the phase transformation temperature, many polycrystalline spherical particles of submicrometer and micrometer-size in diameter were observed within the porous nanoparticle matrix (Fig. 8a). Higher magnification proved the internal structure of the large particles (Fig. 8b andc) to be composed of sub-grains separated by dislocation networks; in some occasions, internal submicrometer-size pores were also observed. The matrix was comprised of partially sintered nanoparticles which formed a porous network resembling the vermicular structure (the upper part in Fig. 8b). Detailed examination of the interface between the spherical particles and the vermicular structure revealed that the former grow on the account of the porous nanoparticle skeleton (Fig. 8c). Selected area diffraction patterns confirmed the cubic crystal symmetry of the spherical particles (Fig. 8d). Therefore, it seems that the spherical particles present nucleation and interface-controlled growth of the cubic grains on the account of the monoclinic nanoparticles.

Finally, TEM images from the 1500 • C treated specimen, shown in Fig. 9, exhibit the micrometer size polyhedral shape grains with nanometric closed pores. Many grains were comprised of sub-grains separated by dislocation networks (Fig. 9b). A few nanometer size grains and closed pores were still visible along the sub-grain boundaries and at their corners (arrowed in Fig. 9b). This microstructure can be considered as an almost fully transformed version of the vermicular structure to the cubic grains. The microstructure evolution in the reference single-phase cubic nanoparticle compacts during the SPS were described in detail elsewhere [15,16,20]. At SPS temperatures below 1100 • C, the nanometric character of the dense compacts was preserved. However, significant grain growth to micrometer-size grains was observed at higher temperatures [16]. The microstructural evolution associated with the polymorphic phase transformation is the basis for the observed densification behavior of the multiphase nanoparticles and will be discussed below.

Discussion

The observed densification behavior of the two nanopowders can be explained by the metastable nature of the monoclinic polymorph. The monoclinic phase is a high pressure version of Y 2 O 3 , but can be retained in a metastable state at the atmospheric conditions when in the nanoparticle form. These aspects of polymorphism, especially in the Y 2 O 3 nano-particles, were discussed in detail elsewhere [19,21,22]. Although both powders exhibited a close to nanocrystalline particle size (18-nm vs. 41-nm), the surface enthalpy of the monoclinic polymorph is significantly higher (2.78 J m -2 ) than that of the cubic phase (1.66 J m -2 ) [19]. Therefore, the highly active surfaces of the monoclinic nano-particles act as an efficient driving force for low-temperature sintering and neck formation. This type of high sinterability is well characterized in transition alumina (␥-alumina) and lead to rapid formation of a rigid porous skeleton by surface diffusion at low temperatures [23]; the resultant vermicular structure leads to low-density sintered compacts. In this respect, consolidation of alumina nanoparticles by SPS showed enhanced densification of the ␣-alumina compared to that of transition ␥-alumina [24]. Surprisingly, dense ␣-alumina was obtained at a considerably lower SPS temperature, albeit originally with a larger particle size. This behavior was related to ␥ → ␣ phase transformation during the SPS, which in turn led to the formation of the vermicular structure.

The theoretical densities of the cubic (c) and monoclinic (m) Y 2 O 3 polymorphs are 5.030 g cm -3 and 5.468 g cm -3 , respectively [19]. Consequently, the polymorphic m → c phase transformation is associated with ∼8% volume increase. Nevertheless, the DSC results indicated the polymorphic transformation temperature to be around 1000 • C, where a rigid skeleton of m Y 2 O 3 has been developed fairly well. On one hand, the kinetics of this interface-controlled polymorphic phase transformation is more sluggish compared to the SPS heating time scale, as evidenced by XRD analysis. On the other hand, the presence of the nanopores within the spherical particles is an evidence for a very rapid interface-controlled process (i.e. nano-pores were not annealed by diffusion). Consequently the change in the compact volume during the heating, due to the phase transformation, may be marginal. Similar effects were reported during densification of Si 3 N 4 with metallic sintering additive by SPS [25], where significant shrinkage occurred by particle rearrangement and while a liquid phase was formed. However, minor shrinkage was observed when phase transformation and grain growth via solution-reprecipitation took place.

Based on the microstructure developed in the multiphase nanoparticle compacts, the following processes may be considered. First, the application of external pressure at room temperature enables particle sliding and rearrangement. The early and rapid densification stage ceases when reaching the maximal pressure applied. Second, highly reactive surfaces of the m nanoparticles enable enhanced neck formation and growth by surface diffusion during the heating. The partially sintered m nanoparticles form a rigid and porous skeleton with a vermicular structure which opposes further densification by particle sliding. At and above the polymorphic m → c phase transformation temperature, nucleation of the stable c phase takes place, homogeneously throughout the porous skeleton (the homogeneous/heterogeneous nature of the nucleation event was not investigated here). Further growth of the cubic nuclei by this interfaced-controlled transformation results in spherical polycrystalline particles. Apparently, the 8% volume increase accompanied to the transformation, is not sufficient to overcome the volume constraints imposed on the growing spherical particles within the rigid porous matrix. Consequently, the elastic constraints may be reduced by the formation of dislocation networks and sub-grains, which, in turn, grow on the account of the m + c nanoparticles, at their growing front. When the rapidly growing front of the spherical particle faces a large cavity of the vermicular structure, it may surpass it, due to insufficient time for diffusion, resulting in occluded nano-pores. At higher temperature, when the phase transformation is accomplished, particle sliding, dislocation creep, and grain growth may be responsible for the later stage densification close to full density.

Finally, the effect of the volume change during the polymorphic phase transformation to densification of the multiphase Y 2 O 3 nanoparticles was negligible. Nevertheless, the metastable nature and the high surface activity of this polymorph were the major cause for the formation of the vermicular structure, which in turn, inhibited the densification during the heating by SPS. The interfacecontrolled character of the transformation led to the formation of very large cubic grains, responsible for the loss of nanometric character of the compact subjected to densification.

Summary

Spark plasma sintering of the multiphase monoclinic and cubic Y 2 O 3 nanoparticles at 1000 • C exhibited limited densification compared to the rapid densification of the cubic single-phase counterpart. XRD of the multiphase sintered compacts revealed that the polymorphic monoclinic to cubic phase transformation occurred during the SPS around 1000 • C, and was completed by reaching 1100 • C. The metastable monoclinic phase led to rapid neck formation during the heating which resulted in a vermicular nanometric matrix with open porosity network; this limited further densification of the multiphase nanopowder and ended in very low final densities. At SPS temperatures above the polymorphic transformation temperature, homogeneous nucleation of the spherical cubic Y 2 O 3 grains was observed within the vermicular matrix. This interface controlled monoclinic to cubic phase transformation resulted in the loss of the nanocrystalline character of the compact. SPS of the multiphase nanoparticles at 1500 • C showed similar densification behavior as the pure cubic Y 2 O 3 , resulting in a dense microstructure and coarse micrometer-size polyhedral shaped grains.

Fig. 1 .

 1 Fig. 1. X-ray diffraction spectra from the Y2O3 nanoparticles. (a) Single phase (SP) cubic. (b) Multiphase (MP) cubic + monoclinic.

Fig. 2 .

 2 Fig. 2. XRD spectra of the as-received MP Y2O3 nanoparticles, after sintering (a) for 5 min at 1000 • C, 1100 • C, and 1500 • C. (b) At 1000 • C for 5, 10, and 15 min.

Fig. 3 .

 3 Fig. 3. Differential scanning calorimetry from nanocrystalline Y2O3. (a) Single phase (SP) cubic. (b) Multiphase (MP) cubic + monoclinic.

Fig. 4 .

 4 Fig. 4. Relative density-time-temperature-pressure dependencies during SPS of (a) MP and (b) SP Y2O3 nanoparticles at 1000 • C for 5 min and 100 MPa.

Fig. 5 .

 5 Fig. 5. Relative density-time-temperature-pressure dependencies during SPS of (a) MP and (b) SP Y2O3 nanoparticles at 1100 • C for 5 min and 100 MPa.

Fig. 6 .

 6 Fig. 6. Relative density-time-temperature-pressure dependencies during SPS of MP cubic Y2O3 nanoparticles at 1500 • C for 5 min and 100 MPa.

Fig. 7 .

 7 Fig. 7. SEM image showing the homogeneous distribution of the spherical grains throughout the specimen sintered at 1100 • C for 5 min and 100 MPa using multiphase Y2O3 nanoparticles.

Fig. 8 .

 8 Fig. 8. TEM images showing the (a) nucleation and growth of the spherical cubic Y2O3 grains on account of the multiphase nanocrystalline matrix at 1000 • C. (b) Higher magnification of (a) showing the vermicular structure of the matrix nanoparticles. (c) The interface-controlled growth of the spherical cubic grains at 1100 • C. (d) Selected area diffraction pattern confirmed the cubic symmetry of the spherical Y2O3 grains.

Fig. 9 .

 9 Fig. 9. TEM images showing the (a) micrometer-size cubic grains formed at 1500 • C. A few pores are visible along the grain boundaries. (b) Many sub-grain boundaries decorated with dislocation networks and nano-grains were present (arrowed).

Acknowledgments

The financial support of the Israel Ministry of Science under contract # 3-3429 is gratefully acknowledged. We thank Dr. Ori Yeheskel from NRC-Negev for supplying the MP nanopowder.