One document matched: draft-zhang-teas-actn-yang-00.txt
TEAS WG Young Lee
Xian Zhang
Internet Draft Huawei
Intended status: Informational
Daniele Ceccarrelli
Expires: February 2017 Ericsson
Bin Yeong Yoon
ETRI
Oscar Gonzalez de Dios
Telefonica
September 27, 2016
Applicability of YANG models for Abstraction and Control of Traffic
Engineered Networks
draft-zhang-teas-actn-yang-00
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), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 27, 2017.
Zhang, et al. Expires January 27, 2017 [Page 1]
Internet-Draft ACTN YANG September 2016
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
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. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Abstract
Abstraction and Control of TE Networks (ACTN) refers to the set of
virtual network operations needed to orchestrate, control and manage
large-scale multi-domain TE networks, so as to facilitate network
programmability, automation, efficient resource sharing, and end-to-
end virtual service aware connectivity and network function
virtualization services.
This document explains how the different types of YANG models
defined in the Operations and Management Area and in the Routing
Area are applicable to the ACTN framework.
Table of Contents
1. Introduction...................................................3
2. Abstraction and Control of TE Networks (ACTN) Architecture.....3
3. Service Models.................................................5
4. Service Model Mapping to ACTN..................................6
4.1. Customer Service Models in the ACTN Architecture (CMI)....8
4.2. Service Delivery Model in ACTN Architecture...............9
4.3. Network Configuration Model in ACTN Architecture (MPI)....9
4.4. Device Model in ACTN Architecture (SBI)..................10
4.5. Advanced Models..........................................10
5. Examples of Using Different Types of YANG Models..............11
5.1. Simple Connectivity Examples.............................11
Zhang, et al. Expires January 27, 2017 [Page 2]
Internet-Draft ACTN YANG September 2016
5.2. VN service example.......................................11
5.3. Data Center-Interconnection Example......................12
5.3.1. CMI (CNC-MDSC Interface)............................14
5.3.2. MPI (MDSC-PNC Interface)............................14
5.3.3. PDI (PNC-Device interface)..........................14
6. Security......................................................15
7. Acknowledgements..............................................15
8. References....................................................15
8.1. Informative References...................................15
9. Contributors..................................................16
Authors' Addresses...............................................17
1. Introduction
Abstraction and Control of TE Networks (ACTN) describes a method for
operating a Traffic Engineered (TE) network (such as an MPLS-TE
network or a layer 1 transport network) to provide connectivity and
virtual network services for customers of the TE network. The
services provided can be tuned to meet the requirements (such as
traffic patterns, quality, and reliability) of the applications
hosted by the customers. More details about ACTN can be found in
Section 2.
Data models are a representation of objects that can be configured
or monitored within a system. Within the IETF, YANG [RFC6020] is the
language of choice for documenting data models, and YANG models have
been produced to allow configuration or modelling of a variety of
network devices, protocol instances, and network services. YANG data
models have been classified in [Netmod-Yang-Model-Classification]
and [Service-YANG].
This document shows how the ACTN architecture can be satisfied using
classes of data model that have already been defined, and discusses
the applicability of specific data models that are under
development. It also highlights where new data models may need to be
developed.
2. Abstraction and Control of TE Networks (ACTN) Architecture
[ACTN-Requirements] describes the high-level ACTN requirements.
[ACTN-Frame] describes the architecture model for ACTN including the
entities (Customer Network Controller (CNC), Multi-domain Service
Coordinator (MDSC), and Physical Network Controller (PNC)) and their
interfaces.
Figure 1 depicts a high-level control and interface architecture for
ACTN and is a reproduction of Figure 7 from [ACTN-Frame]. A number
Zhang, et al. Expires January 27, 2017 [Page 3]
Internet-Draft ACTN YANG September 2016
of key ACTN interfaces exist for deployment and operation of ACTN-
based networks. These are highlighted in Figure 1 (ACTN Interfaces)
below:
.--------------
------------- |
| Application |--
-------------
^
| I/F A --------
v ( )
-------------- - -
| Customer | ( Customer )
| Network |--------->( Network )
| Controller | ( )
-------------- - -
^ ( )
| I/F B --------
v
--------------
| MultiDomain |
| Service |
| Coordinator| --------
-------------- ( )
^ - -
| I/F C ( Physical )
v ( Network )
--------------- ( ) --------
| |<----> - - ( )
-------------- | ( ) - -
| Physical |-- -------- ( Physical )
| Network |<---------------------->( Network )
| Controller | I/F D ( )
-------------- - -
( )
--------
Figure 1 : ACTN Interfaces
The interfaces and functions are described below (without modifying
the definitions) in [ACTN-Frame]:
. Interface A: This is out of scope of this draft.
. Interface B: The CNC-MDSC Interface (CMI) is an interface
between a Customer Network Controller and a Multi Domain
Zhang, et al. Expires January 27, 2017 [Page 4]
Internet-Draft ACTN YANG September 2016
Service Controller. The interface will communicate the service
request or application demand. A request will include specific
service properties, including: services, bandwidth and
constraint information. The CNC can also request the creation
of the virtual network resources and virtual topology based on
underlying physical resources to provide network services for
the applications. The CNC can provide the end-point
information/characteristics, traffic demand, a connectivity
matrix, and a virtual network. The MDSC may also report
potential network topology availability if queried for current
capability from the Customer Network Controller.
. Interface C: The MDSC-PNC Interface (MPI) is an interface
between a Multi Domain Service Coordinator and a Physical
Network Controller. It allows the MDSC to communicate requests
to create connectivity or to modify bandwidth reservations in
the physical network. In multi-domain environments, each PNC is
responsible for a separate domain and so the MDSC needs to
establish multiple MPIs, one for each PNC and perform
coordination between them.
. Interface D: The provisioning interface for creating forwarding
state in the physical network, requested via the Physical
Network Controller.
3. Service Models
[Service-YANG] introduces a reference architecture to explain the
nature and usage of service YANG models in the context of service
orchestration. Figure 2 below depicts this relationship and is a
reproduction of Figure 2 from [Service-YANG]. Four models depicted
in Figure 2 are defined as follows:
. Customer Service Model: A customer service model is used to
describe a service as offer or delivered to a customer by a
network operator.
. Service Delivery Model: A service delivery model is used by a
network operator to define and configure how a service is
provided by the network.
. Network Configuration Model: A network configuration model is
used by a network orchestrator to provide network-level
configuration model to a controller.
. Device Configuration Model: A device configuration model is
used by a controller to configure physical network elements.
Zhang, et al. Expires January 27, 2017 [Page 5]
Internet-Draft ACTN YANG September 2016
Customer
------------------ Service ----------
| | Model | |
| Service |<-------->| Customer |
| Orchestrator | | |
| | ----------
------------------
. .
. . -----------
. . ......|Application|
. . : | BSS/OSS |
. . : -----------
. Service Delivery . :
. Model . :
------------------ ------------------
| | | |
| Network | | Network |
| Orchestrator | | Orchestrator |
| | | |
.------------------ ------------------.
. : : .
. : Network Configuration : .
. : Model : .
------------ ------------ ------------ ------------
| | | | | | | |
| Controller | | Controller | | Controller | | Controller |
| | | | | | | |
------------ ------------ ------------ ------------
: . . : :
: . . Device : :
: . . Configuration : :
: . . Model : :
--------- --------- --------- --------- ---------
| Network | | Network | | Network | | Network | | Network |
| Element | | Element | | Element | | Element | | Element |
--------- --------- --------- --------- ---------
Figure 2: An SDN Architecture with a Service Orchestrator
4. Service Model Mapping to ACTN
YANG models coupled with the RESTCONF/NETCONF protocol
[Netconf][Restconf] is a solution for the ACTN framework. This
section explains which types of YANG models apply to each of the
ACTN interfaces.
Zhang, et al. Expires January 27, 2017 [Page 6]
Internet-Draft ACTN YANG September 2016
+-------------------------------------------------------------+
| |
| +-----------+ +-------+ |
| | Customer | | CNC | |
| +-----------+ +-------+ |
| /|\ /|\ |
+---------|-------------------------------------------|-------+
| Customer Service Model | CMI
| |
+------ --|-------------------------------------------|--------+
| \|/ | |
| +------------+ | |
| | Service | \|/ |
| |Orchestrator| +----------+ |
| +------------+ | | |
| /|\ | MDSC | |
| | Service Delivery Model | | |
| \|/ | | |
| +------------+ +----------+ |
| | Network | /|\ |
| |Orchestrator| | |
| +------------+ | |
| /|\ | |
| | | |
+---------|-------------------------------------------|--------+
| | MPI
| Network Configuration Model |
+---------|-------------------------------------------|--------+
| \|/ \|/ |
| +----------+ +-----------+ |
| | Domain | | PNC | |
| |Controller| +-----------+ |
| +----------+ /|\ /|\ |
| /|\ /|\ | | |
| | | | | |
+------|-----|-------------------------------------|-----|-----+
| | Device Configuration Model | | SBI
\|/ \|/ \|/ \|/
--- --- --- ---
/ \ / \ / \ / \
\ / \ / \ / \ /
--- --- --- ---
Figure 3 : Mapping between Service Model and ACTN Architecture
Zhang, et al. Expires January 27, 2017 [Page 7]
Internet-Draft ACTN YANG September 2016
As shown in Figure 3, the architecture described in [Service-YANG]
can be mapped to the ACTN architecture well. A point worth noting is
that here the functions of the MDSC can include:
1. Customer mapping/translation
This function is to map customer intent-like commands into network
provisioning requests to the Physical Network Controller (PNC)
according to business OSS/NMS provisioned static or dynamic policy.
. Moreover, it provides mapping and translation of customer network
slices into physical network resources.
2. Service/Virtual service coordination
This function translates customer service-related information into
the virtual network operations in order to seamlessly operate
virtual networks while meeting customer's service requirements.
3. Multi domain coordination
This function oversees the specific aspects of the different domains
and to build a single abstracted end-to-end network topology in
order to coordinate end-to-end path computation and path/service
provisioning. Domain sequence path calculation/determination is also
a part of this function.
4. Virtualization/Abstraction
This function provides an abstracted view of the underlying network
resources towards customer, being it the client or a higher level
controller entity. It includes computation of customer resource
requests into network paths based on the global network-wide
abstracted topology and the creation of an abstracted view of
network slices allocated to each customer, according to customer-
specific network objective functions, and to the customer traffic
profile.
The first two of these functions (1 and 2) are related to service
orchestration while function 3 is related to network orchestration
and function 4 is related to both service and network orchestration.
4.1. Customer Service Models in the ACTN Architecture (CMI)
Customer Service Models, which are used between a customer and a
service orchestrator as in [Service-YANG], should be used between
Zhang, et al. Expires January 27, 2017 [Page 8]
Internet-Draft ACTN YANG September 2016
the CNC and MDSC (e.g., CMI) serving as providing a simple intent-
like model/interface.
Among the key functions of Customer Service Models on the CMI is the
service request. A request will include specific service properties,
including: service type and its characteristics, bandwidth,
constraint information, and end-point characteristics.
Examples of service models applicable to ACTN are [Transport-
Service-Model] and [ACTN-VN-YANG].
4.2. Service Delivery Model in ACTN Architecture
The Service Delivery Models (as shown in Figure 3) where the service
orchestration and the network orchestration could be implemented as
separate components as seen in [Service-YANG]. This is also known as
Network Service Models. On the other hand, from an ACTN architecture
point of view, the service delivery model between the service
orchestrator and the network orchestrator is an internal interface
between sub-components of the MDSC.
4.3. Network Configuration Model in ACTN Architecture (MPI)
The Network Configuration Models is used between the network
orchestrator (MSDC) and the controller (PNC) in [Service-YANG]. In
ACTN, this model is used either between hierarchical MDSCs (see
Section 4.5) or between a MDSC and a PNC.
The Network Configuration Model captures the parameters which are
network wide information. Examples of Network configuration models
are [TE-Tunnel] and [TE-Topology].
The following table provides key functions of the MPI mapped with
Network Configuration Yang Models. Note that there are various Yang
models are work in progress.
Function Yang Models
------------------------------------------
Configuration Scheduling [Schedule]
Path computation TDB
Path Provisioning [TE-Tunnel]*
Topology Abstraction [TE-topology]
Telemetry TDB
*Note that path provisioning function is provided by ietf-te module
in [TE-Tunnel].
Zhang, et al. Expires January 27, 2017 [Page 9]
Internet-Draft ACTN YANG September 2016
4.4. Device Models in ACTN Architecture (SBI)
For the device YANG models are used for per-device configuration
purpose, they can be used between the PNC and the physical
network/devices. An example of Device Models is ietf-te-device yang
module defined in [TE-tunnel]. Note that SBI is not in the scope of
ACTN. This section is provided to give some examples of YANG-based
Device Models.
4.5. Advanced Models
There may be some variation of interface C whereby there may be
MDSC-MDSC interface (MMI) in case where there may be a recursive
hierarchy among the MDSCs. This is a variation of ACTN architecture.
See Figure 4 for this.
+-------+ +-------+ +-------+
| CNC-A | | CNC-B | | CNC-C |
+-------+ +-------+ +-------+
\ | /
---------- | ----------
\ | /
+-----------------------+
| MDSC |
+-----------------------+
/ | \
---------- | -----------
/ | \
+----------+ +----------+ +--------+
| MDSC | | MDSC | | MDSC |
+----------+ +----------+ +--------+
| / | / \
| / | / \
+-----+ +-----+ +-----+ +-----+ +-----+
| PNC | | PNC | | PNC | | PNC | | PNC |
+-----+ +-----+ +-----+ +-----+ +-----+
Figure 4: MDSC Controller Hierarchy
The MDSC-MDSC interface can be viewed as a recursive network
configuration model which is similar to the MDSC-PNC interface.
Zhang, et al. Expires January 27, 2017 [Page 10]
Internet-Draft ACTN YANG September 2016
5. Examples of Using Different Types of YANG Models
5.1. Simple Connectivity Examples
The data model in [Transport-Service-Model] provides an intent-like
connectivity service model which can be used in connection-oriented
transport networks.
It would be used as follows in the ACTN architecture:
. A CNC uses this service model to specify the two client nodes
that are to be connected, and also indicates the amount of
traffic (i.e., the bandwidth required) and payload type. What
may additionally is the SLA that describes the required quality
and resilience of the service.
. The MDSC uses the information in the request to pick the right
network (domain) and also to select the provider edge nodes
corresponding to the customer edge nodes.
If there are multiple domains, then the MDSC needs to
coordinate across domains to set up network tunnels to deliver
a service. Thus coordination includes, but is not limited to,
picking the right domain sequence to deliver a service. Before
it can perform such functions, it needs to get the topology
information from each PNC, be it abstract or not, using
topology YANG models such as [te-topology].
Additionally, a MDSC can initiate the creation of a tunnel (or
tunnel segment) in order to fulfill the service request from
CNC based on path computation upon the overall topology
information it synthesized from different PNCs. The based model
that can cater this purpose is the te-tunnel model specified in
[te-tunnel].
. Then, the PNC needs to decide the explicit route of such a
tunnel or tunnel segment (in case of multiple domains), and
create such a tunnel using protocols such as PCEP and RSVP-TE
or using per-hop configuration.
5.2. VN service example
The service model defined in [ACTN-VN-YANG] describes a virtual
network (VN) as a service which is a set of multiple connectivity
services:
Zhang, et al. Expires January 27, 2017 [Page 11]
Internet-Draft ACTN YANG September 2016
. A CNC will specify to the MDSC a list of VN members. Each VN
member specifies either a single connectivity service, or a
source with multiple potential destination points in the case
that the precise destination sites are to be determined by
MDSC.
o In the first case, the procedure is the same as the
connectivity service, except that in this case, there is a
list of connections requested.
o In the second case, where the CNC requests the MDSC to
select the right destination out of a list of candidates,
the MDSC needs to choose the best candidate and reply with
the chosen destination for a given VN member. After this
is selected, the connectivity request setup procedure is
the same as in the connectivity-as-a-service example.
5.3. Data Center-Interconnection Example
This section describes more concretely how existing YANG models
described in Section 4 map to an ACTN data center interconnection
use case. Figure 5 shows a use-case which shows service policy-
driven Data Center selection and is a reproduction of Figure A.1
from [ACTN-Info].
Zhang, et al. Expires January 27, 2017 [Page 12]
Internet-Draft ACTN YANG September 2016
+----------------+
| CNC |
| (Global DC |
| Operation |
| Control) |
+--------+-------+
| | VN Requirement/Policy:
CMI: | | - Endpoint/DC location info
Service model | | - Endpoint/DC dynamic
| | selection policy
| | (for VM migration, DR, LB)
| v
+---------+---------+
| Multi-domain | Service policy-driven
|Service Coordinator| dynamic DC selection
MPI: +-----+---+---+-----+
Network Configuration | | |
Model | | |
+----------------+ | +---------------+
| | |
+-----+-----+ +------+-----+ +------+-----+
| PNC for | | PNC for | | PNC for |
| Transport | | Transport | | Transport |
| Network A | | Network B | | network C |
+-----------+ +------------+ +------------+
Device | | |
Model | | |
| | |
+---+ ------ ------ ------ +---+
|DC1|--//// \\\\ //// \\\\ //// \\\\---+DC5|
+---+ | | | | | | +---+
| TN A +-----+ TN B +----+ TN C |
/ | | | | |
/ \\\\ //// / \\\\ //// \\\\ ////
+---+ ------ / ------ \ ------ \
|DC2| / \ \+---+
+---+ / \ |DC6|
+---+ \ +---+ +---+
|DC3| \|DC4|
+---+ +---+
DR: Disaster Recovery
LB: Load Balancing
Figure 5: Service Policy-driven Data Center Selection
Zhang, et al. Expires January 27, 2017 [Page 13]
Internet-Draft ACTN YANG September 2016
Figure 5 shows how VN policies from the CNC (Global Data Center
Operation) are incorporated by the MDSC to support multi-destination
applications. Multi-destination applications refer to applications
in which the selection of the destination of a network path for a
given source needs to be decided dynamically to support such
applications.
Data Center selection problems arise for VM mobility, disaster
recovery and load balancing cases. VN's policy plays an important
role for virtual network operation. Policy can be static or dynamic.
Dynamic policy for data center selection may be placed as a result
of utilization of data center resources supporting VMs. The MDSC
would then incorporate this information to meet the objective of
this application.
5.3.1. CMI (CNC-MDSC Interface)
The VN Service Model [ACTN-VN-YANG] is used to express the
definition of a VN, its VN creation request, the service objectives
(metrics, QoS parameters, etc.), dynamic service policy when VM
needs to be moved from one Data Center to another Data Center, etc.
This service model is used between the CNC and the MDSC (CMI). The
CNC in this use-case is an external entity that wants to create a VN
and operates on the VN.
5.3.2. MPI (MDSC-PNC Interface)
The Network Configuration Model is used between the MDSC and the
PNCs. Based on the Customer Service Model's request, the MDSC will
need to translate the service model into the network configuration
model to instantiate a set of multi-domain connections between the
prescribed sources and the destinations. The MDSC will also need to
dynamically interact with the CNC for dynamic policy changes
initiated by the CNC. Upon the determination of the multi-domain
connections, the MDSC will need to use the network configuration
model such as [TE-Tunnel] to interact with each PNC involved on the
path. [TE-Topology] is used to for the purpose of underlying domain
network abstraction from the PNC to the MDSC.
5.3.3. PDI (PNC-Device interface)
The Device Model can be used between the PNC and its underlying
devices that are controlled by the PNC. The PNC will need to trigger
signaling using any mechanisms it employees (e.g. [RSVP-TE-YANG]) to
provision its domain path segment. There can be a plethora of
choices how to control/manage its domain network. The PNC is
responsible to abstract its domain network resources and update it
Zhang, et al. Expires January 27, 2017 [Page 14]
Internet-Draft ACTN YANG September 2016
to the MDSC. Note that this interface is not in the scope of ACTN.
This section is provided just for an illustration purpose.
6. Security
This document is an informational draft. When the models mentioned
in this draft are implemented, detailed security consideration will
be given in such work.
How security fits into the whole architecture has the following
components:
- the use of Restconf security between components
- the use of authentication and policy to govern which services can
be requested by different parties.
- how security may be requested as an element of a service and
mapped down to protocol security mechanisms as well as separation
(slicing) of physical resources)
7. Acknowledgements
We thank Adrian Farrel for providing useful comments and suggestions
for this draft.
8. References
8.1. Informative References
[Service-YANG] Q. Wu, W. Liu and A. Farrel, "Service Models
Explained", draft-wu-opsawg-service-model-explained, work
in progress.
[Netmod-Yang-Model-Classification] D. Bogdanovic, B. Claise, and C.
Moberg, "YANG Module Classification", draft-ietf-netmod-
yang-model-classification, work in progress.
[Netconf] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241.
[Restconf] A. Bierman, M. Bjorklund, and K. Watsen, "RESTCONF
Protocol", draft-ietf-netconf-restconf, work in progress.
Zhang, et al. Expires January 27, 2017 [Page 15]
Internet-Draft ACTN YANG September 2016
[ACTN-Requirements] Y. Lee, et al., "ACTN Requirements for
Abstraction and Control of TE Networks", draft-ietf-teas-
actn-requirements, work in progress.
[ACTN-Frame] D. Cecarelli and Y. Lee, "Framework for Abstraction and
Control of Traffic Engineered Networks", draft-ietf-teas-
actn-framework, work in progress.
[TE-Topology] X. Liu, et. al., "YANG Data Model for TE Topologies",
draft-ietf-teas-yang-te-topo, work in progress.
[TE-Tunnel] T. Saad (Editor), "A YANG Data Model for Traffic
Engineering Tunnels and Interfaces", draft-ietf-teas-yang-
te, work in progress.
[ACTN-VN-YANG] Y. Lee (Editor), "A Yang Data Model for ACTN VN
Operation", draft-lee-teas-actn-vn-yang, work in progress.
[ACTN-Info] Y. Lee & S. Belotti, "Information Model for Abstraction
and Control of TE Networks (ACTN)", draft-leebelotti-teas-
actn-info, work in progress.
[Transport-Service-Model] X. Zhang (Editor), "A Service YANG Model
for Connection-oriented Transport Networks", draft-zhang-
teas-transport-service-model, work in progress.
[RSVP-TE-YANG] T. Saad (Editor), "A YANG Data Model for Resource
Reservation Protocol (RSVP)", draft-ietf-teas-yang-rsvp,
work in progress.
[Schedule] X. Liu, et. al., "A YANG Data Model for Configuration
Scheduling", draft-liu-netmod-yang-schedule, work in
progress.
9. Contributors
Contributor's Addresses
Dhruv Dhoddy
Huawei Technologies
Email: dhruv.ietf@gmail.com
Zhang, et al. Expires January 27, 2017 [Page 16]
Internet-Draft ACTN YANG September 2016
Haomian Zheng
Huawei Technologies
Email: zhenghaomian@huawei.com
Sergio Belotti
Nokia
Email: sergio.belotti@nokia.com
Authors' Addresses
Young Lee
Huawei Technologies
5340 Legacy Drive
Plano, TX 75023, USA
Phone: (469)277-5838
Email: leeyoung@huawei.com
Xian Zhang
Huawei Technologies
Email: zhang.xian@huawei.com
Daniele Ceccarelli
Ericsson
Torshamnsgatan,48
Stockholm, Sweden
Email: daniele.ceccarelli@ericsson.com
Bin Yeong Yoon
ETRI
Email: byyun@etri.re.kr
Oscar Gonzalez de Dios
Telefonica
Email: oscar.gonzalezdedios@telefonica.com
Zhang, et al. Expires January 27, 2017 [Page 17]
| PAFTECH AB 2003-2026 | 2026-04-24 10:29:49 |