idnits 2.17.1 draft-homma-sfc-forwarding-methods-analysis-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: ---------------------------------------------------------------------------- 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 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 (June 8, 2015) is 3239 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'CF' is mentioned on line 378, but not defined == Missing Reference: 'FWD' is mentioned on line 378, but not defined == Unused Reference: 'RFC7498' is defined on line 1281, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-dolson-sfc-hierarchical-00 == Outdated reference: A later version (-11) exists of draft-ietf-sfc-architecture-08 == Outdated reference: A later version (-06) exists of draft-ietf-sfc-dc-use-cases-02 == Outdated reference: A later version (-28) exists of draft-ietf-sfc-nsh-00 == Outdated reference: A later version (-09) exists of draft-ietf-sfc-use-case-mobility-03 == Outdated reference: A later version (-08) exists of draft-song-sfc-legacy-sf-mapping-04 Summary: 2 errors (**), 0 flaws (~~), 12 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: December 10, 2015 D. R. Lopez 6 Telefonica I+D 7 M. Stiemerling 8 NEC/H-DA 9 D. Dolson 10 Sandvine 11 A. Gorbunov 12 Nokia 13 N. Leymann 14 Deutsche Telekom AG 15 June 8, 2015 17 Analysis on Forwarding Methods for Service Chaining 18 draft-homma-sfc-forwarding-methods-analysis-02 20 Abstract 22 Some working groups of the IETF and other Standards Developing 23 Organizations are now discussing use cases of a technology that 24 enables data packets to traverse appropriate service functions 25 located remotely through networks. This is called Service Chaining 26 in this document. (Also, in Network Functions Virtualisation (NFV), 27 a subject that forwarding packets to required service functions in 28 appropriate order is called VNF Forwarding Graph.) This draft does 29 not focus only on SFC method, and thus, use the term "Service 30 Chaining." SFC may be one of approaches to realize Service Chaining. 31 There are several Service Chaining methods to forward data packets to 32 service functions, and the applicable methods will vary depending on 33 the service requirements of individual networks. 35 This document presents the results of analyzing packet forwarding 36 methods and path selection patterns for achieving Service Chaining. 37 For forwarding data packets to the appropriate service functions, 38 distribution of route information and steering data packets following 39 the route information, are required. Examples of route information 40 are packet identifier and the routing configurations based on the 41 identifier. Also, forwarding functions are required to decide the 42 path according to the route information. 44 Status of This Memo 46 This Internet-Draft is submitted in full conformance with the 47 provisions of BCP 78 and BCP 79. 49 Internet-Drafts are working documents of the Internet Engineering 50 Task Force (IETF). Note that other groups may also distribute 51 working documents as Internet-Drafts. The list of current Internet- 52 Drafts is at http://datatracker.ietf.org/drafts/current/. 54 Internet-Drafts are draft documents valid for a maximum of six months 55 and may be updated, replaced, or obsoleted by other documents at any 56 time. It is inappropriate to use Internet-Drafts as reference 57 material or to cite them other than as "work in progress." 59 This Internet-Draft will expire on December 10, 2015. 61 Copyright Notice 63 Copyright (c) 2015 IETF Trust and the persons identified as the 64 document authors. All rights reserved. 66 This document is subject to BCP 78 and the IETF Trust's Legal 67 Provisions Relating to IETF Documents 68 (http://trustee.ietf.org/license-info) in effect on the date of 69 publication of this document. Please review these documents 70 carefully, as they describe your rights and restrictions with respect 71 to this document. Code Components extracted from this document must 72 include Simplified BSD License text as described in Section 4.e of 73 the Trust Legal Provisions and are provided without warranty as 74 described in the Simplified BSD License. 76 Table of Contents 78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 79 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 80 3. Classification of Forwarding Methods and SP Decision Patterns 5 81 3.1. Forwarding Methods . . . . . . . . . . . . . . . . . . . 5 82 3.1.1. Method 1: Forwarding Based on Flow Identifiable 83 Information . . . . . . . . . . . . . . . . . . . . . 5 84 3.1.2. Method 2: Forwarding with Stacked Transport Headers . 6 85 3.1.3. Method 3: Forwarding Based on Service Chain 86 Identifiable Tags . . . . . . . . . . . . . . . . . . 8 87 3.2. Service Path Selection Patterns . . . . . . . . . . . . . 9 88 3.2.1. Pattern 1: Static Selection of End to End Service 89 Path . . . . . . . . . . . . . . . . . . . . . . . . 10 90 3.2.2. Pattern 2: Dynamic Selection of Segmented Service 91 Path . . . . . . . . . . . . . . . . . . . . . . . . 12 92 4. Consideration of Forwarding Methods and Paths Selection 93 Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . 18 94 4.1. Analysis of 3.1. Forwarding Methods . . . . . . . . . . . 18 95 4.1.1. Analysis of Method 1 . . . . . . . . . . . . . . . . 18 96 4.1.2. Analysis of Method 2 . . . . . . . . . . . . . . . . 19 97 4.1.3. Analysis of Method 3 . . . . . . . . . . . . . . . . 20 98 4.2. Analysis of 3.2. Service Paths Selection Patterns . . . . 21 99 4.2.1. Analysis of Pattern 1 . . . . . . . . . . . . . . . . 21 100 4.2.2. Analysis of Pattern 2 . . . . . . . . . . . . . . . . 22 101 4.3. Example of selecting Methods and Patterns . . . . . . . . 25 102 4.3.1. Example#1: Enterprise Datacenter Network . . . . . . 25 103 4.3.2. Example#2: Current Mobile Service Providers Network . 26 104 4.3.3. Example#3: Fixed and Mobile Converged Service 105 Providers Network . . . . . . . . . . . . . . . . . . 27 106 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 107 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28 108 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 109 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 112 1. Introduction 114 Service Chaining is a technology to provide service oriented 115 forwarding which enables data packets to traverse the appropriate 116 service functions deployed in networks. This draft assumes that 117 Service Chaining is achieved by the following steps: 119 a. A classification function identifies data packets and determines 120 the set of services that will be provided for the packets and in 121 which order. 123 b. The path, that the packets will traverse for reaching the required 124 service functions, is established based on the result of step a. 125 The paths may be established in advance. 127 c. Forwarding functions determine the appropriate destination and 128 forward each packet to the next hop according to the path. 130 d. A service function provides services to received packets and 131 return each packet to the forwarding function. 133 e. Steps c and d are repeated until each packet has been transferred 134 to all required service functions. 136 f. After a packet has been transferred to all required Service 137 Functions, it is forwarded to its original destination. 139 There are several forwarding methods for Service Chaining, and they 140 can be classified into certain categories in terms of distribution of 141 information for setting the paths and decision of the paths. The 142 methods used to distribute the information and the patterns used to 143 decide the paths will affect the mechanism of Service Chaining as 144 well as service flexibility. 146 The applicable methods vary depending on network requirements, and 147 thus, classifying and determining forwarding methods will be 148 important in designing the architecture of Service Function Chaining 149 (SFC). This document provides the results of analyzing forwarding 150 methods for Service Chaining. 152 OAM, security, and redundancy are outside the scope of this draft. 154 2. Definition of Terms 156 Term "Classification", "Classifier" referred to 157 [I-D.ietf-sfc-architecture]. Term "Service Function", "Service Node" 158 referred to [I-D.ietf-sfc-dc-use-cases]. 160 Service Chaining: A technology that lets data packets traverse a 161 series of service functions. 163 Classification: Locally instantiated policy and customer/network/ 164 service profile matching of traffic flows for identification of 165 appropriate outbound forwarding actions. 167 Classifier (CF): The entity that performs classification. 169 Service Function (SF): A function that is responsible for specific 170 treatment of received packets. A Service Function can act at 171 various layers of a protocol stack (e.g. at the network layer or 172 other OSI layers). A Service Function can be a virtual element or 173 be embedded in a physical network element. One of multiple 174 Service Functions can be embedded in the same network element. 175 Multiple occurrences of the Service Function can be enabled in the 176 same administrative domain. 178 One or more Service Functions can be involved in the delivery of 179 added-value services. A non-exhaustive list of Service Functions 180 includes: firewalls. WAN and application acceleration, Deep 181 Packet Inspection (DPI), LI (Lawful Intercept) module, server load 182 balancers, NAT44 [RFC3022], NAT64 [RFC6146], NPTv6 [RFC6296], 183 HOST_ID injection, HTTP Header Enrichment functions, TCP 184 optimizer, etc. 186 Service Node (SN): A virtual or physical device that hosts one or 187 more service functions, which can be accessed via the network 188 location associated with it. 190 Forwarder (FWD): The entity, responsible for forwarding data packets 191 along the service path, which includes delivery of traffic to the 192 connected service functions. FWD handles Forwarding Tables, which 193 is used for forwarding packets. 195 Control Entity (CE): The entity responsible for managing service 196 topology and indicating forwarding configurations to Forwarders. 198 Service Chain (SC): A service chain defines an ordered list of 199 service functions that must be applied to user packets selected as 200 a result of classification. The implied order may not be a linear 201 progression as the architecture allows for nodes that copy to more 202 than one branch. 204 Service Path (SP): The instantiation of a service chain in the 205 network. Packets follow a service path through the requisite 206 service functions. Service path shows a specific path of 207 traversing SF instance. For example, SC is written as SF#1 -> 208 SF#2 -> SF#3 (This shows an ordered list of SFs), and SP is 209 written as SF#1_1(1_1 means instance 1 of SF1) -> SF#2_1 -> 210 SF#3_1. 212 Service Chaining Domain (SC Domain): The domain managed by one or a 213 set of CEs. 215 Service Path Information (SP Information): The information used to 216 forward packets to the appropriate SFs based on the selected 217 service. Examples of SP information include routing 218 configurations for Forwarders, transport headers for forwarding 219 packets to required SFs, and service/flow identifiable tags. 221 3. Classification of Forwarding Methods and SP Decision Patterns 223 3.1. Forwarding Methods 225 In Service Chaining, data packets are transferred to service 226 functions, which can be located outside the regular computed path to 227 the original destination. Therefore, a routing mechanism that is 228 different from general L2/L3 switching/routing may be required. The 229 routing mechanism can be classified into three methods in terms of 230 distribution of SP information and packet forwarding. 232 3.1.1. Method 1: Forwarding Based on Flow Identifiable Information 234 The mechanism of method 1 is shown in Figure 1. In this method, 235 routing configurations based on flow identifiable information, such 236 as 5-tuple (e.g. dst IP, src IP, dst port, src port, tcp) are 237 indicated to the CF and each FWD. There may be an CE to handle this. 238 The flow identifiable information can be constructed with some fields 239 of L2 or L3 or combination of those. The information can be 240 configured either before packets arrive, or at the time packets 241 arrive at CF and FWD. Each FWD identifies the packets with flow 242 identifiable information and forwards the packets to the SFs 243 according to the configuration. This method does not require 244 changing any fields of the original packet frame. 246 *Distribution model of SP information* 248 +----------------+ 249 | Control Entity | 250 +----------------+ 251 ^ | indication of routing configuration 252 | | based on packet identifiable information 253 | +---------------+-------------------------------+---------> 254 | | | | 255 | | | | 256 | v v v 257 +--------+ +-------+ +------+ +-------+ 258 ------>| CF |------> | FWD |------> | SF#1 |------>| FWD |-----> 259 +--------+ +-------+ +------+ +-------+ 261 //////////////////////////////////////////////////////////////////////// 262 *Forwarding Tables* 264 Locate: [CF] [FWD] [FWD] 266 Table: 192.168.1.1 192.168.1.1 192.168.1.1 267 ->FWD#1 ->SF#1 ->SF#2 268 10.0.1.1 10.0.1.1 10.0.1.1 269 ->FWD#1 ->FWD#2 ->SF#2 270 ... ... ... 272 //////////////////////////////////////////////////////////////////////// 273 *Condition of Packet* 275 Locate: [CF] [FWD] [SF#1] [FWD] 277 +-------+ +-------+ +-------+ +-------+ 278 Packet: | PDU | | PDU | | PDU | | PDU | 279 +-------+ +-------+ +-------+ +-------+ 281 Figure 1: Forwarding Based on Flow Identifiable Information 283 3.1.2. Method 2: Forwarding with Stacked Transport Headers 285 The mechanism of method 2 is shown in Figure 2. In this method, the 286 CF classifies packets and stacks transport headers in which actual 287 network address is included, e.g., MPLS or GRE headers, onto the 288 packets based on the classification. This method does not require 289 any forwarding function for forwarding packets based on the service 290 information. Forwarding functions of underlay networks forward the 291 packets to SFs following the outermost header. The outermost header 292 is removed after service process of the SF. The actions are repeated 293 until all headers are removed. 295 *Distribution model of SP information* 297 +----------------+ 298 | Control Entity | 299 +----------------+ 300 ^ | 301 | | indication of 302 | | stacking headers 303 | v 304 +--------+ +-------+ +------+ +------+ 305 -------->| CF |------>| SF#1 |------>| SF#2 |------>| SF#3 |------> 306 +--------+ +-------+ +------+ +------+ 308 //////////////////////////////////////////////////////////////////////// 309 *Forwarding Tables* 311 Locate: [CF] 313 Table: 192.168.1.1 __/__/__/__/__/__/__/__/__/__/__/__/__/ 314 ->Stack #1,2,3 __/ Packets are forwarded to SFs by __/ 315 10.0.1.1 __/ the outermost transport header. __/ 316 ->Stack #1,3 __/__/__/__/__/__/__/__/__/__/__/__/__/ 317 ... 319 //////////////////////////////////////////////////////////////////////// 320 *Condition of Packet* 322 Locate: [CF] [SF#1] [SF#2] [SF#3] 324 +--------+ 325 Header: |To SF#1 | 326 +--------+ +--------+ 327 |To SF#2 | |To SF#2 | 328 +--------+ +--------+ +--------+ 329 |To SF#3 | |To SF#3 | |To SF#3 | 330 +--------+ +--------+ +--------+ 331 : : : : 332 +--------+ +--------+ +--------+ +--------+ 333 Packet: | PDU | | PDU | | PDU | | PDU | 334 +--------+ +--------+ +--------+ +--------+ 336 Figure 2: Forwarding with Stacked Multiple Transport Headers 338 3.1.3. Method 3: Forwarding Based on Service Chain Identifiable Tags 340 The mechanism of this method is shown in Figure 3. In this method, a 341 CF classifies each packet and attaches a tag for identifying the 342 service or flow on the packets based on the classification. The 343 routing configuration based on the tags is sent to each FWD (from 344 some CE) in advance. Each FWD forwards packets to the SFs following 345 the configuration and the tag. After a packet has traversed all SFs, 346 the tag is removed and the packet is transported to the original 347 destination. 349 *Distribution model of SP information* 351 +----------------+ 352 | Control Entity | 353 +----------------+ 354 ^ | indication of attached tag 355 | | and routing configuration based on tags 356 | +----------------+------------------------------+---------> 357 | | | | 358 | | | | 359 | v v v 360 +--------+ +-------+ +------+ +-------+ 361 ----->| CF |------> | FWD |------>| SF#1 |------>| FWD |-----> 362 +--------+ +-------+ +------+ +-------+ 364 ////////////////////////////////////////////////////////////////////// 365 *Forwarding Tables* 367 Locate: [CF] [FWD] [FWD] 369 Table: 192.168.1.1 IF ID#1,3 IF ID#1,2,5 370 ->Stack ID#1 ->SF#1 ->SF#2 371 10.0.1.1 372 ->Stack ID#2 373 ... ... ... 375 ////////////////////////////////////////////////////////////////////// 376 *Condition of Packet* 378 Locate: [CF] [FWD] [SF#1] [FWD] 380 +-------+ +-------+ +-------+ +-------+ 381 Tag: | ID#1 | | ID#1 | | ID#1 | | ID#1 | 382 +-------+ +-------+ +-------+ +-------+ 383 Packet:| PDU | | PDU | | PDU | | PDU | 384 +-------+ +-------+ +-------+ +-------+ 386 Figure 3: Forwarding Based on Service Chain Identifiable Tags 388 3.2. Service Path Selection Patterns 390 Since SC contains only logical information (e.g. series of services 391 that are applied to flows and their sequences), the actual instances, 392 which are called SPs, are needed in order for the forwarding process 393 to work. In this process, an instance of SP is created at certain 394 points during a packet's delivery. Therefore, to forward packets, 395 the SC needs to be turned into an SP, which indicates specific FWDs 396 (or switches, routers) and SFs that the packets will be forwarded to. 397 From the perspective of points translating SC to SP, the methods that 398 establish SPs from end to end are classified into two patterns. 400 3.2.1. Pattern 1: Static Selection of End to End Service Path 402 The translation point is only a CF; that is, the SP is statically 403 pre-established as an end-to-end path and a CF inserts packets into 404 the appropriate path based on the result of the classification. Each 405 FWD on the route has a forwarding table to uniquely determine the 406 next destination of packets, and each FWD statically forwards the 407 received packets to the next destination based on the table. FWD 408 requires only a function to receive indications of forwarding 409 configurations from the CE. Pattern 1 can be achieved in the 410 following ways. 412 3.2.1.1. SF Shared Model 414 Figure 4 shows the mechanism of this model. In this model, an SF is 415 shared by multiple SPs. Therefore, FWDs require a function to 416 identify SP for each packet and insert the packets into the next 417 appropriate hop. 419 *Path Structure* 421 +----+ +---+ +----+ +---+ +------+ +---+ +----+ 422 | |SC#1 |FWD| |SF#1| |FWD| |SF#2_1| |FWD| |SF#3| SP#1 423 | |==============================================================> 424 | |SC#2 | | | | | | +------+ | | | | SP#2 425 | |============================# +------+ #======================> 426 | | | | +----+ | | # |SF#2_2| # | | +----+ 427 | | | | | | #==========# | | 428 ->| CF | +---+ +---+ +------+ +---+ 429 | | 430 . . 431 . . 432 . . 433 +---+ +----+ +---+ +----+ 434 | |SC#n |FWD| |SF#4| |FWD| |SF#5| SP#n 435 | |==============================================================> 436 +----+ +---+ +----+ +---+ +----+ 438 SC:Service Chain SP:Service Path 439 /////////////////////////////////////////////////////////////////////// 440 *Packet Flow* 442 Service Chain#1: 443 SP#1 444 [ CF ]---->[FWD]-->[SF#1]-->[FWD]-->[SF#2_1]-->[FWD]-->[SF#3]---> 446 Service Chain#2: 447 SP#2 448 [ CF ]---->[FWD]-->[SF#1]-->[FWD]-->[SF#2_2]-->[FWD]-->[SF#3]---> 449 : 450 Service Chain#n: 451 SP#n 452 [ CF ]---->[FWD]-->[SF#4]--------------------->[FWD]-->[SF#5]---> 454 Figure 4: SF Shared Model 456 3.2.1.2. SF Dedicated Model 458 Figure 5 shows the mechanism of this model. In this model, an SF 459 instance (or a set of SF instances) is used by only one single SP; in 460 other words, a set of SF instance is prepared for each SP. At each 461 FWD, incoming packets are statically forwarded to the single 462 predefined next hop. 464 *Path Structure* 466 +----+ +---+ +------+ +---+ +------+ +---+ +------+ 467 | |SC#1 |FWD| |SF#1_1| |FWD| |SF#2_1| |FWD| |SF#3_1| SP#1 468 | |=============================================================> 469 | | +---+ +------+ +---+ +------+ +---+ +------+ 470 | | +---+ +------+ +---+ +------+ +---+ +------+ 471 | |SC#2 |FWD| |SF#1_2| |FWD| |SF#2_2| |FWD| |SF#3_2| SP#2 472 | |=============================================================> 473 ->| CF | +---+ +------+ +---+ +------+ +---+ +------+ 474 | | 475 . . 476 . . 477 . . 478 +---+ +------+ +---+ +------+ 479 | |SC#n |FWD| | SF#4 | |FWD| | SF#5 | SP#n 480 | |=============================================================> 481 +----+ +---+ +------+ +---+ +------+ 483 SC:Service Chain SP:Service Path 484 ////////////////////////////////////////////////////////////////////// 485 *How packets traverse* 487 Service Chain#1: 488 SP#1 489 [ CF ]--->[FWD]-->[SF#1_1]->[FWD]->[SF#2_1]->[FWD]->[SF#3_1]---> 491 Service Chain#2: 492 SP#2 493 [ CF ]--->[FWD]-->[SF#1_2]->[FWD]->[SF#2_2]->[FWD]->[SF#3_2]---> 494 : 495 Service Chain#n: 496 SP#n 497 [ CF ]--->[FWD]-->[ SF#4 ]------------------>[FWD]->[ SF#5 ]---> 499 Figure 5: SF Dedicated Model 501 3.2.2. Pattern 2: Dynamic Selection of Segmented Service Path 503 The mechanism of this pattern is shown in Figure 6. The translation 504 points are CFs and some FWDs. The SP is established by a series of 505 multiple paths, which are sectioned by CFs and FWDs. The path, which 506 is sectioned by CFs and FWDs, is referred to as a segmented path in 507 this draft. CFs or FWDs that select the next segmented path may 508 require notification of forwarding configurations from the CE. 509 Moreover, some FWDs require functions to select the destination of 510 packets from various alternatives and to retrieve the information for 511 selecting the next path. For example, each FWD obtains metric 512 information or load conditions of servers and selects an optimal 513 segmented path based on the information. The CE may have the 514 selection mechanism and may notify CFs or FWDs of it. 516 *Path Structure* 518 +----+ +---+ +----+ +---+ +------+ +---+ +----+ 519 | |SC#1 |FWD| |SF#1| |FWD| |SF#2_1| |FWD| |SF#3| SP#1 520 | |========================*=====================================> 521 | | | | | | | # | +------+ | | | | SP#2 522 | | | | | | | # | +------+ #======================> 523 | | | | +----+ | # | |SF#2_2| # | | +----+ 524 | | | | | #==============# | | 525 ->| CF | +---+ +---+ +------+ +---+ 526 | | 527 . . 528 . . 529 . . 530 +---+ +----+ +---+ +----+ 531 | |SC#n |FWD| |SF#4| |FWD| |SF#5| SP#m 532 | |==============================================================> 533 +----+ +---+ +----+ +---+ +----+ 535 SC:Service Chain SP:Service Path 536 /////////////////////////////////////////////////////////////////////// 538 *How packets traverse* 540 Service Chain#1: 541 SP#1 542 [ CF ]---->[FWD]-->[SF#1]-->[FWD]-->[SF#2_1]-->[FWD]-->[SF#3]---> 544 SP#2 545 [ CF ]---->[FWD]-->[SF#1]-->[FWD]-->[SF#2_2]-->[FWD]-->[SF#3]---> 546 : 547 Service Chain#n: 548 SP#m 549 [ CF ]---->[FWD]-->[SF#4]--------------------->[FWD]-->[SF#5]---> 551 Figure 6: Dynamic Selection of Segmented Service Path 553 In addition, this pattern accepts establishment of hierarchical 554 domains as following: 556 3.2.2.1. Hierarchical Service Path Domains 558 Complex problems often become manageable with a hierarchical 559 approach. This pattern allows network-wide orchestration of Service 560 Chaining to be relatively simple, while hiding the complexities of 561 fine-grained policy-based path selection within sub-domains. Each 562 sub-domain can be independently administered and orchestrated. This 563 architecture is described in [I-D.dolson-sfc-hierarchical]. 565 Figure 7 shows two levels of hierarchy in a service provider's 566 network. At the top level in the hierarchy, Service Chaining 567 components are: 569 1. Edge-classifiers (Edge CF) that reside near the edge of a service 570 provider's domain and 572 2. SF sub-domains that reside in data centers. 574 3. SF Domain Gateways that reside in data centers, linking together 575 the levels of the hierarchy. To the higher level, this is an SF. 576 To the lower level, this is a classifier and FWD. 578 *How packets traverse* 580 +----+ +-----+ +----------------------+ +-----+ 581 | |SC#1| FWD | |SF Domain Gateway#1 | | FWD | 582 ->| |================* *=====================> 583 | | +-----+ | # (in DC#1) # | +-----+ 584 | | | V # | 585 |Edge| |+---+ +---+| Top domain 586 | CF | * * * * *||CF | * * * * * *|FWD|| * * * * * 587 | | * |+---+ +-+-+| * 588 | | * | | | | | | Sub * 589 | | * +-o-o--------------o-o-+ domain* 590 | | * SC#1.2 | |SC#1.1 ^ ^ #1 * 591 | | * +-----+ | | | * 592 | | * | V | | * 593 | | * | +---+ +------+ | | * 594 | | * | |FWD|->|SF#1_1|--+ | * 595 | | * | +---+ +------+ | * 596 | | * V | * 597 | | * +---+ +------+ +---+ +------+ * 598 | | * |FWD|->|SF#1_2|->|FWD|->|SF#2_1| * 599 | | * +---+ +------+ +---+ +------+ * 600 . * * * * * * * * * * * * * * * * * * * * * * 601 . 602 | | +-----+ +---------------------+ +-----+ 603 | |SC#n| FWD | | SF Domain Gateway#q | | FWD | 604 | |=======================================================> 605 | | +-----+ | (in DC#m) | +-----+ 606 +----+ +---------------------+ 607 (Details of sub-domain #q not shown) 609 Figure 7: Service Chain Hierarchy in Service Provider Network 611 The components within an SF sub-domain are opaque at the top level; 612 each SF domain gateway acts as a single SF node in the top-level 613 domain. A service path in the top-level domain may visit multiple 614 sub-domains. 616 At the lower level in the hierarchy, each sub-domain contains an 617 independently administrated Service Chaining network, generally 618 comprised of multiple instances of multiple types of hosts, most 619 likely (but not necessarily) within the same data center. There is 620 no need for knowledge of the "big picture" at the level of the SF- 621 sub-domain except as required to forward packets to the other SFs 622 that are the next hop of each chain. 624 Note that different encapsulation methods can be used at each layer 625 in the hierarchy, provided the SF domain-Proxy can translate between 626 them. For example, MPLS could be used to deliver packets from 627 network edge to the SF clusters within data centers, and NSH 628 [I-D.ietf-sfc-nsh] could be used within the data center. 630 Details of Top Level of Hierarchy 632 In this pattern, referring to Figure 8, network-wide Service Chaining 633 orchestration is only concerned with creating service paths from 634 network edge points to sub-domains within data centers and 635 configuring classifiers at a coarse level to get the correct hosts' 636 traffic onto paths that will arrive at appropriate sub-domains. The 637 figure shows one possible service chain passing from edge, through 638 two sub-domains, to network egress. 640 This top level of orchestration may attach meta-data to provide 641 context from the network edge into the data center. 643 +------------+ 644 |Sub-domain#1| 645 | in DC1 | 646 +----+-------+ 647 | 648 .------+---------. +--+ 649 +--+ / / | \--|CF| 650 --->|CF|--/---->' | \ +--+ 651 +--+ / SC#1 | \ 652 | | | 653 | | .------>|---> 654 | / / | 655 \ | / / 656 +--+ \ | / / +--+ 657 |CF|---\ V / /---|CF| 658 +--+ '------+---------' +--+ 659 | 660 +----+-------+ 661 |Sub-domain#2| 662 | in DC2 | 663 +------------+ 665 Figure 8: Network-wide view of Top Level of Hierarchy 667 The orchestration at this top level must ensure bidirectional path 668 symmetry so that inbound packets traverse sub-domains in the reverse 669 order as outbound packets. 671 Because classifiers must have rules to handle any traffic passing 672 through the network, we believe that a useful approach to 673 classification will be to assign traffic to service function paths on 674 the basis of coarse classification like subscriber tier, tenant or 675 VRF identifier. These classification rules could be relatively 676 static, changing in response to provisioning but not in response to 677 traffic. 679 In some networks it might be possible to create a rule per 680 residential subscriber, resulting in rule updates when subscribers 681 are assigned IP addresses. However, with judicious allocation of IP 682 blocks, entire classes of subscribers could be classified with IP- 683 prefix rules. Similarly, in a mobile network path selection could be 684 based on APN. 686 Hence, there are methods of globally managing very large networks by 687 choosing a suitable classification granularity. 689 Details of Lower Level of Hierarchy 691 Within each SF sub-domain, there are: 693 1. An SF domain-gateway to receive incoming data packets on any of 694 the configured service chains and load-balance (if necessary) 695 traffic to classifiers, 697 2. Classifier(s) to select internal service chain to use, 698 potentially based on stateful flow analysis, DPI, etc. 700 3. Service components comprised of FWD and SF. 702 Local Service Chaining orchestration is concerned with providing 703 viable paths to various functions, providing failure recovery, NFV 704 elasticity, etc. 706 Classification within each sub-domain can be concerned with 707 determining the local service paths for individual transport-layer 708 flows based on ports, DPI and meta-data provided by the higher-level 709 chain. 711 For any classifier that is transport-layer-stateful, it is most 712 efficient for the same classifier instance to handle traffic in both 713 directions of a bidirectional connection. State tracking may require 714 that service function paths begin and end at the same node with the 715 flow state, where the same classifier instance can be used for both 716 directions of traffic. 718 4. Consideration of Forwarding Methods and Paths Selection Patterns 720 This chapter presents the results of analyzing the forwarding methods 721 and architecture patterns in chapter 3. 723 4.1. Analysis of 3.1. Forwarding Methods 725 4.1.1. Analysis of Method 1 727 Data Plane Aspects 729 This method can achieve Service Chaining without changing packet 730 format, such as attaching any header on packets, so it may not 731 cause any increase in packet size or be subject to MTU 732 restrictions. Furthermore, this method does not require 733 additional functions for SFs to apply or handle any header because 734 data packets are transported in original format. Therefore, it 735 will be easier to use legacy SFs for network operators. 737 On the other hand, it is difficult to forward a packet to same 738 FWDs several times because flow identifiable information is not 739 basically chainged in the forwarding processes. For example, 740 distinction of incoming ports will be required for FWD to decide 741 the next hop appropriately when a packet traverse it several 742 times. 744 Control Plane Aspects 746 This method requires FWDs to set forwarding entries for each flow. 747 For example, if there are 10,000 flows to be handled at a CF/FWD, 748 the forwarding table for each CF/FWD uses 10,000 flow entries at 749 most. Therefore, it might not be feasible for large-scale 750 networks such as carrier networks that handle a SC per user (which 751 means that individual users have their own policies), because some 752 large carriers have over a million users and even more flows. 753 Another concern is increase of control signaling because route 754 setting is required for each flow. Moreover, it may be hard to 755 use this method if some SFs modify header fields of a packet or 756 frame, for example, NAT/NAPT, in a chain. For example, if a NAT 757 changes the IP address of packets dynamically, the FWDs that 758 follow need to renew their forwarding tables. 760 The results of the above analysis suggest that, although this method 761 is beneficial in terms of impact to existing network, it would not be 762 scalable. Therefore, this method might be suitable for networks with 763 a limited number of flows. 765 Measurements taken in multiple residential service providers' 766 networks indicate that for each 1Gbps of traffic the sustained rate 767 of new flows can range from 1,000 flows/s to 30,000 flows/s. From 768 this, for example, there would be between 10,000 and 300,000 new 769 flows/s on a 10 Gbps link. Therefore, in some networks at some times 770 of day, this method using 5-tuple as flow identifiable information 771 would require sustaining up to 300,000 table updates per second for 772 each FWD. This incurs a significant amount of control traffic and 773 computational effort. 775 4.1.2. Analysis of Method 2 777 Data Plane Aspects 779 In this method, SP information is attached on each packet as 780 transport headers, and the number of the headers increases 781 depending on the number of SFs which the packet will traverse. 782 This means that size of each packet increases. Packet sizes may 783 be restricted by the minimal available MTU of any link in the 784 network and exceeding the MTU will require to fragment the 785 original packets. Fragmentation adds a new source of errors and 786 may require forwarding processes to be more complex. For example, 787 the whole original packet will get discarded even if one of 788 fragments of the packet gets lost, or in terms of SF equipment, it 789 would be very wasteful of CPU if fragmented packets need to be 790 reassembled at every SF resources, and some equipment has 791 restricted resources and memory for reassembly. Fragmentation 792 will also cause an increase in traffic as more packets have to be 793 processed by the network. 795 Moreover, this method requires SF to be applied to the headers 796 because they receive packets with optional headers. Therefore SFs 797 will be required to be able to recognize the headers, or proxy 798 functions, which remove the tags before inserting packets into SFs 799 and reattaches the appropriate tag on the returned packet, will be 800 required. In addition, when a SF is used by multiple SCs, it will 801 be challenging for SFs to process packets because header length 802 attached on each packet may vary and SFs are required to have a 803 mechanism to recognize the header length for each packet. 805 Control Plane Aspects 807 In this method, none of the FWDs require any specific forwarding 808 tables for Service Chaining or interface to receive indications of 809 forwarding configuration. Also, no CEs will be required to manage 810 the forwarding configuration of FWDs, so the control plane might 811 become simple. 813 On the other hand, some relay nodes such as switches or SFs are 814 required to have a function to remove the outermost header from 815 the received packets. FWDs also don't have identify flow or 816 service so can not change the following SPs. Moreover, CF must 817 grasp all of addresses of relay nodes which packets will traverse, 818 and it will require any CE to manage addresses of relay nodes and 819 a link between CF and the CE. There are already several 820 technologies proposed that can be used to achieve this method, 821 such as segment routing. 823 The results of the above analysis indicate that this method would be 824 appropriate when the number of SFs in a SC is small, and most SFs are 825 deployed in a single domain. On the other hand, it may be unsuitable 826 in cases where there are many SFs in a chain, or packets have to 827 traverse multiple domains. 829 4.1.3. Analysis of Method 3 831 Data Plane Aspects 833 In this method, a tag is defined for each SC and attached on each 834 packet. By adopting single fixed-length tag, this method can 835 prevent an increase in the amount of traffic, and can provide an 836 upper bound on packet size. (Problems which happen as a result of 837 exceeding MTU are stated in Section 4.1.2.) Also, FWDs recognize 838 the next hops of received packets from the tags independent of any 839 information of original packets. Therefore, SFs which modify 840 original packet format can be also used. In addition, it is easy 841 to change the following SPs on a route by renewing the tag. 843 On the other hand, this method requires SFs to be applied to the 844 tags because SFs receive packets with the tags. (Problems which 845 happens as result of inserting packet with optional tags into SF 846 are stated in Section 4.1.2) By using existing transport headers 847 as the tags or outer header for forwarding, effect on network 848 nodes such as existing router and switches might be restrained. 850 Control Plane Aspects 852 This method enables FWDs to save resources for managing forwarding 853 tables and all SPs may be established in advance in most of cases. 854 This prevents an increase of control signals, and also enables to 855 change the following SPs without changing forwarding 856 configurations of FWDs. 858 On the other hand, this method requires a new control mechanism 859 based on the tags, therefore, FWDs, CE and interface between them 860 have to be updated to apply forwarding configuration based on the 861 tags. 863 The results of the above analysis indicate that this method has many 864 advantages in terms of scalability, and it might be appropriate for 865 use in large-scaled networks in which there are many SFs and flows. 866 By the way, if the tag handling mechanism is an entirely new 867 architecture such as SFC[I-D.ietf-sfc-architecture], renewal or 868 introduction of several equipment such as FWDs and CE will be 869 required. 871 4.2. Analysis of 3.2. Service Paths Selection Patterns 873 4.2.1. Analysis of Pattern 1 875 In this pattern, the mechanism of FWDs would be simpler than the one 876 in pattern 2 because FWDs do not require any functions to select 877 paths or retrieve any information for determination of the next hop. 878 Moreover, it is not necessary to maintain the state of each flow. 879 Therefore, existing protocols for virtualizing networks, such as 880 VxLAN or MPLS, can be used to achieve Service Chaining in this 881 pattern. 883 However, this pattern will impact the flexibility of the SCs, as 884 adding new SFs to a SC, removing SFs from a SC, or migrating SFs to 885 other locations requires an update or new creation of a path in the 886 Service Path. Furthermore, unified management of FWDs and SFs in an 887 SC domain would be required in setting end-to-end paths. Therefore, 888 the management system of SPs, for example, a CE, for wide-area 889 networks that include several segments may be massive and complex. 890 Figure 9 shows the case in which SPs are established across multiple 891 datacenters in pattern 1. In Figure 9, a CE manages multiple 892 datacenters as a single SC domain for establishing SPs across 893 multiple datacenters. 895 In pattern 4.2.1.2 (SF Dedicated Model), the number of flow entries 896 that FWDs hold can be extremely small, as FWDs hold only static next- 897 hop information. Also, the CF function would be simple, as the CF 898 only determines the gateway of each SP. However, because the SF 899 (instance) is settled for each SP, resource usage would be high if 900 there were many SPs. 902 +--------------+ 903 . . . . . . . . . . |Control Entity| . . . . . 904 . . +--------------+ . 905 . . . 906 * * . * * * * . * * * * * * * * * * * * * * * * . * * * * * * * * * 907 * . . . * 908 * . . . * 909 * . .-----. .-----------. .-----. * 910 * +----+ / DC#1 \ / WAN \ / DC#2 \ * 911 * | |=====================================================> SP#1 * 912 * | CF |=====================================================> SP#2 * 913 * : : : * 914 * | |=====================================================> SP#n * 915 * +----+ \ / \ / \ / * 916 * '-----' '-----------' '-----' * 917 * * 918 * SC Domain * 919 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 921 Figure 9: Establishment of SPs Across Multiples DCs in Pattern 1 923 4.2.2. Analysis of Pattern 2 925 In this pattern, SPs are established with a combination of segmented 926 paths, so it enables SPs to be established flexibly (which means, CEs 927 do not need to constantly manage the entire end-to-end SP) based on 928 additional information such as the load condition of SFs. 930 Furthermore, as it is described in the previous section, in cases 931 where some SPs traverse multiple datacenters across a WAN, SPs could 932 be established with a combination of segmented paths that each 933 datacenter determines independently based on the Service Chain 934 information. Therefore, it might be possible to separate SC domains 935 into several small areas for WANs, which would enable a simpler 936 configuration of each CE. Figure 10 shows the case in which SPs are 937 established across multiple datacenters in pattern 2. In Figure 10, 938 each CE manages a single datacenter independently, and the CEs 939 synchronize the Service Chain information for establishing and 940 determining the appropriate segmented SPs in each domain. 942 However, the (fault) monitoring of the whole SC can get harder as 943 multiple domains are part of the SC. On the other hand, each domain 944 can perform its fault management as required (and probably better as 945 it is more specific). This will require an overarching (fault) 946 monitoring where information from multiple SC domains is collected 947 and aggregated to get a full view of the end-to-end service of the 948 SC. 950 Moreover, in this pattern, some FWDs may require additional 951 mechanisms to select the next segmented path, and the FWDs must 952 maintain the states of each flow because some SFs require a stateful 953 process, and the FWDs need to insert packets into the same SF 954 instances in the same session. 956 In case that SC information is conveyed to some components via data 957 plane as any encapsulation, a new protocol such as SFC 958 [I-D.ietf-sfc-architecture] will be required. 960 Synchronization of 961 Service Chain info. 962 +--------------------------------------+ 963 | | 964 v v 965 +--------+ +--------+ 966 | CE#1 | | CE#2 | 967 +--------+ +--------+ 968 . . 969 * * * * * * . * * * * * * * * * * * * . * * * * * * 970 * . * * . * 971 * .-------------. * * .------------. * 972 * / DC#1 \ * .------. * / DC#2 \ * 973 * +----+ +-----+ * / WAN \ * +-----+ | * 974 * | |=========>| | * | | * | CF/ |==========> SP#1 * 975 * | CF |=========>| FWD |===============>| FWD |==========> SP#2 * 976 * : : : * | | * : : : * 977 * | |=========>| | * \ / * | |==========> SP#n * 978 * +----+ +-----+ * '------' * +-----+ | * 979 * \ / * * \ / * 980 * '-------------' * * '-----------' * 981 * SC Domain#1 * * SC Domain#2 * 982 * * * * * * * * * * * * * * * * * * * * * * * * * * * * 984 Figure 10: Establishment of SPs Across Multiples DCs in pattern 2 986 Also, the detail analysis of establishment of "Hierarchical Service 987 Path domains" is shown in the following section. 989 4.2.2.1. Analysis of Hierarchical Service Path domains 991 The dynamic selection of SPs pattern allows multiple independent 992 domains of administration. (In the example, two levels were shown, 993 but the pattern could be extended to multiple levels.) 994 This pattern allows even the largest networks to implement SC from 995 the edges of the network by using coarse-grained classification. 996 Classification choices can be made that are feasible within the 997 constraints of the edge classifiers and FWDs. There is no need to 998 maintain flow state or react to traffic at the top level. 1000 This pattern allows control of sub-domains to be delegated to 1001 different owners. Each domain is simpler to comprehend than would be 1002 the case by dealing with a single flat network. Furthermore, 1003 failures and errors are localized. (See Figure 11.) 1005 +----------+ 1006 |Top-level | . . . . . . . . . . . . . . . . . . . . . 1007 |Control | . 1008 |Entity | +------------+ +--------+ . 1009 +----------+ |sub-domain#1|. . .| CE#1 | . 1010 . +-----+------+ +--------+ . 1011 . | . 1012 . .------+---------. +---+ . 1013 . +---+ / \--|CF |. . . . 1014 . . . .|CF |--/ \ |FWD| . 1015 . |FWD| / \+---+ . 1016 . +---+ | | . 1017 . | | . 1018 . | | . 1019 . +---+ \ / . 1020 . |CF | \ / +---+ . 1021 . . . .|FWD|---\ /---|CF | . . . 1022 +---+ '------+---------' |FWD| 1023 | +---+ 1024 +--------+ +------------+ 1025 | CE#2 |. . .|sub-domain#2| 1026 +--------+ +-----+------+ 1028 Figure 11: Multiple Control Entities in Hierarchical Service Chaining 1030 This hierarchical model supports management of large networks by 1031 adhering to these principles: 1033 1. At higher levels of hierarchy packet classification is coarse, to 1034 minimize state and control-plane chatter. 1036 2. At lower levels of hierarchy packet classification can be more 1037 granular because classifiers in the lower levels deal with a 1038 subset of the entire network: fewer flows, lower bit-rate and a 1039 subset of network policy. 1041 However, in this model, a new component that can proxy between the 1042 different domains, termed "SF Domain Gateway," will be required. It 1043 has some commonality with the legacy SF proxy discussed in 1044 [I-D.song-sfc-legacy-sf-mapping]. 1046 This model also requires some coordination of path information within 1047 the SF Domain Gateway component, since the gateway must map packets 1048 back and forth between domains. Solving this probably requires 1049 sharing metadata dictionaries among controllers and inventing a 1050 scheme that provides a level of indirection by naming path 1051 identifiers and metadata values. 1053 4.3. Example of selecting Methods and Patterns 1055 In this section, clarifications about the most suitable method and 1056 pattern are made for the following example networks based on the 1057 results of the above analysis. 1059 4.3.1. Example#1: Enterprise Datacenter Network 1061 The conditions of the target network are as follows: 1063 Network type: Network with a single DC. 1065 Intended service: For providing several network service to traffic 1066 of one or several business offices. 1068 Variation of service: A group of adopting network service varies per 1069 office. 1071 The number of SFs included in a service chain: Less than 5 (ref. 1072 section 3.2.1. Sample north-south service function chains in 1073 [I-D.ietf-sfc-dc-use-cases]). 1075 Features of SFs: SFs are set statically, and SFs are exclusively 1076 used for each service. 1078 On the basis of the conditions "network type" and "features of SFs", 1079 pattern 1 with SF dedicated model would be selected. 1081 As the condition "variation of service" describes, such network 1082 requires few flow entries for each FWD, so method 1 would be 1083 applicable. Method 1 also does not require SFs to have any 1084 additional mechanism to apply any header, thus the impact of 1085 implementing this method would be smaller than other methods. 1087 4.3.2. Example#2: Current Mobile Service Providers Network 1089 The conditions of the target network are as follows: 1091 Network type: Network with a single DC (e.g., (S)Gi-LAN (3GPP, 1092 [TS.23.203])). 1094 Intended service: For providing network access service and several 1095 network service to traffic of millions customers. 1097 Variation of service: Service varies per user or applications. 1099 The number of SFs included in a service chain: Around 5(ref. 1100 examples of service in [I-D.ietf-sfc-use-case-mobility].). 1102 Features of SFs: Many SFs are hardware equipment and they are set 1103 statically. Also, many SFs are used for several service. A 1104 function to inspect the user traffic in detail, such as TDF (3GPP, 1105 [TS.23.203]), is located around the edge of the network, and it 1106 might behave as a CF. 1108 On the basis of the conditions "network type" and "features of SFs," 1109 pattern 1 with SF shared model would be selected. In such network, 1110 classification based on deep packet inspection such as application 1111 type inspections is done, and paths branching will not be happen. 1113 As the other conditions describe, the operator must handle millions 1114 of flows and the flows traverse multiple SFs, so method 3 would be 1115 applicable. Configuring such amounts of flows among large scale 1116 network might be too much work for operators. 1118 The examples of concrete service of such network are described as 1119 follows: 1121 1. HTTP Modification 1123 Packet Gateway(P-GW), which is defined in 3GPP (ref. [tS.23.203]), 1124 detects traffic to the specific website and that traffic must be 1125 sent through a special element to insert additional data to the 1126 http header or advertisement to the HTTP traffic, so the 1127 destination site can apply specific deals with the operator's 1128 customer (simplify DRM, premium service, etc.) That would require 1129 flow entries with mobile source IP, destination IP and port. 1131 2. VoLTE Calls 1133 VoLTE calls are sent via a special SP. The VoLTE control plane 1134 selects all application network elements. But to reach 1135 application network elements it fully relies on standard routing 1136 and switching protocols. With Service Chaining it is possible to 1137 select the SP which can provide required QoS. That would require 1138 to set flow entries with mobile source IP, destination IP and 1139 port. 1141 3. Secure Internet Access 1143 Some customers' HTTP traffic are forwarded to one or more security 1144 functions to inspect for malware. This case would require flow 1145 entries with source IP, destination IP and port. 1147 4. Content Optimizer 1149 Based on the policy rules, a SC/SP with the content optimization 1150 might be provided. Content optimization primarily affects video 1151 and HTTP traffic, and saves valuable radio resources in the 1152 specific radio cells during times of congestion. A controller 1153 might monitor Key Performance Indicators (KPIs) of the radio 1154 network to detect congestion. When congestion is detected, the 1155 controller might apply content optimization policy for the users 1156 on the congested radio cell. Most resource-expensive traffic can 1157 be transcoded by a content optimizer to save bandwidth. Selecting 1158 traffic for optimization would require to set flow entries with 1159 mobile source IP, destination IP and port. Also, content 1160 optimization might require changing SCs/SPs assigned to users 1161 flows based on the result of KPI monitoring or the time of day. 1163 On the other hand, method 1 might be also selected with pattern 1 1164 with SF dedicated model. For example, the series of the above 1165 service might be achieved by static configured flow entries, for 1166 example, with incoming port. However, it will require many incoming 1167 ports for FWDs when the operator would like to share a SF with 1168 multiple SCs, and it will not be scalable. 1170 4.3.3. Example#3: Fixed and Mobile Converged Service Providers Network 1172 The conditions of the target network are as follows: 1174 Network type: Network with multiple DCs (e.g., SFs are deployed at 1175 multiple DCs based on their applications). 1177 Intended service: For providing network access service or several 1178 network service to traffic of millions customers. 1180 Variation of service: Service varies per user. Also, the service 1181 assigned to each flow might vary based on using applications. 1183 The number of SFs included in a service chain: More than 5. 1184 (Various service such as enriched security service and value added 1185 service would be provided) 1187 Features of SFs: Many SFs are deployed as vNF, and some SFs are 1188 shared with multiple SCs. Also, some SFs changes the following 1189 SPs dynamically based on the result of the process. 1191 On the basis of the conditions "network type" and "features of SFs," 1192 pattern 2 would be selected. Pattern 2 allows hierarchical approach 1193 which enables operators to deploy SFs in multiple domains easily 1194 based on service requirements. For example, operators can deploy SFs 1195 into several domains based on application types. This concept is 1196 introduced in [I-D.ietf-sfc-dc-use-cases]. 1198 From the above conditions describe, the operator must handle enormous 1199 flows and paths branching, thus method 3 will be appreciable for such 1200 network. Especially, security scenario sometimes requires paths 1201 branching based on the result of packet inspection such as processes 1202 of DPI or traffic analyzer. Some security functions such as web 1203 application firewall (WAF) are specialized for each application, and 1204 it might be inefficient to insert all traffic into such SFs. 1205 Therefore, for inserting only target packets to appropriate security 1206 functions, classifying and paths branching based packet inspection 1207 would be required. 1209 5. Acknowledgements 1211 The authors would like to thank Konomi Mochizuki and Lily Guo for 1212 their reviews and comments. 1214 6. Contributors 1216 The following people are active contributors to this document and 1217 have provided review, content and concepts (listed alphabetically by 1218 surname): 1220 Chuong D. Pham 1221 Telstra 1223 Hiroshi Dempo 1224 NEC 1226 Ron Parker 1227 Affirmed Networks 1229 Paul Quinn 1230 Cisco Systems 1232 7. IANA Considerations 1234 This memo includes no request to IANA. 1236 8. References 1238 [I-D.dolson-sfc-hierarchical] 1239 Dolson, D., Homma, S., and D. Lopez, "Hierarchical Service 1240 Chaining", draft-dolson-sfc-hierarchical-00 (work in 1241 progress), May 2015. 1243 [I-D.ietf-sfc-architecture] 1244 Halpern, J. and C. Pignataro, "Service Function Chaining 1245 (SFC) Architecture", draft-ietf-sfc-architecture-08 (work 1246 in progress), May 2015. 1248 [I-D.ietf-sfc-dc-use-cases] 1249 Surendra, S., Tufail, M., Majee, S., Captari, C., and S. 1250 Homma, "Service Function Chaining Use Cases In Data 1251 Centers", draft-ietf-sfc-dc-use-cases-02 (work in 1252 progress), January 2015. 1254 [I-D.ietf-sfc-nsh] 1255 Quinn, P. and U. Elzur, "Network Service Header", draft- 1256 ietf-sfc-nsh-00 (work in progress), March 2015. 1258 [I-D.ietf-sfc-use-case-mobility] 1259 Haeffner, W., Napper, J., Stiemerling, M., Lopez, D., and 1260 J. Uttaro, "Service Function Chaining Use Cases in Mobile 1261 Networks", draft-ietf-sfc-use-case-mobility-03 (work in 1262 progress), January 2015. 1264 [I-D.song-sfc-legacy-sf-mapping] 1265 Song, H., You, J., Yong, L., Jiang, Y., Dunbar, L., 1266 Bouthors, N., and D. Dolson, "SFC Header Mapping for 1267 Legacy SF", draft-song-sfc-legacy-sf-mapping-04 (work in 1268 progress), December 2014. 1270 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1271 Address Translator (Traditional NAT)", RFC 3022, January 1272 2001. 1274 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1275 NAT64: Network Address and Protocol Translation from IPv6 1276 Clients to IPv4 Servers", RFC 6146, April 2011. 1278 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 1279 Translation", RFC 6296, June 2011. 1281 [RFC7498] Quinn, P. and T. Nadeau, "Problem Statement for Service 1282 Function Chaining", RFC 7498, April 2015. 1284 Authors' Addresses 1286 Shunsuke Homma 1287 NTT, Corp. 1288 3-9-11, Midori-cho 1289 Musashino-shi, Tokyo 180-8585 1290 Japan 1292 Phone: +81 422 59 3486 1293 Email: homma.shunsuke@lab.ntt.co.jp 1295 Kengo Naito 1296 NTT, Corp. 1297 3-9-11, Midori-cho 1298 Musashino-shi, Tokyo 180-8585 1299 Japan 1301 Email: naito.kengo@lab.ntt.co.jp 1303 Diego R. Lopez 1304 Telefonica I+D. 1305 Don Ramon de la Cruz, Street 1306 Madrid 28006 1307 Spain 1309 Phone: +34 913 129 041 1310 Email: diego.r.lopez@telefonica.com 1312 Martin Stiemerling 1313 NEC Laboratories Europe / Hochschule Darmstadt 1314 Kurfuerstenanlage 36 1315 Heidelberg 69115 1316 Germany 1318 URI: ietf.stiemerling.org 1319 David Dolson 1320 Sandvine 1321 408 Albert Street 1322 Waterloo, Ontario N2L 3V3 1323 Canada 1325 Email: ddolson@sandvine.com 1327 Alexey Gorbunov 1328 Nokia 1329 6000 Connection Drive 1330 Irving, Texas 75039 1331 USA 1333 Phone: +1 214 516 11 41 1334 Email: Alexey.gorbunov82@gmail.com 1336 Nicolai Leymann 1337 DT 1338 Winterfeldtstrasse 21-27 1339 Berlin 10781 1340 Germany 1342 Phone: +49 (0)30 835392761 1343 Email: n.leymann@telekom.de