idnits 2.17.1 draft-homma-sfc-forwarding-methods-analysis-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 a Security Considerations section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 40 instances of too long lines in the document, the longest one being 5 characters in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 6 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 27, 2014) is 3468 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'CF' is mentioned on line 363, but not defined == Missing Reference: 'FWD' is mentioned on line 363, but not defined == Unused Reference: 'I-D.ietf-sfc-architecture' is defined on line 841, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-sfc-dc-use-cases' is defined on line 846, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-sfc-problem-statement' is defined on line 852, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-sfc-use-case-mobility' is defined on line 857, but no explicit reference was found in the text == Unused Reference: 'I-D.quinn-sfc-nsh' is defined on line 863, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-sfc-architecture-02 == Outdated reference: A later version (-06) exists of draft-ietf-sfc-dc-use-cases-01 == Outdated reference: A later version (-13) exists of draft-ietf-sfc-problem-statement-10 == Outdated reference: A later version (-09) exists of draft-ietf-sfc-use-case-mobility-01 == Outdated reference: A later version (-07) exists of draft-quinn-sfc-nsh-03 Summary: 3 errors (**), 0 flaws (~~), 15 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Service Function Chaining S. Homma 3 Internet-Draft K. Naito 4 Intended status: Informational NTT 5 Expires: April 30, 2015 D. R. Lopez 6 Telefonica I+D 7 October 27, 2014 9 Analysis on Forwarding Methods for Service Chaining 10 draft-homma-sfc-forwarding-methods-analysis-00 12 Abstract 14 Some working groups of the IETF and other Standards Developing 15 Organizations are now discussing use cases of a technology that 16 enables data packets to traverse appropriate service functions 17 through networks. This is called Service Chaining in this document. 18 (Also, in Network Functions Virtualisation (NFV), a subject that 19 forwarding packets to required service functions in appropriate order 20 is called VNF Forwarding Graph.) This draft does not focus only on 21 SFC method, and thus, use the term "Service Chaining". SFC may be 22 one method to realize Service Chaining. There are several Service 23 Chaining methods to forward data packets to service functions, and 24 the applicable methods will vary depending on the service/network 25 requirements of individual networks. 27 This document presents the results of analyzing packet forwarding 28 methods and path decision patterns for achieving Service Chaining. 29 For forwarding data packets to the appropriate service functions, 30 distribution of route infromation and steering data packets following 31 the route infromation, are required. Examples of route information 32 are packet identifier and the routing configurations based on the 33 identifier. Also, forwarding functions are required to decide the 34 path according to the route information. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on April 30, 2015. 53 Copyright Notice 55 Copyright (c) 2014 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 72 3. Classification of Forwarding Methods and SP Decision Patterns 5 73 3.1. Forwarding Methods . . . . . . . . . . . . . . . . . . . 5 74 3.1.1. Method 1: Forwarding Based on Flow Identifiable 75 Information . . . . . . . . . . . . . . . . . . . . . 5 76 3.1.2. Method 2: Forwarding with Stacked Transport Headers . 6 77 3.1.3. Method 3: Forwarding Based on Service Chain 78 Identifiable Tags . . . . . . . . . . . . . . . . . . 7 79 3.2. Service Path Decision Patterns . . . . . . . . . . . . . 9 80 3.2.1. Pattern 1: End to End Static Service Path . . . . . . 9 81 3.2.2. Pattern 2: Dynamically Determined Service Path . . . 11 82 4. Consideration of Service Chaining Methods and Architecture 83 Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 4.1. Analysis of 3.1. Forwarding Methods . . . . . . . . . . . 13 85 4.1.1. Analysis of Method 1 . . . . . . . . . . . . . . . . 13 86 4.1.2. Analysis of Method 2 . . . . . . . . . . . . . . . . 13 87 4.1.3. Analysis of Method 3 . . . . . . . . . . . . . . . . 14 88 4.2. Analysis of 3.2. Determination of Service Paths . . . . . 14 89 4.2.1. Analysis of Pattern 1 . . . . . . . . . . . . . . . . 14 90 4.2.2. Analysis of Pattern 2 . . . . . . . . . . . . . . . . 15 91 4.3. Example of selecting Methods and Patterns . . . . . . . . 16 92 4.3.1. Example A: Datacenter Network . . . . . . . . . . . . 17 93 4.3.2. Example B: Current Mobile Carrier Network . . . . . . 17 94 4.3.3. Example C: Fixed Mobile Convergence Network . . . . . 18 95 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 96 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 97 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 98 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 101 1. Introduction 103 Service Chaining is a technology that enables data packets to 104 traverse the appropriate service functions deployed in a network. 105 This draft assumes that Service Chaining is achieved in the following 106 steps: 108 a. A classification function identifies data packets and determines 109 the set of services that will be provided for the packets and in 110 which order. 112 b. The path, that the packets will traverse for reaching the required 113 service functions, is established based on the result of step a. 115 c. Forwarding functions determine the appropriate destination and 116 forward each packet to the next hop according to the path. 118 d. A service function provides services to received packets and 119 return each packet to the forwarding function. 121 e. Steps c and d are repeated until each packet has been transferred 122 to all required service functions. 124 f. After a packet has been transferred to all required Service 125 Functions, it is forwarded to its original destination. 127 There are several forwarding methods for Service Chaining, and they 128 can be classified into certain categories in terms of distribution of 129 information for setting the paths and decision of the paths. The 130 methods used to distribute the information and the patterns used to 131 decide the paths will affect the mechanism of Service Chaining as 132 well as service flexibility. 134 The applicable methods vary depending on network requirements, and 135 thus, classifying and determining forwarding methods will be 136 important in designing the architecture of Service Function Chaining 137 (SFC). This document provides the results of analyzing forwarding 138 methods for Service Chaining. 140 OAM, security, and redundancy are outside the scope of this draft. 142 2. Definition of Terms 144 Term "Classification", "Classifier" referred to draft-merged-sfc- 145 architecture-01. Term "Service Function", "Service Node" referred to 146 draft-ietf-sfc-dc-use-cases-01. 148 Service Chaining: A technology that lets data packets traverse a 149 series of service functions. 151 Classification: Locally instantiated policy and customer/network/ 152 service profile matching of traffic flows for identification of 153 appropriate outbound forwarding actions. 155 Classifier (CF): The entity that performs classification. 157 Service Function (SF): A function that is responsible for specific 158 treatment of received packets. A Service Function can act at 159 various layers of a protocol stack (e.g. at the network layer or 160 other OSI layers). A Service Function can be a virtual element or 161 be embedded in a physical network element. One of multiple 162 Service Functions can be embedded in the same network element. 163 Multiple occurrences of the Service Function can be enabled in the 164 same administrative domain. 166 One or more Service Functions can be involved in the delivery of 167 added-value services. A non-exhaustive list of Service Functions 168 includes: firewalls. WAN and application acceleration, Deep 169 Packet Inspection (DPI), LI (Lawful Intercept) module, server load 170 balancers, NAT44 [RFC3022], NAT64 [RFC6146]. NPTv6 [RFC6296], 171 HOST_ID injection, HTTP Header Enrichment functions, TCP 172 optimizer, etc. 174 Service Node (SN): A virtual or physical device that hosts one or 175 more service functions, which can be accessed via the network 176 location associated with it. 178 Forwarder (FWD): The entity, responsible for forwarding data packets 179 along the service path, which includes delivery of traffic to the 180 connected service functions. FWD handles Forwarding Tables, which 181 is used for forwarding packets. 183 Control Entity (CE): The entity responsible for managing service 184 topology and indicating forwarding configurations to Forwarders. 186 Service Chain (SC): A service chain defines an ordered list of 187 service functions that must be applied to user packets selected as 188 a result of classification. The implied order may not be a linear 189 progression as the architecture allows for nodes that copy to more 190 than one branch. 192 Service Path (SP): The instantiation of a service chain in the 193 network. Packets follow a service function path through the 194 requisite service functions. SP shows a specific path of 195 taraversing SF instance. For example, SC is written as SF#1 -> 196 SF#2 -> SF#3 (This shows an ordered list of SFs), and SP is 197 written as SF#1_1(1_1 means instance 1 of SF1) -> SF#2_1 -> 198 SF#3_1. 200 Service Chaining Domain (SC Domain): The domain managed by one or a 201 set of CEs. 203 Service Path Information (SPI): The information used to forward 204 packets to The appropriate SFs based on the selected service. 205 Examples of SPI include routing configurations for Forwarders, 206 transport headers for forwarding packets to required SFs, and 207 service/flow identifiable tags. 209 3. Classification of Forwarding Methods and SP Decision Patterns 211 3.1. Forwarding Methods 213 In Service Chaining, data packets are transferred to service 214 functions, which can be located outside the regular computed path to 215 the original destination. Therefore, a routing mechanism that is 216 different from general L2/L3 switching/routing may be required. The 217 routing mechanism can be classified into three methods in terms of 218 distribution of SPI and packet forwarding. 220 3.1.1. Method 1: Forwarding Based on Flow Identifiable Information 222 The mechanism of method 1 is shown in Figure 1. In this method, 223 routing configurations based on flow identifiable information, such 224 as 5-tuple (e.g. dst IP, src IP, dst port, src port, tcp) are 225 indicated to the CF and each FWD. There may be an CE to handle this. 226 The flow identifiable information can be constructed with some fields 227 of L2 or L3 or combination of those. The information can be 228 configured either before packets arrive, or at the time packets 229 arrive at CF and FWD. Each FWD identifies the packets with flow 230 identifable information and forwards the packets to the SFs according 231 to the configuration. This method does not require changing any 232 fields of the original packet frame. 234 *Distribution model of SPI* 236 +----------------+ 237 | Control Entity | 238 +----------------+ 239 ^ | indication of routing configuration 240 | | based on packet identifiable information 241 | +---------------+-------------------------------+-----------> 242 | | | | 243 | | | | 244 | v v v 245 +--------+ +-------+ +------+ +-------+ 246 ------->| CF |------> | FWD |------> | SF#1 |------>| FWD |-------> 247 +--------+ +-------+ +------+ +-------+ 249 //////////////////////////////////////////////////////////////////////////// 250 *Forwarding Tables* 252 Locate: [CF] [FWD] [FWD] 254 Table: 192.168.1.1 192.168.1.1 192.168.1.1 255 ->FWD#1 ->SF#1 ->SF#2 256 10.0.1.1 10.0.1.1 10.0.1.1 257 ->FWD#1 ->FWD#2 ->SF#2 258 ... ... ... 260 //////////////////////////////////////////////////////////////////////////// 261 *Condition of Packet* 263 Locate: [CF] [FWD] [SF#1] [FWD] 265 +-------+ +-------+ +-------+ +-------+ 266 Packet: | PDU | | PDU | | PDU | | PDU | 267 +-------+ +-------+ +-------+ +-------+ 269 Fig.1 Forwarding Based on Flow Identifiable Information 271 3.1.2. Method 2: Forwarding with Stacked Transport Headers 273 The mechanism of method 2 is shown in Figure 2. In this method, the 274 CF classifies packets and stacks transport headers, e.g., MPLS or GRE 275 headers, onto the packets based on the classification. The 276 configuration about how FWDs handle the headers is pre-configured. 277 Each FWD forwards the packets to SFs following the outermost header. 278 The outermost header is removed after each forwarding or service 279 process. The actions are repeated until all headers are removed. 281 *Distribution model of SPI* 283 +----------------+ 284 | Control Entity | 285 +----------------+ 286 ^ | 287 | | indication of 288 | | stacking headers 289 | v 290 +--------+ +-------+ +------+ +------+ 291 ---------->| CF |------>| SF#1 |------>| SF#2 |------>| SF#3 |------> 292 +--------+ +-------+ +------+ +------+ 294 ////////////////////////////////////////////////////////////////////////// 295 *Forwarding Tables* 297 Locate: [CF] 299 Table: 192.168.1.1 *********************************** 300 ->Stack #1,2,3 * Packets are forwarded to SFs by * 301 10.0.1.1 FWD1 * the outermost transport header. * 302 ->Stack #1,3 *********************************** 303 ... 305 ////////////////////////////////////////////////////////////////////////// 306 *Condition of Packet* 308 Locate: [CF] [SF#1] [SF#2] [SF#3] 310 +--------+ 311 Header: |To SF#1 | 312 +--------+ +--------+ 313 |To SF#2 | |To SF#2 | 314 +--------+ +--------+ +--------+ 315 |To SF#3 | |To SF#3 | |To SF#3 | 316 +--------+ +--------+ +--------+ 317 : : : : 318 +--------+ +--------+ +--------+ +--------+ 319 Packet: | PDU | | PDU | | PDU | | PDU | 320 +--------+ +--------+ +--------+ +--------+ 322 Fig.2 Forwarding with Stacked Multiple Transport Headers 324 3.1.3. Method 3: Forwarding Based on Service Chain Identifiable Tags 326 This method is shown in Figure 3. In this method, a CF classifies 327 each packet and attaches a tag for identifying the service or flows 328 on the packets based on the classification. The routing 329 configuration based on the tags is sent to each FWD (from some CE) in 330 advance. Each FWD fowards packets to the SFs following the 331 configuration and the tag. After a packet has traversed all SFs, the 332 tag is removed. 334 *Distribution model of SPI* 336 +----------------+ 337 | Control Entity | 338 +----------------+ 339 ^ | indication of attached tag 340 | | and routing configuration based on tags 341 | +----------------+------------------------------+---------> 342 | | | | 343 | | | | 344 | v v v 345 +--------+ +-------+ +------+ +-------+ 346 ----->| CF |------> | FWD |------>| SF#1 |------>| FWD |-----> 347 +--------+ +-------+ +------+ +-------+ 349 ////////////////////////////////////////////////////////////////////// 350 *Forwarding Tables* 352 Locate: [CF] [FWD] [FWD] 354 Table: 192.168.1.1 IF ID#1,3 IF ID#1,2,5 355 ->Stack ID#1 ->SF#1 ->SF#2 356 10.0.1.1 FWD1 357 ->Stack ID#2 358 ... ... ... 360 ////////////////////////////////////////////////////////////////////// 361 *Condition of Packet* 363 Locate: [CF] [FWD] [SF#1] [FWD] 365 +-------+ +-------+ +-------+ +-------+ 366 Tag: | ID#1 | | ID#1 | | ID#1 | | ID#1 | 367 +-------+ +-------+ +-------+ +-------+ 368 Packet:| PDU | | PDU | | PDU | | PDU | 369 +-------+ +-------+ +-------+ +-------+ 371 Fig.3 Forwarding Based on Service Chain Identifiable Tags 373 3.2. Service Path Decision Patterns 375 Since Service Chain contains only logical information (e.g. series of 376 services that are applied to flows and their sequences), the actual 377 instances, which are called Service Paths, are needed in order for 378 the forwarding process to work. In this process, an instance of 379 Service Path is created at certain points during a packet's delivery. 380 Therefore, to forward packets, the Service Chain needs to be turned 381 into an SP, which indicates specific FWDs (or switches, routers) and 382 SFs that the packets will be forwarded to. In the Service Chain to 383 SP change points, the paths that determine the Service Chaining are 384 classified into two patterns. 386 3.2.1. Pattern 1: End to End Static Service Path 388 The translation point is only a CF; that is, the SP is statically 389 pre-established as an end-to-end path. A CF inserts packets into the 390 appropriate pre-established path based on their classification. Each 391 FWD on the route has a routing table to uniquely determine the next 392 destination of packets, and each FWD statically forwards the received 393 packets to the next destination. FWDs require only a function to 394 receive indications of routing configurations from the CE. Pattern 1 395 can be achieved in the following ways. 397 3.2.1.1. SF Shared Model 399 Figure 4 shows the mechanism of this way. An SF is shared by 400 multiple SPs. In this way, the FWDs require a function to identify 401 packets and insert the packets into the next appropriate hop. 403 *Path Structure* 405 +----+ +-----+ +------+ +-----+ +------+ +-----+ +------+ 406 | |SC#1| FWD | | SF#1 | | FWD | |SF#2_1| | FWD | | SF#3 |SP#1 407 | |===================================================================> 408 | |SC#2| | | | | | +------+ | | | |SP#2 409 | |=================================# +------+ #======================> 410 | | | | +------+ | | # |SF#2_2| # | | +------+ 411 | | | | | | #==========# | | 412 ->| CF | +-----+ +-----+ +------+ +-----+ 413 | | 414 . . 415 . . 416 . . 417 +-----+ +------+ +-----+ +------+ 418 | |SC#n| FWD | | SF#4 | | FWD | | SF#5 |SP#n 419 | |===================================================================> 420 +----+ +-----+ +------+ +-----+ +------+ 422 SC:Service Chain 423 //////////////////////////////////////////////////////////////////////////// 424 *Packet Flow* 426 Service Chain#1: 427 SP#1 428 [ CF ]--->[ FWD ]-->[ SF#1 ]-->[ FWD ]-->[SF#2_1]-->[ FWD ]-->[ SF#3 ]--> 430 Service Chain#2: 431 SP#2 432 [ CF ]--->[ FWD ]-->[ SF#1 ]-->[ FWD ]-->[SF#2_2]-->[ FWD ]-->[ SF#3 ]--> 433 : 434 Service Chain#n: 435 SP#n 436 [ CF ]--->[ FWD ]-->[ SF#4 ]----------------------->[ FWD ]-->[ SF#5 ]--> 438 Fig.4 SF Shared Model 440 3.2.1.2. SF Dedicated Model 442 Figure 5 shows the mechanism of this style. An SF (instance) is used 443 by only one single SP; in other words, there is an SF instance per 444 SP. At each FWD, incoming packets are statically routed to a single 445 predefined next hop. 447 *Path Structure* 449 +----+ +-----+ +------+ +-----+ +------+ +-----+ +------+ 450 | |SC#1| FWD | |SF#1_1| | FWD | |SF#2_1| | FWD | |SF#3_1|SP#1 451 | |===================================================================> 452 | | +-----+ +------+ +-----+ +------+ +-----+ +------+ 453 | | +-----+ +------+ +-----+ +------+ +-----+ +------+ 454 | |SC#2| FWD | |SF#1_2| | FWD | |SF#2_2| | FWD | |SF#3_2|SP#2 455 | |===================================================================> 456 ->| CF | +-----+ +------+ +-----+ +------+ +-----+ +------+ 457 | | 458 . . 459 . . 460 . . 461 +-----+ +------+ +-----+ +------+ 462 | |SC#n| FWD | | SF#4 | | FWD | | SF#5 |SP#n 463 | |===================================================================> 464 +----+ +-----+ +------+ +-----+ +------+ 466 SC:Service Chain 467 ///////////////////////////////////////////////////////////////////////////// 468 *How packets traverse* 470 Service Chain#1: 471 SP#1 472 [ CF ]--->[ FWD ]-->[SF#1_1]-->[ FWD ]-->[SF#2_1]-->[ FWD ]-->[SF#3_1]--> 474 Service Chain#2: 475 SP#2 476 [ CF ]--->[ FWD ]-->[SF#1_2]-->[ FWD ]-->[SF#2_2]-->[ FWD ]-->[SF#3_2]--> 477 : 478 Service Chain#n: 479 SP#n 480 [ CF ]--->[ FWD ]-->[ SF#4 ]----------------------->[ FWD ]-->[ SF#5 ]--> 482 Fig.5 SF Dedicated Model 484 3.2.2. Pattern 2: Dynamically Determined Service Path 486 The mechanism of this style is shown in Figure 6. The translation 487 points are a CF and FWDs. The SP is established by a series of 488 multiple paths, which are sectioned by CFs and FWDs. Each path 489 determined by CFs and FWDs is referred to as a segmented path in this 490 draft. CFs or FWDs that determine the next segmented path may 491 require notification of routing configurations from the CE. 492 Moreover, some FWDs require functions to select the destination of 493 packets from various alternatives and to retrieve the information for 494 selecting the next path. For example, each FWD obtains metric 495 information or load conditions of servers and selects an optimal 496 segmented path based on that information. The CE may have the 497 selection mechanism and may notify CSs/FWDs of it. 499 *Path Structure* 501 +----+ +-----+ +------+ +-----+ +------+ +-----+ +------+ 502 | |SC#1| FWD | | SF#1 | | FWD | |SF#2_1| | FWD | | SF#3 |SP#1 503 | |============================*======================================> 504 | | | | | | | # | +------+ | | | |SP#2 505 | | | | | | | # +------+ #======================> 506 | | | | +------+ | # | |SF#2_2| # | | +------+ 507 | | | | | #===============# | | 508 ->| CF | +-----+ +-----+ +------+ +-----+ 509 | | 510 . . 511 . . 512 . . 513 +-----+ +------+ +-----+ +------+ 514 | |SC#n| FWD | | SF#4 | | FWD | | SF#5 |SP#m 515 | |===================================================================> 516 +----+ +-----+ +------+ +-----+ +------+ 517 SC:Service Chain 518 //////////////////////////////////////////////////////////////////////////// 520 *How packets traverse* 522 Service Chain#1: 523 SP#1 524 [ CF ]--->[ FWD ]-->[ SF#1 ]-->[ FWD ]-->[SF#2_1]-->[ FWD ]-->[ SF#3 ]--> 526 SP#2 527 [ CF ]--->[ FWD ]-->[ SF#1 ]-->[ FWD ]-->[SF#2_2]-->[ FWD ]-->[ SF#3 ]--> 528 : 529 Service Chain#n: 530 SP#m 531 [ CF ]--->[ FWD ]-->[ SF#4 ]----------------------->[ FWD ]-->[ SF#5 ]--> 533 Fig.6 Dynamically Determined Service Path 535 4. Consideration of Service Chaining Methods and Architecture Patterns 537 This chapter presents the results of analyzing the forwarding methods 538 and architecture patterns in chapter 3. 540 4.1. Analysis of 3.1. Forwarding Methods 542 4.1.1. Analysis of Method 1 544 This method can achieve Service Chaining without adding any headers 545 to packets, so it may not cause any increase in packet size or be 546 subject to MTU restrictions. Furthermore, this method does not 547 require additional functions within SFs to be applied to any headers 548 because data packets are transported in original format. Therefore, 549 it will be easier to use legacy SFs for network operators. 551 However, forwarding entries or static configuration for a flow at 552 each FWD is required. For example, if there are 10,000 flows to be 553 handled at a CF/FWD, the routing table for each CF/FWD uses 10,000 554 flow entries at most. Therefore, it might not be feasible for large- 555 scale networks such as carrier networks that handle a Service Chain 556 per user (which means that individual users have their own policies), 557 because some large carriers have over a million users and even more 558 flows. Another concern is the traffic increase in the control plane 559 because route setting is required for each flow. Moreover, it may be 560 hard to use this method if some service functions modify header 561 fields of a packet or frame, for example, NAT/NAPT, in a chain. For 562 example, if a NAT changes the IP address of packets dynamically, the 563 FWDs that follow need to renew their routing tables. The results of 564 the above analysis suggest that this method may be suitable for 565 networks with a limited number of flows. 567 4.1.2. Analysis of Method 2 569 In this method, none of the FWDs require any specific routing tables 570 for Service Chaining, but they require a function to forward packets 571 based on header information, and to remove the outermost header from 572 the received packets. Therefore, the control plane would be simple 573 because the SC controller would not be required to manage the routing 574 configuration of FWDs. Also, there are already several technologies 575 proposed that can be used to achieve this method, such as MPLS. 577 However, the more the SFs packets traverse, the more headers have to 578 be added to the packet and this in turn means that the packet size 579 increases. But packet sizes are restricted by the minimal available 580 MTU of any link in the network path and exceeding the MTU will 581 require to fragement the original packet before starting to add more 582 headers required to the service chaining. This requires more 583 complexity in processing due to the fragementation, adds a new source 584 of errors, as fragments of packets can get lost and so the whole 585 original packet will get discared, and also will cause an increase in 586 traffic as more packets have to be processed by the network. 587 Moreover, from a hardware point of view, it might be challenging for 588 FWDs or SFs to process packets with variable length headers. In 589 terms of SF equipments, if fragmented packets need to be reassembled 590 at every SF, this would be very wasteful of CPU resources, and some 591 equipment has restricted resources and memory for reassembly. The 592 results of the above analysis indicate that this method would be 593 appropriate when the number of SFs in an SC is small, or most packets 594 are forwarded to a static SP. On the other hand, it may be 595 unsuitable in cases where there are many SFs in a chain. 597 4.1.3. Analysis of Method 3 599 In this method, a tag is defined for each Service Chain. By adopting 600 single fixed-length tags, this method can prevent an increase in the 601 amount of traffic in the data plane, and can provide an upper bound 602 on packet size. (Problems which happen as a result of exceeding MTU 603 are stated in 4.1.2.) This method also enables FWDs to save 604 resources when handling flow entries. Therefore, this method has 605 many advantages in terms of scalability, and it might be appropriate 606 for use in large-scale networks. 608 However, this method might require renewal of equipments, or 609 Operating Systems (OSes) installed in hardware, or softwares, or any 610 other components to realize the method in network which includes SFs, 611 if this tag handling is an entirely new mechanism. Furthermore 612 discussion might be required to deploy such standardized 613 technologies. 615 4.2. Analysis of 3.2. Determination of Service Paths 617 4.2.1. Analysis of Pattern 1 619 In this pattern, the mechanism of FWDs would be simpler than the one 620 in pattern 2 because FWDs do not require any functions to select 621 paths or retrieve any information for determination of the next hop. 622 Moreover, it is not necessary to maintain the state of each flow. 624 However, this pattern will impact the flexibility of the SCs, as 625 adding new SFs to a SC, removing SFs from a SC, or migrating SFs to 626 other locations requires an update or new creation of a path in the 627 Service Path. Furthermore, unified management of FWDs and SFs in an 628 SC domain would be required in setting end-to-end paths. Therefore, 629 the management system of SPs, for example, a CE, for wide-area 630 networks that include several segments may be massive and complex. 631 Figure 7 shows the case in which SPs are established across multiple 632 datacenters in pattern 1. In Figure 7, a CE manages multiple 633 datacenters as a single SC domain for establishing SPs across 634 multiple datacenters. 636 In pattern 4.2.1.2 (SF Dedicated Model), the number of flow entries 637 that FWDs hold can be extremely small, as FWDs hold only static next- 638 hop information. Also, the CF function would be simple, as the CF 639 only determines the gateway of each SP. However, because the SF 640 (instance) is settled for each SP, resource usage would be high if 641 there were many SPs. 643 +--------------+ 644 +-----------+Control Entity+----------+ 645 | +--------------+ | 646 | | 647 ************ | *********************************** | ***************** 648 * | | * 649 * /------+------\ /------+------\ * 650 * / Datacenter#1 \ /------\ / Datacenter#2 \ * 651 * +----+ \ / WAN \ / \ * 652 * | |======================================================> SP#1 * 653 * | CF |======================================================> SP#2 * 654 * : : : * 655 * | |======================================================> SP#n * 656 * +----+ / \ / \ / * 657 * \---------------/ \------/ \-------------/ * 658 * * 659 * SC Domain * 660 ********************************************************************** 662 Fig.7 Establishment of SPs Accross Multiples DCs in Pattern 1 664 4.2.2. Analysis of Pattern 2 666 In this pattern, SPs are established with a combination of segmented 667 paths, so it enables SPs to be established flexibly (which means, CEs 668 do not need to constantly manage the entire end-to-end SP) based on 669 additional information such as the load condition of SFs. 671 Furthermore, in cases where some SPs traverse multiple datacenters 672 across a WAN, SPs could be established with a combination of 673 segmented paths that each datacenter determines independently based 674 on the Service Chain information. Therefore, it might be possible to 675 separate SC domains into several small areas for WANs, which would 676 enable a simpler configuration of each CE. Figures 8 shows the case 677 in which SPs are established across multiple datacenters in pattern 678 2. In Figure 8, each CE manages a single datacenter independently, 679 and the CEs synchronize the Service Chain information for 680 establishing and determining the appropriate segmented SPs in each 681 domain. 683 However, the (fault) monitoring of the whole SC can get harder as 684 multiple domains are part of the SC. On the other hand each domain 685 can perfom its fault management as required (and probably better as 686 it is more specific). This will require an overarching (fault) 687 monitoring where information from multiple SC domains is collected 688 and aggregated to get a full view of the end-to-end service of the 689 SC. 691 Moreover, in this pattern, some FWDs may require additional 692 mechanisms to select the next segmented path, and the FWDs must 693 maintain the states of each flow because some SFs require a stateful 694 process, and the FWDs need to insert packets into the same SF 695 instances in the same session. 697 Synchronization of 698 Service Chain info. 699 +-------------------------------------+ 700 | | 701 v v 702 +--------------+ +--------------+ 703 |Control Entity| |Control Entity| 704 +------+-------+ +------+-------+ 705 | | 706 ************ | ************* ********** | ************** 707 * | * * | * 708 * /------+------\ * * /------+------\ * 709 * / Datacenter#1 \ * /------\ * / Datacenter#2 \ * 710 * +----+ +-----+ * / WAN \ * +-----+ | * 711 * | |==========>| | * | | * | |===========> SP#1* 712 * | CF |==========>| FWD |===============>| FWD |===========> SP#2* 713 * : : : * | | * : : : * 714 * | |==========>| | * \ / * | |===========> SP#n* 715 * +----+ +-----+ * \------/ * +-----+ / * 716 * \---------------/ * * \-------------/ * 717 * * * * 718 * SC Domain#1 * * SC Domain#2 * 719 **************************** *************************** 721 Fig.8 Establishment of SPs Accross Multiples DCs in pattern 2 723 4.3. Example of selecting Methods and Patterns 725 In this section, clarifications about the most suitable method and 726 pattern are made for the following example networks based on the 727 results of the above analysis. 729 4.3.1. Example A: Datacenter Network 731 The conditions of network A are as follows: 733 1. The network is used for several business offices as a single DC. 735 2. Service Chain varies per office (not per user). 737 3. The number of SF included in for each Service Chain is few. (e.g. 738 within 5.) 740 4. SF (instance) cost is not so high. 742 5. MTU should not be restricted. 744 6. Service Chains do not fork paths through end-to-end. (As 745 monitoring, or controlling will be harder, some operators may not 746 want to change paths after packets got into a service chain.) 748 On the basis of conditions 4 and 6, Pattern 1 (SF Dedicated Model) 749 would be selected. In this case, any method would be applicable. 750 (Even if method 2 is selected, only one header that shows the gateway 751 to the specific SC is stacked on packets. This does not restrict the 752 MTU.) 754 4.3.2. Example B: Current Mobile Carrier Network 756 The conditions of network B are as follows: 758 1. The network handles millions of users. 760 2. Service Chain (SF set and order) is predefined and limited. 762 3. The number of SF, included in for each Service Chain, is few. 763 (e.g. within 5.) 765 4. The user chooses or the provider can choose for the user a 766 predefined Service Chain to adopt to their traffic. 768 5. SFs are located in (S)Gi-LAN.(Term referred to draft-ietf-sfc-use- 769 case-mobility-01) 771 6. Service Chains do not require to fork paths through end-to-end. 773 On the basis of conditions 1, 2, and 5, Pattern 1 (SF Shared Model) 774 would be selected because the architecture would be simple. 776 On the basis of conditions 3 and 4, method 1 (unless the 777 configuration or forwarding table does not increase explosively) or 3 778 would be applicable. 780 4.3.3. Example C: Fixed Mobile Convergence Network 782 Conditions of the network A is as follows: 784 1. The network handles millions of users. 786 2. The user chooses or the provider can choose for the user multiple 787 SFs to adopt to their traffic. 789 3. Many SFs (e.g. 5 or more,) are included in for each Service Chain. 791 4. SFs are located in multiple DCs.(e.g. Some delay sensitive SFs, 792 or SFs which should be placed near users' locations are installed 793 in DCs located locally, and added-value SFs are installed in DCs 794 located centrally.) 796 5. There are some expansive SFs (instance) that should be shared by 797 several SPs. 799 6. Service Chains may be forked according to the process of SF. 801 On the basis of conditions 1, 2, 3, 4, and 5, Method 3 would be 802 applicable in terms of scalability. Pattern 2 should be selected 803 based on conditions 1 and 6. Although the operation would be 804 complex, there may be a case in which some carriers set multiple DCs 805 and separate SC domains according to their network or service policy. 806 The use case and architecture pattern is introduced in draft-ietf- 807 sfc-dc-use-cases-01. 809 5. Acknowledgements 811 The authors would like to thank Konomi Mochizuki and Lily Guo for 812 their reviews and comments. 814 6. Contributors 816 The following people are active contributors to this document and 817 have provided review, content and concepts (listed alphabetically by 818 surname): 820 Hiroshi Dempo 821 NEC 823 David Dolson 824 Sandvine 826 Ron Parker 827 Affirmed Networks 829 Paul Quinn 830 Cisco Systems 832 Martin Stiemerling 833 NEC 835 7. IANA Considerations 837 This memo includes no request to IANA. 839 8. References 841 [I-D.ietf-sfc-architecture] 842 Halpern, J. and C. Pignataro, "Service Function Chaining 843 (SFC) Architecture", draft-ietf-sfc-architecture-02 (work 844 in progress), September 2014. 846 [I-D.ietf-sfc-dc-use-cases] 847 Surendra, S., Tufail, M., Majee, S., Captari, C., and S. 848 Homma, "Service Function Chaining Use Cases In Data 849 Centers", draft-ietf-sfc-dc-use-cases-01 (work in 850 progress), July 2014. 852 [I-D.ietf-sfc-problem-statement] 853 Quinn, P. and T. Nadeau, "Service Function Chaining 854 Problem Statement", draft-ietf-sfc-problem-statement-10 855 (work in progress), August 2014. 857 [I-D.ietf-sfc-use-case-mobility] 858 Haeffner, W., Napper, J., Stiemerling, M., Lopez, D., and 859 J. Uttaro, "Service Function Chaining Use Cases in Mobile 860 Networks", draft-ietf-sfc-use-case-mobility-01 (work in 861 progress), July 2014. 863 [I-D.quinn-sfc-nsh] 864 Quinn, P., Guichard, J., Fernando, R., Surendra, S., 865 Smith, M., Yadav, N., Agarwal, P., Manur, R., Chauhan, A., 866 Elzur, U., Garg, P., McConnell, B., and C. Wright, 867 "Network Service Header", draft-quinn-sfc-nsh-03 (work in 868 progress), July 2014. 870 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 871 Address Translator (Traditional NAT)", RFC 3022, January 872 2001. 874 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 875 NAT64: Network Address and Protocol Translation from IPv6 876 Clients to IPv4 Servers", RFC 6146, April 2011. 878 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 879 Translation", RFC 6296, June 2011. 881 Authors' Addresses 883 Shunsuke Homma 884 NTT, Corp. 885 3-9-11, Midori-cho 886 Musashino-shi, Tokyo 180-8585 887 Japan 889 Email: homma.shunsuke@lab.ntt.co.jp 891 Kengo Naito 892 NTT, Corp. 893 3-9-11, Midori-cho 894 Musashino-shi, Tokyo 180-8585 895 Japan 897 Email: naito.kengo@lab.ntt.co.jp 899 Diego R. Lopez 900 Telefonica I+D. 901 Don Ramon de la Cruz, Street 902 Madrid 28006 903 Spain 905 Phone: +34 913 129 041 906 Email: diego.r.lopez@telefonica.com