Internet DRAFT - draft-unify-sfc-control-plane-exp
draft-unify-sfc-control-plane-exp
SFC R. Szabo
Internet-Draft Ericsson
Intended status: Informational B. Sonkoly
Expires: September 22, 2016 BME
March 21, 2016
A Multi-Domain Multi-Technology SFC Control Plane Experiment: A UNIFYed
Approach
draft-unify-sfc-control-plane-exp-00
Abstract
This document reports on the experimentation with a combined Network
Function Virtualization (NFV) orchestrator and Service Function Chain
(SFC) Control Plane proof of concept prototype.
Status of This Memo
This Internet-Draft is submitted 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.
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.
Szabo & Sonkoly Expires September 22, 2016 [Page 1]
Internet-DrafSFC Control Plane Experiment: UNIFYed Approach March 2016
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 2
3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. SFC Control Plane: An Experimental Design . . . . . . . . . . 3
5. Experimental Network Scenario . . . . . . . . . . . . . . . . 9
5.1. SFC Control Interfaces . . . . . . . . . . . . . . . . . . 11
5.1.1. C1/C2 Interfaces . . . . . . . . . . . . . . . . . . . . 11
5.1.2. C3 Interface . . . . . . . . . . . . . . . . . . . . . . 12
6. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. SFC Requirements . . . . . . . . . . . . . . . . . . . . . 12
6.1.1. General requirements . . . . . . . . . . . . . . . . . . 12
6.1.2. SFC Control Plane Bootstrapping . . . . . . . . . . . . . 13
7. Open Questions . . . . . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 15
11. Informative References . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction
The goal of this report is to provide an insight into a Service
Function Chain (SFC) control and Network Function Virtualization
(NFV) orchestration proof of concept implementation and
experimentation in multi-domain/technology environments.
The reported concept is based on the EU-FP7 UNIFY project's approach
[I-D.unify-nfvrg-challenges], [UNIFY-GLOBECOM], which defines joint
compute and network virtualization and control interfaces
[I-D.unify-nfvrg-recursive-programming].
The rest of the document is structured as follows: In Section 2 we
define the related terminology, which is followed with the listing of
our assumptions in Section 3. In Section 4 we derive our design from
the SFC Control Plane framework. In Section 5 we outline our
experimental network scenario. In Section 6 we analyze the gaps
between our experimental design and the SFC Control Plane. Finally,
in Section 7 we formulate some questions to the community based on
our learnings.
2. Terms and Definitions
The reader should be familiar with the terms defined in [RFC7498] and
[RFC7665].
Szabo & Sonkoly Expires September 22, 2016 [Page 2]
Internet-DrafSFC Control Plane Experiment: UNIFYed Approach March 2016
3. Assumptions
We assume a Network Function Virtualization (NFV) environment, where
Service Functions (SF) of a SFC will map as Virtualized Network
Functions (VNFs).
We assume that both Classification and Service Function Forwarding
(SFF) behavior can be expressed by SDN forwarding rules (match rules
and actions); if a Classification or a SFF cannot be mapped to match
and action pairs, then a corresponding control plane SF (VNF) is
instantiated to analyze and tag the flows into SFP. (This is not
different than an SF being SFC aware.)
We assume the existence of multiple SFC domains as a result of
technology, administration or ownership considerations.
We assume that a boundary node can act as ingress/egress for Service
Function Paths entering/leaving the SFC domain.
We assume dynamic establishment of SFC; static configuration is not
considered in this document.
4. SFC Control Plane: An Experimental Design
We start with the reference architecture of
[I-D.ietf-sfc-control-plane]:
Szabo & Sonkoly Expires September 22, 2016 [Page 3]
Internet-DrafSFC Control Plane Experiment: UNIFYed Approach March 2016
+----------------------------------------------+
| |
| SFC Control Plane |
+-------| |
| | |
C1 +------^-----------^-------------^-------------+
+---------------------|C3---------|-------------|-------------+
| | +----+ | | |
| | |SF1 | |C2 |C2 |
| | +----+ | | |
| +----V--- --+ | | | |
| | SFC | +----+ +-|--+ +----+ |
| |Classifier |---->|SFF1|----->|SFF2|------->|SFF3| |
| | Node A |<----| |<-----| |<-------| | |
| +-----------+ +----+ +----+ +----+ |
| | | | |
| |C2 ------- | |
| | | | +-----------+ C4 |
| V +----+ +----+ | SFC Proxy |--> |
| |SF2 | |SF3 | +-----------+ |
| +----+ +----+ |
| |C3 |C3 |
| SFC Data Plane Components V V |
+-------------------------------------------------------------+
Figure 1: SFC Control Plane: Overview
Let's map the above architecture to Logical Data Plane Components,
where classification / forwarding is controlled by SDN forwarding
behavior control over interface "C" consumed by SFC Controller's C1
and C2 (see Figure 2).
Szabo & Sonkoly Expires September 22, 2016 [Page 4]
Internet-DrafSFC Control Plane Experiment: UNIFYed Approach March 2016
+----------------------------------------------+
| |
| SFC Control Plane |
+---|C1 |
| | C3 C2 C3 C3 C2 C2 |
| +-------+----+-----------+------+---+-------+--+
| | | | | | |
| |C3 | |C3 |C3 | |
| +---+ | +---+ +---+ | |
| | S | | | S | | S | | |
| | F | | | F | | F | | |
| | 1 | | | 2 | | 3 | | |
| +---+ | +---+ +---+ | |
| | | | | | | | |
+----C--+ +--a-b---C+ +--a-b-----d---C+ +-C-------+
| | | | | | | | | / \ | | |
[1------>3]->[1->+ +->--3]<-->[1->+ +->-+ +--3]->[1------\ 3]
| | | /| |\ | | \ |
[2<------4]<-[2--<----/ 4]<---[2 \-<-----------4]<-[2<------- 4]->C4
| | | SFF1 | | SFF2 | | SFF3 |
+-------+ +---------+ +---------------+ +---------+
SFC Class Proxy
Node A
Figure 2: SFC Control Plane with Virtual Data Plane Elements
If we consider an NFV environment, where SFs are instantiated on
demand as VNF instances, then the SFC Controller's C3 interfaces to
SFs map to data plane links, which are situationally used for control
plane communication. Such DP configuration is by no means different
from an SFP.
However, from SDN forwarding control point of view, traffic
classification or forwarding is again situational. Classification
may encapsulate (label) flows based on given match criteria with
respect to different protocol headers, while forwarding may simply
based on matching on the SFC encapsulation labels. Therefore, in a
virtual data plane component SFC classification and SFF may be
merged. Note, if necessary, port based capability reporting may
constrain logical use of ports for classification or pure forwarding.
Ports incapable of any match rule processing revert to port based
forwarding.
Figure 3 shows a virtual data plane where Classifications and SFF of
Figure 2 are combined into a single DP node abstraction.
Szabo & Sonkoly Expires September 22, 2016 [Page 5]
Internet-DrafSFC Control Plane Experiment: UNIFYed Approach March 2016
+----------------------------------------------------+
| |
| SFC Control Plane C2 |
| C3 | C3|
| \|/ |
+------------------------------------------------+---+
|
|
+---+ +---+ +---+ |
| S | | S | | S | |
| F +--+ +--+ F | | F +--+ |
| 1 | | | | 2 | | 3 | | |
+---+ | | +---+ +---+ | |
| | | | | | | | |
+-----a-b---C------C---d-e-----f----C-------+ |
| | | '......'.. | |..../.\...'...... | |
->[1---->+ +->----------->+ +->-+ \ '3]--+
| \--->----\|
<-[2-----<-----------------<-------------<-----4]->C4
| SFC Classifier + SFF + SFC Proxy |
+-------------------------------------------+
Figure 3: SFC Control Plane: Overview
But there must exist a control component who is responsible for
instantiating the SFs (VNFs).
Szabo & Sonkoly Expires September 22, 2016 [Page 6]
Internet-DrafSFC Control Plane Experiment: UNIFYed Approach March 2016
+----------------------------------------------------+
| +---+
| SFC Control Plane C2 | |
| C3 | C3| |
| \|/ | |
+------------------------------------------------+---+ |
. |
. |
+---+ +---+ +---+ . |C
| S | | S | | S | . |O
| F +--+ +--+ F | | F +--+ . |O
| 1 | | | | 2 | | 3 | | . |R
+---+ | | +---+ +---+ | . |D
| | | | | | | | . |I
+-----a-b---C------C---d-e-----f----C-------+ . |N
| | | '......'.. | |..../.\...'...... | . |A
SFP->[1---->+ +->----------->+ +->-+ \ '3]...SFPc |T
| \--->----\| . |I
<-[2-----<-----------------<-------------<-----4]---->C4 |O
| SFC Classifier + SFF + SFC Proxy | . |N
+-------------------------------------------+ . |
. |
. |
. |
+------------------------------------------------+---+ |
| NFV Orchestrator /| | |
| | | |
| Virtualized Infrastructure Manager / +---+
| |
+----------------------------------------------------+
... - SFP for the Control Plane/C3
--- - SFP for the Tenant Data Plane
Figure 4: SFC Controller with NFV Orchestrator
We combined the SFC Control Plane with the NFV Orchestrator and the
Virtualized Infrastructure Manager (VIM) into a Joint NFV and SFC
Control API. The combined control (VNF and SFC) together with the
virtualized data plane creates a single Big Switch with Big Software
(BiS-BiS) data and control plane abstraction (see Figure 5.
Szabo & Sonkoly Expires September 22, 2016 [Page 7]
Internet-DrafSFC Control Plane Experiment: UNIFYed Approach March 2016
Joint NFV and SFC Control API
| U
|
+---------|-----------------------------------------+
| +-----+-------------------------------------+ |
| | | |
| | SFC Control Plane | |
| | NFV Orchestrator | |
| | Virtualized Infrastructure Manager | |
| +----------------------------------------+--+ |
| . |
| ' |
| +---+ +---+ +---+ ' |
| | S | | S | | S | ' |
| | F +--+ +--+ F | | F +--+ ' |
| | 1 | | | | 2 | | 3 | | ' |
| +---+ | | +---+ +---+ | .|
| | | | | | | | | .|
| +-----a-b---C------C---d-e-----f----C-------+ .|
| | | | '......'.. | |..../.\...'...... | .|
[1--[1---->+ +->----------->+ +->-+ \ '3]..|
| | \--->----\| |
[2--[2-----<-----------------<-------------<-----4]--4]
| | SFC Classifier + SFF + SFC Proxy | |
| +-------------------------------------------+ |
| |
+---------------------------------------------------+
Big Switch with
Big Software (BiS-BiS)
Data and Control Plane Abstraction
Figure 5: Joint Data and Control Plane Abstraction for NFV and SFC
Any technology/administration/ownership domains may consist of an
arbitrary topology of BiS-BiS virtualized data and control plane
nodes. There exists an NFV and SFC data and control plane
abstraction over which control entities can be recursively connected
into a hierarchy [I-D.unify-nfvrg-recursive-programming]. An example
control plane structure hierarchy is shown in Figure 6, where the "U"
denotes the recurring joint abstraction control interface.
Szabo & Sonkoly Expires September 22, 2016 [Page 8]
Internet-DrafSFC Control Plane Experiment: UNIFYed Approach March 2016
+---------+
|Service |
|Orchestr.|
+---------+
|
V U
+-------------------+
| NFV&SFC |
| Control |
+-------------------+
/ | \
/ V U \
| +---------+ |
U V | NFV&SFC | V U
+---------+ | Control | +---------+
| NFV&SFC | +---------+ | NFV&SFC |
| Control | / | \ | Control |
+---------+ +--- V ----+ +---------+
| | +----+ | |
| | |BiS.| | |
V | +----+ | V
+----+ V / . \ V +----+
1 |BiS | +----+ . +----+ |BiS | 8
o--|BiS |----|BiS |------|BiS |----|BiS |--o
+----+ |BiS | . |BiS | +----+
. +----+ . +----+ .
. . . . .
SFC1 ->-SF1-------SF2----SF3------------SF4-->-o
SFC2 ->------------------------SFa----------->-o
[--domain1-][------domain2-------][-domain3--]
Figure 6: Recurring NFV and SFC Control Plane
5. Experimental Network Scenario
Figure 7 shows our network scenario with two layers of SFC
Controllers corresponding to the technology domains and the
overarching SFC Controller.
The Mininet SDN and Click Execution Environment (EE) domain contains
four OVS switches with two Click EEs attached to two of the four OVS
switches. A host emulation is also attached to one of the OVS
switches. There is an inter-domain link connecting one of the OVS
switch to the Transport SDN Domain.
The transport SDN domain consists of two MikroTik RB2011Ui HW
OpenFlow switches and is controller by a POX controller integrated
within the overarching SFC Controller.
Szabo & Sonkoly Expires September 22, 2016 [Page 9]
Internet-DrafSFC Control Plane Experiment: UNIFYed Approach March 2016
The OpenStack domain is a vanilla OpenStack release with an OVS
switch converting L2 steering to VxLAN connections to the Virtual
Machines (VMs) running in the compute nodes.
The Docker host is extended with SFF forwarding, i.e., it natively
encapsulates/decapsulates frames received over its data plane
connection to and from the hosted containers.
In the example SFC request, a L3 Host is connected to a L3 WebServer
in the forward direction and in the backward path a deep packet
inspection (DPI), a sniffer, a header compressor (HC) and a header
de-compressor (HDC) are inserted into the SFC as bump-in-the-wire
(middlebox) SFs. (See Figure 7).
The SFC request to the infrastructure mapping is dynamic and is based
on i) compute, storage and networking resource availabilities and
capabilities; ii) constraints contained within the SFC request (e.g.,
latency, bandwidth, memory, etc. requirements) and iii) operational
policies (e.g., utilization, energy efficiency, etc.)
The SFC example mapping shown in Figure 7 are: WebServer and DPI ->
OpenStack; sniffer -> Docker; HC and HDC -> Mininet. The example is
built incrementally by extending the Host -- WebServer connection by
an additional SF in each step.
Szabo & Sonkoly Expires September 22, 2016 [Page 10]
Internet-DrafSFC Control Plane Experiment: UNIFYed Approach March 2016
Tenant
:
+---------+
|SFC&NFV |
|Ctrller G|
|Global |
+---------+
......' : : '.....................
U . : '...........U :U
+---------+ : +---------+ +---------+
|SFC&NFV | : |SFC&NFV | |SFC&NFV |
|Ctrller M| : |Ctrller D| |Ctrller O|
|Mininet | : |Docker | |OpenStack|
+---------+ : +---------+ +---------+
: : : :
: : : +---------+
: : : |OpenStack|
+---------+ +---------+ : |based |
|Mininet | |Transport|-#----------------|Cloud |
|SDN |-#-|SDN | +----:----+ +---------+
|Click EE | |Domain |-#--|Docker |
+---------+ +---------+ |Host |
| |
# ENNI reference points +---------+
SFC:
H1--->--------------------->----------------------+WebSrv
'-HDC--HC---------------<-------Sniffer------DPI-'
Host2<------------'
Figure 7: Experimental Network Scenario
5.1. SFC Control Interfaces
5.1.1. C1/C2 Interfaces
Since C1/C2 interfaces are combined in our design, it is situational,
which one is in use. For example, the classification and the SFP
encapsulation of the Host's traffic into the SFC is requested for the
Host's attachment point by Controller G to Controller M. Controller
M in turn, determines where such classification can happen and maps
the request to a network element, where the classification can be
executed. For example, if a complex classification is not supported
at the attachment point, then a port based forwarding is configured
to convey all the Host's traffic to a classification port. In our
case, the classification is executed at the Host's attachment port
and an SFP encapsulation is assigned.
Szabo & Sonkoly Expires September 22, 2016 [Page 11]
Internet-DrafSFC Control Plane Experiment: UNIFYed Approach March 2016
The SFP encapsulation, however, is split according to the
Controllers' responsibility domains. While Controller G is
responsible the encapsulation for External Network Network Interfaces
(ENNI) between the different domains, domain Controllers M, D, O are
responsible for the SFP mapping between their ingress an egress
points.
The ENNI encapsulations are technology specific as alignment between
multiple domains must be achieved. Such domain specific parameters
(e.g., supported transport layer encapsulations) are part of the
domain virtualizations shown to the higher layer control entity.
5.1.2. C3 Interface
We use the C3 interface to configure SFs, which must be SFF aware.
The VMs within the OpenStack domain must terminate/initiate L2 in L3
tunnels, in our case VxLAN tunnels.
In the case when SFs are instantiated on demand (part of an NFV
orchestration together with SFC configuration), then the SF to SFC
Controller connection must also be established on-demand. This,
however, - as one can observer - is no way different compared to SFP
connecting two or more SFs; one situationally being the SFC
Controller itself. Therefore, the control or data plane usage of an
SFC is situational; in a fully dynamic environment they boil down to
the same configuration mechanisms.
Interestingly, conveying SFF forwarding configuration to SFs may
happen via various platform services. In our case, when we only used
the SF's C3 interface to configure the VxLAN endpoints, we used
OpenStack to VM metadata communication services with an agent in the
VM pulling VxLAN configuration data.
However, if a direct C3 control interface is needed between the SF
and the SFC Controller then a corresponding SFC must be established.
6. Gap Analysis
6.1. SFC Requirements
6.1.1. General requirements
We assess the requirements of [I-D.ietf-sfc-control-plane] one by
one:
"Some deployments require that forwarding within an SFC-enabled
domain must be allowed even if no control protocols are enabled.
Static configuration must be allowed."
Szabo & Sonkoly Expires September 22, 2016 [Page 12]
Internet-DrafSFC Control Plane Experiment: UNIFYed Approach March 2016
o No specific considerations; both the SFs can be Physical Network
Functions (PNFs) or pre-instantiated VNFs; the forwarding
configuration may be statically configured.
"A permanent association between an SFC data plane element with a
Control Element must not be required; (...)"
o No special considerations; both SFs and the forwarding overlay
works according to their configurations if connection to the
control entity is lost.
6.1.2. SFC Control Plane Bootstrapping
"The interface that is used to feed the SFC control plane with
service objectives and guidelines is not part of the SFC control
plane itself. (...)"
"Locators for classifiers/SFF/SFs/SFC proxies, etc."
o In the proposed domain abstraction only classifiers/SFF/SFC
proxies are visible for the SFC Controller (the rest is not of the
concern of the SFC Control, hence are hidden); therefore, the
logical locators for the classifiers/SFF/SFC proxies are
inherently known
o SFs are instantiated by the NFVO logic co-existing with the SFC
controller. Therefore, the combined Control Plane inherently
knows the location of all SFs.
"SFs serviced by each SFF"
o This is the control plane association; hence inherently exists.
"A list of service function chains, including how they are structured
and unambiguously identified."
o The structure of SFC is created within the SFC Control Plane,
hence it inherently exists there.
Status of each SFC: active/pre-deployment phase/etc.(...)"
o In the experimental implementation these states are internal to
the Control Plane and they do not exist below the SFC Controller.
This is because an SFC Controller configures the underlying
virtual data plane instead of communicating with SFC intents.
However, there may exist various configuration targets in the
could be running, candidate, initial, etc. or other configuration
Szabo & Sonkoly Expires September 22, 2016 [Page 13]
Internet-DrafSFC Control Plane Experiment: UNIFYed Approach March 2016
targets may exist, however, those are independent generic
configuration targets.
"A list of classification guidelines and/or rules to bind flows to
SFCs/SFPs."
o In our view, all these parameters are input to the SFC Controller
and are part of the SFC request. As such, the goal of the SFC
Controller is to map such northbound requests to its southbound
interfaces. All the requests, the mapping and the southbound
outputs are inherently stored.
"Optionally, (traffic/CPU/memory) load balancing objectives at the
SFC level or on a per node (e.g., per-SF/SFF/SFP proxy) basis."
o In our design, the northbound to southbound mapping algorithm
takes into account these objectives as part of the operational
policies or explicit tenant requirements contained in the SFC
request. It is important to note, that such requirements are
service agnostic.
"Security credentials."
o In our design, each tenant has its own SFC Control plane interface
with its full context (policy, access, accounting, security,
etc.). Our SFC API is build over the NETCONF protocol [RFC6241]
relying on a secure transport layer.
"Context information that needs to be shared on a per SFC basis."
o We maintain per tenant context; individual SFCs are situational
with this respect as a tenant may merge/split SFCs any time. The
SFC Controller builds configuration request for the underlying
layers aggregating all of its tenants' request, therefore SFCs are
always scoped to control API and does not travel individually
through the vertical SFC control plane layers.
7. Open Questions
o What is the rationale behind the separation of the SF placement
and the SFC Control Plane (traffic steering) if the SFC Control
Plane needs to know the locators of the SF? In a dynamic
environment, when SFs are deployed as VNFs, can a joint
consideration of software and networking resources result in
better deployments?
o What is the rationale behind the coupling of the Service Path
Header with the Context Headers? Can the Service Path Header
Szabo & Sonkoly Expires September 22, 2016 [Page 14]
Internet-DrafSFC Control Plane Experiment: UNIFYed Approach March 2016
stripped from the encapsulation before sending it the SF? Is the
Context Header service specific? If separated, can the Service
Path Header be encoded into the forwarding behavior of the domain
and yield all SFs SFP (overlay) unaware?
8. IANA Considerations
This memo includes no request to IANA.
9. Security Considerations
TBD
10. Acknowledgement
The research leading to these results has received funding from the
European Union Seventh Framework Programme (FP7/2007-2013) under
grant agreement no. 619609 - the UNIFY project. The views expressed
here are those of the authors only. The European Commission is not
liable for any use that may be made of the information in this
document.
11. Informative References
[I-D.ietf-sfc-control-plane]
Li, H., Wu, Q., Huang, O., Boucadair, M., Jacquenet, C.,
Haeffner, W., Lee, S., Parker, R., Dunbar, L., Malis, A.,
Halpern, J., Reddy, T., and P. Patil, "Service Function
Chaining (SFC) Control Plane Components & Requirements",
draft-ietf-sfc-control-plane-03 (work in progress),
January 2016.
[I-D.unify-nfvrg-challenges]
Szabo, R., Csaszar, A., Pentikousis, K., Kind, M., Daino,
D., Qiang, Z., and H. Woesner, "Unifying Carrier and Cloud
Networks: Problem Statement and Challenges", draft-unify-
nfvrg-challenges-03 (work in progress), January 2016.
[I-D.unify-nfvrg-recursive-programming]
Szabo, R., Qiang, Z., and M. Kind, "Towards recursive
virtualization and programming for network and cloud
resources", draft-unify-nfvrg-recursive-programming-02
(work in progress), October 2015.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<http://www.rfc-editor.org/info/rfc6241>.
Szabo & Sonkoly Expires September 22, 2016 [Page 15]
Internet-DrafSFC Control Plane Experiment: UNIFYed Approach March 2016
[RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for
Service Function Chaining", RFC 7498,
DOI 10.17487/RFC7498, April 2015,
<http://www.rfc-editor.org/info/rfc7498>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015,
<http://www.rfc-editor.org/info/rfc7665>.
[UNIFY-GLOBECOM]
Sonkoly, B., Szabo, R., Jocha, D., Czentye, J., Kind, M.,
and F-J. Westphal, "UNIFYing Cloud and Carrier Network
Resources: An Architectural View", Proc. IEEE GLOBECOM
2015, San Diego, CA, USA GLOBECOM, December 2015.
Authors' Addresses
Robert Szabo
Ericsson Research, Hungary
Irinyi Jozsef u. 4-20
Budapest 1117
Hungary
Email: robert.szabo@ericsson.com
URI: http://www.ericsson.com/
Balazs Sonkoly
Budapest University of Technology and Economics
Magyar tudosok krt. 2
Budapest 1111
Hungary
Email: sonkoly@tmit.bme.hu
URI: http://www.tmit.bme.hu/
Szabo & Sonkoly Expires September 22, 2016 [Page 16]
