idnits 2.17.1 draft-xia-vsnpool-management-use-case-01.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 (October 21, 2013) is 3838 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC6707' is defined on line 819, but no explicit reference was found in the text == Unused Reference: 'WT-317' is defined on line 825, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'BBF-FSC-UC' -- Possible downref: Non-RFC (?) normative reference: ref. 'NFV-INF-UC' -- Possible downref: Non-RFC (?) normative reference: ref. 'NFV-ISG-UC' ** Downref: Normative reference to an Informational RFC: RFC 5351 ** Downref: Normative reference to an Informational RFC: RFC 6707 -- Possible downref: Non-RFC (?) normative reference: ref. 'TR-101' -- Possible downref: Non-RFC (?) normative reference: ref. 'WT-317' == Outdated reference: A later version (-09) exists of draft-ietf-nvo3-framework-00 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Xia 3 Internet-Draft Q. Wu 4 Intended status: Standards Track Huawei 5 Expires: April 24, 2014 D. King 6 Lancaster University 7 H. Yokota 8 KDDI Lab 9 October 21, 2013 11 Use cases and Requirements for Virtual Service Node Pool Management 12 draft-xia-vsnpool-management-use-case-01 14 Abstract 16 Network edge appliances such as subscriber termination, firewalls, 17 tunnel switching, intrusion detection, and routing are currently 18 provided using dedicated network function hardware. As network 19 function is migrated from dedicated hardware platforms into a 20 virtualized environment, a set of use cases with application specific 21 requirements begin to emerge. These use cases and requirements cover 22 a broad range of capability and objectives, which will require 23 detailed investigation and documentation in order to identify 24 relevant architecture, protocol and procedure solutions. 26 This document provides an analysis of the key management requirements 27 for applications that may be hosted within a virtualized environment. 28 These engineering requirements are based on a variety of uses cases 29 and goals , which include: virtual application security, reliability, 30 scalability, performance, operation and automation. 32 Note that this document is not intended to provide or recommend 33 protocol solutions. 35 Status of this Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on April 24, 2014. 51 Copyright Notice 53 Copyright (c) 2013 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 3. Virtual Service Node (VSN) Overview . . . . . . . . . . . . . 7 71 3.1. Reliability of VSN, VServer, VSNP . . . . . . . . . . . . 8 72 3.2. Reliability of Network Connectivity . . . . . . . . . . . 9 73 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 4.1. Virtualized Mobile Core Network and Service Systems . . . 10 75 4.2. Resilience for Stateful Service . . . . . . . . . . . . . 11 76 4.3. Auto Scale of Virtual Network Function Instances . . . . . 12 77 4.4. Reliable Network Connectivity between Network Nodes . . . 14 78 4.5. Existing Operating Virtual Network Function Instance 79 Replacement . . . . . . . . . . . . . . . . . . . . . . . 15 80 4.6. Reliable vCDN . . . . . . . . . . . . . . . . . . . . . . 16 81 4.7. VSN Cluster . . . . . . . . . . . . . . . . . . . . . . . 16 82 4.8. VSN Resilience Classes . . . . . . . . . . . . . . . . . . 18 83 4.9. Reliable Traffic Steering . . . . . . . . . . . . . . . . 18 84 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 85 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 86 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 87 7.1. Normative References . . . . . . . . . . . . . . . . . . . 23 88 7.2. Informative References . . . . . . . . . . . . . . . . . . 23 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 91 1. Introduction 93 Network virtualization technologies are finding increasing support 94 among network and Data Center (DC) operators. This is due to 95 demonstrable capital cost reduction and operational energy savings, 96 simplification of service management, potential for increased network 97 and service resiliency, and service and traffic elasticity. 99 Within traditional DC networks, varied middleware boxes including FW 100 (Fire Wall), NAT (Network Address Translation), LB (Load Balancers), 101 WoC (Wan Optimization Controller), etc., are being used to provide 102 network applications (services), traffic control and optimization. 103 Each function is an essential part of the entire operator and DC 104 network, and overall service chain (required traffic path for users) 105 Combined these functions and capabilities can be termed as service 106 nodes. 108 In terms of virtualizing network functions, a significant amount of 109 service nodes and function instances within the service nodes can be 110 migrated into virtualized environments, in essence the middleware 111 capability is implemented in software on commodity hardware using 112 well defined industry standard servers. Thus allowing the creation, 113 scaling, migration, modification, and deletion of single or groups of 114 functions, across few or many service nodes. 116 These virtual service nodes may be location independent, i.e., they 117 may exist across distributed or centralized DC hardware. This 118 architecture will pose new issues and great challenges to the 119 automated provisioning across the DC network, while maintaining high 120 availability, fault-tolerant, load balancing, and plethora of other 121 requirements some of which are technology and policy based. 123 Today, architecture and protocol mechanisms exist for the management 124 and operation of server hardware supporting applications, these 125 hardware resources are known as server node pools, which may be 126 accessed by other servers and clients. These server node pools have 127 a well-established set of requirements related to management, 128 availability, scalability and performance. Within this document we 129 refer to virtualization of server node pools as Virtual Service Node 130 Pool (VSNP). 132 [VNF-PS] provides an overview of the problem space related to service 133 node reliability. This document provides an analysis of the key 134 applications that may be hosted within a virtualized environment. 135 These engineering requirements are based on a variety of objectives 136 related to virtual application security, reliability, scalability, 137 performance, operation and automation. 139 This document is not intended to provide or recommend solutions. The 140 intention of this document is to present an agreed set of objectives 141 and use cases for VSNPs, identify requirements and present 142 architecture framing. 144 2. Terminology 146 Broadband Network Gateway (BNG): IP Edge Route where bandwidth and 147 QoS policies may be applied, to support multi-service delivery 148 [TR-101]. 150 Call Session Control Function (CSCF): A function that is used to 151 manage the mobile IP Multimedia Subsystem (IMS) signaling from 152 users to services and network gateways. 154 Hypervisor: Software running on a server that allows multiple VMs to 155 run on the same physical server. The hypervisor manages and 156 provide network connectivity to Virtual machines [NVO3-FWK]. 158 IP Multimedia Subsystem (IMS): The IP Multimedia Subsystem used 159 within mobile core networks. 161 Network Functions Virtualization (NFV): Moving network function from 162 dedicated hardware platforms onto industry standard high volume 163 servers, switches and storage. 165 Residential Gateway (RGW): A device located in the home network 166 performing gateway function. 168 Set-top Box (STB): This device contains audio and video decoders and 169 is intended to connects to a variety of home user devices media 170 servers and televisions. 172 Virtual Machine (VM): Software abstraction of underlying hardware. 174 Virtualized Server (VServer): A virtualized server runs a hypervisor 175 supporting one or more VMs [NVO3-FWK]. 177 Virtualized Service Node (VSN): A virtualized network function 178 instance implemented in software on Virtualized Server. 180 Virtual Service Node Pool (VSNP): Virtualized Server resources 181 supporting a variety of network functions.. 183 3. Virtual Service Node (VSN) Overview 185 Shifting towards virtualization of hardware function presents a 186 number of challenges and requirements, this document focuses on those 187 related to network function availability and reliability. In large 188 DC environments, a Virtual Service Node (VSN) may need to deal with 189 traffic from millions of hosts. This represents a significant 190 scaling challenge for VSN operation. 192 +----------------------+ 193 | | 194 | network application | 195 | | 196 +---------/-\----------+ 197 // \\ 198 // \\ 199 / \\ 200 +-------------+ // \\ +-------------+ 201 | VSNP |// \\| VSNP | 202 | manager +----------------------+ manager | 203 | | | | 204 +---/-\-------+ +-----/-\-----+ 205 / \ / \ 206 / \ / \ 207 / \ / \ 208 -/----- ------------ \ 209 // \\ //--- ---\\ 210 // +--+-+ +----+\\ /// \\\ 211 / |vSN1| |vSN2| \ // \\ 212 | +----+ +----+ | // \\ 213 | +----+ ------+ | /+----+ +----+ +----- +----+ +----\ 214 | |VM1 | | VM2 | | | |vSN3| |vSN4| |vSN5| |vSN6| |vSN7|| 215 | +----+ +-----+ | | +----+ +----+ +----+ +----+ +----+ | 216 | +------------+ | | +------------+ +-------------------+ | 217 | | | | | | VM3 | | VM4 | | 218 | | vServer1 | | | +------------+ +-------------------+ | 219 \ | | / | +------------+ +-------------------+ | 220 \\ |------------// | | | | | | 221 \\- VSNP -// | | vServer2 | | vServer3 | 222 -------- \| | | / 223 \\-----------+ +-----------------//+ 224 \\ // 225 \\\ VSNP /// 226 \\--- ---// 227 ------------ 229 Figure 1: Overall Architecture of VSNP 231 As shown in Figure 1, the overall architecture of VSNP includes VS, 232 VSN, VSNP, VSNP manager and the connectivity between any two VSs, and 233 the connectivity between VSN and VSNP manager. Rserpool [RFC5351] 234 has the similar architecture to provide high-availability and load 235 balancing, However Rserpool are only used to manage physical servers 236 and can not deal with virtualized function instance when it was 237 designed. 239 Note that VSNP and VSNP manager also can be used to manage 240 traditional service node. 242 3.1. Reliability of VSN, VServer, VSNP 244 The VSN, VServer and VSNP components are implemented in different 245 network layers and should be considered as different hardware or 246 logical elements. 248 Multiple VSNs can be provided on one or more VServers for increased 249 reliability. If a VServer detects the failure of the VSNs, it should 250 take the appropriate action for failover and ensures the service 251 continuity. 253 In order to manage server virtualization across a set of VServers and 254 provide fault tolerant and load sharing across VServers, the VSNPs 255 may be initiated and established as logical element(e.g., a set of 256 VSN providing the same service type), facilitating the migration of a 257 large number of VSNs running on different hypervisors and belonging 258 to different VServers to register into and deregister out. In case 259 of VSN failure or VServer overloading, such VSNPs can be used to 260 support both traditional and virtualized service node replacement or 261 service node adding. However when VSNPs is used to support the 262 operation of traditional service nodes, this doesn't scale very well. 264 Considering the reliability requirements, VSNP architecture should 265 support several key points detailed below: 267 o Application resource monitoring and health checking; 269 o Automatic detection of application failure; 271 o Failover to another VServer or VSNP; 273 o Transparency to other VSNs, VServers or VSNPs; 275 o Isolation and reporting of failures; 276 o Replication of state for active/standby network functions. 278 3.2. Reliability of Network Connectivity 280 The other category of reliability requirements concerns the network 281 connectivity between any two VSNs,or any two VSNP managers and the 282 network connectivity between VSN and VSN manager. 284 The connectivity between VSNs is used to deliver service through a 285 set of VSNs to meet the service requirements. 287 The connectivity between VSNP manager and VSN is used by the VSNP 288 manager to provide registry service to the VSN belonging to different 289 VServer and provide failover of the VSN. A set of VSNP managers can 290 be configured to provide reliable registration. When one VSN cannot 291 obtain a register response from one VSNP manager, it can go to 292 another VSNP manager for registration. This connectivity can also be 293 used by VSNP to monitor the work status of VSNs periodically. 295 The connectivity between VSNP managers is used to maintain 296 synchronization of data between VSNs located in different VSNP. This 297 allows every VSNP to acquire and maintain overall information of all 298 VSNs and provide protection for each other. 300 For all types of network connectivity discussed previously, the key 301 key reliability requirements stay consistant and include: 303 o Automatic detection of link failure; 305 o Failover to another usable link; 307 o Automated routing recovery. 309 4. Use Cases 311 4.1. Virtualized Mobile Core Network and Service Systems 313 A key use case for NFV is the virtualization of key mobile core 314 network functions. The ETSI NFV use case [NFV-ISG-UC] describes 315 requirements for server and packet gateways (S/P-GW) used for Packet 316 Data Network (PDN) connections and IMS session (see Figure 2: 317 Virtualized mobile core network and IMS). These services are 318 typically time dependent and may require a large number of computing 319 resources in proportion to the number of users and/or service 320 requests. Therefore it is desirable to scale them according to their 321 specific computing requirements. The virtualization can be applied 322 to the Evolved Packet Core (EPC) and the IMS to provide end to end 323 service with service availability and resilience. When those 324 virtualized service nodes(e.g., virtualized S/P-GW and IMS functions) 325 are failed or overloaded, dynamic relocation of those VSNs can be 326 performed, the relocation of the managed sessions and/or connections 327 must be accordingly managed. It also should be noted in [NFV-REL- 328 REQ]that the traffic in the original VSN must be routed to the new 329 location and it is desirable that the movement of the VSN is 330 transparent to other VSN and or physical network entities such as 331 client application on the UE. That is to say the other VSNs don't 332 require to take any special action to this movement. 334 +----------------+ +---------------------------------+ 335 | vEPC | | vIMS | 336 | | | | 337 | +---------+ | | +----------+ | 338 | | | | | | | | 339 | | vP/SGW +---+-+-| +--+ vS-CSCF | | 340 | | | | | | | | | | 341 | +---------+ | | | +--------+ | +----------+ | 342 |Overload/Failure| |-+-| +---| Overload/Failure | 343 | | | | P-CSCF | | 344 | | ++++| +++++ | 345 | +---------+ | + | +--------+ + +----------+ | 346 | | | | + | + | | | 347 | | vP/SGW +++++++ | +++| vS-CSCF | | 348 | | | | | | | | 349 | +---------+ | | +----------+ | 350 | | | | 351 | PDN Connection| | IMS Session | 352 +----------------+ +---------------------------------+ 354 Figure 2: Virtualized Mobile Core Network and IMS 356 In this use case, the following requirements need to be satisfied: 358 o Resource scaling - elastic service aware resource allocation to 359 network functions; 361 o State maintenance - network and network function state management 362 during VSN relocation, replication, and resource scaling; 364 o Monitoring/fault detection/diagnosis/recovery - appropriate 365 mechanism for monitoring/fault detection/diagnosis/recovery of all 366 components and their states after virtualization, e.g. VNF, 367 hardware, hypervisor; 369 o Service Availability - achieving the same level of service 370 availability for the end-to-end virtualized mobile core network as 371 in non-virtualized networks with reduced cost; 373 o Minimum impact on other relevant functions. 375 [More detailed description needs to be discussed.] 377 4.2. Resilience for Stateful Service 379 In the service continuity use case provided by the European 380 Telecommunications Standards Institute (ETSI) Network Function 381 Virtualization (NFV) Industry Specification Group (ISG) [NFV-REL-REQ] 382 , which describes virtual middlebox appliances providing layer-3 to 383 layer-7 services may require maintaining stateful information, e.g., 384 stateful vFW. In case of hardware failure or processing overload of 385 VSN, in addition to the replacement of VSN, it is necessary to move 386 its key status information to new VSN for service continuity. See 387 Figure 3 (Resilience for Stateful Service) for clarification. 389 In case of multiple vFws on one VM and not enough resources are 390 available at the time of failure, two strategies can be taken: one is 391 to move as many vFws as possible to a new place according to the 392 available resources, and the other is to suspend one or more running 393 VSNs in the new place and move all vFws on the failed hardware to it. 395 MAC, IP, VLAN, 396 Session id, Sequence No, ... 397 +-----------------+-----------------+ 398 | ************************************* 399 | * | |Limited | * | 400 | * | |Resource | * Suspend| 401 | * | V | * V 402 +--+-+ +-*--+ +--V-+ +----+ +--V-+ +-V--+ +----+ 403 |vFw1| |vFw1| |vFw1| |vFw2| |vFw1| |vFw1| |vFw3| 404 +----+ +----+ +----+ +----+ +----+ +----+ +----+ 405 +------------+ +------------+ +-------------------+ 406 | VM | | VM | | VM | 407 +------------+ +------------+ +-------------------+ 408 +------------+ +------------+ +-------------------+ 409 /-\ | | | | | 410 | || vServer | | vServer | | vServer | 411 \-/ | | | | | 412 +------------+ +------------+ +-------------------+ 413 Hardware 414 Failure 416 Figure 3: Resilience for Stateful Service 418 In both scenarios, the following requirements need to be satisfied: 420 o Supporting status information maintaining; 422 o Supporting status information moving; 424 o Supporting VSN moving from one VM to another VM; 426 o Supporting partial VSNs moving; 428 o Seamless switching user traffic to alternative VMs and VSNs. 430 4.3. Auto Scale of Virtual Network Function Instances 432 Adjusting resource to achieve dynamic scaling of VMs described in the 433 ETSI [NFV-INF-UC] use case and [NFV-REL-REQ]. As shown in Figure 4, 434 if more service requests come to a VSN than one physical node can 435 accommodate, processing overload occurs. In this case, the movement 436 of the VSN to another physical node with the same resource 437 constraints will create a similar overload situation. A more 438 desirable approach is to replicate the VSN and distribute service 439 node instances ones to one or more new VSNs and at the same time 440 distribute the incoming requests to those nodes. 442 In a scenario where a particular VSN requires increased resource 443 allocation to improve overall application performance, the network 444 function might be distributed across multiple VMs. To guarantee 445 performance improvement, the hypervisor dynamically adjusts (scaling 446 up or scaling down) resources to each VSNs in line with the current 447 or predicted performance needs. 449 +--------------+ 450 +-------------------+ | | 451 | | |Management and| 452 | <===>Orchestration | 453 | +---------+ | | Entity | 454 | | #1 | | +--------------+ 455 | --| vIPS/IDS|-- | /\ 456 | | +---------+ | | || +---------+ 457 | | |--|-- || <--|End User1| 458 | | VM #1 | | | || +---------+ 459 | +-------------+ | | +----\/---+ 460 | | | | | +---------+ 461 | +---------+ | | | | <--|End User2| 462 | | #2 | | | | | +---------+ 463 | --| vIPS/IDS|-- | | | | 464 | | +---------+ | | | | | +---------+ 465 | | ---|------- Service | <--|End User3| 466 | | VM #2 | | | | Router | +---------+ 467 | +-------------+ | | | | +---------+ 468 | | | | | <--|End User4| 469 | +---------+ | | | | +---------+ 470 | | #3 | | | | | +---------+ 471 | --| vIPS/IDS|-- | | | | <--|End User5| 472 | | +---------+ | | | +---------+ +---------+ 473 | | ---|-- : 474 | | VM #3 | | 475 | +-------------+ | : 476 | | 477 +-------------------+ 479 Figure 4: Auto Scaling of Virtual network Function Instances 481 In this case, the following requirements need to be satisfied: 483 o Monitoring/fault detection/diagnosis/recovery - appropriate 484 mechanism for monitoring/fault detection/diagnosis/recovery of all 485 components and their states after virtualization, e.g. VNF, 486 hardware, hypervisor; 488 o Resource scaling - elastic service aware resource allocation to 489 network functions. 491 4.4. Reliable Network Connectivity between Network Nodes 493 In the reliable network connectivity between network nodes use case 494 provided by ETSI [NFV-INF-UC], the management and orchestration 495 entities must be informed of changes in network connectivity 496 resources between network nodes. For example, Some network 497 connectivity resources may be temporarily put in power savings mode 498 when resources are not in use. This change is not desirable since it 499 may have great impact on reachability and topology. Another example, 500 some network connectivity resource may be temporarily in a fault 501 state and comes back into an active state, however some other network 502 connectivity resource becomes permanent in a fault state and is not 503 available for use. 505 +-----------+ 506 |Ochestrator| 507 +-----------+ 509 Web 510 vDPI vCache vFW vNATPT 512 +--------+ +--------+ +--------+ +--------+ 513 | +----+ | | +----+ | | +-++-+ | | +----+ | 514 |------| ------| -------| || | ----| |<----- 515 | | | | | | | | | | | || | | | | | | | 516 | | +----+ | | +----+ | | +-++-+ | | +----+ | | 517 | | | | | | | | | | 518 +----+ | | | +----+ | | +-++-+ | | | V| ,--,--,--. 519 | | | | | | | | | | || | | | | ,-' `-. 520 | |<->---------- | |----- | || |-----------<--> Internet ) 521 | | | | | +----+ | | +-++-+ | | | `-. ,-' 522 +-|--+ | | | | | | | | A `--'--'--' 523 | | +----+ | | | | +-++-+ | | +----+ | | 524 | | | ------------------| || ------| |<----| 525 -------- | | | | | | || | | | | | | 526 | +----+ | | | | +-++-+ | | +----+ | 527 +--------+ +--------+ +--------+ +--------+ 529 Figure 5: Reliable Network connectivity 531 In this case, the following requirements need to be satisfied: 533 o Quick detection of link failures; 535 o Adding network node instances, compute node instances and/or 536 hypervisor instances; 538 o Removing network node instances, compute node instances and/or 539 hypervisor instances; 541 o Adding or removing network links between nodes. 543 4.5. Existing Operating Virtual Network Function Instance Replacement 545 In the Replacement of existing operating VNF instance use case 546 provided by ETSI [NFV-INF-UC] use case, the Management and 547 Orchestration entity may be configured to support virtualized network 548 function replacement. For example, the Network Service Provider has 549 a virtual firewall that is operating. When the operating vFW 550 overloads or fails, the Management and Orchestration entity 551 determines that this vFW instance needs to be replaced by another vFW 552 instance. 554 Direct flow to new | | 555 +------------+ vFW | | 556 |Orchestrator|---------------| | | 557 +-|---------|+ | +-V---V+ 558 | | --------|,--,--|/ 559 Create and launch | Report Statist ,-' +------+`-. 560 new vFW | (Traffic,CPU ( ') 561 | | Failure..) `-. +-------+,-' 562 | | `| APP | 563 +--------|---+ +--|---------+ | Server| 564 |Host2 | |Host1 | +-------+ 565 | | | | 566 | +---++---+ | | +---++---+ | 567 | |vFW||vFW| | | |vFW||vFW| | 568 | +---++---+ | | +---++---+ | 569 | +---++---+ | | +---++---+ | 570 | |vFW||vFW| | | |vFW||vFW| | 571 | +---++---+ | | +---++---+ | 572 +------------+ +------------+ 574 Figure 6: Existing vFW replacement 576 In this case, the following requirements need to be satisfied: 578 o Verifying if capacity is available for a new instance of the VSN 579 at some location; 581 o Instantiating the new instance of VSN at the location; 583 o Transferring the traffic input and output connections from the old 584 instance to the new instance. This may require transfer of state 585 between the instances, and reconfiguration of redundancy 586 mechanisms; 588 o Pausing or deleting the old VSN instance. 590 4.6. Reliable vCDN 592 Virtualization of CDNs in the ETSI [NFV-ISG-UC] use case described 593 the CDN controller (a centralized component such as Global Load- 594 Balancer(GLB)) selects a Cache Node(CN), or a pool of CNs, to 595 redirect the proper CN which will deliver user request's content. 596 The CDN Controller and CNs may be virtualized so that the resources 597 for the vCDN can be scaled up and down according to the volume of 598 user requests. Then, content placed closer to the user is delivered 599 for providing cost-effective resource utilization and network 600 bandwidth savings. 602 In this case, the following requirements need to be satisfied: 604 o Resource scaling (elastic virtual CN allocation according to the 605 number of requests, proximity, etc); 607 o Acceleration of network I/O (I/O centric application needs to 608 overcome the network I/O degradation on the virtualized 609 environment); 611 o Performance monitoring (vCDN should be monitored in terms of the 612 number of sessions, load balancing, storage usage, network 613 throughput, etc); 615 o Interoperating 3rd party DC infra (3rd party DC infra can be 616 utilized to enhance vCDN coverage globally and to reduce infra 617 cost for delivering the short-term international event); 619 o Flexibility to fulfill specific storage density requirements, e.g. 620 to cache a large catalog of popular content; 622 o Ability of cache nodes to comply with main monitoring and 623 reporting requirements (e.g., SNMP, syslog, etc. so that operator 624 shall be able to manage different types of cache node for a 625 Delivery Service). 627 [More description is needed.] 629 4.7. VSN Cluster 631 VSN cluster is a set of VSNs which assemble together to support load 632 balancing and high availability. It tends to be a common case in 633 virtual networks for the following reasons: 635 o The performance of VSN is usually not as good as the appliances on 636 dedicated hardware (e.g., physical FW, LB, etc) for VSN is 637 realized mainly depending on software, not on dedicated hardware. 638 VSN cluster should be supported to achieve the same performance as 639 hardware appliance; 641 o New requirements of network virtualization as well as multi-tenant 642 support result in a large number of virtual DC network and a large 643 amount of traffic going through them. VSN cluster can be a good 644 choice to deal with this challenge. 646 There may be multiple different types of VSN clusters in one network. 647 A large number of VSNs dispersed in the network brings difficulty to 648 connect part of them and assemble them as an integrated network 649 function. Also, there should be a flexible load balancing policy 650 between all VSNs in one cluster to achieve good performance. At 651 last, synchronization of status information between lots of VSNs in 652 one or more clusters is more complicated than before and needs more 653 consideration. 655 --------------- 656 /-------- --------\ 657 ///// +----------+ +----------+\\\ 658 //// |+---++---+| |+---++---+| \\\\ 659 /// ||vFw||vFw|| ||vLB||vLB|| \\\ 660 // |+---++---+| |+---++---+| \\ 661 | /||vFw||vFw|| ||vLB||vLB|| | 662 || // |+---++---+| |+---++---+| || 663 | // +----------+ +--/-------+ | 664 | // // | 665 | +----/------+ +------/------+ | 666 | | | | | | 667 -+---------+ SBR +----...-----+ SBR +--------... | 668 | | | | | | 669 | +-----------+ +-------------+ | 670 | | 671 | | 672 \\ // 673 \\\ /// 674 \\\\ //// 675 \\\\\ ///// 676 \-------- --------/ 677 --------------- 679 Figure 10: VSNs cluster 681 As shown in Figure 10, two VSNs clusters are in network, each one 682 consists of 4 VSNs to provide the FW and LB function in a tenant 683 network. The service border routers connecting to them distribute 684 different flows to each VSN for load balancing. 686 In this case, the following requirements must be satisfied: 688 o Supporting the integration of all connecting VSNs in one cluster 689 to provide one network function for services; 691 o Improving performance by providing flexible load balancing policy 692 between VSNs in one cluster; 694 o Supporting the synchronization of status information between lots 695 of VSNs in one or more clusters while minimizing the complication 696 and impaction of signaling traffic. 698 4.8. VSN Resilience Classes 700 Different end-to-end services(e.g., Web, Video, financial backend, 701 etc) have different classes of resilience requirement for the VNFs. 702 The use of class-based resiliency to achieve service resiliency SLAs, 703 without "building to peak" is critical for operators. 705 VSN resilience classes can be specified by some attributes and 706 metrics as followed: 708 o Does VSN need status synchronization; 710 o Fault Detection and Restoration Time Objective (e.g., real-time, 711 near-real time, non-realtime) and metrics; 713 o Service availability metrics; 715 o Service Quality metrics; 717 o Service reliability; 719 o Service Latency metrics for components. 721 [More description is needed.] 723 4.9. Reliable Traffic Steering 725 The characteristics shared by aggregation and mobile-backhaul 726 networks, include a large number of nodes, middlebox appliances and 727 applications providing layer-3 to layer-7 services. Connections are 728 relatively static tunnel, that provide traffic multiplexing for many 729 flows (see Figure 11: Reliable Traffic Steering). These networks are 730 also known for their stringent requirements with regard to 731 reliability and short recovery times. The virtualization of the 732 aggregation network will provide optimization of resource allocation 733 and improved traffic forwarding. 735 Within the aforementioned networks subscriber traffic may be steered 736 through more than one appliances or bypass some appliances 737 completely. For example, traffic may pass through virtualized DPI 738 and FW functions, However, once the type of the flow has been 739 determined by the virtualized DPI function, the operator may decide 740 to modify the services applied to it. For example, if the flow is an 741 internet video stream, it may no longer need to pass the FW service, 742 reducing traffic load on it. Furthermore, in order to reduce traffic 743 load on some appliances or isolate fault on some appliances, after 744 the service type has been detected, the subsequent packets of the 745 same flow may no longer need to pass the LB service either; hence the 746 path of the flow can be updated. 748 --,--.,--,--,--.--,--. 749 ,-' `-. 750 , - 751 Home ( ------- | | - 752 Enviroment ( +-|--+ +-|-++----++----+ +----+ ) 753 +-----------+( |vDPI| |vLB||vFW1||vNAT| |vFW2| ) 754 | |( +----+ +---++----++----+ +----+ ) 755 | +----+ |( \ | / / ) 756 | |STB |\ |( \ | / / ) 757 | +----+ \|--` \ / /-------/ / ) 758 | |( \ +---+ ,--,+---+_._ _ _ / -) 759 | +----+ |( --- | |----'|SBR|-- . ) 760 | |PC |++++++++++++|SBR| +---+ |') ) 761 | +----+ |(------ | |+ +---+ ) 762 | +----+ /|( +---+ ++++'++'| |------- ) 763 | |iPad|/ |( |SBR| ) 764 | +----+ |( | |++++++- ) 765 | |( +---+ ) 766 +-----------+ . ) 767 `- SBR-Service Border Router ,-' 768 `-. --,--.,--,--,--.--,- , 770 Figure 11: Reliable traffic steering 772 In this case, the following requirements need to be satisfied: 774 o Dynamic steering traffic through a set of virtual service nodes 775 with each providing the same or different service [BBF-FSC-UC]; 777 o Dynamic changes to the data path for a given traffic session/flow 778 [BBF-FSC-UC]; 780 o Virtualization transparency to services - services using a network 781 function need not know whether it's a virtual function or a non- 782 virtualized; 784 o Virtualization transparency to network control and management - 785 network control and management plane need not be aware whether a 786 function is virtualized or not; 788 o Traffic control mechanism - data and management traffic 789 identification/separation for non-virtualized and virtualized 790 mobile core networks. 792 5. IANA Considerations 794 This document has no actions for IANA. 796 6. Security Considerations 798 TBD. 800 7. References 802 7.1. Normative References 804 [BBF-FSC-UC] 805 Broadband Forum, "Flexible Service Chaining", 2013. 807 [NFV-INF-UC] 808 "Network Functions Virtualisation Infrastructure 809 Architecture Part 2: Use Cases", ISG INF Use Case, 810 June 2013. 812 [NFV-ISG-UC] 813 "Network Function Virtualisation; Use Cases;", ISG NFV Use 814 Case, June 2013. 816 [RFC5351] Lei, P., Ong, L., Tuexen, M., and T. Dreibholz, "An 817 Overview of Reliable Server Pooling Protocols", May 2008. 819 [RFC6707] Niven-Jenkins, B., "Content Distribution Network 820 Interconnection (CDNI) Problem Statement", September 2012. 822 [TR-101] Broadband Forum, "Migration to Ethernet-Based DSL 823 Aggregation", 2006. 825 [WT-317] Broadband Forum, "Network Enhanced Residential Gateway", 826 2013. 828 7.2. Informative References 830 [NFV-REL-REQ] 831 "Network Function Virtualisation Resiliency Requirements", 832 ISG REL Requirements, June 2013. 834 [NVO3-FWK] 835 Lasserre, M., "Framework for DC Network Virtualization", 836 ID draft-ietf-nvo3-framework-00, September 2012. 838 [VNF-PS] Zong, N., "Problem Statement for Reliable Virtualized 839 Network Function (VNF) Pool", July 2013. 841 Authors' Addresses 843 Liang Xia 844 Huawei 845 101 Software Avenue, Yuhua District 846 Nanjing, Jiangsu 210012 847 China 849 Email: frank.xialiang@huawei.com 851 Qin Wu 852 Huawei 853 101 Software Avenue, Yuhua District 854 Nanjing, Jiangsu 210012 855 China 857 Email: bill.wu@huawei.com 859 Daniel King 860 Lancaster University 861 UK 863 Email: d.king@lancaster.ac.uk 865 Hidetoshi Yokota 866 KDDI Lab 867 Japan 869 Email: yokota@kddilabs.jp