idnits 2.17.1 draft-dolson-sfc-nfv-patterns-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 21, 2016) is 2929 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-28) exists of draft-ietf-sfc-nsh-02 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Service Function Chaining D. Dolson 3 Internet-Draft M. Marchetti 4 Intended status: Informational K. Larose 5 Expires: September 22, 2016 Sandvine 6 March 21, 2016 8 Efficient Patterns for Service Function Chaining within Network Function 9 Virtualization Infrastructure 10 draft-dolson-sfc-nfv-patterns-00 12 Abstract 14 The document presents some considerations for efficiently deploying 15 Service Function Chaining (SFC) within a Network Function 16 Virtualization Infrastructure (NFVI). 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 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 54 2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4.1. Use MAC-NSH to address functions . . . . . . . . . . . . 3 58 4.2. Locate SFF with the SF . . . . . . . . . . . . . . . . . 4 59 4.3. Prefer NSH MD Type 2 . . . . . . . . . . . . . . . . . . 6 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 62 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 64 7.2. Informative References . . . . . . . . . . . . . . . . . 7 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 67 1. Introduction 69 Service Function Chaining (SFC) is a technique for prescribing 70 differentiated traffic forwarding policies. SFC is described in 71 detail in the SFC architecture document [RFC7665], and is not 72 repeated here. 74 Network Function Virtualization (NFV) is technology for deploying 75 network forwarding software functions on an infrastructure providing 76 generic compute and network resources. Such an infrastructure is 77 termed NFVI [ETSI_NFV]. 79 This document presents some efficient patterns for deploying SFC 80 within an NFVI, in the hope of sharing good practices. 82 1.1. Requirements Language 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in RFC 2119 [RFC2119]. 88 2. Objectives 90 The patterns described in this document are designed to satisfy: 92 o Minimize latency by minimizing both the number of physical hops 93 and number of queues each packet traversing a service chain must 94 undergo. 96 o Minimize CPU processing by avoiding unnecessary software 97 switching. 99 These objectives serve both to increase network performance that 100 would be measured by end users and increase efficiency of NFVI by 101 minimizing switching and CPU resources required to implement each 102 chain. 104 3. Assumptions 106 We wish to discuss solutions that are available with current 107 technology. In particular: 109 o the NFVI is to be built using only currently available commercial 110 off-the-shelf (COTS) hardware; 112 o the infrastructure is to be built using currently available NFVI 113 technology and hosting, in particular the ability of the NFV 114 infrastructure to provide virtual compute resources with 115 interfaces to virtual Ethernet LAN segments. 117 4. Patterns 119 The following sections describe design patterns for using SFC that we 120 consider to be appropriate under the above NFV assumptions. 122 4.1. Use MAC-NSH to address functions 124 A common infrastructure model (e.g., OpenStack/Neutron) allows 125 provisioning of virtual machines with interfaces on specified 126 Ethernet segments. Although the physical implementation of an 127 Ethernet segment is opaque to the tenants, all machines on a segment 128 can send packets to one another by addressing the destination MAC 129 address. 131 Single-Root I/O Virtualization (SR-IOV) is a technology that allows a 132 single physical interface on a compute host to be split into multiple 133 virtual interfaces such that each guest has a hardware interface to 134 the network. When so configured, the physical interface hardware 135 sorts incoming packets into queues for the distinct emulated 136 interfaces according to destination MAC addresses. This technology 137 removes any need for a software module to sort packets received from 138 the physical interfaces into virtual interfaces of the guests. Thus, 139 an extra queuing stage is avoided and no CPU switching resources are 140 required. 142 The NVFI operator may choose to deploy simple switching, with 143 hardware backplane and top-of-rack Ethernet/VLAN switches providing 144 minimum latency. The operator may also deploy Ethernet-over-IP 145 (e.g., VXLAN) when functions are remote. In any case, the virtual 146 host is agnostic to the implementation. 148 Thus, by using SR-IOV and efficient zero-copy drivers, functions 149 naturally address one another by MAC address on the layer-2 segment. 150 In the optimal NFV scenario, software in one function queues packets 151 to an outbound SR-IOV queue, hardware sends the packet on the 152 physical interface, backplane or top-of-rack switches deliver the 153 packet to the physical destination and SR-IOV destination queue. 154 There need not be any software between functions, only Ethernet 155 switches. 157 Note that to capture the benefit of using SR-IOV to avoid software 158 switching, any L2-over-L3 (e.g., VXLAN) should be arranged for in 159 hardware. The functions themselves can then behave the same whether 160 virtual or physical network segments are used. 162 We conclude that carrying NSH packets directly within Ethernet frames 163 is an efficient and natural way to implement Service Function 164 Chaining. The Ethernet encapsulation of NSH is documented in 165 [I-D.ietf-sfc-nsh]. 167 4.2. Locate SFF with the SF 169 Service function chains are often drawn like this two-SF example in 170 which a packet goes from ingress to Classifier, to SFF1, to SF1, back 171 to SFF1, to SFF2, to SF2, back to SF2 and finally to egress: 173 ingress --> Classifier --> SFF1 --> SFF2 --> Egress 174 ^ ^ 175 | | 176 | | 177 V V 178 SF1 SF2 180 Figure 1: A conceptual service function chain 182 But in NFV infrastructure, if SFFs are considered distinct processing 183 elements, the common reality is that each of the components are 184 separated by Ethernet switching: 186 ingress-->Classifier-->switch-->SFF1-->switch-->SFF2-->switch-->Egress 187 ^ ^ 188 | | 189 | | 190 V V 191 switch switch 192 ^ ^ 193 | | 194 | | 195 V V 196 SF1 SF2 198 Figure 2: A service function chain showing switches 200 In an NFV environment, the "switch" blocks in Figure 2 can be 201 implemented by Ethernet backplane, top-of-rack switching or (for 202 remotely separated virtual machines) VXLAN virtual layer-2 network. 204 There is an optimization that can be made when all of the "switch" 205 modules are the same Ethernet switching domain. In other words, when 206 this is the logical topology of Figure 3: 208 SFF1 SFF2 209 | | 210 | | 211 ingress ---Classifier----- switch ---------- egress 212 | | 213 | | 214 SF1 SF2 216 Figure 3: Service chain components attached to a layer-2 network 218 Notice that to implement the path of Figure 1 and Figure 2, a packet 219 must pass through the switch seven times. It must also pass through 220 each SFF twice, limiting the capacity of an SFF. 222 We can reduce the number of transits through the switch by placing 223 SFF forwarding tables in the SF software module itself, like this: 225 ingress ---Classifier----- switch ---------- egress 226 | | 227 | | 228 SFF1 SFF2 229 SF1 SF2 231 Figure 4: SFFs embedded in SF machines 233 In this case, a packet taking the path of Figure 1 only transits the 234 switch three times. For minimal latency, an implementation can avoid 235 queuing between the SF and attached SFF. 237 Although keeping the SFFs distinct from the SFs has an architectural 238 purity, the purity has a big cost in switching throughput and 239 corresponding cost in money and latency. Since each packet enters 240 and exits each SFF twice, there could also be contention on the SFF 241 interfaces. 243 There is additional control-plane burden to achieve this data-plane 244 efficiency gain: 246 o SF software must implement SFF lookup functions. We feel this 247 computation of next-hop and packet formatting can be done 248 efficienty in software, but it does require support of the SFF 249 feature in the software. 251 o There will be as many SFFs as SFs, each of which much have correct 252 forwarding entries populated by the control plane during the 253 orchestration of bringing an SF on line. 255 There are many ways to physically realize the logical switch entities 256 in Figure 3 and Figure 4. The best case is a hardware Ethernet 257 switch; considerations about how to optimally deploy functions are 258 discussed elsewhere, e.g., in Network Function Virtualization 259 Research Group (NFVRG). In any of these cases, reducing the number 260 of passages though the switch will reduce latency and reduce 261 operational cost. 263 4.3. Prefer NSH MD Type 2 265 The NSH draft [I-D.ietf-sfc-nsh] defines two options for metadata, 266 types 1 and 2. Type 2 is more efficient when there is no metadata, 267 and is the only choice supporting more than 128 bits of metadata. 269 Using the approaches described in Section 4.1 and Section 4.2, NSH 270 packets are transported from one MAC endpoint to another via standard 271 Ethernet switches, so there are no requirements on the NFV 272 Infrastructure to support NSH. 274 Given that parsing the variable-length header poses no concerns for 275 software, we feel these considerations make MD Type 2 the preferred 276 choice for service chaining with NFV. 278 5. IANA Considerations 280 This memo includes no request to IANA. 282 6. Security Considerations 284 We are not aware of any additional security concerns raised by 285 employing the methods discussed in this memo. 287 The MAC-NSH approach assumes security of (virtual) LAN segments. 289 Employing SFF functionality within Service Function software puts 290 trust in that software, but SF functions must in any case be trusted 291 to return packets to the correct path. 293 7. References 295 7.1. Normative References 297 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 298 Requirement Levels", BCP 14, RFC 2119, 299 DOI 10.17487/RFC2119, March 1997, 300 . 302 7.2. Informative References 304 [ETSI_NFV] 305 ETSI, "Network Functions Virtualization (NFV); 306 Architectural Framework", October 2013, 307 . 310 [I-D.ietf-sfc-nsh] 311 Quinn, P. and U. Elzur, "Network Service Header", draft- 312 ietf-sfc-nsh-02 (work in progress), January 2016. 314 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 315 Chaining (SFC) Architecture", RFC 7665, 316 DOI 10.17487/RFC7665, October 2015, 317 . 319 Authors' Addresses 320 David Dolson 321 Sandvine 322 408 Albert Street 323 Waterloo, ON N2L 3V3 324 Canada 326 Phone: +1 519 880 2400 327 Email: ddolson@sandvine.com 329 Michael Marchetti 330 Sandvine 331 408 Albert Street 332 Waterloo, ON N2L 3V3 333 Canada 335 Phone: +1 519 880 2400 336 Email: mmarchetti@sandvine.com 338 Kyle Larose 339 Sandvine 340 408 Albert Street 341 Waterloo, ON N2L 3V3 342 Canada 344 Phone: +1 519 880 2400 345 Email: klarose@sandvine.com