idnits 2.17.1 draft-xuan-nfvrg-ha-sfc-02.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 4) being 72 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (Jul 1, 2017) is 2490 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ETSI-NFV-MANO' is mentioned on line 100, but not defined == Unused Reference: 'ETSI-NFV-REL002' is defined on line 319, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Truong-Xuan Do 2 Internet Draft Younghan Kim 3 Intended status: Informational Soongsil University, Korea 4 Expires: Jan 2018 Jul 1, 2017 6 High Availability Mechanisms for Service Function Chaining 7 draft-xuan-nfvrg-ha-sfc-02 9 Status of this Memo 11 This Internet-Draft is submitted in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/1id-abstracts.html 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 This Internet-Draft will expire on Jan 2018. 32 Copyright Notice 34 Copyright (c) 2014 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions 39 Relating to IETF Documents (http://trustee.ietf.org/license-info) 40 in effect on the date of publication of this document. Please 41 review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 In the NFV domain, the high availability for SFC is the combination 47 of HA for individual service chain components and dynamic adjustment 48 This document considers the high availability mechanisms for 49 service chain from the viewpoint of the interaction between virtual 50 network function, virtual link, NFV-MANO, and NFVI. 52 Table of Contents 54 1. Introduction...................................................3 55 2. Conventions used in this document..............................3 56 3. High availability of SFC.......................................4 57 3.1. SFP adjustment............................................8 58 3.2. High availability for VNF.................................5 59 3.2.1 active standby........................................4 60 3.2.2 active active.........................................5 61 3.2.3 load balancing........................................6 62 3.3. High availability for NFV-MANO............................6 63 3.4. High availability for service function forwarder..........6 64 3.5. High availability for virtual link........................7 65 4. Multisite considerations.......................................7 66 5. Security Considerations........................................8 67 6. IANA Considerations............................................8 68 7. References.....................................................8 69 7.1. Normative References......................................8 70 7.2. Informative References....................................8 72 1. Introduction 74 Network function virtualization (NFV) offers a great flexibility, 75 CAPEX and OPEX reduction, and short time-to-market for provisioning 76 network services in cloud environment. 78 For traditional networks, the service function deployments are 79 relatively static and are tightly coupled to network topology and 80 physical resources. Therefore, the design of network service 81 availability is done hop by hop and the service of each hop is 82 configured and operated independently. There is no mechanism for 83 managing the end-to-end service availability. In NFV, the service 84 deployment is more dynamic, flexible, visible, and automated. 85 The service function chain could be adjusted dynamically in case 86 of failure. However, the interaction between the HA mechanisms for 87 individual components and service chain has not been discussed yet. 89 In this document, we considers the high availability mechanisms for 90 individual virtual network functions, virtual link, service function 91 forwarder, and interaction beetween those individual mechanisms 92 with the service chain adjustment. 94 2. Conventions used in this document 96 The terms about SFC, SFP, SFF, SF, and classifier are defined in 97 [RFC7665]. The terms about VNF, VNFFG, VL, NFV-MANO are defined in 98 [ETSI-NFV-ARCH]. The terms VNF and VNFFG are also called SF and SFC 99 respectively. In this document, we assume that there are some mappings 100 between the term SFC in [RFC7665] and VNFFG in [ETSI-NFV-MANO]. 101 The packets are encapsulated by the network service header (NSH) when 102 traversing the service chain or VNFFG. The control plane for the SFC 103 is placed in the NFV-MANO. 105 3. High availability of SFC 107 The high availability for SFC is ensured by the HA for individual 108 service chain compnents and the adjustment of service function path. 109 Depending on customer type and traffic type, the different redundancy 110 methods for each service chain component (VNF, VL) are applied to achieve 111 the corresponding Service Availability Level (SAL) [ETSI-NFV-REL001]. 113 3.1. SFP adjustment 115 Service function chain can have serveral service function paths (SFP) 116 which are created by the combination of service function instances 117 located in different physical hardware nodes. The high availability 118 of service function chain can be ensured by adjusting the current SFP 119 to create a new SFP. The high availability is one of use cases for 120 SFC adjustment in the [ietf-sfc-control-plane]. The SFP adjustment also 121 takes into account some policies defined by network operators. 123 3.2. High availability of Virtual Network Function 125 The high availability of VNFs are done using popular redundancy 126 methods such as Active-Standby, Active-Active [ETSI-NFV-REL003]. 128 3.2.1 Active-Standby configuration for VNF 130 In this case, the VNF is configured using active standby mode. when the 131 active VNF fails, the NFV-MANO detects the failure. The NFV-MANO will 132 configure the virtual router to map the external connection point (eCP) 133 to the internal connection point (iCP2) of the standby VNF. The IP 134 address of the VNF4 exposed to outside doesn't change, and the SFP 135 adjustment is not required in this case. 137 +-----------------------------------------------------+ +---------+ 138 | +--------+ Fail | | | 139 | | VNF2 | +----------------------^+ | 140 | +--+ +--+ | | |NFV-MANO | 141 | +-----+ | +--------+ | +---+----+ +--------+ | | | 142 | | +----+ | | VNF4 | | VNF4 | | | | 143 | |VNF1 | | +--+(active)| |(standby| | | | 144 | | | | +--------+ | +--------+ +-+------+ | | | 145 | +--^--+ | | VNF3 +--+ | | + + | 146 | | +--+ | +-iCP1---iCP2-+ configure mapping | 147 | | +------+-+ | Virtual +^----+----+ | 148 | | ^ | router | | | | 149 | | | +----+eCP+----+ | | | 150 | | | | | +---------+ 151 +----|-----------------|-----------------|------------+ 152 +----|-----------------|-----------------|------------+ 153 | +--|-----------------|-----------------|--+ | 154 | | | Virtualization| layer | | | 155 | +--|-----------------|-----------------|--+ | 156 | | | | | 157 | +--+----+ | +----+-----+ | 158 | |SFF1 | | | SFF3 | | 159 | | +-------------------------+ | | 160 | +----+--+ | +---+------+ | 161 | | +----+-----+ | | 162 | | | SFF2 | | | 163 | +----------+ +----------+ | 164 | NFVI +----------+ | 165 +-----------------------------------------------------+ 167 Figure 1. Service function chaining with VNFs at active-standby 169 3.2.2. Active-Active configuration for VNF 171 In this case, two VNF4s are active and use different IP addresses. In 172 active active mode, two internal connection points of VNFs are 173 connected to the two external connection points of virtual routers. 174 when one active VNF4 fails, the NFV-MANO needs to perform the SFP 175 adjustment to direct packet to the another active VNF4. 177 +-----------------------------------------------------+ +---------+ 178 | +--------+ Fail | | | 179 | | VNF2 | +---------------------^+ | 180 | +--+ +--+ | | | | 181 | +-----+ | +--------+ | +---+----+ +--------+ | |NFV-MANO | 182 | | +----+ | | VNF4 | | VNF4 | | | | 183 | |VNF1 | | +--+(active)| |(active)| | | | 184 | | | | +---------+ | +--------+ +-+------+ | | | 185 | +--^--+ | | VNF3 +-+ | | | | | 186 | | +--+ | +iCP1--iCP2+ | | | 187 | | +------+--+ | Virtual | | | | 188 | | ^ | Router | | | | 189 | | | +eCP1--eCP2+ | | | 190 | | | | | | +----+----+ 191 +----|-----------------|--------------|-------|-------+ | 192 +----|-----------------|--------------|-------|-------+ | 193 | +--|-----------------|--------------|-----+ | | | 194 | | | Virtualization| layer | | | | | 195 | +--|-----------------|--------------|-----+ | | | 196 | | | | | | | 197 | +--+----+ | +-+-------++ | SFC | 198 | |SFF1 | | | SFF3 | | adjustment 199 | | +-------------------------+ | | | 200 | +----+--+ | +---+------+ +^-------+ 201 | | +----+-----+ | | 202 | | | SFF2 | | | 203 | +----------+ +----------+ | 204 | NFVI +----------+ | 205 +-----------------------------------------------------+ 207 Figure 2. Service function chaining with VNFs at active-active 209 3.2.3. Load balancing configuration 211 In this case, a load balancer is deployed before active VNFs. These 212 VNFs should be managed by a cluster manager placed on NFV-MANO. The 213 traffic is distributed among VNFs in a cluster by the load balancer. 214 When a VNF fails, the traffic comming to the failed VNF will be 215 forwarded to another alive VNF in the cluster to process instead. In 216 this case, the SFP adjustment is not needed. 218 3.3. High availability for NFV-MANO 220 Clustering or redundancy mechanisms can be used to provide HA for 221 NFV-MANO. Mechanisms depends on the sub components of the NFV-MANO. 222 If the sub component is stateless, the cluster and load balancing can 223 be used. If the sub component is stateful, other mechanisms such as 224 active active or active standby can be used. 226 3.4. High availability for service function forwarder 228 In the NFV environment, the service function forwarder is 229 implemented as virtual switch (e.g. openvswitch). The virtual switch 230 connects virtual NIC of the VMs to the physical NICs. The virtual 231 switch redundancy is typically implemented by bonding multiple physical 232 NICs to it. 234 +-------------------------------+ 235 | openvswitch (SFF) | 236 | | 237 | +---------------+ | 238 | | vNIC (bonding)| | 239 +--------++-------------+-------+ 240 | | 241 | | 242 +---+-+ +-+----+ 243 |pNIC1| | pNIC2| 244 +-----+ +------+ 245 Figure 3. NIC bonding for SFF HA 247 3.5. High availability for virtual link 249 Virtual links connect different connection points using different type 250 of transport networks and protocols, such as VLAN, VXLAN, MPLS, IP. 251 The recovery of failed or congested virtual links could use fast 252 rerouting algorithms, e.g. MPLS fast rerouting. The SAL will determine 253 the threshold of virtual link bandwidth or latency and rerouting 254 algorithms to make another virtual link. In this case, the SFP 255 adjustment is not required. 257 +------------+ +---------+ 258 | service +-^+ | 259 | availability | | 260 | level + | | 261 +------------+ | | 262 | NFV-MANO| 263 | (E2E) | 264 +-------+ +--------+ +-------+ | | 265 | SFF1 | | SFF2 | | SFF3 | | | 266 | | | | | | | | 267 +---+---+ +--+-+---+ +----+--+ +----+----+ 268 | | | | | 269 | | | | +----v------+ 270 | +------------+ | | +----------+ | | WAN | 271 | | Transport | | | | Transport+--+ link | controller| 272 +-----+ network +-----+ +--+ network +-----fails--^+--+--+--^--+ 273 +-----^---+--+ +------+---+ | | | 274 | | ^ reroute | | | 275 | | reroute +--------------------+ | | 276 +------------------------------------------------+ | 277 | | 278 +-----------------link fails--------------------+ 280 Figure 4. High availability for virtual links 282 4. Multisite considerations 284 In the case of multisite cloud-based SFC, if high availability 285 mechanisms for VNF are deloyed over multisite (e.g. the active and 286 standby machines are distributed into multiple geographical locations). 287 Thus, when an active VNF fails, a standby VNF will be awoken in another 288 site. In order to guarantee the high availability of SFC, the SFP 289 should be adjusted and the SFF attached to failed VNF should tunnel 290 packets to standby VNF in another site. The state synchronization is 291 required among VNFs over multisites. The state synchronization can be 292 done by direct links among multiple cloud locations or via the central 293 NFV-MANO. 295 5. Security Considerations 297 TBD. 299 6. IANA Considerations 301 TBD. 303 7. References 305 7.1. Normative References 307 [RFC7665] 308 J. Halpern, C. Pignataro, "Service Function Chaining 309 (SFC) architecture", IETF RFC 7665, Oct 2015 311 7.2. Informative References 313 [ETSI-NFV-ARCH] 314 Network Function Virtualisation (NFV): architectural 315 framework 316 [ETSI-NFV-REL001] 317 Network Functions Virtualisation (NFV); Resiliency 318 Requirements 319 [ETSI-NFV-REL002] 320 Network Functions Virtualisation (NFV); Reliability; 321 Report on Scalable Architectures for Reliability 322 Management 323 [ETSI-NFV-REL003] 324 Network Functions Virtualisation (NFV); Reliability; 325 Report on Models and Features for End-to-End Reliability 327 Authors' Addresses 329 Truong-Xuan Do 330 Soongsil University 331 Changui Bldg. 403, 332 (156-743) 511 Sangdo-Dong, Dongjak-Gu, Seoul, Korea 334 Phone: +82 10 4473 6869 335 Email: thespring1989@gmail.com 337 Younghan Kim 338 Soongsil University 339 11F Hyungnam Engineering Bldg. 1107, 340 (156-743) 511 Sangdo-Dong, Dongjak-Gu, Seoul, Korea 342 Phone: +82-2-820-0904 343 Email: younghak@ssu.ac.kr