Internet DRAFT - draft-ciavaglia-anima-knowledge
draft-ciavaglia-anima-knowledge
ANIMA L. Ciavaglia
Internet-Draft P. Peloso
Intended status: Informational Nokia
Expires: September 22, 2016 March 21, 2016
Knowledge Exchange in Autonomic Networks
draft-ciavaglia-anima-knowledge-00.txt
Abstract
This document describes a solution to manage the exchange and
processing of information and knowledge between autonomic functions.
The objective is to provide a unified interface to enable an
interoperable management of information flows among autonomic
functions by insuring the use common mechanisms. The protocol
negotiate and automatically adapt to the communication and
information capabilities, requirements and constraints of the
participating entities.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 22, 2016.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
Ciavaglia & Peloso Expires September 22, 2016 [Page 1]
Internet-Draft Knowledge in Autonomics March 2016
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
This document may not be modified, and derivative works of it may not
be created, except to format it for publication as an RFC or to
translate it into languages other than English.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Knowledge Exchange Interface . . . . . . . . . . . . . . . . 3
2.1. Information Collection and Dissemination - ICD . . . . . 4
2.2. Information Storage and Indexing - ISI . . . . . . . . . 5
2.3. Information Processing and Knowledge Production - IPKP . 5
2.4. Information Flow Establishment and Optimization - IFEO . 7
3. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Normative References . . . . . . . . . . . . . . . . . . 13
6.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
The ANIMA autonomic management framework addresses the growing
management complexity of the highly decentralized and dynamic
environment of service provider networks. The ANIMA autonomic
management framework will help to produce the unification,
governance, and "plug and play" for autonomic networking solutions
within existing and future management ecosystems. Three main
functional blocks namely the Governance, Coordination and Knowledge
functionalities are essential to ensure a proper management and
interworking of Autonomic Service Agents (ASAs). This document
describes a solution to manage the exchange and processing of
information and knowledge between autonomic functions. The objective
is to provide a unified interface to enable an interoperable
management of information flows among autonomic functions by insuring
the use common mechanisms. The protocol negotiate and automatically
adapt to the communication and information capabilities, requirements
and constraints of the participating entities. The Knowledge
functionality plays the role of information / knowledge collection,
aggregation, storage/registry, knowledge production and distribution
across all the ANIMA functional components (i.e. ANI and ASAs).
Ciavaglia & Peloso Expires September 22, 2016 [Page 2]
Internet-Draft Knowledge in Autonomics March 2016
The Knowledge block is composed of the following functions:
o Information Collection and Dissemination - ICD
o Information Storage and Indexing - ISI
o Information Processing and Knowledge Production - IPKP
o Information Flow Establishment and Optimization - IFEO
The Knowledge Block offers basic information/knowledge manipulation
functionalities to the ANIMA entities through the Knowledge Exchange
Interface. A second interface, the Knowledge Management Interface,
handles information flow management that includes configuration
actions towards the optimal handling of the information/knowledge in
the management system.
2. Knowledge Exchange Interface
An Autonomic Service Agent needs two different types of interfaces to
deal with the exchange of knowledge.
Knowledge Exchange Interface: Interfaces through which the
information are actually exchanged.
Knowledge Management Interface: Interfaces through which the
information flows are negotiated, and information capacities are
being discovered/advertised. This interface provides
configuration actions towards the optimal handling of the
information/knowledge in the ASA.
The most important concept is the knowledge exchange flow, which is
being set between two knowledge exchange interfaces. It is
determined by the two endpoints of the flow and by the type of
information that is being conveyed over the flow. Some additional
parameters define the way the information are being exchanged (Push
or Pull mode plus additional parameters to determine the frequency
and conditions of the actual information exchange).
The features of the knowledge exchange flow are being negotiated by
Knowledge Management Interfaces and possibly a third party in charge
of optimizing the information flows over the whole system. The
objective of this negotiation is to determine the characteristics of
the exchange flow, which will then be enforced between two/multiple
knowledge exchange interfaces.
Ciavaglia & Peloso Expires September 22, 2016 [Page 3]
Internet-Draft Knowledge in Autonomics March 2016
2.1. Information Collection and Dissemination - ICD
The Information Collection and Dissemination (ICD) function is
responsible for information collection, sharing, retrieval and
dissemination. The ASAs can act as sources or sinks of information.
The sources subscribe to the Information Catalog by exposing the type
of information they can produce. On the one hand, each information
source should subscribe information availability and the equivalent
collection constraints (e.g., the supported granularity of
collection). On the other hand, each information sink should
subscribe information retrieval requirements with a similar process.
The subscription process takes place during the ASA bootstrapping.
The matching of constraints with requirements takes place during an
equivalent negotiation process.
Information can be directly retrieved from or shared with a dedicated
Knowledge Sharing system (a sort of ASA which roles is limited to be
used as a store and sharing entity at the service of other ASAs). As
an information collection process is triggered by a component
requesting the information, a catalog of the available information
has to be built and kept. This catalog indexes which ASA can produce
which information. Then upon a bootstrapping ASA requesting a given
information to work, the entity in charge of this catalog would then
inform requesting ASA of the source ASA. This process could be
supported by GRASP discovery mechanism.
The information collection process may be optimized by the
Information Flow Establishment and Optimization - IFEO or another
utility ASA in charge of optimizing the flows. This ASA acts as the
third party during the negotiation phase between an information
source and an information sink. If many information sink need the
same information, the negotiation entity, is liable to enforce the
use of an intermediate Knowledge Sharing system that would collect
the information from the source before flooding to sinks according to
their requirements.
The collected information may either be directed to the Information
Processing and Knowledge Production function for a further processing
(e.g., aggregation or knowledge production) and then optionally
stored/indexed to the Information Storage and Indexing - ISI
function. The storage option may be provided or demanded based on
the nature of the information, ASA demands, optimization goals, etc.
After this stage, the information or produced knowledge could be
passed back to the ICD function for dissemination.
Ciavaglia & Peloso Expires September 22, 2016 [Page 4]
Internet-Draft Knowledge in Autonomics March 2016
2.2. Information Storage and Indexing - ISI
The Information Storage and Indexing (ISI) function is a logical
construct representing a distributed repository for registering ASAs,
indexing (and optionally storing) information/knowledge. The ISI
function stores information, such as ASA registration information and
knowledge. The ISI functionality includes methods and functions for
keeping track of information sources, including information
registration and naming, constraints of information sources,
information directory and indexing. An important storage aspect,
which can assist the knowledge production handled by the Information
Processing and Knowledge Production function, is the inherent support
of historical capabilities. For example, an ASA could request
information and/or knowledge that was stored in the past using an
appropriate time stamp. It should be noted that knowledge production
functionality is not part of the ISI function, but it supports the
storing of knowledge derived due to some earlier calculations. The
ISI optionally stores knowledge produced from the Information
Processing and Knowledge Production function (for extended-scoped
knowledge) or Knowledge Building ASAs (for locally-scoped knowledge).
The different ANIMA entities either requesting or storing information
to the Knowledge block, do not directly communicate with the ISI.
The ICD function handles information collection or dissemination
between the storage points and the ASAs. Furthermore, ISI supports:
(i) publish/subscribe information dissemination capabilities, (ii)
alternative storage structures (i.e., centralized versus distributed
or hierarchical) and database technologies based on the context, and
(iii) information and knowledge caching.
2.3. Information Processing and Knowledge Production - IPKP
The Information Processing and Knowledge Production function (IPKP)
is responsible for operations related to information processing
(i.e., aggregation) and knowledge production. The IPKP provides to
ASAs and the ANIMA management functions the necessary tool kit to
produce different information abstractions, including processed
information and extended-scoped knowledge. The Knowledge Production
(KP) operation handles and produces knowledge that may be extended-
scoped. The latter type of knowledge is being produced out of
aggregated information or locally-scoped knowledge. Locally-scoped
knowledge can be built from the Knowledge Building ASAs out of data/
information directly collected from the managed entities, i.e., its
scope is limited to those entities. In all cases of knowledge
production, reasoning and inference mechanisms are required. These
mechanisms are based on different techniques depending on the exact
problem addressed, the type of inputs used and the type of output
that needs to be acquired. Such techniques come from scientific
areas like statistics, clustering, reasoning, Fuzzy or machine
Ciavaglia & Peloso Expires September 22, 2016 [Page 5]
Internet-Draft Knowledge in Autonomics March 2016
learning (including supervised, unsupervised and reinforcement
learning techniques). All the above information (e.g., problem
addressed, type of inputs / outputs, inference/reasoning mechanisms
etc) must be described in a proper ontology, ready to be looked up
from the IPKP function when such a demand appears. An ASA or ANIMA
management function that requires the IPKP functionalities requests
to utilize either an Information Aggregation (IA) or a Knowledge
Production (KP) operation. The ICD function handles the
communication of the ANIMA management component with the internal
IPKP functionalities and the IPKP controller is responsible to
control the internal IPKP components. The two IPKP operations (i.e.,
information aggregation and knowledge production) require a number of
basic steps:
Step 1: Determining the information aggregation or knowledge
production parameters (e.g., information filtering configuration,
the inference/reasoning algorithm to use, translation
requirements, whether aggregation is required and/or information/
knowledge post-processing requirements). This process is being
handled from the IPKP controller, which matches the ANIMA
component's requirements and the type of problem to solve with the
relevant information. The parameters are being communicated to
all relevant internal IPKP components.
Step 2: Collection of input information either from an ANIMA
component that produces it or from the ISI function (i.e., the
knowledge storage). A collection request is being passed back
from the IPKP controller to the ICD function.
Step 3: Pre-processing of the input information (e.g., applying
information filtering) that may be required. The pre-processing
requirements are being set from the IPKP controller.
Step 4: The input information is being passed to the IA operation
in case of information aggregation, where an aggregation process
takes place according the requirements (e.g., aggregation function
used) being set from the IPKP controller. In case of knowledge
production, this step may be bypassed or not (i.e., the higher-
level knowledge production processes may require aggregation
before the inference/reasoning process).
Step 5: In case of knowledge production, the input information may
need to be translated in a convenient representation, e.g., to
OWL. The translation configuration is being set from the IPKP
controller to match the requirements of the inference/reasoning
mechanism identified from the (TBD) ANIMA ontology.
Ciavaglia & Peloso Expires September 22, 2016 [Page 6]
Internet-Draft Knowledge in Autonomics March 2016
Step 6: The actual inference/reasoning process takes place in this
step. The input information (i.e., in an appropriate form) and
the relevant knowledge production rules are being passed to the
identified inference/reasoning mechanism. A rule description
language that can be used is the Semantic Web Rule Language
(SWRL). The output of this process is the produced Knowledge.
This step may be bypassed, in case of a request for information
aggregation without knowledge production.
Step 7: The produced knowledge or aggregated information may need
a post-processing (e.g., filtering). This step is optional.
Step 8: At this stage, the result is being communicated to the ICD
function, to find its way to the requesting ANIMA component. The
produced knowledge or aggregated information can be optionally
stored in the ISI function so as to be available for ANIMA
management mechanisms or ASAs when requested/needed.
2.4. Information Flow Establishment and Optimization - IFEO
The information flow negotiation and optimization aspects are crucial
processes overseen from the Information Flow Establishment and
Optimization (IFEO) function. The IFEO function, besides organizing
internal optimization aspects (e.g., setting filtering or information
accuracy objectives), also regulates the information flow based on
the current state and the locations of the participating ANIMA
components (e.g., the ASAs producing or requiring information). All
relevant communication between the knowledge functions and the ANIMA
components takes place through the Knowledge Management interface,
unless it is otherwise stated.
For clarity purposes, we define the specifications of the IFEO
function along with a representative example. We assume the
following two ASAs: (a) the Virtual Infrastructure Management (VIM)
ASA that provides management and control facilities for virtual
infrastructures, including support of traffic monitoring; and (b) the
Placement Optimization (PO) ASA that optimizes the data flow over a
virtual network through adapting the positioning of communicating
nodes (e.g., data servers) in response to the dynamic network
conditions. In this example, the VIM ASA provides traffic monitoring
information from a particular virtual network to the PO ASA. The PO
ASA takes optimization decisions for the network based on this
information, i.e., repositions communicating nodes in order to
optimize network communication. The information flow negotiation and
optimization processes include a number of basic phases, elaborated
below:
Ciavaglia & Peloso Expires September 22, 2016 [Page 7]
Internet-Draft Knowledge in Autonomics March 2016
Phase 1 - Registration: In this phase the ASAs, as part of their
registration process with the knowledge block (i.e., described in
section 3.6.2), will communicate the following information to the
knowledge:
Information they can offer instantly or after an information
collection process.
Knowledge they can offer instantly or after a knowledge
production process.
Information/knowledge they would require (mandatory or
optional).
The above information is embedded in the description of the ASA
instance description. In our example, the VIM ASA registers the
information it can offer (e.g., the topology information and
measurements on the link loads). This information can be offered
instantly (i.e., does not require an information collection
process to start, since it monitors the network continuously).
The PO ASA registers the same information type as mandatory
information required.
Phase 2 - An ANIMA management function requesting knowledge: In
this phase a process in an ANIMA management function (like a
supervision process in management or a knowledge production
mechanism or a coordination mechanism) demands to register to a
given piece of information produced by a given ASA. This
information is expressed as a information specification. In that
case, the Knowledge Management Interface of the requesting entity
is calling a TBD knowledge method named to request the registered
information.
Phase 3 - Information Flow Negotiation: In the third phase, the
knowledge block through its IFEO function handles a flow
negotiation process between entities (i.e., ASAs or management
mechanisms) requiring information and those can provide it. The
two entities exchange information flow related parameters with the
knowledge block, in order to confirm that all information-related
requirements can be satisfied under the given constraints. An
information flow is either established between the two entities
directly or between an entity and the knowledge block itself, in
case the requested information is available in the knowledge
storage. The negotiation process includes flow-level optimization
aspects as well. This phase is composed of the following steps:
Step 1 - Preselecting the information flow ends: Whenever a ASA
registers it advertises requested information/knowledge (under
Ciavaglia & Peloso Expires September 22, 2016 [Page 8]
Internet-Draft Knowledge in Autonomics March 2016
a specific format TBD), the knowledge block fetches in its
indexing storage the appropriate entity (ASA or management
mechanism) that can produce the requested information/
knowledge. It may either select an entity by considering the
type of information/knowledge required or, in case of
alternative options, assign the first entity it finds and
enlist the other potential choices in a queue. In case the
required information is in the knowledge storage, an
information flow is created with the knowledge. The same
process happens when a ANIMA management entity requests some
knowledge, depending on the form of the request (i.e., a
fetching from the indexing storage may or may not be required):
ASA information: already specifies which is the Instance ID
of the ASA producing the information.
ANIMA information: a fetching from the index table is
required to pick the appropriate flow ends.
Management information: then the fetching does not concern
finding a flow end, but finding all the flow ends matching
the pattern provided by the management information in order
to establish as many flows as indexed ANIMA information
objects inheriting from the management information (this
corresponds to a supervision mechanism requesting to
register to ASA utilities, hence a flow for each ASA capable
of advertising its utility will be created). Reversely,
knowledge may have postponed flow establishments of some
requested information because at the time the request was
received, no entity producing this information was
registered. In that case, knowledge checks with every
received instance description whether the advertised
information matches previously unsolved requests. After
that, the IFEO proceeds to Step 2. In the studied example,
the knowledge block preselects the VIM ASA as information
source for the PO ASA that acts as the information sink.
This selection was based on the matching information URIs
referenced in the registered ANIMA information data
structures from the two ASAs.
Step 2 -Communicating the negotiation parameters: in step 2, a
negotiation process is initiated between the entity requiring
information/knowledge (i.e., the information sink entity) and
the selected information source entity. The negotiation begins
with the two entities communicating additional negotiation
parameters to the knowledge block. Specifically, the
information sink entity communicates an augmented version of
the ANIMA information with:
Ciavaglia & Peloso Expires September 22, 2016 [Page 9]
Internet-Draft Knowledge in Autonomics March 2016
-QoS Requirements on the information/knowledge it requires.
-Preferred information communication method (i.e., either
push/pull or pub/sub).
-List of Knowledge Exchange interfaces (addresses) on which
the information can be received and possibly an internal
metric regarding the internal costs to use this information
from each of these interfaces.
-REST callback functions that may be required at this end of
communication (e.g., in case of an information subscribe
method).
In a similar way, the information source entity communicates
the following to the knowledge block:
-QoS Constraints on the information/knowledge it can offer.
-Supported(and preferred) information communication method
(i.e., either push/pull or pub/sub).
-Whether for this requested information/knowledge an
"information collection/knowledge production" process is
already activated or needs to be initiated.
-List of Knowledge Exchange interfaces (addresses) on which
the information can be provided and possibly an internal
metric regarding their internal cost to bring this
information up to the interface.
-REST Callback functions for the relevant capabilities
(i.e., triggering functions for information collection or
knowledge production - if relevant).
Practically, the knowledge block initiates a new negotiation
with the execution of the sink and source parameters
negotiation methods of the Knowledge Management Interface.
Both methods take as input the specifications of the
information to be communicated from the established
communication flow, represented as an ANIMA information data
structure. In the reference scenario, the VIM ASA communicates
to the knowledge: (i) the QoS constraints of the topology and
link load information it can offer, e.g., monitors information
once per 10 secs, and (ii) a number of available Knowledge
Exchange interfaces that can provide the information. The PO
ASA communicates to the knowledge: (i) the QoS requirements of
the required information, e.g., once per 30 secs, and (ii) a
Ciavaglia & Peloso Expires September 22, 2016 [Page 10]
Internet-Draft Knowledge in Autonomics March 2016
number of available Knowledge Exchange interfaces that can
receive the information.
Step 3 - Completing the negotiation: The knowledge block
matches information flow requirements with constraints,
determines the information flow parameters with flow
optimization considerations and then issues a Knowledge
Exchange Policy summarizing an information flow contract to
both entities. knowledge also stores the Knowledge Exchange
Policy through the Information Flow Configuration and
Statistics operation of the IFEO function. In case of an
unsuccessful negotiation (i.e., the requirements do not match
the constraints), it may disengage or trigger a new
negotiation:
a) With the same information source entity but lower
requirements.
>b) With another information source entity that waits in the
queue, until the queue is exhausted.
The Information Exchange Policies for the corresponding flow
are being produced from the Information Quality Controller
operation of the IFEO knowledge block function and include:
-Location/addresses of the participating Knowledge Exchange
Interfaces in the information flow.
-Internal knowledge optimization decisions that may impact
the information flow (e.g., optimal knowledge aggregation/
storage points), in case the knowledge block is the one end
of the flow.
-Addresses of triggering callback functions for knowledge
production or information collection - if relevant.
These policies are considering the requirements/constraints of the
participating entities and the global performance objective coming
from the operator (e.g. via the ANIMA Intent Policy). The knowledge
establishes the information flow using a set flow method of the
Knowledge Management Interface, that takes as an input the decided
Information Flow Exchange Policies, represented as a flow data
structure.
The decided Information Exchange Policies are being applied to the
network through the respective ASAs or communicated to the knowledge
functions they are associated with. Since the appropriate context
environment for the new information flow is prepared, a suitable path
Ciavaglia & Peloso Expires September 22, 2016 [Page 11]
Internet-Draft Knowledge in Autonomics March 2016
between the participating nodes is established next. This process
considers the locations of the entities producing and requiring
information and the required knowledge nodes (e.g., aggregation
points, storage points etc) as well as the potential traffic
characteristics. After that, the Knowledge Exchange interface can be
accessed anytime from the information sink entity to receive the
needed information/knowledge. In our reference scenario, the
knowledge block matches the information flow constraints (e.g.,
supported monitoring rate) of the VIM ASA with the information flow
requirements from the PO ASA. Then it selects the most appropriate
Knowledge Exchange interfaces to communicate the information from the
VIM to the PO ASA. A new information flow contract is established
and communicated to the two ASAs and stored in the knowledge block.
The information flow is established and the PO ASA can retrieve the
required information from the VIM ASA via the appropriate Knowledge
Exchange interface. The PO ASA can now begin taking network
optimization decisions using that information.
Knowledge-level Optimization: Furthermore, knowledge supports a
global optimization process that is triggered periodically or when a
global performance objective change is requested from the GOV. This
process takes optimization decisions using the aggregated information
from the configuration of all established information flows and is
related with a restructuring of the knowledge functions themselves.
In other words, global-optimization algorithms may discard or update
Knowledge Exchange Policies enforced for established information
flows. It takes as an input the global picture of all the
established information flow contacts and provides as an output
different contracts aligned better to the new updated demands (e.g.,
a new received global objective). This process may initiate re-
negotiations that include requesting again from the entities what
their requirements and capabilities are. For example, the
distributed knowledge nodes may be increased, decreased or
repositioned in order to accommodate all established information
flows and the global optimization goal better. The optimization
process is triggered by the IFEO function and regulates the
information flow based on the current state and the locations of the
participating ANIMA components. In particular, the IFEO controls
information collection handled from the ICD function, information
aggregation, and aggregation node placement. Furthermore, it guides
a filtering system for information collection and aggregation points
that can significantly reduce the communication overhead.
3. Acknowledgments
This draft was written using the xml2rfc project.
Ciavaglia & Peloso Expires September 22, 2016 [Page 12]
Internet-Draft Knowledge in Autonomics March 2016
The content of this draft builds upon work achieved during the EU FP7
UniverSelf project (www.univerself-project.eu).
4. IANA Considerations
This memo includes no request to IANA.
5. Security Considerations
TBD
6. References
6.1. Normative References
[I-D.ciavaglia-anima-coordination]
Ciavaglia, L. and P. Peloso, "Autonomic Functions
Coordination", draft-ciavaglia-anima-coordination-00 (work
in progress), July 2015.
[I-D.peloso-anima-autonomic-function]
Peloso, P. and L. Ciavaglia, "A Day in the Life of an
Autonomic Function", draft-peloso-anima-autonomic-
function-00 (work in progress), October 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
6.2. Informative References
[I-D.behringer-anima-reference-model]
Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L.,
Liu, B., Jeff, J., and J. Strassner, "A Reference Model
for Autonomic Networking", draft-behringer-anima-
reference-model-04 (work in progress), October 2015.
[RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A.,
Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic
Networking: Definitions and Design Goals", RFC 7575,
DOI 10.17487/RFC7575, June 2015,
<http://www.rfc-editor.org/info/rfc7575>.
Ciavaglia & Peloso Expires September 22, 2016 [Page 13]
Internet-Draft Knowledge in Autonomics March 2016
Authors' Addresses
Laurent Ciavaglia
Nokia
Villarceaux
Nozay 91460
FR
Email: laurent.ciavaglia@nokia.com
Pierre Peloso
Nokia
Villarceaux
Nozay 91460
FR
Email: pierre.peloso@nokia.com
Ciavaglia & Peloso Expires September 22, 2016 [Page 14]
