idnits 2.17.1 draft-unify-sfc-control-plane-exp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 21, 2016) is 2930 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '--domain1-' is mentioned on line 341, but not defined == Missing Reference: '------domain2-------' is mentioned on line 341, but not defined == Missing Reference: '-domain3--' is mentioned on line 341, but not defined == Outdated reference: A later version (-08) exists of draft-ietf-sfc-control-plane-03 == Outdated reference: A later version (-04) exists of draft-unify-nfvrg-challenges-03 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SFC R. Szabo 3 Internet-Draft Ericsson 4 Intended status: Informational B. Sonkoly 5 Expires: September 22, 2016 BME 6 March 21, 2016 8 A Multi-Domain Multi-Technology SFC Control Plane Experiment: A UNIFYed 9 Approach 10 draft-unify-sfc-control-plane-exp-00 12 Abstract 14 This document reports on the experimentation with a combined Network 15 Function Virtualization (NFV) orchestrator and Service Function Chain 16 (SFC) Control Plane proof of concept prototype. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on September 22, 2016. 35 Copyright Notice 37 Copyright (c) 2016 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 2 54 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 4. SFC Control Plane: An Experimental Design . . . . . . . . . . 3 56 5. Experimental Network Scenario . . . . . . . . . . . . . . . . 9 57 5.1. SFC Control Interfaces . . . . . . . . . . . . . . . . . . 11 58 5.1.1. C1/C2 Interfaces . . . . . . . . . . . . . . . . . . . . 11 59 5.1.2. C3 Interface . . . . . . . . . . . . . . . . . . . . . . 12 60 6. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 12 61 6.1. SFC Requirements . . . . . . . . . . . . . . . . . . . . . 12 62 6.1.1. General requirements . . . . . . . . . . . . . . . . . . 12 63 6.1.2. SFC Control Plane Bootstrapping . . . . . . . . . . . . . 13 64 7. Open Questions . . . . . . . . . . . . . . . . . . . . . . . 14 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 66 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 67 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 15 68 11. Informative References . . . . . . . . . . . . . . . . . . . 15 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 71 1. Introduction 73 The goal of this report is to provide an insight into a Service 74 Function Chain (SFC) control and Network Function Virtualization 75 (NFV) orchestration proof of concept implementation and 76 experimentation in multi-domain/technology environments. 78 The reported concept is based on the EU-FP7 UNIFY project's approach 79 [I-D.unify-nfvrg-challenges], [UNIFY-GLOBECOM], which defines joint 80 compute and network virtualization and control interfaces 81 [I-D.unify-nfvrg-recursive-programming]. 83 The rest of the document is structured as follows: In Section 2 we 84 define the related terminology, which is followed with the listing of 85 our assumptions in Section 3. In Section 4 we derive our design from 86 the SFC Control Plane framework. In Section 5 we outline our 87 experimental network scenario. In Section 6 we analyze the gaps 88 between our experimental design and the SFC Control Plane. Finally, 89 in Section 7 we formulate some questions to the community based on 90 our learnings. 92 2. Terms and Definitions 94 The reader should be familiar with the terms defined in [RFC7498] and 95 [RFC7665]. 97 3. Assumptions 99 We assume a Network Function Virtualization (NFV) environment, where 100 Service Functions (SF) of a SFC will map as Virtualized Network 101 Functions (VNFs). 103 We assume that both Classification and Service Function Forwarding 104 (SFF) behavior can be expressed by SDN forwarding rules (match rules 105 and actions); if a Classification or a SFF cannot be mapped to match 106 and action pairs, then a corresponding control plane SF (VNF) is 107 instantiated to analyze and tag the flows into SFP. (This is not 108 different than an SF being SFC aware.) 110 We assume the existence of multiple SFC domains as a result of 111 technology, administration or ownership considerations. 113 We assume that a boundary node can act as ingress/egress for Service 114 Function Paths entering/leaving the SFC domain. 116 We assume dynamic establishment of SFC; static configuration is not 117 considered in this document. 119 4. SFC Control Plane: An Experimental Design 121 We start with the reference architecture of 122 [I-D.ietf-sfc-control-plane]: 124 +----------------------------------------------+ 125 | | 126 | SFC Control Plane | 127 +-------| | 128 | | | 129 C1 +------^-----------^-------------^-------------+ 130 +---------------------|C3---------|-------------|-------------+ 131 | | +----+ | | | 132 | | |SF1 | |C2 |C2 | 133 | | +----+ | | | 134 | +----V--- --+ | | | | 135 | | SFC | +----+ +-|--+ +----+ | 136 | |Classifier |---->|SFF1|----->|SFF2|------->|SFF3| | 137 | | Node A |<----| |<-----| |<-------| | | 138 | +-----------+ +----+ +----+ +----+ | 139 | | | | | 140 | |C2 ------- | | 141 | | | | +-----------+ C4 | 142 | V +----+ +----+ | SFC Proxy |--> | 143 | |SF2 | |SF3 | +-----------+ | 144 | +----+ +----+ | 145 | |C3 |C3 | 146 | SFC Data Plane Components V V | 147 +-------------------------------------------------------------+ 149 Figure 1: SFC Control Plane: Overview 151 Let's map the above architecture to Logical Data Plane Components, 152 where classification / forwarding is controlled by SDN forwarding 153 behavior control over interface "C" consumed by SFC Controller's C1 154 and C2 (see Figure 2). 156 +----------------------------------------------+ 157 | | 158 | SFC Control Plane | 159 +---|C1 | 160 | | C3 C2 C3 C3 C2 C2 | 161 | +-------+----+-----------+------+---+-------+--+ 162 | | | | | | | 163 | |C3 | |C3 |C3 | | 164 | +---+ | +---+ +---+ | | 165 | | S | | | S | | S | | | 166 | | F | | | F | | F | | | 167 | | 1 | | | 2 | | 3 | | | 168 | +---+ | +---+ +---+ | | 169 | | | | | | | | | 170 +----C--+ +--a-b---C+ +--a-b-----d---C+ +-C-------+ 171 | | | | | | | | | / \ | | | 172 [1------>3]->[1->+ +->--3]<-->[1->+ +->-+ +--3]->[1------\ 3] 173 | | | /| |\ | | \ | 174 [2<------4]<-[2--<----/ 4]<---[2 \-<-----------4]<-[2<------- 4]->C4 175 | | | SFF1 | | SFF2 | | SFF3 | 176 +-------+ +---------+ +---------------+ +---------+ 177 SFC Class Proxy 178 Node A 180 Figure 2: SFC Control Plane with Virtual Data Plane Elements 182 If we consider an NFV environment, where SFs are instantiated on 183 demand as VNF instances, then the SFC Controller's C3 interfaces to 184 SFs map to data plane links, which are situationally used for control 185 plane communication. Such DP configuration is by no means different 186 from an SFP. 188 However, from SDN forwarding control point of view, traffic 189 classification or forwarding is again situational. Classification 190 may encapsulate (label) flows based on given match criteria with 191 respect to different protocol headers, while forwarding may simply 192 based on matching on the SFC encapsulation labels. Therefore, in a 193 virtual data plane component SFC classification and SFF may be 194 merged. Note, if necessary, port based capability reporting may 195 constrain logical use of ports for classification or pure forwarding. 196 Ports incapable of any match rule processing revert to port based 197 forwarding. 199 Figure 3 shows a virtual data plane where Classifications and SFF of 200 Figure 2 are combined into a single DP node abstraction. 202 +----------------------------------------------------+ 203 | | 204 | SFC Control Plane C2 | 205 | C3 | C3| 206 | \|/ | 207 +------------------------------------------------+---+ 208 | 209 | 210 +---+ +---+ +---+ | 211 | S | | S | | S | | 212 | F +--+ +--+ F | | F +--+ | 213 | 1 | | | | 2 | | 3 | | | 214 +---+ | | +---+ +---+ | | 215 | | | | | | | | | 216 +-----a-b---C------C---d-e-----f----C-------+ | 217 | | | '......'.. | |..../.\...'...... | | 218 ->[1---->+ +->----------->+ +->-+ \ '3]--+ 219 | \--->----\| 220 <-[2-----<-----------------<-------------<-----4]->C4 221 | SFC Classifier + SFF + SFC Proxy | 222 +-------------------------------------------+ 224 Figure 3: SFC Control Plane: Overview 226 But there must exist a control component who is responsible for 227 instantiating the SFs (VNFs). 229 +----------------------------------------------------+ 230 | +---+ 231 | SFC Control Plane C2 | | 232 | C3 | C3| | 233 | \|/ | | 234 +------------------------------------------------+---+ | 235 . | 236 . | 237 +---+ +---+ +---+ . |C 238 | S | | S | | S | . |O 239 | F +--+ +--+ F | | F +--+ . |O 240 | 1 | | | | 2 | | 3 | | . |R 241 +---+ | | +---+ +---+ | . |D 242 | | | | | | | | . |I 243 +-----a-b---C------C---d-e-----f----C-------+ . |N 244 | | | '......'.. | |..../.\...'...... | . |A 245 SFP->[1---->+ +->----------->+ +->-+ \ '3]...SFPc |T 246 | \--->----\| . |I 247 <-[2-----<-----------------<-------------<-----4]---->C4 |O 248 | SFC Classifier + SFF + SFC Proxy | . |N 249 +-------------------------------------------+ . | 250 . | 251 . | 252 . | 253 +------------------------------------------------+---+ | 254 | NFV Orchestrator /| | | 255 | | | | 256 | Virtualized Infrastructure Manager / +---+ 257 | | 258 +----------------------------------------------------+ 260 ... - SFP for the Control Plane/C3 261 --- - SFP for the Tenant Data Plane 263 Figure 4: SFC Controller with NFV Orchestrator 265 We combined the SFC Control Plane with the NFV Orchestrator and the 266 Virtualized Infrastructure Manager (VIM) into a Joint NFV and SFC 267 Control API. The combined control (VNF and SFC) together with the 268 virtualized data plane creates a single Big Switch with Big Software 269 (BiS-BiS) data and control plane abstraction (see Figure 5. 271 Joint NFV and SFC Control API 272 | U 273 | 274 +---------|-----------------------------------------+ 275 | +-----+-------------------------------------+ | 276 | | | | 277 | | SFC Control Plane | | 278 | | NFV Orchestrator | | 279 | | Virtualized Infrastructure Manager | | 280 | +----------------------------------------+--+ | 281 | . | 282 | ' | 283 | +---+ +---+ +---+ ' | 284 | | S | | S | | S | ' | 285 | | F +--+ +--+ F | | F +--+ ' | 286 | | 1 | | | | 2 | | 3 | | ' | 287 | +---+ | | +---+ +---+ | .| 288 | | | | | | | | | .| 289 | +-----a-b---C------C---d-e-----f----C-------+ .| 290 | | | | '......'.. | |..../.\...'...... | .| 291 [1--[1---->+ +->----------->+ +->-+ \ '3]..| 292 | | \--->----\| | 293 [2--[2-----<-----------------<-------------<-----4]--4] 294 | | SFC Classifier + SFF + SFC Proxy | | 295 | +-------------------------------------------+ | 296 | | 297 +---------------------------------------------------+ 298 Big Switch with 299 Big Software (BiS-BiS) 300 Data and Control Plane Abstraction 302 Figure 5: Joint Data and Control Plane Abstraction for NFV and SFC 304 Any technology/administration/ownership domains may consist of an 305 arbitrary topology of BiS-BiS virtualized data and control plane 306 nodes. There exists an NFV and SFC data and control plane 307 abstraction over which control entities can be recursively connected 308 into a hierarchy [I-D.unify-nfvrg-recursive-programming]. An example 309 control plane structure hierarchy is shown in Figure 6, where the "U" 310 denotes the recurring joint abstraction control interface. 312 +---------+ 313 |Service | 314 |Orchestr.| 315 +---------+ 316 | 317 V U 318 +-------------------+ 319 | NFV&SFC | 320 | Control | 321 +-------------------+ 322 / | \ 323 / V U \ 324 | +---------+ | 325 U V | NFV&SFC | V U 326 +---------+ | Control | +---------+ 327 | NFV&SFC | +---------+ | NFV&SFC | 328 | Control | / | \ | Control | 329 +---------+ +--- V ----+ +---------+ 330 | | +----+ | | 331 | | |BiS.| | | 332 V | +----+ | V 333 +----+ V / . \ V +----+ 334 1 |BiS | +----+ . +----+ |BiS | 8 335 o--|BiS |----|BiS |------|BiS |----|BiS |--o 336 +----+ |BiS | . |BiS | +----+ 337 . +----+ . +----+ . 338 . . . . . 339 SFC1 ->-SF1-------SF2----SF3------------SF4-->-o 340 SFC2 ->------------------------SFa----------->-o 341 [--domain1-][------domain2-------][-domain3--] 343 Figure 6: Recurring NFV and SFC Control Plane 345 5. Experimental Network Scenario 347 Figure 7 shows our network scenario with two layers of SFC 348 Controllers corresponding to the technology domains and the 349 overarching SFC Controller. 351 The Mininet SDN and Click Execution Environment (EE) domain contains 352 four OVS switches with two Click EEs attached to two of the four OVS 353 switches. A host emulation is also attached to one of the OVS 354 switches. There is an inter-domain link connecting one of the OVS 355 switch to the Transport SDN Domain. 357 The transport SDN domain consists of two MikroTik RB2011Ui HW 358 OpenFlow switches and is controller by a POX controller integrated 359 within the overarching SFC Controller. 361 The OpenStack domain is a vanilla OpenStack release with an OVS 362 switch converting L2 steering to VxLAN connections to the Virtual 363 Machines (VMs) running in the compute nodes. 365 The Docker host is extended with SFF forwarding, i.e., it natively 366 encapsulates/decapsulates frames received over its data plane 367 connection to and from the hosted containers. 369 In the example SFC request, a L3 Host is connected to a L3 WebServer 370 in the forward direction and in the backward path a deep packet 371 inspection (DPI), a sniffer, a header compressor (HC) and a header 372 de-compressor (HDC) are inserted into the SFC as bump-in-the-wire 373 (middlebox) SFs. (See Figure 7). 375 The SFC request to the infrastructure mapping is dynamic and is based 376 on i) compute, storage and networking resource availabilities and 377 capabilities; ii) constraints contained within the SFC request (e.g., 378 latency, bandwidth, memory, etc. requirements) and iii) operational 379 policies (e.g., utilization, energy efficiency, etc.) 381 The SFC example mapping shown in Figure 7 are: WebServer and DPI -> 382 OpenStack; sniffer -> Docker; HC and HDC -> Mininet. The example is 383 built incrementally by extending the Host -- WebServer connection by 384 an additional SF in each step. 386 Tenant 387 : 388 +---------+ 389 |SFC&NFV | 390 |Ctrller G| 391 |Global | 392 +---------+ 393 ......' : : '..................... 394 U . : '...........U :U 395 +---------+ : +---------+ +---------+ 396 |SFC&NFV | : |SFC&NFV | |SFC&NFV | 397 |Ctrller M| : |Ctrller D| |Ctrller O| 398 |Mininet | : |Docker | |OpenStack| 399 +---------+ : +---------+ +---------+ 400 : : : : 401 : : : +---------+ 402 : : : |OpenStack| 403 +---------+ +---------+ : |based | 404 |Mininet | |Transport|-#----------------|Cloud | 405 |SDN |-#-|SDN | +----:----+ +---------+ 406 |Click EE | |Domain |-#--|Docker | 407 +---------+ +---------+ |Host | 408 | | 409 # ENNI reference points +---------+ 411 SFC: 412 H1--->--------------------->----------------------+WebSrv 413 '-HDC--HC---------------<-------Sniffer------DPI-' 414 Host2<------------' 416 Figure 7: Experimental Network Scenario 418 5.1. SFC Control Interfaces 420 5.1.1. C1/C2 Interfaces 422 Since C1/C2 interfaces are combined in our design, it is situational, 423 which one is in use. For example, the classification and the SFP 424 encapsulation of the Host's traffic into the SFC is requested for the 425 Host's attachment point by Controller G to Controller M. Controller 426 M in turn, determines where such classification can happen and maps 427 the request to a network element, where the classification can be 428 executed. For example, if a complex classification is not supported 429 at the attachment point, then a port based forwarding is configured 430 to convey all the Host's traffic to a classification port. In our 431 case, the classification is executed at the Host's attachment port 432 and an SFP encapsulation is assigned. 434 The SFP encapsulation, however, is split according to the 435 Controllers' responsibility domains. While Controller G is 436 responsible the encapsulation for External Network Network Interfaces 437 (ENNI) between the different domains, domain Controllers M, D, O are 438 responsible for the SFP mapping between their ingress an egress 439 points. 441 The ENNI encapsulations are technology specific as alignment between 442 multiple domains must be achieved. Such domain specific parameters 443 (e.g., supported transport layer encapsulations) are part of the 444 domain virtualizations shown to the higher layer control entity. 446 5.1.2. C3 Interface 448 We use the C3 interface to configure SFs, which must be SFF aware. 449 The VMs within the OpenStack domain must terminate/initiate L2 in L3 450 tunnels, in our case VxLAN tunnels. 452 In the case when SFs are instantiated on demand (part of an NFV 453 orchestration together with SFC configuration), then the SF to SFC 454 Controller connection must also be established on-demand. This, 455 however, - as one can observer - is no way different compared to SFP 456 connecting two or more SFs; one situationally being the SFC 457 Controller itself. Therefore, the control or data plane usage of an 458 SFC is situational; in a fully dynamic environment they boil down to 459 the same configuration mechanisms. 461 Interestingly, conveying SFF forwarding configuration to SFs may 462 happen via various platform services. In our case, when we only used 463 the SF's C3 interface to configure the VxLAN endpoints, we used 464 OpenStack to VM metadata communication services with an agent in the 465 VM pulling VxLAN configuration data. 467 However, if a direct C3 control interface is needed between the SF 468 and the SFC Controller then a corresponding SFC must be established. 470 6. Gap Analysis 472 6.1. SFC Requirements 474 6.1.1. General requirements 476 We assess the requirements of [I-D.ietf-sfc-control-plane] one by 477 one: 479 "Some deployments require that forwarding within an SFC-enabled 480 domain must be allowed even if no control protocols are enabled. 481 Static configuration must be allowed." 482 o No specific considerations; both the SFs can be Physical Network 483 Functions (PNFs) or pre-instantiated VNFs; the forwarding 484 configuration may be statically configured. 486 "A permanent association between an SFC data plane element with a 487 Control Element must not be required; (...)" 489 o No special considerations; both SFs and the forwarding overlay 490 works according to their configurations if connection to the 491 control entity is lost. 493 6.1.2. SFC Control Plane Bootstrapping 495 "The interface that is used to feed the SFC control plane with 496 service objectives and guidelines is not part of the SFC control 497 plane itself. (...)" 499 "Locators for classifiers/SFF/SFs/SFC proxies, etc." 501 o In the proposed domain abstraction only classifiers/SFF/SFC 502 proxies are visible for the SFC Controller (the rest is not of the 503 concern of the SFC Control, hence are hidden); therefore, the 504 logical locators for the classifiers/SFF/SFC proxies are 505 inherently known 507 o SFs are instantiated by the NFVO logic co-existing with the SFC 508 controller. Therefore, the combined Control Plane inherently 509 knows the location of all SFs. 511 "SFs serviced by each SFF" 513 o This is the control plane association; hence inherently exists. 515 "A list of service function chains, including how they are structured 516 and unambiguously identified." 518 o The structure of SFC is created within the SFC Control Plane, 519 hence it inherently exists there. 521 Status of each SFC: active/pre-deployment phase/etc.(...)" 523 o In the experimental implementation these states are internal to 524 the Control Plane and they do not exist below the SFC Controller. 525 This is because an SFC Controller configures the underlying 526 virtual data plane instead of communicating with SFC intents. 527 However, there may exist various configuration targets in the 528 could be running, candidate, initial, etc. or other configuration 529 targets may exist, however, those are independent generic 530 configuration targets. 532 "A list of classification guidelines and/or rules to bind flows to 533 SFCs/SFPs." 535 o In our view, all these parameters are input to the SFC Controller 536 and are part of the SFC request. As such, the goal of the SFC 537 Controller is to map such northbound requests to its southbound 538 interfaces. All the requests, the mapping and the southbound 539 outputs are inherently stored. 541 "Optionally, (traffic/CPU/memory) load balancing objectives at the 542 SFC level or on a per node (e.g., per-SF/SFF/SFP proxy) basis." 544 o In our design, the northbound to southbound mapping algorithm 545 takes into account these objectives as part of the operational 546 policies or explicit tenant requirements contained in the SFC 547 request. It is important to note, that such requirements are 548 service agnostic. 550 "Security credentials." 552 o In our design, each tenant has its own SFC Control plane interface 553 with its full context (policy, access, accounting, security, 554 etc.). Our SFC API is build over the NETCONF protocol [RFC6241] 555 relying on a secure transport layer. 557 "Context information that needs to be shared on a per SFC basis." 559 o We maintain per tenant context; individual SFCs are situational 560 with this respect as a tenant may merge/split SFCs any time. The 561 SFC Controller builds configuration request for the underlying 562 layers aggregating all of its tenants' request, therefore SFCs are 563 always scoped to control API and does not travel individually 564 through the vertical SFC control plane layers. 566 7. Open Questions 568 o What is the rationale behind the separation of the SF placement 569 and the SFC Control Plane (traffic steering) if the SFC Control 570 Plane needs to know the locators of the SF? In a dynamic 571 environment, when SFs are deployed as VNFs, can a joint 572 consideration of software and networking resources result in 573 better deployments? 575 o What is the rationale behind the coupling of the Service Path 576 Header with the Context Headers? Can the Service Path Header 577 stripped from the encapsulation before sending it the SF? Is the 578 Context Header service specific? If separated, can the Service 579 Path Header be encoded into the forwarding behavior of the domain 580 and yield all SFs SFP (overlay) unaware? 582 8. IANA Considerations 584 This memo includes no request to IANA. 586 9. Security Considerations 588 TBD 590 10. Acknowledgement 592 The research leading to these results has received funding from the 593 European Union Seventh Framework Programme (FP7/2007-2013) under 594 grant agreement no. 619609 - the UNIFY project. The views expressed 595 here are those of the authors only. The European Commission is not 596 liable for any use that may be made of the information in this 597 document. 599 11. Informative References 601 [I-D.ietf-sfc-control-plane] 602 Li, H., Wu, Q., Huang, O., Boucadair, M., Jacquenet, C., 603 Haeffner, W., Lee, S., Parker, R., Dunbar, L., Malis, A., 604 Halpern, J., Reddy, T., and P. Patil, "Service Function 605 Chaining (SFC) Control Plane Components & Requirements", 606 draft-ietf-sfc-control-plane-03 (work in progress), 607 January 2016. 609 [I-D.unify-nfvrg-challenges] 610 Szabo, R., Csaszar, A., Pentikousis, K., Kind, M., Daino, 611 D., Qiang, Z., and H. Woesner, "Unifying Carrier and Cloud 612 Networks: Problem Statement and Challenges", draft-unify- 613 nfvrg-challenges-03 (work in progress), January 2016. 615 [I-D.unify-nfvrg-recursive-programming] 616 Szabo, R., Qiang, Z., and M. Kind, "Towards recursive 617 virtualization and programming for network and cloud 618 resources", draft-unify-nfvrg-recursive-programming-02 619 (work in progress), October 2015. 621 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 622 and A. Bierman, Ed., "Network Configuration Protocol 623 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 624 . 626 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 627 Service Function Chaining", RFC 7498, 628 DOI 10.17487/RFC7498, April 2015, 629 . 631 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 632 Chaining (SFC) Architecture", RFC 7665, 633 DOI 10.17487/RFC7665, October 2015, 634 . 636 [UNIFY-GLOBECOM] 637 Sonkoly, B., Szabo, R., Jocha, D., Czentye, J., Kind, M., 638 and F-J. Westphal, "UNIFYing Cloud and Carrier Network 639 Resources: An Architectural View", Proc. IEEE GLOBECOM 640 2015, San Diego, CA, USA GLOBECOM, December 2015. 642 Authors' Addresses 644 Robert Szabo 645 Ericsson Research, Hungary 646 Irinyi Jozsef u. 4-20 647 Budapest 1117 648 Hungary 650 Email: robert.szabo@ericsson.com 651 URI: http://www.ericsson.com/ 653 Balazs Sonkoly 654 Budapest University of Technology and Economics 655 Magyar tudosok krt. 2 656 Budapest 1111 657 Hungary 659 Email: sonkoly@tmit.bme.hu 660 URI: http://www.tmit.bme.hu/