idnits 2.17.1 draft-vazquez-nfvrg-netcod-function-virtualization-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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 13, 2016) is 2693 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? 'I-D.irtf-nwcrg-network-coding-taxonomy' on line 391 looks like a reference -- Missing reference section? 'RFC6363' on line 397 looks like a reference -- Missing reference section? 'AHL00' on line 402 looks like a reference -- Missing reference section? 'KOE03' on line 406 looks like a reference -- Missing reference section? 'LI03' on line 410 looks like a reference -- Missing reference section? 'ALE13' on line 416 looks like a reference -- Missing reference section? 'ALE15' on line 421 looks like a reference -- Missing reference section? 'HAN15' on line 438 looks like a reference -- Missing reference section? 'HEI09' on line 443 looks like a reference -- Missing reference section? 'SAX15' on line 447 looks like a reference -- Missing reference section? 'SZA15' on line 452 looks like a reference Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NFVRG M. A. Vazquez-Castro 3 Internet-Draft T. Do-Duy 4 Intended status: Informational UAB 5 Expires: May 17, 2017 P. Saxena 6 M. Vikstrom 7 AnsuR 8 November 13, 2016 10 Network Coding Function Virtualization 11 draft-vazquez-nfvrg-netcod-function-virtualization-00 13 Abstract 15 This document describes network coding as a network function. It 16 also describes how a network coding function can be virtualized and 17 integrated with virtual network functions architectures. The network 18 coding function is not a traditionally implemented network function 19 in dedicated hardware as those that have triggered network function 20 virtualization. It refers to a novel network functionality that 21 generalizes classic packet-level end-to-end coding. Classic packet- 22 level end-to-end coding helps in the provision of quality of service 23 by trading off delay and reliability. Network coding goes beyond 24 that by enabling in-network optimized re-encoding, which can provide 25 both throughput gains and diverse network-controlled degrees of 26 reliability. Consequently, a virtualized network coding function can 27 serve as a flow engineering tool over virtualized networks (e.g. over 28 network slices). 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on May 17, 2017. 47 Copyright Notice 49 Copyright (c) 2016 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Conventions used in this document . . . . . . . . . . . . . . 3 66 3. Network coding as a network function . . . . . . . . . . . . 5 67 4. Virtual Network Coding Function . . . . . . . . . . . . . . . 5 68 4.1. Virtualization of flows . . . . . . . . . . . . . . . . . 5 69 4.2. Integration with ETSI NFV architecture . . . . . . . . . 6 70 4.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 9.1. Normative Information References . . . . . . . . . . . . 9 77 9.2. Conceptual ground basis . . . . . . . . . . . . . . . . . 9 78 9.3. Application references . . . . . . . . . . . . . . . . . 10 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 81 1. Introduction 83 Network coding(NC) is a novel technology that can be seen as the 84 generalization of classic point to point coding to coding for network 85 flows. As with classic coding, both information theoretical and 86 algebraic codes literature provide the conceptual solid basis of NC. 87 Such conceptual basis has clarified NC benefits and corresponding 88 tradeoffs, which need to be considered in practical implementations 89 of the technology. 91 NC does not replace end-to-end (packet-level block) coding, which is 92 a well-established technology for the per-flow provision of quality 93 of service by trading off delay and reliability. Instead, NC 94 provides coding within and across network flows relying on in-network 95 re-encoding based on service-intent-oriented policy strategies. By 96 means of such policy strategies, the provision of quality of service 97 that NC can offer can be tailored according to desired network 98 service intent. 100 For its operation, NC relies on having access to network, computation 101 and storage resources throughout the network. Such novel networking, 102 computational and storage ingredients of a coding technology calls 103 for novel practical design approaches to truly exploit the potential 104 capabilities of NC. 106 On the other hand, Network Function Virtualization (NFV) and NC can 107 be seen as different ways to address different challenges in the 108 design of upcoming network technologies. Moreover, NC is not a 109 traditionally implemented network function in dedicated hardware, 110 which are the network functions that have triggered the design of NFV 111 architectures. However, in this document we show the feasibility and 112 benefits of virtualizing the network coding function. 114 The objective of this document is not to explain network coding 115 technology. The interested reader should find this information 116 outside this document. 118 The objective of this document is fundamentally two fold. First, we 119 show that NC can be designed as a (modular) network function. The 120 modularity is convenient for the user and is given as sets of 121 elementary functionalities (toolboxes) that are defined independent 122 of the physical network. Second, we show that the NC function 123 requirements of connectivity, computation and storage resources find 124 a natural practical design solution in the integration of the NC 125 function with available NFV architectural frameworks. Such solution 126 is described here and it combines network protocol-driven and system 127 modular-driven design approaches. 129 The resulting Virtual Network Coding Function (VNCF) can be useful 130 for upcoming networking needs derived from network virtualization. 132 2. Conventions used in this document 134 The following terms defined in this document can be found in the ETSI 135 NFV [etsi_gs_nfv_002_v1.2.1] and the IETF [I-D.irtf-nwcrg-network- 136 coding-taxonomy]. 138 Coherent Network Coding: Source and destination nodes know network 139 topology and coding operations at intermediate nodes. 141 Noncoherent Network Coding: Source and destination nodes do not know 142 network topology and intermediate coding operations. In this case, 143 random network coding can be applied. 145 Flow: A stream of physical packets logically grouped from the network 146 coding perspective. These packets may come from the same application 147 (in that case they are identified by the five-tuple: source and 148 destination IP address, transport protocol ID, and source and 149 destination port of the transport protocol), or come from the same 150 source host (in which case they are identified by the 3-tuple source 151 and destination IP address, Type of Service (TOS) or Diffserv code 152 point(DSCP)). This distinction depends on the use-case where network 153 coding is applied. 155 Intra-flow coding: Network coding over payloads belonging to the same 156 flow. 158 Inter-flow coding: Network coding over payloads belonging to multiple 159 flows. 161 End-to-end coding : Transport stream is coded and decoded at end- 162 points. 164 Coding node: Node performing coding operations. 166 Virtualized Infrastructure Manager (VIM): functional block that is 167 responsible for controlling and managing the NFVI compute, storage 168 and network resources, usually within one operator's Infrastructure 169 Domain. 171 Virtualized Network Function (VNF): implementation of a Network 172 Function that can be deployed on a Network Function Virtualization 173 Infrastructure (NFVI). 175 Virtualized Network Function Manager (VNFM): functional block that is 176 responsible for the lifecycle management of VNF. 178 NFV Infrastructure (NFVI): totality of all hardware and software 179 components which build up the environment in which VNFs are deployed. 181 NFV Orchestrator (NFVO): functional block that manages the Network 182 Service (NS) lifecycle and coordinates the management of NS 183 lifecycle, VNF lifecycle (supported by the VNFM) and NFVI resources 184 (supported by the VIM) to ensure an optimized allocation of the 185 necessary resources and connectivity. 187 NFV Management and Orchestration (NFV-MANO): functions collectively 188 provided by NFVO, VNFM, and VIM. 190 3. Network coding as a network function 192 NC design involves different domains. We can identify at least three 193 domains: 195 Coding domain - domain for the design of network coding codebooks, 196 coherent or noncoherent encoding/decoding schemes, performance 197 benchmarks, appropriate mathematical-to-logic maps, etc. This is a 198 domain fundamentally designed by coding theorists. 200 Functional domain - domain for the design of the functional 201 properties of NC to achieve the desired design requirements upon 202 abstractions of networks and systems. This domain jointly requires 203 to consider physical-logical abstraction, identification of network 204 coding application to either inter-flow or intra-flow network coding, 205 service intent and related networking for the provision of quality of 206 service. 208 Protocol domain - domain for the design of physical signaling/ 209 transporting of the network coded information flow as one way or 210 interactive protocols. 212 The functional domain can be designed interpreting NC as a network 213 function. In order to provide the designer with sufficient 214 flexibility, NC elementary functionalities can be grouped as a set of 215 toolboxes that the designer can use. We define the following three 216 toolboxes: 218 o Coding/Re-encoding/Decoding Functionalities (CRDF). 220 o Flow Engineering Functionalities (FEF) performing optimization of 221 available network resources to optimally perform NC to meet the 222 service design targets depending on the (statistical) status of 223 the networks (congestion, link failures, etc). 225 o Physical/Abstraction Functionalities (PAF) performing interaction 226 with available storage and computation physical resources that are 227 abstracted by the other toolboxes. 229 4. Virtual Network Coding Function 231 4.1. Virtualization of flows 233 An important differentiating aspect of NC with respect to traditional 234 networking technologies is the following. A network flow for a NC 235 network function is understood as a stream of physical packets 236 logically grouped from the network coding perspective. 238 NC can optimize the NC operation abstracting such physical flow as a 239 mathematical model, which can be subject of computational 240 manipulation. This makes NC to be naturally integrated into a 241 virtualized framework of abstract entities such as virtual network or 242 network slices. This is because in the NC case, not only the network 243 and resources are abstracted, but also the stream of packets is 244 abstracted. 246 Consequently, when interpreting NC as a functionality provided to the 247 network, NC function virtualization simply consists of integrating 248 the NC functional toolboxes described in the previous section into 249 existing architectural NFV frameworks. The virtualization of the 250 network flow is managed by the NC function (CRDF toolbox), and the 251 virtualization of all the functionalities described in Section 3 has 252 no difference with respect to any other network function. 254 4.2. Integration with ETSI NFV architecture 256 Figure 1 shows our proposed virtual NC network function (VNCF). It 257 is integrated with the ETSI NFV architecture given the abstracted 258 underlying physical system/network as part of NFVI. 260 The integration naturally includes too exchanges between VNCF and 261 NFV-MANO over reference points. 263 Clearly, the functionalities of the FEF toolbox need to interact with 264 the NFVO, VNFM, and VIM. Note that the NFVO two main 265 responsibilities of orchestration of NFVI resources across VIMs and 266 the life-cycle management of network services, fit perfectly the 267 needs of the FEF and PAF toolboxes. Specifically, the FEF can obtain 268 available network, connectivity and computation resources, geo- 269 statistical status of the networks such as congestion, link failures, 270 etc. With these, NC operation can be optimized to meet the service 271 design targets given the service-specific design constraints. The 272 optimization may result into manipulation of the (non-physical) flows 273 and other flow engineering policies. On the other hand, the FEF can 274 interact with the VIM to obtain the allocation, upgrade, release, etc 275 of NFVI resources. 277 +-------------------------------------------+ +---------------+ 278 | Virtualized Network Functions (VNFs) | | | 279 | ------- ------- ------- ------- | | | 280 | | | | | | | | | | | | 281 | | VNF | | VNF | |VNCF | | VNF | | | | 282 | | | | | | | | | | | | 283 | ------- ------- ------- ------- | | | 284 +-------------------------------------------+ | | 286 +-------------------------------------------+ | | 287 | NFV Infrastructure (NFVI) | | NFV | 288 | ----------- ----------- ----------- | | Management | 289 | | Virtual | | Virtual | | Virtual | | | and | 290 | | Compute | | Storage | | Network | | | Orchestration | 291 | ----------- ----------- ----------- | | | 292 | +---------------------------------------+ | | | 293 | | Virtualization Layer | | | | 294 | +---------------------------------------+ | | | 295 | +---------------------------------------+ | | | 296 | | ----------- ----------- ----------- | | | | 297 | | | Compute | | Storage | | Network | | | | | 298 | | ----------- ----------- ----------- | | | | 299 | | Hardware resources | | | | 300 | +---------------------------------------+ | | | 301 +-------------------------------------------+ +---------------+ 303 Figure 1: ETSI NFV framework with one VNCF box as part of the set of 304 available VNFs. 306 4.3. Example 308 We describe here a high-level example of a general procedure of 309 interaction between the VNCF and the NFV-MANO. The NFV-MANO has 310 repositories that hold different information regarding network 311 services (NSs) and VNFs (VNCF is part of VNFs). There are four types 312 of repositories as follows: 314 o VNF catalogue represents the repository of all usable VNF 315 packages, supporting the creation and management of the VNF 316 packages. 318 o NS catalogue represents the repository of all usable NSs. 320 o NFV instances is the repository that holds details of all VNF 321 instances and NS instances, represented by either a VNF record or 322 a NS record, respectively, during the execution of VNF/NS life- 323 cycle management operations. 325 o NFVI resources is the repository that holds information about NFVI 326 resources utilized for the establishment of NS and VNF instances. 328 Assume a network abstracted as a set of N coding nodes, each with 329 encoding/re-encoding/decoding and (possibly) multi-link connectivity. 330 A user of the VNCF wants to provide an ultra-reliable service (e.g. 331 mission-critical communications) to the N nodes. The performance 332 objectives are given as a set of N reliability and delay objective 333 performance metrics, which are geo-location dependent. We call this 334 VNCF instantiation as a virtual geo-network coding function (VGNCF), 335 which is activated and its management and orchestration take place. 337 A detailed interaction with the architectural blocks (some under 338 definition) is as follows. 340 o TBD 342 5. Conclusions 344 This memo presents a preliminary version of proposal for the design 345 of NC as a network function. It is also discussed that it can be 346 virtualized and integrated into a NFV architecture. 348 6. Acknowledgements 350 The authors want to thank Dr. Harald Skinnemoen for useful comments 351 and discussions. The first author wants to thank Dr. Carlos J. 352 Bernardos and Luis M. Contreras for useful discussions. 354 The authors also want to acknowledge the following ongoing projects. 356 1. GEO-VISION - GNSS driven EO and Verifiable Image and Sensor 357 Integration for mission-critical Operational Networks. EU funded 358 project under the call H2020-GALILEO-2014-1 by the European 359 Global Navigation Satellite Systems Agency (project reference 360 641451). 362 2. SatNetCode - Satellite Network-Coding for high performance, 363 semantic-aware mission-critical visual communications. This 364 project is funded by the European Space Agency. 366 3. HENCSAT - Highly Efficient Network Coding for Satellite 367 Applications Test-bed. This project is funded by the European 368 Space Agency. 370 7. IANA Considerations 372 This memo includes no request to IANA. 374 8. Security Considerations 376 This memo includes no Network Coding Function Virtualization - 377 specific security definitions yet. 379 9. References 381 9.1. Normative Information References 383 [etsi_gs_nfv_002_v1.2.1] 384 "Network Function Virtualisation (NFV); Architectural 385 Framework", 2014. 387 [etsi_nvf_whitepaper] 388 "Network Functions Virtualisation (NFV). White Paper 2", 389 2014. 391 [I-D.irtf-nwcrg-network-coding-taxonomy] 392 Firoiu, V., Adamson, B., Roca, V., Adjih, C., Bilbao, J., 393 Fitzek, F., Masucci, A., and M. Montpetit, "Network Coding 394 Taxonomy", draft-irtf-nwcrg-network-coding-taxonomy-01 395 (work in progress), October 2016. 397 [RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error 398 Correction (FEC) Framework", RFC 6363, 2011. 400 9.2. Conceptual ground basis 402 [AHL00] Ahlswede, R., Cai, N., Y. R. Li, S., and R. W. Yeung, 403 "Network information flow", in IEEE Trans. Inform. Theory, 404 vol. 46, pp. 1204-1216, July 2000. 406 [KOE03] Koetter, R. and M. Medard, "An algebraic approach to 407 network coding", in IEEE/ACM Trans. on Networking, vol. 408 11, n. 5., pp. 782-795, October 2003. 410 [LI03] Y.R.Li, S., W. Yeung, R., and N. Cai, "Linear network 411 coding", in IEEE Trans. Inform. Theory, vol. 49, n. 2., 412 pp. 371-381, February 2003. 414 9.3. Application references 416 [ALE13] Alegre-Godoy, R. and M. A. Vazquez-Castro, "Spatial 417 Diversity with Network Coding for ON/OFF Satellite 418 Channels", in IEEE Communications Letters, vol. 17, No. 8, 419 pp. 1612-1615, August 2013. 421 [ALE15] Alegre-Godoy, R. and M. A. Vazquez-Castro, "Network Coded 422 Multicast over Multi-beam Satellite Systems", in 423 Mathematical Problems in Engineering, vol. 2015, Article 424 ID 364234, May 2015. 426 [DO16.1] Do-Duy, T. and M. A. Vazquez-Castro, "Design of 427 Virtualized Network Coding Functionality foR Reliability 428 Control of Communication Services over Satellite", 429 submitted to Special Issue on Network Coding. 430 International Journal of Satellite Communications and 431 Networking, 2016. 433 [Do16.2] Do-Duy, T. and M. A. Vazquez-Castro, "Network coding 434 function virtualization", in IEEE 17th International 435 Workshop on Signal Processing Advances in Wireless 436 Communications (SPAWC), September 2016, INVIED PAPER. 438 [HAN15] Hansen, J., E. Lucani, D., Krigslund, J., Medard, M., and 439 F. H. P. Fitzek, "Network coded software defined 440 networking: enabling 5G transmission and storage 441 networks", in IEEE Communications Magazine, 2015. 443 [HEI09] Heide, J., V. Pedersen, M., H. P. Fitzek, F., and T. 444 Larsen, "Network Coding for Mobile Devices - Systematic 445 Binary Random Rateless Codes", in ICC Workshops, 2009. 447 [SAX15] Saxena, P. and M. A. Vazquez-Castro, "DARE: DoF-Aided 448 Random Encoding for Network Coding over Lossy Line 449 Networks", in IEEE Communications Letters, vol. 19, No. 8, 450 pp. 1374-1377, August 2015. 452 [SZA15] Szabo, D., Nemeth, F., Sonkoly, B., Gulyas, A., and F. H. 453 P. Fitzek, "Towards the 5G revolution: A software defined 454 network architecture exploiting network coding as a 455 service", in SIGCOMM Comput. Commun, 2015. 457 [VAZ15.1] A. Vazquez-Castro, M., "A Geometric Approach to Dynamic 458 Network Coding", in Information Theory Workshop, Jeju, 459 Korea, October 2015. 461 [VAZ15.2] A. Vazquez-Castro, M., "Subspace coding over Fq-linear 462 erasure satellite channels", in 12th International 463 Symposium on Wireless Communication Systems, pp. 216-220, 464 August 2015. 466 [VAZ15.3] A. Vazquez-Castro, M. and P. Saxena, "Network Coding over 467 Satellite: From Theory to Design and Performance", in 468 Volume 154 of the series Lecture Notes of the Institute 469 for Computer Sciences, Social Informatics and 470 Telecommunications Engineering, pp. 315-327, September 471 2015, INVITED PAPER. 473 Authors' Addresses 475 M.A. Vazquez-Castro 476 Autonomus University of Barcelona 477 Campus de Bellaterra 478 Barcelona, 08391 479 Spain 481 Email: angeles.vazquez@uab.es 483 Tan Do-Duy 484 Autonomus University of Barcelona 485 Campus de Bellaterra 486 Barcelona, 08391 487 Spain 489 Email: tan.doduy@uab.es 491 Paresh Saxena 492 AnsuR Technologies 493 Martin Linges Vei 25, Fornebu 494 Oslo, 1364 495 Norway 497 Email: paresh.saxena@ansur.es 499 Magnus Vikstrom 500 AnsuR Technologies 501 Martin Linges Vei 25, Fornebu 502 Oslo, 1364 503 Norway 505 Email: magnus@ansur.no