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