idnits 2.17.1 draft-homma-sfc-forwarding-methods-analysis-04.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 (October 9, 2015) is 3121 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'CF' is mentioned on line 381, but not defined == Missing Reference: 'FWD' is mentioned on line 381, but not defined == Unused Reference: 'RFC7498' is defined on line 1378, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-dolson-sfc-hierarchical-03 == Outdated reference: A later version (-06) exists of draft-ietf-sfc-dc-use-cases-03 == Outdated reference: A later version (-28) exists of draft-ietf-sfc-nsh-01 == Outdated reference: A later version (-09) exists of draft-ietf-sfc-use-case-mobility-04 == Outdated reference: A later version (-08) exists of draft-song-sfc-legacy-sf-mapping-06 Summary: 2 errors (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Service Function Chaining S. Homma 3 Internet-Draft K. Naito 4 Intended status: Informational NTT 5 Expires: April 11, 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 October 9, 2015 17 Analysis on Forwarding Methods for Service Chaining 18 draft-homma-sfc-forwarding-methods-analysis-04 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 April 11, 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 Selection 67 Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3.1. Forwarding Methods . . . . . . . . . . . . . . . . . . . 5 69 3.1.1. Method 1: Forwarding Based on Flow Identifiable 70 Information . . . . . . . . . . . . . . . . . . . . . 6 71 3.1.2. Method 2: Forwarding with Stacked Headers . . . . . . 7 72 3.1.3. Method 3: Forwarding Based on Service Chain 73 Identifiers . . . . . . . . . . . . . . . . . . . . . 9 74 3.2. Service Path Selection Patterns . . . . . . . . . . . . . 11 75 3.2.1. Pattern 1: Static Selection of End-to-End Service 76 Path . . . . . . . . . . . . . . . . . . . . . . . . 12 77 3.2.2. Pattern 2: Dynamic Selection of Segmented Service 78 Path . . . . . . . . . . . . . . . . . . . . . . . . 14 79 4. Consideration on Forwarding Methods and Paths Selection 80 Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . 19 81 4.1. Analysis of Forwarding Methods . . . . . . . . . . . . . 20 82 4.1.1. Analysis of Method 1 . . . . . . . . . . . . . . . . 20 83 4.1.2. Analysis of Method 2 . . . . . . . . . . . . . . . . 21 84 4.1.3. Analysis of Method 3 . . . . . . . . . . . . . . . . 22 85 4.2. Analysis of Service Path Selection Patterns . . . . . . . 24 86 4.2.1. Analysis of Pattern 1 . . . . . . . . . . . . . . . . 24 87 4.2.2. Analysis of Pattern 2 . . . . . . . . . . . . . . . . 25 88 4.3. Example of selecting Methods and Patterns . . . . . . . . 28 89 4.3.1. Example#1: Enterprise Datacenter Network . . . . . . 28 90 4.3.2. Example#2: Current Mobile Service Providers Network . 29 91 4.3.3. Example#3: Fixed and Mobile Converged Service 92 Providers Network . . . . . . . . . . . . . . . . . . 30 93 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 94 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31 95 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 96 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 99 1. Introduction 101 Some IETF working groups of and other Standards Developing 102 Organizations are now discussing use cases of a technology that 103 provides service-oriented traffic forwarding schemes to convey 104 packets to the various service functions, deployed in networks, for 105 providing network services. In this document, we define such 106 technology as Service Chaining. (This draft does not focus only on 107 "Service Function Chaining (SFC)" architecture, and thus, use the 108 term "Service Chaining." SFC is one of approaches to realize Service 109 Chaining.) There are several methods to achieve Service Chaining, 110 and the applicable method will vary depending on the service 111 requirements of individual networks. 113 This draft assumes that Service Chaining is achieved by the following 114 steps: 116 a. A traffic classification function identifies the service that is 117 associated to each incoming packets by inspecting the key 118 information such as IP address or 5-tuple. 120 b. The forwarding path used by packets for reaching the appropriate 121 service functions, is established according to the services 122 provided for the packets. The path might be established in 123 advance. 125 c. Forwarding functions forward the packets to the next destination 126 along the path established in step b. 128 d. A service function operates on received packets. Once the 129 invocation of a service function is completed, the packet is 130 forwarded to the next . 132 e. Steps c and d are repeated until each packet has been transferred 133 to all required service functions. 135 f. After a packet has been transferred to all required Service 136 Functions, it is forwarded to its original destination. 138 There are several forwarding methods for Service Chaining, and they 139 can be classified into certain categories in terms of distribution of 140 information for setting the paths and decision of the paths. The 141 methods used to distribute the information for path setting and the 142 patterns used to decide the paths will affect the mechanism of 143 Service Chaining in terms of scalability and service flexibility. 145 The applicable methods vary depending on network requirements, and 146 thus, classifying and determining forwarding methods will be 147 important in designing the architecture of Service Function Chaining 148 (SFC). This document provides the results of analysis of different 149 forwarding methods for Service Chaining. 151 OAM, security, and redundancy are outside the scope of this draft. 153 2. Definition of Terms 155 Term "Classification", "Classifier" referred to 156 [I-D.ietf-sfc-architecture]. Term "Service Function", "Service Node" 157 referred to [I-D.ietf-sfc-dc-use-cases]. 159 Service Chaining: A technology that enables data packets to invoke a 160 set of service functions. 162 Classification: Locally instantiated matching of traffic flows 163 against policy for subsequent application of the required set of 164 network service functions. The policy may be customer/network/ 165 service specific. 167 Classifier (CF): An element 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 Forwarder (FWD): The entity, responsible for forwarding data packets 187 according to the ordered set of service functions that need to be 188 invoked. A forwarder maintains one or more forwarding tables, 189 which contain entries that asset the forwarder in its forwarding 190 decision-making process. 192 Control Entity (CE): One or a set of control entities responsible 193 for managing service topology and indicating forwarding 194 configurations to forwarders. 196 Service Chain (SC): A service chain defines an ordered list of 197 service functions that must be applied to packets selected as a 198 result of classification. The implied order may not be a linear 199 progression as the architecture allows for nodes that copy to more 200 than one branch. 202 Service Path (SP): The forwarding path followed by packets that are 203 associated to a given service chain. Packets follow a service 204 path through the requisite service functions that need to be 205 invoked, as per the service chain instructions. Service path 206 shows a specific path that traverses several service function 207 instances. For example, SC is written as SF#1 -> SF#2 -> SF#3 208 (This shows an ordered list of SFs), and SP is written as 209 SF#1_1(1_1 means instance 1 of SF1) -> SF#2_1 -> SF#3_1. 211 Segmented Service Path: A Segmented Service Path is an actual path 212 established between FWDs. A service path might be composed of 213 some segmented service paths. 215 Service Chaining Domain (SC Domain): The domain managed by one or a 216 set of CEs. 218 Service Path Information (SP Information): The information used to 219 forward packets to the appropriate SFs according to the service 220 that needs to be provided. Examples of SP information include 221 routing configuration for forwarders, headers for forwarding 222 packets to required SFs, and service/flow identifiable tags. 224 3. Classification of Forwarding Methods and SP Selection Patterns 226 3.1. Forwarding Methods 228 In Service Chaining, data packets are transferred to service 229 functions, which might be located outside the regular computed path 230 to the original destination. Therefore, a routing mechanism that is 231 different from general L2/L3 switching/forwarding might be required. 232 The forwarding mechanism can be classified into three methods in 233 terms of distribution of SP information and packet forwarding. 235 3.1.1. Method 1: Forwarding Based on Flow Identifiable Information 237 The mechanism of method 1 is shown in Figure 1. In this method, 238 forwarding configuration information is based on flow identifiable 239 information, such as 5-tuple (e.g. dst IP, src IP, dst port, src 240 port, tcp) are indicated to the CF and each FWD. There might be an 241 CE to handle this. The flow identifiable information can be 242 constructed with some fields of L2 or L3 or combination thereof. The 243 information can be configured either before packets arrive, or at the 244 time packets arrive at CF and FWD. Each FWD identifies the packets 245 with flow identifiable information and forwards the packets to the 246 SFs according to the configuration. This method does not require the 247 modification of any field in the original packet header. 249 *Distribution model of SP information* 251 +----------------+ 252 | Control Entity | 253 +----------------+ 254 ^ | indication of routing configuration 255 | | based on packet identifiable information 256 | +---------------+-------------------------------+---------> 257 | | | | 258 | | | | 259 | v v v 260 +--------+ +-------+ +------+ +-------+ 261 ------>| CF |------> | FWD |------> | SF#1 |------>| FWD |-----> 262 +--------+ +-------+ +------+ +-------+ 264 //////////////////////////////////////////////////////////////////////// 265 *Forwarding Tables* 267 Locate: [CF] [FWD] [FWD] 269 Table: 192.168.1.1 192.168.1.1 192.168.1.1 270 ->FWD#1 ->SF#1 ->SF#2 271 10.0.1.1 10.0.1.1 10.0.1.1 272 ->FWD#1 ->FWD#2 ->SF#2 273 ... ... ... 275 //////////////////////////////////////////////////////////////////////// 276 *Condition of Packet* 278 Locate: [CF] [FWD] [SF#1] [FWD] 280 +-------+ +-------+ +-------+ +-------+ 281 Packet: | PDU | | PDU | | PDU | | PDU | 282 +-------+ +-------+ +-------+ +-------+ 284 Figure 1: Forwarding Based on Flow Identifiable Information 286 3.1.2. Method 2: Forwarding with Stacked Headers 288 The mechanism of method 2 is shown in Figure 2. In this method, the 289 CF classifies packets and stacks headers in which actual network 290 address is included, e.g., MPLS or GRE headers, onto the packets 291 based on the classification. The packet is transferred to the 292 destination according to the outermost header, and a SF or FWD, as 293 the destination, removes the outermost header after receiving the 294 packet. The processes are repeated until all stacked headers are 295 removed. This method does not require any forwarding entries for 296 forwarding packets based on the service information. 298 *Distribution model of SP information* 300 +----------------+ 301 | Control Entity | 302 +----------------+ 303 ^ | 304 | | indication of 305 | | stacking headers 306 | v 307 +--------+ +-------+ +------+ +------+ 308 -------->| CF |------>| SF#1 |------>| SF#2 |------>| SF#3 |------> 309 +--------+ +-------+ +------+ +------+ 311 //////////////////////////////////////////////////////////////////////// 312 *Forwarding Tables* 314 Locate: [CF] 316 Table: 192.168.1.1 __/__/__/__/__/__/__/__/__/__/__/__/__/ 317 ->Stack #1,2,3 __/ Packets are forwarded to SFs by __/ 318 10.0.1.1 __/ the outermost header. __/ 319 ->Stack #1,3 __/__/__/__/__/__/__/__/__/__/__/__/__/ 320 ... 322 //////////////////////////////////////////////////////////////////////// 323 *Condition of Packet* 325 Locate: [CF] [SF#1] [SF#2] [SF#3] 327 +--------+ 328 Header: |To SF#1 | 329 +--------+ +--------+ 330 |To SF#2 | |To SF#2 | 331 +--------+ +--------+ +--------+ 332 |To SF#3 | |To SF#3 | |To SF#3 | 333 +--------+ +--------+ +--------+ 334 : : : : 335 +--------+ +--------+ +--------+ +--------+ 336 Packet: | PDU | | PDU | | PDU | | PDU | 337 +--------+ +--------+ +--------+ +--------+ 339 Figure 2: Forwarding with Stacked Multiple Headers 341 3.1.3. Method 3: Forwarding Based on Service Chain Identifiers 343 The mechanism of this method is shown in Figure 3. In this method, 344 the corresponding service chain identifier is mapped to each packet 345 by a CF based on the classification. The forwarding configuration 346 based on the identifiers is sent to each FWD. Each FWD identifies 347 the SP assigned to the received packet from the identifier, and 348 forwards the packet to the next hop. After a packet has traversed 349 all SFs, the identifier is removed and the packet is transported to 350 the original destination. 352 *Distribution model of SP information* 354 +----------------+ 355 | Control Entity | 356 +----------------+ 357 ^ | indication of attached tag 358 | | and routing configuration based on tags 359 | +----------------+------------------------------+---------> 360 | | | | 361 | | | | 362 | v v v 363 +--------+ +-------+ +------+ +-------+ 364 ----->| CF |------> | FWD |------>| SF#1 |------>| FWD |-----> 365 +--------+ +-------+ +------+ +-------+ 367 ////////////////////////////////////////////////////////////////////// 368 *Forwarding Tables* 370 Locate: [CF] [FWD] [FWD] 372 Table: 192.168.1.1 IF ID#1,3 IF ID#1,2,5 373 ->Stack ID#1 ->SF#1 ->SF#2 374 10.0.1.1 375 ->Stack ID#2 376 ... ... ... 378 ////////////////////////////////////////////////////////////////////// 379 *Condition of Packet* 381 Locate: [CF] [FWD] [SF#1] [FWD] 383 +-------+ +-------+ +-------+ +-------+ 384 SC-ID: | ID#1 | | ID#1 | | ID#1 | | ID#1 | 385 +-------+ +-------+ +-------+ +-------+ 386 Packet:| PDU | | PDU | | PDU | | PDU | 387 +-------+ +-------+ +-------+ +-------+ 389 Figure 3: Forwarding Based on Service Chain Identifiers 391 Then, there are mainly two approaches to map service chain 392 identifiers to packets as follows. 394 o Tagging an extra header: 396 In this approach, an extra header which has a service chain 397 identifier is attached on each packet. This document defines such 398 headers as service identifiable tags. Some existing tags, such as 399 VLAN-tag or MPLS-tag, or dedicated headers, such as NSH, could be 400 used as service identifiable tags. An example of packet format in 401 tagging approach with NSH is shown in Figure 4. In this example, 402 a service chain identifer is included in NSH. 404 +----------+-------+--------+-------------~~--+ 405 | NSH | Ether | IPv6 |IPv6 Payload | 406 | \SC-ID | Header| Header | | 407 +----------+-------+--------+-------------~~--+ 409 |--- Ethernet Packet ---| 411 Figure 4: Packet Format in Tagging Approach 413 o Inserting into an optional field: 415 In this approach, a service chain identifier is inserted into an 416 optional field inside a packet frame, such as IPv6 extension 417 header. An example of an IPv6 packet with a service chain 418 identifier inserted as an extension header is shown in Figure 5. 420 +-------+--------+----------+-------------~~--+ 421 | Ether |IPv6 |IP Opt.Fld|IPv6 Payload | 422 | Header|Base Hdr| \SC-ID | | 423 +-------+--------+----------+-------------~~--+ 425 |-- IPv6 Header --| 427 |--- Ethernet Packet ---| 429 Figure 5: Packet Format in Inserting Approach 431 3.2. Service Path Selection Patterns 433 Since SC contains only logical information (e.g., a set of services 434 that are associated with flows and their sequences), the actual 435 instances, which are called SPs, are needed in order for the 436 forwarding process to work. In this process, an instance of SP is 437 created at certain points during a packet's delivery. Therefore, to 438 forward packets, the SC needs to be turned into an SP, which 439 indicates specific FWDs (or switches, routers) and SFs that the 440 packets will be forwarded to. From the perspective of points 441 translating SC to SP, the methods that establish SPs from end-to-end 442 are classified into two patterns. 444 3.2.1. Pattern 1: Static Selection of End-to-End Service Path 446 The translation point is a CF; that is, the SP is statically pre- 447 established as an end-to-end path and a CF forwards packets along the 448 appropriate path based on the result of the classification. Each FWD 449 on the SP has a forwarding table to uniquely determine the next 450 destination of packets, and each FWD statically forwards the received 451 packets toward the next destination based on the table. FWD requires 452 only a function to receive indications of forwarding configurations 453 from the CE. Pattern 1 can be achieved in the following ways. 455 3.2.1.1. SF Shared Model 457 Figure 6 shows the mechanism of this model. In this model, an SF is 458 shared by multiple SPs. Therefore, FWDs require a function to 459 identify the SP followed by each packet and forward the packets to 460 the corresponding next hop. 462 *Path Structure* 464 +----+ +---+ +----+ +---+ +------+ +---+ +----+ 465 | |SC#1 |FWD| |SF#1| |FWD| |SF#2_1| |FWD| |SF#3| SP#1 466 | |==============================================================> 467 | |SC#2 | | | | | | +------+ | | | | SP#2 468 | |============================# +------+ #======================> 469 | | | | +----+ | | # |SF#2_2| # | | +----+ 470 | | | | | | #==========# | | 471 ->| CF | +---+ +---+ +------+ +---+ 472 | | 473 . . 474 . . 475 . . 476 +---+ +----+ +---+ +----+ 477 | |SC#n |FWD| |SF#4| |FWD| |SF#5| SP#n 478 | |==============================================================> 479 +----+ +---+ +----+ +---+ +----+ 481 SC:Service Chain SP:Service Path 482 /////////////////////////////////////////////////////////////////////// 483 *Packet Flow* 485 Service Chain#1: 486 SP#1 487 [ CF ]---->[FWD]-->[SF#1]-->[FWD]-->[SF#2_1]-->[FWD]-->[SF#3]---> 489 Service Chain#2: 490 SP#2 491 [ CF ]---->[FWD]-->[SF#1]-->[FWD]-->[SF#2_2]-->[FWD]-->[SF#3]---> 492 : 493 Service Chain#n: 494 SP#n 495 [ CF ]---->[FWD]-->[SF#4]--------------------->[FWD]-->[SF#5]---> 497 Figure 6: SF Shared Model 499 3.2.1.2. SF Dedicated Model 501 Figure 7 shows the mechanism of this model. In this model, an SF 502 instance (or a set of SF instances) is used by only one single SP; in 503 other words, a set of SF instances is prepared for each SP. At each 504 FWD, incoming packets are statically forwarded to the single pre- 505 defined next hop. 507 *Path Structure* 509 +----+ +---+ +------+ +---+ +------+ +---+ +------+ 510 | |SC#1 |FWD| |SF#1_1| |FWD| |SF#2_1| |FWD| |SF#3_1| SP#1 511 | |=============================================================> 512 | | +---+ +------+ +---+ +------+ +---+ +------+ 513 | | +---+ +------+ +---+ +------+ +---+ +------+ 514 | |SC#2 |FWD| |SF#1_2| |FWD| |SF#2_2| |FWD| |SF#3_2| SP#2 515 | |=============================================================> 516 ->| CF | +---+ +------+ +---+ +------+ +---+ +------+ 517 | | 518 . . 519 . . 520 . . 521 +---+ +------+ +---+ +------+ 522 | |SC#n |FWD| | SF#4 | |FWD| | SF#5 | SP#n 523 | |=============================================================> 524 +----+ +---+ +------+ +---+ +------+ 526 SC:Service Chain SP:Service Path 527 ////////////////////////////////////////////////////////////////////// 528 *How packets traverse* 530 Service Chain#1: 531 SP#1 532 [ CF ]--->[FWD]-->[SF#1_1]->[FWD]->[SF#2_1]->[FWD]->[SF#3_1]---> 534 Service Chain#2: 535 SP#2 536 [ CF ]--->[FWD]-->[SF#1_2]->[FWD]->[SF#2_2]->[FWD]->[SF#3_2]---> 537 : 538 Service Chain#n: 539 SP#n 540 [ CF ]--->[FWD]-->[ SF#4 ]------------------>[FWD]->[ SF#5 ]---> 542 Figure 7: SF Dedicated Model 544 3.2.2. Pattern 2: Dynamic Selection of Segmented Service Path 546 The mechanism of this pattern is shown in Figure 8. The translation 547 points are CFs and some FWDs. The SP is established by a series of 548 multiple paths, which are sectioned by CFs and FWDs. The resulting 549 path is referred to as a segmented path in this draft. CFs or FWDs 550 that select the next segmented path might require notification of 551 forwarding configuration information from the CE. Moreover, some 552 FWDs require functions to select the destination of packets from 553 various alternatives and to retrieve the information for selecting 554 the next path. For example, each FWD obtains metric information or 555 load conditions of servers and selects an optimal segmented path 556 based on the information. The CE might support the selection 557 mechanism and may notify CFs or FWDs of it. 559 *Path Structure* 561 +----+ +---+ +----+ +---+ +------+ +---+ +----+ 562 | |SC#1 |FWD| |SF#1| |FWD| |SF#2_1| |FWD| |SF#3| SP#1 563 | |========================*=====================================> 564 | | | | | | | # | +------+ | | | | SP#2 565 | | | | | | | # | +------+ #======================> 566 | | | | +----+ | # | |SF#2_2| # | | +----+ 567 | | | | | #==============# | | 568 ->| CF | +---+ +---+ +------+ +---+ 569 | | 570 . . 571 . . 572 . . 573 +---+ +----+ +---+ +----+ 574 | |SC#n |FWD| |SF#4| |FWD| |SF#5| SP#m 575 | |==============================================================> 576 +----+ +---+ +----+ +---+ +----+ 578 SC:Service Chain SP:Service Path 579 /////////////////////////////////////////////////////////////////////// 581 *How packets traverse* 583 Service Chain#1: 584 SP#1 585 [ CF ]---->[FWD]-->[SF#1]-->[FWD]-->[SF#2_1]-->[FWD]-->[SF#3]---> 587 SP#2 588 [ CF ]---->[FWD]-->[SF#1]-->[FWD]-->[SF#2_2]-->[FWD]-->[SF#3]---> 589 : 590 Service Chain#n: 591 SP#m 592 [ CF ]---->[FWD]-->[SF#4]--------------------->[FWD]-->[SF#5]---> 594 Figure 8: Dynamic Selection of Segmented Service Path 596 In addition, this pattern supports the establishment of hierarchical 597 domains discussed below: 599 3.2.2.1. Hierarchical Service Path Domains 601 Complex problems often become manageable with a hierarchical 602 approach. This pattern allows network-wide orchestration of Service 603 Chaining to be relatively simple, while hiding the complexities of 604 fine-grained policy-based path selection within sub-domains. Each 605 sub-domain can be independently administered and orchestrated. This 606 architecture is described in [I-D.dolson-sfc-hierarchical]. 608 Figure 9 shows two levels of hierarchy in a service provider's 609 network. At the top level in the hierarchy, Service Chaining 610 components are: 612 1. Edge-classifiers (Edge CF) that reside near the edge of a service 613 provider's domain. 615 2. SF sub-domains that reside in data centers. 617 3. Internal Boundary Nodes (IBNs) that reside in data centers, 618 linking together the levels of the hierarchy. To the higher 619 level, sub-domains are viewed as a SF. To the lower level, this 620 is a classifier and FWD. 622 *How packets traverse* 624 +----+ +-----+ +----------------------+ +-----+ 625 | |SC#1| FWD | | IBN#1 | | FWD | 626 ->| |================* *=====================> 627 | | +-----+ | # (in DC#1) # | +-----+ 628 | | | V # | 629 |Edge| |+---+ +---+| Top domain 630 | CF | * * * * *||CF | * * * * * *|FWD|| * * * * * 631 | | * |+---+ +-+-+| * 632 | | * | | | | | | Sub * 633 | | * +-o-o--------------o-o-+ domain* 634 | | * SC#1.2 | |SC#1.1 ^ ^ #1 * 635 | | * +-----+ | | | * 636 | | * | V | | * 637 | | * | +---+ +------+ | | * 638 | | * | |FWD|->|SF#1_1|--+ | * 639 | | * | +---+ +------+ | * 640 | | * V | * 641 | | * +---+ +------+ +---+ +------+ * 642 | | * |FWD|->|SF#1_2|->|FWD|->|SF#2_1| * 643 | | * +---+ +------+ +---+ +------+ * 644 . * * * * * * * * * * * * * * * * * * * * * * 645 . 646 | | +-----+ +---------------------+ +-----+ 647 | |SC#n| FWD | | IBN#q | | FWD | 648 | |=======================================================> 649 | | +-----+ | (in DC#m) | +-----+ 650 +----+ +---------------------+ 651 (Details of sub-domain #q not shown) 653 Figure 9: Service Chain Hierarchy in Service Provider Networks 655 The components within an SF sub-domain are opaque at the top level; 656 each IBN acts as a single SF node in the top-level domain. A service 657 path in the top-level domain may visit multiple sub-domains. 659 At the lower level in the hierarchy, each sub-domain contains an 660 independently administrated Service Chaining network, generally 661 comprised of multiple instances of multiple types of hosts, most 662 likely (but not necessarily) within the same data center. There is 663 no need for knowledge of the "big picture" at the level of the SF- 664 sub-domain except as required to forward packets to the other SFs 665 that are the next hop of each chain. 667 Note that different encapsulation methods can be used at each layer 668 in the hierarchy, provided the SF domain-Proxy can translate between 669 them. For example, MPLS could be used to deliver packets from 670 network edge to the SF clusters within data centers, and NSH 671 [I-D.ietf-sfc-nsh] could be used within the data center. 673 Details of Top Level of Hierarchy 675 In this pattern, referring to Figure 10, network-wide Service 676 Chaining orchestration is only concerned with creating service paths 677 from network edge points to sub-domains within data centers and 678 configuring classifiers at a coarse level to get the correct hosts' 679 traffic onto paths that will arrive at appropriate sub-domains. The 680 figure shows one possible service chain passing from edge, through 681 two sub-domains, to network egress. 683 This top level of orchestration may attach metadata to provide 684 context from the network edge into the data center. 686 +------------+ 687 |Sub-domain#1| 688 | in DC1 | 689 +----+-------+ 690 | 691 .------+---------. +--+ 692 +--+ / / | \--|CF| 693 --->|CF|--/---->' | \ +--+ 694 +--+ / SC#1 | \ 695 | | | 696 | | .------>|---> 697 | / / | 698 \ | / / 699 +--+ \ | / / +--+ 700 |CF|---\ V / /---|CF| 701 +--+ '------+---------' +--+ 702 | 703 +----+-------+ 704 |Sub-domain#2| 705 | in DC2 | 706 +------------+ 708 Figure 10: Network-wide view of Top Level of Hierarchy 710 The orchestration at this top level must ensure bidirectional path 711 symmetry so that inbound packets traverse sub-domains in the reverse 712 order as outbound packets. 714 Because classifiers must have rules to handle any traffic passing 715 through the network, we believe that a useful approach to 716 classification will be to assign traffic to service function paths on 717 the basis of coarse classification like subscriber tier, tenant or 718 VRF identifier. These classification rules could be relatively 719 static, changing in response to provisioning but not in response to 720 traffic. 722 In some networks, it might be possible to create a rule per 723 residential subscriber, resulting in rule updates when subscribers 724 are assigned IP addresses. However, with judicious allocation of IP 725 blocks, entire classes of subscribers could be classified with IP- 726 prefix rules. Similarly, in a mobile network path selection could be 727 based on the APN (Access Point Name) identifier. 729 Hence, there are methods of globally managing very large networks by 730 choosing a suitable classification granularity. 732 Details of Lower Levels of Hierarchy 734 Within each SF sub-domain, there are: 736 1. An IBN to receive incoming data packets on any of the configured 737 service chains and load-balance (if necessary) traffic to 738 classifiers, 740 2. Classifier(s) to select internal service chain to use, 741 potentially based on stateful flow analysis, DPI, etc. 743 3. Service components comprised of FWD and SF. 745 Local Service Chaining orchestration is concerned with providing 746 viable paths to various functions, providing failure recovery, NFV 747 elasticity, etc. 749 Classification within each sub-domain can be concerned with 750 determining the local service paths for individual transport-layer 751 flows based on ports, DPI and meta-data provided by the higher-level 752 chain. 754 For any classifier that is transport-layer-stateful, it is most 755 efficient for the same classifier instance to handle traffic in both 756 directions of a bidirectional connection. State tracking may require 757 that service function paths begin and terminates at the same node 758 with the flow state, where the same classifier instance can be used 759 for both directions of traffic. 761 4. Consideration on Forwarding Methods and Paths Selection Patterns 763 This chapter presents the results of analyzing the forwarding methods 764 and architecture patterns in chapter 3. 766 4.1. Analysis of Forwarding Methods 768 4.1.1. Analysis of Method 1 770 Data Plane Aspects 772 This method can achieve Service Chaining without changing packet 773 format, such as attaching any header on packets, so it may not 774 imply any overhead or be subject to MTU restrictions. 775 Furthermore, this method does not require additional functions for 776 SFs to apply or handle any header because data packets are 777 transported unaltered. Therefore, it will be easier to use legacy 778 SFs for network operators. 780 On the other hand, it is difficult to forward a packet to same 781 FWDs several times because flow identifiable information is not 782 basically changed in the forwarding processes. For example, 783 distinction of incoming ports will be required for FWD to resolve 784 the next hop appropriately when a packet traverses it several 785 times. 787 Control Plane Aspects 789 This method requires FWDs to set forwarding entries for each flow. 790 For example, if there are 10,000 flows to be handled at a CF/FWD, 791 the forwarding table for each CF/FWD uses 10,000 flow entries at 792 most. Therefore, it might not be feasible for large-scale 793 networks such as carrier networks that handle a SC per user (which 794 means that individual users will be associated with different 795 policies), because some large carriers have over a million users 796 and even more flows. Another concern is the increase of control 797 signaling because route setting is required for each flow. 798 Moreover, it may be hard to use this method if some SFs modify 799 header fields of a packet or frame, for example, NAT/NAPT, in a 800 chain. For example, if a NAT changes the IP address of packets 801 dynamically, the FWDs that follow need to renew their forwarding 802 tables. 804 The results of the above analysis suggest that, although this method 805 is beneficial in terms of impact to existing network, it would not be 806 scalable. Therefore, this method might be suitable for networks with 807 a limited number of flows. 809 Measurements taken in multiple residential service providers' 810 networks indicate that for each 1Gbps of traffic the sustained rate 811 of new flows can range from 1,000 flows/s to 30,000 flows/s. From 812 this, for example, there would be between 10,000 and 300,000 new 813 flows/s on a 10 Gbps link. Therefore, in some networks at some times 814 of day, this method using 5-tuple as flow identifiable information 815 would require sustaining up to 300,000 table updates per second for 816 each FWD. This incurs a significant amount of control traffic and 817 computational effort. 819 4.1.2. Analysis of Method 2 821 Data Plane Aspects 823 In this method, SP information is attached on each packet as 824 headers for forwarding, and the number of the headers increases 825 depending on the number of SFs which the packet will traverse. 826 This means that the size of each packet increases. Packet sizes 827 may be restricted by the minimum available MTU of any link in the 828 network and exceeding the MTU will require to fragment the 829 original packets. Fragmentation adds a new source of errors and 830 may require forwarding processes to be more complex. For example, 831 the whole original packet will be discarded even if one of 832 fragments of the packet gets lost, or in terms of SF equipment, it 833 would be very wasteful of CPU if fragmented packets need to be 834 reassembled at every SF resources, and some equipment has 835 restricted resources and memory for reassembly. Fragmentation 836 will also cause an increase in traffic as more packets have to be 837 processed by the network. 839 Moreover, this method requires SF to be applied to the headers 840 because they receive packets with optional headers. Therefore SFs 841 will be required to be able to recognize the headers, or proxy 842 functions, which remove the tags before inserting packets into SFs 843 and re-attach the appropriate tag on the returned packet, will be 844 required. In addition, when a SF is used by multiple SCs, it will 845 be challenging for SFs to process packets because header length 846 attached on each packet may vary and SFs are required to have a 847 mechanism to recognize the header length for each packet. 849 Control Plane Aspects 851 In this method, none of the FWDs require any specific forwarding 852 tables for Service Chaining or interface to receive forwarding 853 configuration information. Also, no CEs will be required to 854 manage the forwarding configuration of FWDs, so the control plane 855 might become simple. 857 On the other hand, some relay nodes such as switches or SFs are 858 required to have a function to remove the outermost header from 859 the received packets. FWDs also don't have to identify flows or 860 services, so cannot change the following SPs. Moreover, CF must 861 grasp all of addresses of relay nodes which packets will traverse, 862 and it will require any CE to manage addresses of relay nodes and 863 a link between CF and the CE. There are already several existing 864 technologies that can be used to achieve this method, such as 865 segment routing. 867 The results of the above analysis indicate that this method would be 868 appropriate when the number of SFs in a SC is small, and most SFs are 869 deployed in a single domain. On the other hand, it may be unsuitable 870 in cases where there are many SFs in a chain, or packets have to 871 traverse multiple domains. 873 4.1.3. Analysis of Method 3 875 Data Plane Aspects 877 In this method, a service chain identifier, defined for each SC, 878 is mapped into each packet. FWDs recognize the next hops of 879 received packets from the identifiers independent of any 880 information of original packets. Therefore, SFs which modify 881 original packet format can also be used. In addition, it is easy 882 to change the following SPs on a route by renewing the identifier. 884 On the other hand, attachment of an identifier might expand packet 885 size, and it would cause an increase of traffic amount or problems 886 which happens as a result of exceeding MTU (The problems are 887 stated in Section 4.1.2.). However, by adopting a single fixed- 888 length identifier, the problems might be prevented. 890 Moreover, forwarding along SPs is provided based on service chain 891 identifiers, and so if there are network nodes which are unaware 892 of the identifiers, such as routers without functions to forward 893 packets based on the identifiers, in a SC domain, some tunnel 894 would be required for passing packets over them. 896 Additionally, the features of each approach to map service chain 897 identifiers are described below. 899 o Tagging an extra header: 901 In this approach, the identifiers are prepended to packets, and 902 so a single mapping mechanism could be used independently of 903 the formats of the target packets. 905 Conversely, this approach requires SFs to parse the extra 906 headers (Problems which happens as result of inserting packet 907 with optional headers into SFs are stated in Section 4.1.2). 909 In case that an existing header, which SFs can recognize, is 910 used as a service identifiable tag, this problem might be 911 restricted. For example, some SFs can recognize VLAN- tags, 912 and they would not need any improvement for the SFs if they are 913 used as service identifiable tags. However, using an existing 914 header might effect on the original uses. 916 o Inserting into an optional field: 918 In this method, service chain identifiers are inserted in some 919 field of the original packets, and the packets seem normal 920 formats from SFs. Therefore, any improvement for enabling SFs 921 to handle the identifiers would not be required. 923 Meanwhile, identifier insertion or packet forwarding mechanisms 924 would vary depending on the formats of the original packets, 925 because positions where identifiers are inserted are different 926 for each packet format. For example, optional field positions 927 of IPv4 and IPv6 headers are different. 929 Also, in case that existing field is used for storing the 930 identifier, amount of identifier information might be small 931 compared with tagging an extra header approaches. 933 Control Plane Aspects 935 This method enables FWDs to save resources for managing forwarding 936 tables and all SPs may be established in advance in most of cases. 937 This prevents an increase of control signals such as openflow or 938 Gx/Sd, and also enables to change the following SPs without 939 changing forwarding configuration information of FWDs. 941 On the other hand, this method requires a new control mechanism 942 based on the tags, therefore, FWDs, CE and interface between them 943 have to be updated to apply forwarding configuration based on the 944 tags. 946 The results of the above analysis indicate that this method has many 947 advantages in terms of scalability, and it might be appropriate for 948 use in large-scaled networks in which there are many SFs and flows. 949 By the way, if the tag handling mechanism is an entirely new 950 architecture such as SFC[I-D.ietf-sfc-architecture], renewal or 951 introduction of several equipment such as FWDs and CE will be 952 required. 954 4.2. Analysis of Service Path Selection Patterns 956 4.2.1. Analysis of Pattern 1 958 In this pattern, the mechanism of FWDs would be simpler than the one 959 in pattern 2 because FWDs do not require any functions to select 960 paths or retrieve any information for next hop resolution purposes. 961 Moreover, it is not necessary to maintain the state of each flow. 962 Therefore, existing protocols for virtualizing networks, such as 963 VxLAN or MPLS, can be used to achieve Service Chaining in this 964 pattern. 966 However, this pattern will impact the flexibility of the SCs, as 967 adding new SFs to a SC, removing SFs from a SC, or migrating SFs to 968 other locations requires an update or the creation of a new path in 969 the Service Path. Furthermore, unified management of FWDs and SFs in 970 an SC domain would be required in setting end-to-end paths. 971 Therefore, the management system of SPs, for example, a CE, for wide- 972 area networks that include several segments may be massive and 973 complex. Figure 11 shows the case in which SPs are established 974 across multiple datacenters in pattern 1. In Figure 11, a CE manages 975 multiple datacenters as a single SC domain for establishing SPs 976 across multiple datacenters. 978 In pattern 4.2.1.2 (SF Dedicated Model), the number of flow entries 979 that FWDs hold can be extremely small, as FWDs hold only static route 980 information. Also, the CF function would be simple, as the CF only 981 determines the gateway of each SP. However, because the SF 982 (instance) is settled for each SP, resource usage would be high if 983 there were many SPs. 985 +--------------+ 986 . . . . . . . . . . |Control Entity| . . . . . 987 . . +--------------+ . 988 . . . 989 * * . * * * * . * * * * * * * * * * * * * * * * . * * * * * * * * * 990 * . . . * 991 * . . . * 992 * . .-----. .-----------. .-----. * 993 * +----+ / DC#1 \ / WAN \ / DC#2 \ * 994 * | |=====================================================> SP#1 * 995 * | CF |=====================================================> SP#2 * 996 * : : : * 997 * | |=====================================================> SP#n * 998 * +----+ \ / \ / \ / * 999 * '-----' '-----------' '-----' * 1000 * * 1001 * SC Domain * 1002 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 1004 Figure 11: Establishment of SPs Across Multiples DCs in Pattern 1 1006 4.2.2. Analysis of Pattern 2 1008 In this pattern, SPs are established with a combination of segmented 1009 paths, so it enables SPs to be established flexibly (which means, CEs 1010 do not need to constantly manage the entire end-to-end SP) based on 1011 additional information such as the SF load conditions. 1013 Furthermore, as described in the previous section, in cases where 1014 some SPs traverse multiple datacenters across a WAN, SPs could be 1015 established with a combination of segmented paths that each 1016 datacenter determines independently based on the Service Chain 1017 information. Therefore, it might be possible to separate SC domains 1018 into several small areas for WANs, which would enable a simpler 1019 configuration of each CE. Figure 12 shows the case in which SPs are 1020 established across multiple datacenters in pattern 2. In Figure 12, 1021 each CE manages a single datacenter independently, and the CEs 1022 synchronize the Service Chain information for establishing and 1023 determining the appropriate segmented SPs in each domain. 1025 However, the (fault) monitoring of the whole SC can become more 1026 difficult, as multiple domains are part of the SC. On the other 1027 hand, each domain can perform its management as required (and this is 1028 probably better as it is more specific). This will require an 1029 overarching (fault) monitoring where information from multiple SC 1030 domains is collected and aggregated to get a full view of the end-to- 1031 end service of the SC. 1033 Moreover, in this pattern, some FWDs may require additional 1034 mechanisms to select the next segmented path, and the FWDs must 1035 maintain the states of each flow because some SFs require a stateful 1036 process, and the FWDs need to insert packets into the same SF 1037 instances in the same session. 1039 In case that SC information is conveyed to some components via data 1040 plane as any encapsulation, a new protocol such as SFC 1041 [I-D.ietf-sfc-architecture] will be required. 1043 Synchronization of 1044 Service Chain info. 1045 +--------------------------------------+ 1046 | | 1047 v v 1048 +--------+ +--------+ 1049 | CE#1 | | CE#2 | 1050 +--------+ +--------+ 1051 . . 1052 * * * * * * . * * * * * * * * * * * * . * * * * * * 1053 * . * * . * 1054 * .-------------. * * .------------. * 1055 * / DC#1 \ * .------. * / DC#2 \ * 1056 * +----+ +-----+ * / WAN \ * +-----+ | * 1057 * | |=========>| | * | | * | CF/ |==========> SP#1 * 1058 * | CF |=========>| FWD |===============>| FWD |==========> SP#2 * 1059 * : : : * | | * : : : * 1060 * | |=========>| | * \ / * | |==========> SP#n * 1061 * +----+ +-----+ * '------' * +-----+ | * 1062 * \ / * * \ / * 1063 * '-------------' * * '-----------' * 1064 * SC Domain#1 * * SC Domain#2 * 1065 * * * * * * * * * * * * * * * * * * * * * * * * * * * * 1067 Figure 12: Establishment of SPs Across Multiples DCs in pattern 2 1069 Also, the detailed analysis of the establishment of "Hierarchical 1070 Service Path domains" is shown in the following section. 1072 4.2.2.1. Analysis of Hierarchical Service Path domains 1074 The dynamic selection of SPs pattern allows multiple independent 1075 domains of administration. (In the example, two levels were shown, 1076 but the pattern could be extended to multiple levels.) 1077 This pattern allows even the largest networks to implement SC from 1078 the edges of the network by using coarse-grained classification. 1079 Classification choices can be made that are feasible within the 1080 constraints of the edge classifiers and FWDs. There is no need to 1081 maintain flow state or react to traffic at the top level. 1083 This pattern allows control of sub-domains to be delegated to 1084 different owners. Each domain is simpler to comprehend than would be 1085 the case by dealing with a single flat network. Furthermore, 1086 failures and errors are localized (See Figure 13.). 1088 +----------+ 1089 |Top-level | . . . . . . . . . . . . . . . . . . . . . 1090 |Control | . 1091 |Entity | +------------+ +--------+ . 1092 +----------+ |sub-domain#1|. . .| CE#1 | . 1093 . +-----+------+ +--------+ . 1094 . | . 1095 . .------+---------. +---+ . 1096 . +---+ / \--|CF |. . . . 1097 . . . .|CF |--/ \ |FWD| . 1098 . |FWD| / \+---+ . 1099 . +---+ | | . 1100 . | | . 1101 . | | . 1102 . +---+ \ / . 1103 . |CF | \ / +---+ . 1104 . . . .|FWD|---\ /---|CF | . . . 1105 +---+ '------+---------' |FWD| 1106 | +---+ 1107 +--------+ +------------+ 1108 | CE#2 |. . .|sub-domain#2| 1109 +--------+ +-----+------+ 1111 Figure 13: Multiple Control Entities in Hierarchical Service Chaining 1113 This hierarchical model supports the management of large networks by 1114 adhering to these principles: 1116 1. At higher levels of hierarchy, packet classification is coarse, 1117 to minimize state and control-plane chatter. 1119 2. At lower levels of hierarchy, packet classification can be more 1120 granular because classifiers in the lower levels deal with a 1121 subset of the entire network: fewer flows, lower bit-rate and a 1122 subset of network policy. 1124 However, in this model, a new component that can proxy between the 1125 different domains, termed "Internal Boundary Node (IBN)," will be 1126 required. It has some commonality with the legacy SF proxy discussed 1127 in [I-D.song-sfc-legacy-sf-mapping]. 1129 This model also requires some coordination of path information within 1130 the IBN, since the IBN must map packets back and forth between 1131 domains. Solving this probably requires sharing metadata 1132 dictionaries among controllers and inventing a scheme that provides a 1133 level of indirection by naming path identifiers and metadata values. 1135 4.3. Example of selecting Methods and Patterns 1137 In this section, clarifications about the most suitable method and 1138 pattern are made for the following example networks based on the 1139 results of the above analysis. 1141 4.3.1. Example#1: Enterprise Datacenter Network 1143 The conditions of the target network are as follows: 1145 Network type: Network with a single DC. 1147 Intended service: For providing several network service to traffic 1148 of one or several business offices. 1150 Variation of service: A group of adopting network service varies per 1151 office. 1153 The number of SFs included in a service chain: Less than 5 (ref. 1154 section 3.2.1. Sample north-south service function chains in 1155 [I-D.ietf-sfc-dc-use-cases]). 1157 Features of SFs: SFs are set statically, and SFs are exclusively 1158 used for each service. 1160 On the basis of the conditions "network type" and "features of SFs", 1161 pattern 1 with SF dedicated model would be selected. 1163 As the condition "variation of service" describes, such network 1164 requires few flow entries for each FWD, so method 1 would be 1165 applicable. Method 1 also does not require SFs to have any 1166 additional mechanism to apply any header, thus the impact of 1167 implementing this method would be less than other methods. 1169 4.3.2. Example#2: Current Mobile Service Providers Network 1171 The conditions of the target network are as follows: 1173 Network type: Network with a single DC (e.g., (S)Gi-LAN (3GPP, 1174 [TS.23.203])). 1176 Intended service: For providing network access service and several 1177 network service to traffic of millions customers. 1179 Variation of service: Service varies per user or applications. 1181 The number of SFs included in a service chain: Around 5(ref. 1182 examples of service in [I-D.ietf-sfc-use-case-mobility].). 1184 Features of SFs: Many SFs are hardware equipment and they are 1185 deployed statically. Also, many SFs are used for several service. 1186 A function to inspect user traffic in detail, such as TDF (3GPP, 1187 [TS.23.203]), is located at the ingress of the network, and it 1188 might behave as a CF. 1190 On the basis of the conditions "network type" and "features of SFs," 1191 pattern 1 with SF shared model would be selected. In such network, 1192 classification based on deep packet inspection such as application 1193 type inspections is done, and paths branching will not be happen. 1195 As the other conditions describe, the operator must handle millions 1196 of flows and the flows traverse multiple SFs, so method 3 would be 1197 applicable. Configuring such amounts of flows among large scale 1198 network might be too much work for operators. 1200 The examples of concrete service of such network are described as 1201 follows: 1203 1. HTTP Modification 1205 Packet Gateway(P-GW), which is defined in 3GPP (ref. [tS.23.203]), 1206 detects traffic to the specific website and that traffic must be 1207 sent through a special element to insert additional data to the 1208 HTTP header or advertisement to the HTTP traffic, so the 1209 destination site can apply specific deals with the operator's 1210 customer (simplify DRM, premium service, etc.) That would require 1211 flow entries with mobile source IP, destination IP and port. 1213 2. VoLTE Calls 1215 VoLTE calls are sent via a special SP. The VoLTE control plane 1216 selects all application network elements. But to reach 1217 application network elements it fully relies on standard routing 1218 and switching mechanisms. With Service Chaining it is possible to 1219 select the SP which can provide required QoS. That would require 1220 to set flow entries with mobile source IP, destination IP and 1221 port. 1223 3. Secure Internet Access 1225 Some customers' HTTP traffic is forwarded to one or more security 1226 functions to inspect for malware. This case would require flow 1227 entries with source IP, destination IP and port. 1229 4. Content Optimizer 1231 Based on the policy rules, a SC/SP with the Content Optimization 1232 might be provided. Content optimization primarily affects video 1233 and HTTP traffic, and saves valuable radio resources in the 1234 specific radio cells during times of congestion. A controller 1235 might monitor Key Performance Indicators (KPIs) of the radio 1236 network to detect congestion. When congestion is detected, the 1237 controller might enforce a content optimization policy for the 1238 users on the congested radio cell. Most resource-expensive 1239 traffic can be transcoded by a content optimizer to save 1240 bandwidth. Selecting traffic for optimization would require to 1241 set flow entries with mobile source IP, destination IP and port. 1242 Also, content optimization might require changing SCs/SPs assigned 1243 to users flows based on the result of KPI monitoring or the time 1244 of day. 1246 On the other hand, method 1 might be also selected with pattern 1 1247 with SF dedicated model. For example, the series of the above 1248 service might be achieved by static configured flow entries, for 1249 example, with incoming port. However, it will require many incoming 1250 ports for FWDs when the operator would like to share a SF with 1251 multiple SCs, and it will not be scalable. 1253 4.3.3. Example#3: Fixed and Mobile Converged Service Providers Network 1255 The conditions of the target network are as follows: 1257 Network type: Network with multiple DCs (e.g., SFs are deployed at 1258 multiple DCs based on their applications). 1260 Intended service: For providing network access service or several 1261 network service to traffic of millions customers. 1263 Variation of service: Service varies per user. Also, the service 1264 assigned to each flow might vary based on using applications. 1266 The number of SFs included in a service chain: More than 5. 1267 (Various services such as enriched security service and value 1268 added services would be provided) 1270 Features of SFs: Many SFs are deployed as VNFs (Virtualized Network 1271 Functions), and some SFs are shared with multiple SCs. Also, some 1272 SFs changes the following SPs dynamically based on the result of 1273 the process. 1275 On the basis of the conditions "network type" and "features of SFs," 1276 pattern 2 would be selected. Pattern 2 allows hierarchical approach 1277 which enables operators to deploy SFs in multiple domains easily 1278 based on service requirements. For example, operators can deploy SFs 1279 into several domains based on application types. This concept is 1280 introduced in [I-D.ietf-sfc-dc-use-cases]. 1282 From the above conditions describe, the operator must handle enormous 1283 flows and paths branching, thus method 3 will be appreciable for such 1284 network. Especially, security scenario sometimes requires paths 1285 branching based on the result of packet inspection such as processes 1286 of DPI or traffic analyzer. Some security functions such as web 1287 application firewall (WAF) are specialized for each application, and 1288 it might be inefficient to insert all traffic into such SFs. 1289 Therefore, for inserting only target packets to appropriate security 1290 functions, classifying and paths branching based on packet inspection 1291 would be required. 1293 5. Acknowledgements 1295 The authors would like to thank Konomi Mochizuki and Lily Guo for 1296 their reviews and comments. 1298 6. Contributors 1300 The following people are active contributors to this document and 1301 have provided review, content and concepts (listed alphabetically by 1302 surname): 1304 Mohamed Boucadair 1305 France Telecom 1307 Nicolas Bouthors 1308 Qosmos 1310 Hiroshi Dempo 1311 NEC 1313 Christian Jacquenet 1314 France Telecom 1316 Ron Parker 1317 Affirmed Networks 1319 Chuong D. Pham 1320 Telstra 1322 Paul Quinn 1323 Cisco Systems 1325 7. IANA Considerations 1327 This memo includes no request to IANA. 1329 8. References 1331 [I-D.dolson-sfc-hierarchical] 1332 Dolson, D., Homma, S., Lopez, D., Boucadair, M., and D. 1333 Liu, "Hierarchical Service Function Chaining", draft- 1334 dolson-sfc-hierarchical-03 (work in progress), October 1335 2015. 1337 [I-D.ietf-sfc-architecture] 1338 Halpern, J. and C. Pignataro, "Service Function Chaining 1339 (SFC) Architecture", draft-ietf-sfc-architecture-11 (work 1340 in progress), July 2015. 1342 [I-D.ietf-sfc-dc-use-cases] 1343 Surendra, S., Tufail, M., Majee, S., Captari, C., and S. 1344 Homma, "Service Function Chaining Use Cases In Data 1345 Centers", draft-ietf-sfc-dc-use-cases-03 (work in 1346 progress), July 2015. 1348 [I-D.ietf-sfc-nsh] 1349 Quinn, P. and U. Elzur, "Network Service Header", draft- 1350 ietf-sfc-nsh-01 (work in progress), July 2015. 1352 [I-D.ietf-sfc-use-case-mobility] 1353 Haeffner, W., Napper, J., Stiemerling, M., Lopez, D., and 1354 J. Uttaro, "Service Function Chaining Use Cases in Mobile 1355 Networks", draft-ietf-sfc-use-case-mobility-04 (work in 1356 progress), July 2015. 1358 [I-D.song-sfc-legacy-sf-mapping] 1359 Song, H., You, J., Yong, L., Jiang, Y., Dunbar, L., 1360 Bouthors, N., and D. Dolson, "SFC Header Mapping for 1361 Legacy SF", draft-song-sfc-legacy-sf-mapping-06 (work in 1362 progress), August 2015. 1364 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1365 Address Translator (Traditional NAT)", RFC 3022, 1366 DOI 10.17487/RFC3022, January 2001, 1367 . 1369 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1370 NAT64: Network Address and Protocol Translation from IPv6 1371 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 1372 April 2011, . 1374 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 1375 Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, 1376 . 1378 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 1379 Service Function Chaining", RFC 7498, 1380 DOI 10.17487/RFC7498, April 2015, 1381 . 1383 Authors' Addresses 1385 Shunsuke Homma 1386 NTT, Corp. 1387 3-9-11, Midori-cho 1388 Musashino-shi, Tokyo 180-8585 1389 Japan 1391 Phone: +81 422 59 3486 1392 Email: homma.shunsuke@lab.ntt.co.jp 1394 Kengo Naito 1395 NTT, Corp. 1396 3-9-11, Midori-cho 1397 Musashino-shi, Tokyo 180-8585 1398 Japan 1400 Email: naito.kengo@lab.ntt.co.jp 1401 Diego R. Lopez 1402 Telefonica I+D. 1403 Don Ramon de la Cruz, Street 1404 Madrid 28006 1405 Spain 1407 Phone: +34 913 129 041 1408 Email: diego.r.lopez@telefonica.com 1410 Martin Stiemerling 1411 NEC Laboratories Europe / Hochschule Darmstadt 1412 Kurfuerstenanlage 36 1413 Heidelberg 69115 1414 Germany 1416 URI: ietf.stiemerling.org 1418 David Dolson 1419 Sandvine 1420 408 Albert Street 1421 Waterloo, Ontario N2L 3V3 1422 Canada 1424 Email: ddolson@sandvine.com 1426 Alexey Gorbunov 1427 Nokia 1428 6000 Connection Drive 1429 Irving, Texas 75039 1430 USA 1432 Phone: +1 214 516 11 41 1433 Email: Alexey.gorbunov82@gmail.com 1435 Nicolai Leymann 1436 DT 1437 Winterfeldtstrasse 21-27 1438 Berlin 10781 1439 Germany 1441 Phone: +49 (0)30 835392761 1442 Email: n.leymann@telekom.de