idnits 2.17.1 draft-homma-sfc-forwarding-methods-analysis-05.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 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 (January 29, 2016) is 3010 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'CF' is mentioned on line 385, but not defined == Missing Reference: 'FWD' is mentioned on line 385, but not defined == Unused Reference: 'RFC7498' is defined on line 1520, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-dolson-sfc-hierarchical-04 == Outdated reference: A later version (-02) exists of draft-fedyk-sfc-mac-chain-01 == Outdated reference: A later version (-06) exists of draft-ietf-sfc-dc-use-cases-04 == Outdated reference: A later version (-28) exists of draft-ietf-sfc-nsh-02 == Outdated reference: A later version (-09) exists of draft-ietf-sfc-use-case-mobility-05 == 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: August 1, 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 P. Bottorff 16 D. Fedyk 17 HP Enterprise 18 January 29, 2016 20 Analysis on Forwarding Methods for Service Chaining 21 draft-homma-sfc-forwarding-methods-analysis-05 23 Abstract 25 This document presents the results of analyzing packet forwarding 26 methods and path selection patterns for achieving Service Chaining. 27 In Service Chaining, data packets need to be forwarded to the 28 appropriate service functions deployed in networks based on service 29 provided for the packets, and distribution of the service-oriented 30 route information and steering data packets following the route 31 information would be required. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on August 1, 2016. 50 Copyright Notice 52 Copyright (c) 2016 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 69 3. Classification of Forwarding Methods and SP Selection 70 Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3.1. Forwarding Methods . . . . . . . . . . . . . . . . . . . 5 72 3.1.1. Method 1: Forwarding Based on Flow Identifiable 73 Information . . . . . . . . . . . . . . . . . . . . . 6 74 3.1.2. Method 2: Forwarding with Stacked Headers . . . . . . 7 75 3.1.3. Method 3: Forwarding Based on Service Chain 76 Identifiers . . . . . . . . . . . . . . . . . . . . . 9 77 3.2. Service Path Selection Patterns . . . . . . . . . . . . . 12 78 3.2.1. Pattern 1: Static Selection of End-to-End Service 79 Path . . . . . . . . . . . . . . . . . . . . . . . . 13 80 3.2.2. Pattern 2: Dynamic Selection of Segmented Service 81 Path . . . . . . . . . . . . . . . . . . . . . . . . 16 82 4. Consideration on Forwarding Methods and Paths Selection 83 Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . 21 84 4.1. Analysis of Forwarding Methods . . . . . . . . . . . . . 22 85 4.1.1. Analysis of Method 1: Using Flow Identifiable 86 Information . . . . . . . . . . . . . . . . . . . . . 22 87 4.1.2. Analysis of Method 2: Stacking Headers . . . . . . . 23 88 4.1.3. Analysis of Method 3: Using Service Chain Identifier 24 89 4.2. Analysis of Service Path Selection Patterns . . . . . . . 27 90 4.2.1. Analysis of Pattern 1: Static SP Selection . . . . . 27 91 4.2.2. Analysis of Pattern 2: Dynamic SP Selection . . . . . 28 92 4.3. Example of selecting Methods and Patterns . . . . . . . . 32 93 4.3.1. Example#1: Enterprise Datacenter Network . . . . . . 32 94 4.3.2. Example#2: Current Mobile Service Providers Network . 32 95 4.3.3. Example#3: Fixed and Mobile Converged Service 96 Providers Network . . . . . . . . . . . . . . . . . . 34 97 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 98 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 35 99 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 100 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 103 1. Introduction 105 Some IETF working groups of and other Standards Developing 106 Organizations are now discussing use cases of a technology that 107 provides service-oriented traffic forwarding schemes to convey 108 packets to the various service functions, deployed in networks, for 109 providing network services. In this document, we define such 110 technology as Service Chaining. (This draft does not focus only on 111 "Service Function Chaining (SFC)" architecture, and thus, use the 112 term "Service Chaining." SFC is one of approaches to realize Service 113 Chaining.) There are several methods to achieve Service Chaining, 114 and the applicable method will vary depending on the service 115 requirements of individual networks. 117 This draft assumes that Service Chaining is achieved by the following 118 steps: 120 a. A traffic classification function identifies the service that is 121 associated to each incoming packets by inspecting the key 122 information such as IP address or 5-tuple. 124 b. The forwarding path used by packets for reaching the appropriate 125 service functions, is established according to the services 126 provided for the packets. The path might be established in 127 advance. 129 c. Forwarding functions forward the packets to the next destination 130 along the path established in step b. 132 d. A service function operates on received packets. Once the 133 invocation of a service function is completed, the packet is 134 forwarded to the next forwarding function. 136 e. Steps c and d are repeated until each packet has been transferred 137 to all required service functions. 139 f. After a packet has been transferred to all required Service 140 Functions, it is forwarded to its original destination. 142 There are several forwarding methods for Service Chaining, and they 143 can be classified into certain categories in terms of distribution of 144 information for setting the paths and decision of the paths. The 145 methods used to distribute the information for path setting and the 146 patterns used to decide the paths will affect the mechanism of 147 Service Chaining in terms of scalability and service flexibility. 149 The applicable methods vary depending on network requirements, and 150 thus, classifying and determining forwarding methods will be 151 important in designing the architecture of Service Function Chaining 152 (SFC). This document provides the results of analysis of different 153 forwarding methods for Service Chaining. 155 OAM, security, and redundancy are outside the scope of this draft. 157 2. Definition of Terms 159 Term "Classification", "Classifier" referred to [RFC7665]. Term 160 "Service Function", "Service Node" referred to 161 [I-D.ietf-sfc-dc-use-cases]. 163 Service Chaining: A technology that enables data packets to invoke a 164 set of service functions. 166 Classification: Locally instantiated matching of traffic flows 167 against policy for subsequent application of the required set of 168 network service functions. The policy may be customer/network/ 169 service specific. 171 Classifier (CF): An element that performs classification. 173 Service Function (SF): A function that is responsible for specific 174 treatment of received packets. A Service Function can act at 175 various layers of a protocol stack (e.g. at the network layer or 176 other OSI layers). A Service Function can be a virtual element or 177 be embedded in a physical network element. One of multiple 178 Service Functions can be embedded in the same network element. 179 Multiple occurrences of the Service Function can be enabled in the 180 same administrative domain. 182 One or more Service Functions can be involved in the delivery of 183 added-value services. A non-exhaustive list of Service Functions 184 includes: firewalls. WAN and application acceleration, Deep 185 Packet Inspection (DPI), LI (Lawful Intercept) module, server load 186 balancers, NAT44 [RFC3022], NAT64 [RFC6146], NPTv6 [RFC6296], 187 HOST_ID injection, HTTP Header Enrichment functions, TCP 188 optimizer, etc. 190 Forwarder (FWD): The entity, responsible for forwarding data packets 191 according to the ordered set of service functions that need to be 192 invoked. A forwarder maintains one or more forwarding tables, 193 which contain entries that asset the forwarder in its forwarding 194 decision-making process. 196 Control Entity (CE): One or a set of control entities responsible 197 for managing service topology and indicating forwarding 198 configurations to forwarders. 200 Service Chain (SC): A service chain defines an ordered list of 201 service functions that must be applied to packets selected as a 202 result of classification. The implied order may not be a linear 203 progression as the architecture allows for nodes that copy to more 204 than one branch. 206 Service Path (SP): The forwarding path followed by packets that are 207 associated to a given service chain. Packets follow a service 208 path through the requisite service functions that need to be 209 invoked, as per the service chain instructions. Service path 210 shows a specific path that traverses several service function 211 instances. For example, SC is written as SF#1 -> SF#2 -> SF#3 212 (This shows an ordered list of SFs), and SP is written as 213 SF#1_1(1_1 means instance 1 of SF1) -> SF#2_1 -> SF#3_1. 215 Segmented Service Path: A Segmented Service Path is an actual path 216 established between FWDs. A service path might be composed of 217 some segmented service paths. 219 Service Chaining Domain (SC Domain): The domain managed by one or a 220 set of CEs. 222 Service Path Information (SP Information): The information used to 223 forward packets to the appropriate SFs according to the service 224 that needs to be provided. Examples of SP information include 225 routing configuration for forwarders, headers for forwarding 226 packets to required SFs, and service/flow identifiable tags. 228 3. Classification of Forwarding Methods and SP Selection Patterns 230 3.1. Forwarding Methods 232 In Service Chaining, data packets are transferred to service 233 functions, which might be located outside the regular computed path 234 to the original destination. Therefore, a routing mechanism that is 235 different from general L2/L3 switching/forwarding might be required. 236 The forwarding mechanism can be classified into three methods in 237 terms of distribution of SP information and packet forwarding. 239 3.1.1. Method 1: Forwarding Based on Flow Identifiable Information 241 The mechanism of method 1 is shown in Figure 1. In this method, 242 forwarding configuration information is based on flow identifiable 243 information, such as 5-tuple (e.g. dst IP, src IP, dst port, src 244 port, tcp) are indicated to the CF and each FWD. There might be an 245 CE to handle this. The flow identifiable information can be 246 constructed with some fields of L2, L3 or L4 or combination thereof. 247 The information can be configured either before packets arrive, or at 248 the time packets arrive at CF and FWD. Each FWD identifies the 249 packets with flow identifiable information and forwards the packets 250 to the SFs according to the configuration. This method does not 251 require the modification of any field in the original packet header. 253 *Distribution model of SP information* 255 +----------------+ 256 | Control Entity | 257 +----------------+ 258 ^ | indication of routing configuration 259 | | based on packet identifiable information 260 | +---------------+-------------------------------+---------> 261 | | | | 262 | | | | 263 | v v v 264 +--------+ +-------+ +------+ +-------+ 265 ------>| CF |------> | FWD |------> | SF#1 |------>| FWD |-----> 266 +--------+ +-------+ +------+ +-------+ 268 //////////////////////////////////////////////////////////////////////// 269 *Forwarding Tables* 271 Locate: [CF] [FWD] [FWD] 273 Table: 192.168.1.1 192.168.1.1 192.168.1.1 274 ->FWD#1 ->SF#1 ->SF#2 275 10.0.1.1 10.0.1.1 10.0.1.1 276 ->FWD#1 ->FWD#2 ->SF#2 277 ... ... ... 279 //////////////////////////////////////////////////////////////////////// 280 *Condition of Packet* 282 Locate: [CF] [FWD] [SF#1] [FWD] 284 +-------+ +-------+ +-------+ +-------+ 285 Packet: | PDU | | PDU | | PDU | | PDU | 286 +-------+ +-------+ +-------+ +-------+ 288 Figure 1: Forwarding Based on Flow Identifiable Information 290 3.1.2. Method 2: Forwarding with Stacked Headers 292 The mechanism of method 2 is shown in Figure 2. In this method, the 293 CF classifies packets and stacks headers in which actual network 294 address is included, e.g., MPLS, GRE headers or IPv6 Segment Routes, 295 onto the packets based on the classification. The packet is 296 transferred to the destination according to the outermost header, and 297 a SF or FWD, as the destination, removes the outermost header after 298 receiving the packet. The processes are repeated until all stacked 299 headers are removed. This method does not require any forwarding 300 entries for forwarding packets based on the service information. 302 *Distribution model of SP information* 304 +----------------+ 305 | Control Entity | 306 +----------------+ 307 ^ | 308 | | indication of 309 | | stacking headers 310 | v 311 +--------+ +-------+ +------+ +------+ 312 -------->| CF |------>| SF#1 |------>| SF#2 |------>| SF#3 |------> 313 +--------+ +-------+ +------+ +------+ 315 //////////////////////////////////////////////////////////////////////// 316 *Forwarding Tables* 318 Locate: [CF] 320 Table: 192.168.1.1 __/__/__/__/__/__/__/__/__/__/__/__/__/ 321 ->Stack #1,2,3 __/ Packets are forwarded to SFs by __/ 322 10.0.1.1 __/ the outermost header. __/ 323 ->Stack #1,3 __/__/__/__/__/__/__/__/__/__/__/__/__/ 324 ... 326 //////////////////////////////////////////////////////////////////////// 327 *Condition of Packet* 329 Locate: [CF] [SF#1] [SF#2] [SF#3] 331 +--------+ 332 Header: |To SF#1 | 333 +--------+ +--------+ 334 |To SF#2 | |To SF#2 | 335 +--------+ +--------+ +--------+ 336 |To SF#3 | |To SF#3 | |To SF#3 | 337 +--------+ +--------+ +--------+ 338 : : : : 339 +--------+ +--------+ +--------+ +--------+ 340 Packet: | PDU | | PDU | | PDU | | PDU | 341 +--------+ +--------+ +--------+ +--------+ 343 Figure 2: Forwarding with Stacked Multiple Headers 345 3.1.3. Method 3: Forwarding Based on Service Chain Identifiers 347 The mechanism of this method is shown in Figure 3. In this method, 348 the corresponding service chain identifier is mapped to each packet 349 by a CF based on the classification. The forwarding configuration 350 based on the identifiers is sent to each FWD. Each FWD identifies 351 the SP assigned to the received packet from the identifier, and 352 forwards the packet to the next hop. After a packet has traversed 353 all SFs, the identifier is removed and the packet is transported to 354 the original destination. 356 *Distribution model of SP information* 358 +----------------+ 359 | Control Entity | 360 +----------------+ 361 ^ | indication of attached tag 362 | | and routing configuration based on tags 363 | +----------------+------------------------------+---------> 364 | | | | 365 | | | | 366 | v v v 367 +--------+ +-------+ +------+ +-------+ 368 ----->| CF |------> | FWD |------>| SF#1 |------>| FWD |-----> 369 +--------+ +-------+ +------+ +-------+ 371 ////////////////////////////////////////////////////////////////////// 372 *Forwarding Tables* 374 Locate: [CF] [FWD] [FWD] 376 Table: 192.168.1.1 IF ID#1,3 IF ID#1,2,5 377 ->Stack ID#1 ->SF#1 ->SF#2 378 10.0.1.1 379 ->Stack ID#2 380 ... ... ... 382 ////////////////////////////////////////////////////////////////////// 383 *Condition of Packet* 385 Locate: [CF] [FWD] [SF#1] [FWD] 387 +-------+ +-------+ +-------+ +-------+ 388 SC-ID: | ID#1 | | ID#1 | | ID#1 | | ID#1 | 389 +-------+ +-------+ +-------+ +-------+ 390 Packet:| PDU | | PDU | | PDU | | PDU | 391 +-------+ +-------+ +-------+ +-------+ 393 Figure 3: Forwarding Based on Service Chain Identifiers 395 Then, there are mainly three approaches to map service chain 396 identifiers to packets as follows. 398 o Tagging an extra header: 400 In this approach, an extra header which has a service chain 401 identifier is attached on each packet. This document defines such 402 headers as service identifiable tags. Some existing tags, such as 403 VLAN-tag or MPLS-tag, or dedicated headers, such as NSH, could be 404 used as service identifiable tags. As an example, SFC[RFC7665] is 405 categorized into this approach. An example of packet format in 406 tagging approach with NSH is shown in Figure 4. In this example, 407 a service chain identifier is included in NSH. 409 +----------+-------+--------+-------------~~--+ 410 | NSH | Ether | IPv6 |IPv6 Payload | 411 | \SC-ID | Header| Header | | 412 +----------+-------+--------+-------------~~--+ 414 |--- Ethernet Packet ---| 416 Figure 4: Packet Format in Tagging Approach 418 o Inserting into an optional field: 420 In this approach, a service chain identifier is inserted into an 421 optional field inside a packet frame, such as IPv6 extension 422 header. An example of an IPv6 packet with a service chain 423 identifier inserted as an extension header is shown in Figure 5. 425 +-------+--------+----------+-------------~~--+ 426 | Ether |IPv6 |IP Opt.Fld|IPv6 Payload | 427 | Header|Base Hdr| \SC-ID | | 428 +-------+--------+----------+-------------~~--+ 430 |-- IPv6 Header --| 432 |--- Ethernet Packet ---| 434 Figure 5: Packet Format in Inserting Approach 436 o Overloading on a destination or source address: 438 In this approach, service chain identifier is overloaded on a 439 destination or a source address such as MAC or IP address. In 440 other words, the addresses are used for both showing the 441 destination or source in network and identifying service chain 442 which each packet belongs to. An address is required for each hop 443 in a service chain, and FWDs switch the address to new one for the 444 next hop by referring the address of the received packet. An 445 example of using destination address overloading is shown in 446 Figure 6. In this example, SFs are used as L2 transparent mode, 447 and service chain identifiers are overloaded on destination MAC 448 addresses. FWD2 refers the destination MAC address which shows 449 the address for Port B, and changes it to the address for port D 450 for sending the packet to the next hop in the service chain. When 451 using non-transparent SFs in the overloading approach, the 452 identifier is carried from the FWD to the SF in the source 453 address(SA) and is carried from the SF to the FWD in the 454 destination address(DA). More detailed processes of the 455 overloading approach using MAC addresses is described in Ethernet 456 MAC Chaining[I-D.fedyk-sfc-mac-chain]. 458 *Network Structure* 460 Port A Port B Port C Port D 461 | | | | 462 | | | | 463 .------. | +[SF1]+ | .------. | +[SF2]+ | .------. 464 / \v | | v/ \v | | v/ \ 465 --# FWD1 #--+ +--# FWD2 #--+ +--# FWD3 #-- 466 \ / ^ \ / ^ \ / 467 '------' | '------' | '------' 468 | | 469 . . . . . . . . | . . . . . . . . . . .| . . . . . . . . . . . . . 470 | | 471 *Packet Frame* | | 472 | | 473 +--------+-------~-+ +--------+-------~-+ 474 |MAC-DA:B| Payload | |MAC-DA:D| Payload | 475 +--------+-------~-+ +--------+-------~-+ 477 ============== Flow Direction ==============> 479 Figure 6: Overview of DA Overloading Approach 481 3.2. Service Path Selection Patterns 483 Since SC contains only logical information (e.g., a set of services 484 that are associated with flows and their sequences), the actual 485 instances, which are called SPs, are needed in order for the 486 forwarding process to work. In this process, an instance of SP is 487 created at certain points during a packet's delivery. Therefore, to 488 forward packets, the SC needs to be turned into an SP, which 489 indicates specific FWDs (or switches, routers) and SFs that the 490 packets will be forwarded to. From the perspective of points 491 translating SC to SP, the methods that establish SPs from end-to-end 492 are classified into two patterns. 494 3.2.1. Pattern 1: Static Selection of End-to-End Service Path 496 The translation point is a CF; that is, the SP is statically pre- 497 established as an end-to-end path and a CF forwards packets along the 498 appropriate path based on the result of the classification. Each FWD 499 on the SP has a forwarding table to uniquely determine the next 500 destination of packets, and each FWD statically forwards the received 501 packets toward the next destination based on the table. FWD requires 502 only a function to receive indications of forwarding configurations 503 from the CE. Pattern 1 can be achieved in the following models. 505 3.2.1.1. SF Dedicated Model: Network Slicing Model 507 In this model, an SF instance (or a set of SF instances) is used by 508 only one single SP; in other words, a set of SF instances is prepared 509 for each SP. This model also enables operators to establish SPs 510 without any FWDs by slicing network physically or virtually and 511 deploying a set of SFs required for service providing in each sliced 512 network. A CF assigns packets to the network in which the 513 appropriate SF set is installed inline, and the packets traverse the 514 SFs by being forwarded along the pre-configured route. The overview 515 of network slicing model is shown in Figure 7. 517 *Path Structure* 518 * * * * * * * * * * * * * * * * * * * * * * * 519 * network#1 * 520 +----+ * +------+ +------+ +------+ * 521 | |SC#1 * | SF#1 | | SF#2 | | SF#3 | * SP#1 522 | |=======================================================> 523 | | * +------+ +------+ +------+ * 524 | | * * * * * * * * * * * * * * * * * * * * * * * 525 | | 526 | | * * * * * * * * * * * * * * * * * * * * * * * 527 | | * network#2 * 528 | | * +------+ +------+ * 529 | |SC#2 * | SF#4 | | SF#5 | * SP#2 530 | |=======================================================> 531 ->| CF | * +------+ +------+ * 532 | | * * * * * * * * * * * * * * * * * * * * * * * 534 . . 535 . . 536 . . 537 * * * * * * * * * * * * * * * * * * * * * * * 538 * network#n * 539 * +------+ +------+ +------+ * 540 | |SC#n * | SF#6 | | SF#7 | | SF#8 | * SP#n 541 | |======================================================> 542 +----+ * +------+ +------+ +------+ * 543 * * * * * * * * * * * * * * * * * * * * * * * 544 SC:Service Chain SP:Service Path 545 ////////////////////////////////////////////////////////////////////// 546 *How packets traverse* 548 Service Chain#1: 549 SP#1 550 [ CF ]----------->[ SF#1 ]---->[ SF#2 ]----->[ SF#3 ]-------> 552 Service Chain#2: 553 SP#2 554 [ CF ]----------->[ SF#4 ]------------------>[ SF#5 ]-------> 555 : 556 Service Chain#n: 557 SP#n 558 [ CF ]----------->[ SF#6 ]---->[ SF#7 ]----->[ SF#8 ]-------> 560 Figure 7: SF Dedicated Model 562 3.2.1.2. SF Shared Model 564 In this model, an SF is shared by multiple SPs. Several SPs are 565 mixed at shared SFs, and thus this method requires FWDs for 566 forwarding each packet to the corresponding next hop by identifying 567 the SP which each packet belongs to. The overview of the SF shared 568 model is shown Figure 8. 570 *Path Structure* 572 +----+ +---+ +----+ +---+ +------+ +---+ +----+ 573 | |SC#1 |FWD| |SF#1| |FWD| |SF#2_1| |FWD| |SF#3| SP#1 574 | |==============================================================> 575 | |SC#2 | | | | | | +------+ | | | | SP#2 576 | |============================# +------+ #======================> 577 | | | | +----+ | | # |SF#2_2| # | | +----+ 578 | | | | | | #==========# | | 579 ->| CF | +---+ +---+ +------+ +---+ 580 | | 581 . . 582 . . 583 . . 584 +---+ +----+ +---+ +----+ 585 | |SC#n |FWD| |SF#4| |FWD| |SF#5| SP#n 586 | |==============================================================> 587 +----+ +---+ +----+ +---+ +----+ 589 SC:Service Chain SP:Service Path 590 /////////////////////////////////////////////////////////////////////// 591 *Packet Flow* 593 Service Chain#1: 594 SP#1 595 [ CF ]---->[FWD]-->[SF#1]-->[FWD]-->[SF#2_1]-->[FWD]-->[SF#3]---> 597 Service Chain#2: 598 SP#2 599 [ CF ]---->[FWD]-->[SF#1]-->[FWD]-->[SF#2_2]-->[FWD]-->[SF#3]---> 600 : 601 Service Chain#n: 602 SP#n 603 [ CF ]---->[FWD]-->[SF#4]--------------------->[FWD]-->[SF#5]---> 605 Figure 8: SF Shared Model 607 3.2.2. Pattern 2: Dynamic Selection of Segmented Service Path 609 The mechanism of this pattern is shown in Figure 9. The translation 610 points are CFs and some FWDs. The SP is established by a series of 611 multiple paths, which are sectioned by CFs and FWDs. The resulting 612 path is referred to as a segmented path in this draft. CFs or FWDs 613 that select the next segmented path might require notification of 614 forwarding configuration information from the CE. Moreover, some 615 FWDs require functions to select the destination of packets from 616 various alternatives and to retrieve the information for selecting 617 the next path. For example, each FWD obtains metric information or 618 load conditions of servers and selects an optimal segmented path 619 based on the information. The CE might support the selection 620 mechanism and may notify CFs or FWDs of it. 622 *Path Structure* 624 +----+ +---+ +----+ +---+ +------+ +---+ +----+ 625 | |SC#1 |FWD| |SF#1| |FWD| |SF#2_1| |FWD| |SF#3| SP#1 626 | |========================*=====================================> 627 | | | | | | | # | +------+ | | | | SP#2 628 | | | | | | | # | +------+ #======================> 629 | | | | +----+ | # | |SF#2_2| # | | +----+ 630 | | | | | #==============# | | 631 ->| CF | +---+ +---+ +------+ +---+ 632 | | 633 . . 634 . . 635 . . 636 +---+ +----+ +---+ +----+ 637 | |SC#n |FWD| |SF#4| |FWD| |SF#5| SP#m 638 | |==============================================================> 639 +----+ +---+ +----+ +---+ +----+ 641 SC:Service Chain SP:Service Path 642 /////////////////////////////////////////////////////////////////////// 644 *How packets traverse* 646 Service Chain#1: 647 SP#1 648 [ CF ]---->[FWD]-->[SF#1]-->[FWD]-->[SF#2_1]-->[FWD]-->[SF#3]---> 650 SP#2 651 [ CF ]---->[FWD]-->[SF#1]-->[FWD]-->[SF#2_2]-->[FWD]-->[SF#3]---> 652 : 653 Service Chain#n: 654 SP#m 655 [ CF ]---->[FWD]-->[SF#4]--------------------->[FWD]-->[SF#5]---> 657 Figure 9: Dynamic Selection of Segmented Service Path 659 In addition, this pattern supports the establishment of hierarchical 660 domains discussed below: 662 3.2.2.1. Hierarchical Service Path Domains 664 Complex problems often become manageable with a hierarchical 665 approach. This pattern allows network-wide orchestration of Service 666 Chaining to be relatively simple, while hiding the complexities of 667 fine-grained policy-based path selection within sub-domains. Each 668 sub-domain can be independently administered and orchestrated. This 669 architecture is described in [I-D.dolson-sfc-hierarchical]. 671 Figure 10 shows two levels of hierarchy in a service provider's 672 network. At the top level in the hierarchy, Service Chaining 673 components are: 675 1. Edge-classifiers (Edge CF) that reside near the edge of a service 676 provider's domain. 678 2. SF sub-domains that reside in data centers. 680 3. Internal Boundary Nodes (IBNs) that reside in data centers, 681 linking together the levels of the hierarchy. To the higher 682 level, sub-domains are viewed as a SF. To the lower level, this 683 is a classifier and FWD. 685 *How packets traverse* 687 +----+ +-----+ +----------------------+ +-----+ 688 | |SC#1| FWD | | IBN#1 | | FWD | 689 ->| |================* *=====================> 690 | | +-----+ | # (in DC#1) # | +-----+ 691 | | | V # | 692 |Edge| |+---+ +---+| Top domain 693 | CF | * * * * *||CF | * * * * * *|FWD|| * * * * * 694 | | * |+---+ +-+-+| * 695 | | * | | | | | | Sub * 696 | | * +-o-o--------------o-o-+ domain* 697 | | * SC#1.2 | |SC#1.1 ^ ^ #1 * 698 | | * +-----+ | | | * 699 | | * | V | | * 700 | | * | +---+ +------+ | | * 701 | | * | |FWD|->|SF#1_1|--+ | * 702 | | * | +---+ +------+ | * 703 | | * V | * 704 | | * +---+ +------+ +---+ +------+ * 705 | | * |FWD|->|SF#1_2|->|FWD|->|SF#2_1| * 706 | | * +---+ +------+ +---+ +------+ * 707 . * * * * * * * * * * * * * * * * * * * * * * 708 . 709 | | +-----+ +---------------------+ +-----+ 710 | |SC#n| FWD | | IBN#q | | FWD | 711 | |=======================================================> 712 | | +-----+ | (in DC#m) | +-----+ 713 +----+ +---------------------+ 714 (Details of sub-domain #q not shown) 716 Figure 10: Service Chain Hierarchy in Service Provider Networks 718 The components within an SF sub-domain are opaque at the top level; 719 each IBN acts as a single SF node in the top-level domain. A service 720 path in the top-level domain may visit multiple sub-domains. 722 At the lower level in the hierarchy, each sub-domain contains an 723 independently administrated Service Chaining network, generally 724 comprised of multiple instances of multiple types of hosts, most 725 likely (but not necessarily) within the same data center. There is 726 no need for knowledge of the "big picture" at the level of the SF- 727 sub-domain except as required to forward packets to the other SFs 728 that are the next hop of each chain. 730 Note that different encapsulation methods can be used at each layer 731 in the hierarchy, provided the SF domain-Proxy can translate between 732 them. For example, MPLS could be used to deliver packets from 733 network edge to the SF clusters within data centers, and NSH 734 [I-D.ietf-sfc-nsh] could be used within the data center. 736 Details of Top Level of Hierarchy 738 In this pattern, referring to Figure 11, network-wide Service 739 Chaining orchestration is only concerned with creating service paths 740 from network edge points to sub-domains within data centers and 741 configuring classifiers at a coarse level to get the correct hosts' 742 traffic onto paths that will arrive at appropriate sub-domains. The 743 figure shows one possible service chain passing from edge, through 744 two sub-domains, to network egress. 746 This top level of orchestration may attach metadata to provide 747 context from the network edge into the data center. 749 +------------+ 750 |Sub-domain#1| 751 | in DC1 | 752 +----+-------+ 753 | 754 .------+---------. +--+ 755 +--+ / / | \--|CF| 756 --->|CF|--/---->' | \ +--+ 757 +--+ / SC#1 | \ 758 | | | 759 | | .------>|---> 760 | / / | 761 \ | / / 762 +--+ \ | / / +--+ 763 |CF|---\ V / /---|CF| 764 +--+ '------+---------' +--+ 765 | 766 +----+-------+ 767 |Sub-domain#2| 768 | in DC2 | 769 +------------+ 771 Figure 11: Network-wide view of Top Level of Hierarchy 773 The orchestration at this top level must ensure bidirectional path 774 symmetry so that inbound packets traverse sub-domains in the reverse 775 order as outbound packets. 777 Because classifiers must have rules to handle any traffic passing 778 through the network, we believe that a useful approach to 779 classification will be to assign traffic to service function paths on 780 the basis of coarse classification like subscriber tier, tenant or 781 VRF identifier. These classification rules could be relatively 782 static, changing in response to provisioning but not in response to 783 traffic. 785 In some networks, it might be possible to create a rule per 786 residential subscriber, resulting in rule updates when subscribers 787 are assigned IP addresses. However, with judicious allocation of IP 788 blocks, entire classes of subscribers could be classified with IP- 789 prefix rules. Similarly, in a mobile network path selection could be 790 based on the APN (Access Point Name) identifier. 792 Hence, there are methods of globally managing very large networks by 793 choosing a suitable classification granularity. 795 Details of Lower Levels of Hierarchy 797 Within each SF sub-domain, there are: 799 1. An IBN to receive incoming data packets on any of the configured 800 service chains and load-balance (if necessary) traffic to 801 classifiers, 803 2. Classifier(s) to select internal service chain to use, 804 potentially based on stateful flow analysis, DPI, etc. 806 3. Service components comprised of FWD and SF. 808 Local Service Chaining orchestration is concerned with providing 809 viable paths to various functions, providing failure recovery, NFV 810 elasticity, etc. 812 Classification within each sub-domain can be concerned with 813 determining the local service paths for individual transport-layer 814 flows based on ports, DPI and meta-data provided by the higher-level 815 chain. 817 For any classifier that is transport-layer-stateful, it is most 818 efficient for the same classifier instance to handle traffic in both 819 directions of a bidirectional connection. State tracking may require 820 that service function paths begin and terminates at the same node 821 with the flow state, where the same classifier instance can be used 822 for both directions of traffic. 824 4. Consideration on Forwarding Methods and Paths Selection Patterns 826 This chapter presents the results of analyzing the forwarding methods 827 and architecture patterns in chapter 3. 829 4.1. Analysis of Forwarding Methods 831 4.1.1. Analysis of Method 1: Using Flow Identifiable Information 833 Data Plane Aspects 835 This method can achieve Service Chaining without changing packet 836 format, such as attaching any header on packets, so it may not 837 imply any overhead or be subject to MTU restrictions. 838 Furthermore, this method does not require additional functions for 839 SFs to apply or handle any header because data packets are 840 transported unaltered. Therefore, it will be easier to use legacy 841 SFs for network operators. 843 On the other hand, it is difficult to forward a packet to same 844 FWDs several times because flow identifiable information is not 845 basically changed in the forwarding processes. For example, 846 distinction of incoming ports will be required for FWD to resolve 847 the next hop appropriately when a packet traverses it several 848 times. 850 Control Plane Aspects 852 This method might be achieved by using existing control 853 mechanisms. For example, openflow, which is able to provide 854 flexible forwarding control, would be available for creating SPs. 856 However, this methoed might require FWDs to configure forwarding 857 entries for each flow to each FWD. For example, if there are 858 10,000 flows to be handled at a CF/FWD, the forwarding table for 859 each CF/FWD uses 10,000 flow entries at most. Therefore, it might 860 not be feasible for large-scale networks such as carrier networks 861 that handle a SC per user (which means that individual users will 862 be associated with different policies), because some large 863 carriers have over a million users and even more flows. In 864 addition, control signaling would increase because forwarding 865 configuration for each flow to each FWD is required. Moreover, it 866 may be hard to use this method if some SFs modify header fields of 867 a packet or frame, for example, NAT/NAPT, in a chain. For 868 example, if a NAT changes the IP address of packets dynamically, 869 the FWDs that follow need to renew their forwarding tables. This 870 method also have restriction about forwarding based on high-layer 871 information, such as application information in packet payload. 872 The process of detecting high-layer information is usually heavy 873 compared with L2 or L3 forwarding process, and most existing 874 forwarding functions have capability to refer only under L4 875 headers. Therefore, it will be difficult to use this method to 876 forward packets along SPs decided by detecting high-layer 877 information since individual L2-4 packet headers may not retain 878 enough information. An example of this type of problem is a video 879 streaming imbedded within a web page. The identifiable 880 information at the L2-4 level does not allow differentiation 881 between the video stream and the rest of the frame, and thus the 882 all traffic on the web page is forwarded following the same SC. 884 The results of the above analysis suggest that, although this method 885 is beneficial in terms of impact to existing network, it would not be 886 scalable. Therefore, this method might be suitable for networks with 887 a limited number of flows. 889 Measurements taken in multiple residential service providers' 890 networks indicate that for each 1Gbps of traffic the sustained rate 891 of new flows can range from 1,000 flows/s to 30,000 flows/s. From 892 this, for example, there would be between 10,000 and 300,000 new 893 flows/s on a 10 Gbps link. Therefore, in some networks at some times 894 of day, this method using 5-tuple as flow identifiable information 895 would require sustaining up to 300,000 table updates per second for 896 each FWD. This incurs a significant amount of control traffic and 897 computational effort. 899 4.1.2. Analysis of Method 2: Stacking Headers 901 Data Plane Aspects 903 In this method, SP information is attached on each packet as 904 headers for forwarding, and the number of the headers increases 905 depending on the number of SFs which the packet will traverse. 906 This means that the size of each packet increases. Packet sizes 907 may be restricted by the minimum available MTU of any link in the 908 network and exceeding the MTU will require to fragment the 909 original packets. Fragmentation adds a new source of errors and 910 may require forwarding processes to be more complex. For example, 911 the whole original packet will be discarded even if one of 912 fragments of the packet gets lost, or in terms of SF equipment, it 913 would be very wasteful of CPU if fragmented packets need to be 914 reassembled at every SF resources, and some equipment has 915 restricted resources and memory for reassembly. Fragmentation 916 will also cause an increase in traffic as more packets have to be 917 processed by the network. 919 Moreover, this method requires SF to be applied to the headers 920 because they receive packets with optional headers. Therefore SFs 921 will be required to be able to recognize the headers, or proxy 922 functions, which remove the headers before inserting packets into 923 SFs and re-attach the appropriate headers on the returned packet, 924 will be required. In addition, when a SF is used by multiple SCs, 925 it will be challenging for SFs to process packets because header 926 length attached on each packet may vary and SFs are required to 927 have a mechanism to recognize the header length for each packet. 929 Control Plane Aspects 931 In this method, none of the FWDs require any specific forwarding 932 tables for Service Chaining or interface to receive forwarding 933 configuration information. In short, FWDs are stateless or 934 eliminated at hops, and this method has advantages of high scale 935 in SPs managements and lower latency. In addition, no CEs will be 936 required to manage the forwarding configuration of FWDs for 937 Service Chaining, and so the control mechanism might become simple 938 compared with other methods. 940 On the other hand, some relay nodes such as switches or SFs are 941 required to have a function to remove the outermost header from 942 the received packets. FWDs also don't have to identify flows or 943 services, so cannot change the following SPs. Moreover, CF must 944 grasp all of addresses of relay nodes which packets will traverse, 945 and it will require any CE to manage addresses of relay nodes and 946 a link between CF and the CE. There are already several existing 947 technologies that can be used to achieve this method, such as 948 segment routing. 950 The results of the above analysis indicate that this method would be 951 appropriate when the number of SFs in a SC is small, and most SFs are 952 deployed in a single domain. On the other hand, it may be unsuitable 953 in cases where there are many SFs in a chain, or packets have to 954 traverse multiple domains. 956 4.1.3. Analysis of Method 3: Using Service Chain Identifier 958 Data Plane Aspects 960 The common features of this method and the individual features of 961 each approach to map service chain identifiers in terms of data 962 plane aspects are described below. 964 o Common features of method3 966 In this method, a service chain identifier, defined for each 967 SC, is mapped into each packet. FWDs recognize the next hops 968 of received packets from the identifiers independent of any 969 information of original packets. Therefore, SFs which modify 970 original packet format can also be used. In addition, it is 971 easy to change the following SPs on a route by renewing the 972 identifier. 974 On the other hand, attachment of an identifier might expand 975 packet size, and it would cause an increase of traffic amount 976 or problems which happens as a result of exceeding MTU (The 977 problems are stated in Section 4.1.2.). However, by adopting a 978 single fixed-length identifier, the problems might be 979 prevented. Or, when overloading the identifier on an existing 980 field, such as MAC address, packet size is not changed and such 981 issues would not occur. 983 Moreover, forwarding along SPs is provided based on service 984 chain identifiers, and so if there are network nodes which are 985 unaware of the identifiers, such as routers without functions 986 to forward packets based on the identifiers, in a SC domain, 987 some tunnel would be required for passing packets over them. 989 o Tagging an extra header: 991 In this approach, the identifiers are prepended to packets, and 992 so a single mapping mechanism could be used independently of 993 the formats of the target packets. 995 Conversely, this approach requires SFs to parse the extra 996 headers (Problems which happens as result of inserting packet 997 with optional headers into SFs are stated in Section 4.1.2). 998 In case that an existing header, which SFs can recognize, is 999 used as a service identifiable tag, this problem might be 1000 restricted. For example, some SFs can recognize VLAN- tags, 1001 and they would not need any improvement for the SFs if they are 1002 used as service identifiable tags. However, using an existing 1003 header might have some effects on the original uses. 1005 o Inserting into an optional field: 1007 In this approach, service chain identifiers are inserted in 1008 some field of the original packets, and the packets seem normal 1009 formats from SFs. Therefore, any improvement for enabling SFs 1010 to handle the identifiers would not be required. 1012 Meanwhile, identifier insertion or packet forwarding mechanisms 1013 would vary depending on the formats of the original packets, 1014 because positions where identifiers are inserted are different 1015 for each packet format. For example, optional field positions 1016 of IPv4 and IPv6 headers are different. Furthermore, 1017 especially, the inserting approach, using IPv4 optional fields, 1018 might have some problems. For example, some server OS and 1019 applications strip the IPv4 optional field due to security 1020 concerns. Therefore, it appears this is a difficult solution 1021 for IPv4 networks. 1023 Also, in case that existing field is used for storing the 1024 identifier, amount of identifier information might be small 1025 compared with tagging an extra header approaches. 1027 o Overloading on a destination or source address: 1029 In this approach, a destination or source address is used for 1030 identifying service chain which the packet belongs to in 1031 addition to original usage, and so packets size increase caused 1032 by attaching additional headers does not occur. Also, any 1033 improvement for enabling SFs or any other network equipment to 1034 handle the identifiers would not be required, because the 1035 packets seem normal formats from them. In other words, this 1036 approach can coexist with legacy equipment. 1038 Meanwhile, the addresses for Service Chaining are overwritten 1039 on the original address in this approach, and so an additional 1040 encapsulation would be required during the Service Chaining 1041 process when retaining the original address information. 1042 Therefore, for cases when L2 or L3 addresses are used for 1043 identifying subscribers, the overloading approach might require 1044 the MTU expansion for additional encapsulation. Moreover, when 1045 using L2 addresses as service chain identifier and sending 1046 packets to another L2 domain across a L3 domain, an extra means 1047 such as L3 tunnel is required. 1049 Control Plane Aspects 1051 The common features of this method and the individual features of 1052 the overloading approach in terms of control plane aspects are 1053 described below. 1055 o Common features of method3 1057 This method enables FWDs to save resources for managing 1058 forwarding tables and allows all SPs to be established in 1059 advance in most of cases. This prevents an increase of control 1060 signals such as openflow or Gx/Sd, and also enables changing 1061 the following SPs without changing forwarding configuration of 1062 FWDs. 1064 On the other hand, this method requires a new control mechanism 1065 based on service chain identifiers, therefore, FWDs, CE and 1066 interface between them have to be updated to apply forwarding 1067 configuration based on the identifiers. 1069 o Overloading on a destination or source address: 1071 Overloading approach might be achieved without new control 1072 mechanisms or drastic remodeling of existing control entities. 1073 For example, MAC chaining can be established by using 1074 programmed standard openflow switches. 1076 On the other hand, in the overloading approach, each SP is 1077 composed of a set of unique addresses, and thus FWDs are 1078 required to have addresses as many as service chains which pass 1079 through them. 1081 The results of the above analysis indicate that this method has many 1082 advantages in terms of scalability, and it might be appropriate for 1083 use in large-scaled networks in which there are so many SFs and 1084 various types of flows. On the other hand, when the identifier 1085 handling mechanism is an entirely new architecture such as 1086 SFC[RFC7665], renewal or introduction of several equipment such as 1087 FWDs and CE will be required. 1089 4.2. Analysis of Service Path Selection Patterns 1091 4.2.1. Analysis of Pattern 1: Static SP Selection 1093 In this pattern, the mechanism of FWDs would be simpler than the one 1094 in pattern 2 because FWDs do not require any functions to select 1095 paths or retrieve any information for next hop resolution purposes. 1096 Moreover, it is not necessary to maintain the state of each flow. 1097 Therefore, existing network virtuarizing techniques, such as VxLAN or 1098 MPLS, can be used to achieve Service Chaining in this pattern. 1099 Especially, network slicing model does not require any special 1100 forwarding mechanisms. 1102 On the other hand, this pattern has restriction in the management of 1103 SPs. When adding new SFs to a SC, removing SFs from a SP, or 1104 migrating SFs to other locations, re-establishment of SP would be 1105 required. This restriction in network slicing model would be more 1106 strict because this model need to establish a new network for adding 1107 a SP. For relaxing the restriction, it is desirable to use this 1108 pattern together with a means, such as load balancer, which enable to 1109 add the same kind SFs into a SP without changing the configuration of 1110 the SP. Or the restriction would be relaxed when network 1111 virtuarizing technique progresses significantly and network operaters 1112 can install SFs more freely. 1114 In addition, this pattern would also have restriction for use in wide 1115 area networks which include multiple domains. This pattern requires 1116 unified management of FWDs and SFs, in an SC domain, for setting end- 1117 to-end paths. Therefore, the management system of SPs, for example, 1118 a CE, for wide-area networks that include several segments might be 1119 massive and complex. Figure 12 shows the case in which SPs are 1120 established across multiple datacenters in pattern 1. In this case, 1121 a CE (or a set of CEs) manages multiple datacenters as a single SC 1122 domain for establishing SPs across the datacenters. 1124 +--------------+ 1125 . . . . . . . . . . |Control Entity| . . . . . 1126 . . +--------------+ . 1127 . . . 1128 * * . * * * * . * * * * * * * * * * * * * * * * . * * * * * * * * * 1129 * . . . * 1130 * . . . * 1131 * . .-----. .-----------. .-----. * 1132 * +----+ / DC#1 \ / WAN \ / DC#2 \ * 1133 * | |=====================================================> SP#1 * 1134 * | CF |=====================================================> SP#2 * 1135 * : : : * 1136 * | |=====================================================> SP#n * 1137 * +----+ \ / \ / \ / * 1138 * '-----' '-----------' '-----' * 1139 * * 1140 * SC Domain * 1141 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 1143 Figure 12: Establishment of SPs across Multiples DCs in Pattern 1 1145 4.2.2. Analysis of Pattern 2: Dynamic SP Selection 1147 In this pattern, SPs are established with a combination of segmented 1148 paths, so it enables SPs to be established flexibly (which means, CEs 1149 do not need to constantly manage the entire end-to-end SP) based on 1150 additional information such as the SF load conditions. 1152 Furthermore, as described in the previous section, in cases where 1153 some SPs traverse multiple datacenters across a WAN, SPs could be 1154 established with a combination of segmented paths that each 1155 datacenter determines independently based on the Service Chain 1156 information. Therefore, it might be possible to separate SC domains 1157 into several small areas for WANs, which would enable a simpler 1158 configuration of each CE. Figure 13 shows the case in which SPs are 1159 established across multiple datacenters in pattern 2. In Figure 13, 1160 each CE manages a single datacenter independently, and the CEs 1161 synchronize the Service Chain information for establishing and 1162 determining the appropriate segmented SPs in each domain. 1164 However, the (fault) monitoring of the whole SC can become more 1165 difficult, as multiple domains are part of the SC. On the other 1166 hand, each domain can perform its management as required (and this is 1167 probably better as it is more specific). This will require an 1168 overarching (fault) monitoring where information from multiple SC 1169 domains is collected and aggregated to get a full view of the end-to- 1170 end service of the SC. 1172 Moreover, in this pattern, some FWDs may require additional 1173 mechanisms to select the next segmented path, and the FWDs must 1174 maintain the states of each flow because some SFs require a stateful 1175 process, and the FWDs need to insert packets into the same SF 1176 instances in the same session. 1178 In case that SC information is conveyed to some components via data 1179 plane as any encapsulation, a new protocol such as SFC [RFC7665] will 1180 be required. 1182 Synchronization of 1183 Service Chain info. 1184 +--------------------------------------+ 1185 | | 1186 v v 1187 +--------+ +--------+ 1188 | CE#1 | | CE#2 | 1189 +--------+ +--------+ 1190 . . 1191 * * * * * * . * * * * * * * * * * * * . * * * * * * 1192 * . * * . * 1193 * .-------------. * * .------------. * 1194 * / DC#1 \ * .------. * / DC#2 \ * 1195 * +----+ +-----+ * / WAN \ * +-----+ | * 1196 * | |=========>| | * | | * | CF/ |==========> SP#1 * 1197 * | CF |=========>| FWD |===============>| FWD |==========> SP#2 * 1198 * : : : * | | * : : : * 1199 * | |=========>| | * \ / * | |==========> SP#n * 1200 * +----+ +-----+ * '------' * +-----+ | * 1201 * \ / * * \ / * 1202 * '-------------' * * '-----------' * 1203 * SC Domain#1 * * SC Domain#2 * 1204 * * * * * * * * * * * * * * * * * * * * * * * * * * * * 1206 Figure 13: Establishment of SPs Across Multiples DCs in pattern 2 1208 Also, the detailed analysis of the establishment of "Hierarchical 1209 Service Path domains" is shown in the following section. 1211 4.2.2.1. Analysis of Hierarchical Service Path domains 1213 The dynamic selection of SPs pattern allows multiple independent 1214 domains of administration. (In the example, two levels were shown, 1215 but the pattern could be extended to multiple levels.) 1217 This pattern allows even the largest networks to implement SC from 1218 the edges of the network by using coarse-grained classification. 1219 Classification choices can be made that are feasible within the 1220 constraints of the edge classifiers and FWDs. There is no need to 1221 maintain flow state or react to traffic at the top level. 1223 This pattern allows control of sub-domains to be delegated to 1224 different owners. Each domain is simpler to comprehend than would be 1225 the case by dealing with a single flat network. Furthermore, 1226 failures and errors are localized (See Figure 14.). 1228 +----------+ 1229 |Top-level | . . . . . . . . . . . . . . . . . . . . . 1230 |Control | . 1231 |Entity | +------------+ +--------+ . 1232 +----------+ |sub-domain#1|. . .| CE#1 | . 1233 . +-----+------+ +--------+ . 1234 . | . 1235 . .------+---------. +---+ . 1236 . +---+ / \--|CF |. . . . 1237 . . . .|CF |--/ \ |FWD| . 1238 . |FWD| / \+---+ . 1239 . +---+ | | . 1240 . | | . 1241 . | | . 1242 . +---+ \ / . 1243 . |CF | \ / +---+ . 1244 . . . .|FWD|---\ /---|CF | . . . 1245 +---+ '------+---------' |FWD| 1246 | +---+ 1247 +--------+ +------------+ 1248 | CE#2 |. . .|sub-domain#2| 1249 +--------+ +-----+------+ 1251 Figure 14: Multiple Control Entities in Hierarchical Service Chaining 1253 This hierarchical model supports the management of large networks by 1254 adhering to these principles: 1256 1. At higher levels of hierarchy, packet classification is coarse, 1257 to minimize state and control-plane chatter. 1259 2. At lower levels of hierarchy, packet classification can be more 1260 granular because classifiers in the lower levels deal with a 1261 subset of the entire network: fewer flows, lower bit-rate and a 1262 subset of network policy. 1264 However, in this model, a new component that can proxy between the 1265 different domains, termed "Internal Boundary Node (IBN)," will be 1266 required. It has some commonality with the legacy SF proxy discussed 1267 in [I-D.song-sfc-legacy-sf-mapping]. 1269 This model also requires some coordination of path information within 1270 the IBN, since the IBN must map packets back and forth between 1271 domains. Solving this probably requires sharing metadata 1272 dictionaries among controllers and inventing a scheme that provides a 1273 level of indirection by naming path identifiers and metadata values. 1275 4.3. Example of selecting Methods and Patterns 1277 In this section, clarifications about the most suitable method and 1278 pattern are made for the following example networks based on the 1279 results of the above analysis. 1281 4.3.1. Example#1: Enterprise Datacenter Network 1283 The conditions of the target network are as follows: 1285 Network type: Network with a single DC. 1287 Intended service: For providing several network service to traffic 1288 of one or several business offices. 1290 Variation of service: A group of adopting network service varies per 1291 office. 1293 The number of SFs included in a service chain: Less than 5 (ref. 1294 section 3.2.1. Sample north-south service function chains in 1295 [I-D.ietf-sfc-dc-use-cases]). 1297 Features of SFs: SFs are set statically, and SFs are exclusively 1298 used for each service. 1300 On the basis of the conditions "network type" and "features of SFs", 1301 pattern 1 with SF dedicated model would be selected. 1303 As the condition "variation of service" describes, such network 1304 requires few flow entries for each FWD, so method 1 would be 1305 applicable. Method 1 also does not require SFs to have any 1306 additional mechanism to apply any header, thus the impact of 1307 implementing this method would be less than other methods. 1309 4.3.2. Example#2: Current Mobile Service Providers Network 1311 The conditions of the target network are as follows: 1313 Network type: Network with a single DC (e.g., (S)Gi-LAN (3GPP, 1314 [TS.23.203])). 1316 Intended service: For providing network access service and several 1317 network service to traffic of millions customers. 1319 Variation of service: Service varies per user or applications. 1321 The number of SFs included in a service chain: Around 5(ref. 1322 examples of service in [I-D.ietf-sfc-use-case-mobility].). 1324 Features of SFs: Many SFs are hardware equipment and they are 1325 deployed statically. Also, many SFs are used for several service. 1326 A function to inspect user traffic in detail, such as TDF (3GPP, 1327 [TS.23.203]), is located at the ingress of the network, and it 1328 might behave as a CF. 1330 On the basis of the conditions "network type" and "features of SFs," 1331 pattern 1 with SF shared model would be selected. In such network, 1332 classification based on deep packet inspection such as application 1333 type inspections is done, and paths branching will not be happen. 1335 As the other conditions describe, the operator must handle millions 1336 of flows and the flows traverse multiple SFs, so method 3 would be 1337 applicable. Configuring such amounts of flows among large scale 1338 network might be too much work for operators. 1340 The examples of concrete service of such network are described as 1341 follows: 1343 1. HTTP Modification 1345 Packet Gateway(P-GW), which is defined in 3GPP (ref. [tS.23.203]), 1346 detects traffic to the specific website and that traffic must be 1347 sent through a special element to insert additional data to the 1348 HTTP header or advertisement to the HTTP traffic, so the 1349 destination site can apply specific deals with the operator's 1350 customer (simplify DRM, premium service, etc.) That would require 1351 flow entries with mobile source IP, destination IP and port. 1353 2. VoLTE Calls 1355 VoLTE calls are sent via a special SP. The VoLTE control plane 1356 selects all application network elements. But to reach 1357 application network elements it fully relies on standard routing 1358 and switching mechanisms. With Service Chaining it is possible to 1359 select the SP which can provide required QoS. That would require 1360 to set flow entries with mobile source IP, destination IP and 1361 port. 1363 3. Secure Internet Access 1365 Some customers' HTTP traffic is forwarded to one or more security 1366 functions to inspect for malware. This case would require flow 1367 entries with source IP, destination IP and port. 1369 4. Content Optimizer 1370 Based on the policy rules, a SC/SP with the Content Optimization 1371 might be provided. Content optimization primarily affects video 1372 and HTTP traffic, and saves valuable radio resources in the 1373 specific radio cells during times of congestion. A controller 1374 might monitor Key Performance Indicators (KPIs) of the radio 1375 network to detect congestion. When congestion is detected, the 1376 controller might enforce a content optimization policy for the 1377 users on the congested radio cell. Most resource-expensive 1378 traffic can be transcoded by a content optimizer to save 1379 bandwidth. Selecting traffic for optimization would require to 1380 set flow entries with mobile source IP, destination IP and port. 1381 Also, content optimization might require changing SCs/SPs assigned 1382 to users flows based on the result of KPI monitoring or the time 1383 of day. 1385 On the other hand, method 1 might be also selected with pattern 1 1386 with SF dedicated model. For example, the series of the above 1387 service might be achieved by static configured flow entries, for 1388 example, with incoming port. However, it will require many incoming 1389 ports for FWDs when the operator would like to share a SF with 1390 multiple SCs, and it will not be scalable. 1392 4.3.3. Example#3: Fixed and Mobile Converged Service Providers Network 1394 The conditions of the target network are as follows: 1396 Network type: Network with multiple DCs (e.g., SFs are deployed at 1397 multiple DCs based on their applications). 1399 Intended service: For providing network access service or several 1400 network service to traffic of millions customers. 1402 Variation of service: Service varies per user. Also, the service 1403 assigned to each flow might vary based on using applications. 1405 The number of SFs included in a service chain: More than 5. 1406 (Various services such as enriched security service and value 1407 added services would be provided) 1409 Features of SFs: Many SFs are deployed as VNFs (Virtualized Network 1410 Functions), and some SFs are shared with multiple SCs. Also, some 1411 SFs changes the following SPs dynamically based on the result of 1412 the process. 1414 On the basis of the conditions "network type" and "features of SFs," 1415 pattern 2 would be selected. Pattern 2 allows hierarchical approach 1416 which enables operators to deploy SFs in multiple domains easily 1417 based on service requirements. For example, operators can deploy SFs 1418 into several domains based on application types. This concept is 1419 introduced in [I-D.ietf-sfc-dc-use-cases]. 1421 From the above conditions describe, the operator must handle enormous 1422 flows and paths branching, thus method 3 will be appreciable for such 1423 network. Especially, security scenario sometimes requires paths 1424 branching based on the result of packet inspection such as processes 1425 of DPI or traffic analyzer. Some security functions such as web 1426 application firewall (WAF) are specialized for each application, and 1427 it might be inefficient to insert all traffic into such SFs. 1428 Therefore, for inserting only target packets to appropriate security 1429 functions, classifying and paths branching based on packet inspection 1430 would be required. 1432 5. Acknowledgements 1434 The authors would like to thank Konomi Mochizuki and Lily Guo for 1435 their reviews and comments. 1437 6. Contributors 1439 The following people are active contributors to this document and 1440 have provided review, content and concepts (listed alphabetically by 1441 surname): 1443 Poul Bottorff 1444 Hewlett Packard Networking 1446 Mohamed Boucadair 1447 France Telecom 1449 Nicolas Bouthors 1450 Qosmos 1452 Hiroshi Dempo 1453 NEC 1455 Christian Jacquenet 1456 France Telecom 1458 Ron Parker 1459 Affirmed Networks 1461 Chuong D. Pham 1462 Telstra 1464 Paul Quinn 1465 Cisco Systems 1467 7. IANA Considerations 1469 This memo includes no request to IANA. 1471 8. References 1473 [I-D.dolson-sfc-hierarchical] 1474 Dolson, D., Homma, S., Lopez, D., Boucadair, M., and D. 1475 Liu, "Hierarchical Service Function Chaining", draft- 1476 dolson-sfc-hierarchical-04 (work in progress), December 1477 2015. 1479 [I-D.fedyk-sfc-mac-chain] 1480 Bottorff, P., don.fedyk@hpe.com, d., and H. Assarpour, 1481 "Ethernet MAC Chaining", draft-fedyk-sfc-mac-chain-01 1482 (work in progress), January 2016. 1484 [I-D.ietf-sfc-dc-use-cases] 1485 Surendra, S., Tufail, M., Majee, S., Captari, C., and S. 1486 Homma, "Service Function Chaining Use Cases In Data 1487 Centers", draft-ietf-sfc-dc-use-cases-04 (work in 1488 progress), January 2016. 1490 [I-D.ietf-sfc-nsh] 1491 Quinn, P. and U. Elzur, "Network Service Header", draft- 1492 ietf-sfc-nsh-02 (work in progress), January 2016. 1494 [I-D.ietf-sfc-use-case-mobility] 1495 Haeffner, W., Napper, J., Stiemerling, M., Lopez, D., and 1496 J. Uttaro, "Service Function Chaining Use Cases in Mobile 1497 Networks", draft-ietf-sfc-use-case-mobility-05 (work in 1498 progress), October 2015. 1500 [I-D.song-sfc-legacy-sf-mapping] 1501 Song, H., You, J., Yong, L., Jiang, Y., Dunbar, L., 1502 Bouthors, N., and D. Dolson, "SFC Header Mapping for 1503 Legacy SF", draft-song-sfc-legacy-sf-mapping-06 (work in 1504 progress), August 2015. 1506 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1507 Address Translator (Traditional NAT)", RFC 3022, 1508 DOI 10.17487/RFC3022, January 2001, 1509 . 1511 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1512 NAT64: Network Address and Protocol Translation from IPv6 1513 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 1514 April 2011, . 1516 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 1517 Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011, 1518 . 1520 [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for 1521 Service Function Chaining", RFC 7498, 1522 DOI 10.17487/RFC7498, April 2015, 1523 . 1525 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 1526 Chaining (SFC) Architecture", RFC 7665, 1527 DOI 10.17487/RFC7665, October 2015, 1528 . 1530 Authors' Addresses 1532 Shunsuke Homma 1533 NTT, Corp. 1534 3-9-11, Midori-cho 1535 Musashino-shi, Tokyo 180-8585 1536 Japan 1538 Phone: +81 422 59 3486 1539 Email: homma.shunsuke@lab.ntt.co.jp 1541 Kengo Naito 1542 NTT, Corp. 1543 3-9-11, Midori-cho 1544 Musashino-shi, Tokyo 180-8585 1545 Japan 1547 Email: k.naito@nttv6.jp 1549 Diego R. Lopez 1550 Telefonica I+D. 1551 Don Ramon de la Cruz, Street 1552 Madrid 28006 1553 Spain 1555 Phone: +34 913 129 041 1556 Email: diego.r.lopez@telefonica.com 1557 Martin Stiemerling 1558 NEC Laboratories Europe / Hochschule Darmstadt 1559 Kurfuerstenanlage 36 1560 Heidelberg 69115 1561 Germany 1563 URI: ietf.stiemerling.org 1565 David Dolson 1566 Sandvine 1567 408 Albert Street 1568 Waterloo, Ontario N2L 3V3 1569 Canada 1571 Email: ddolson@sandvine.com 1573 Alexey Gorbunov 1574 Nokia 1575 6000 Connection Drive 1576 Irving, Texas 75039 1577 USA 1579 Phone: +1 214 516 11 41 1580 Email: Alexey.gorbunov82@gmail.com 1582 Nicolai Leymann 1583 DT 1584 Winterfeldtstrasse 21-27 1585 Berlin 10781 1586 Germany 1588 Phone: +49 (0)30 835392761 1589 Email: n.leymann@telekom.de 1591 Paul Bottorff 1592 Hewlett Packard Enterprise 1593 8000 Foothills Blvd. 1594 Roseville, CA 1595 USA 1597 Email: paul.bottorff@hpe.com 1598 Don Fedyk 1599 Hewlett Packard Enterprise 1600 153 Taylor Street 1601 Littleton, MA 1602 USA 1604 Email: don.fedyk@hpe.com