idnits 2.17.1 draft-dunbar-sfc-legacy-l4-l7-chain-architecture-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 4, 2014) is 3556 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'SFC-ARCH' is mentioned on line 601, but not defined == Unused Reference: 'Boucadair-framework' is defined on line 714, but no explicit reference was found in the text == Unused Reference: 'NSH-Header' is defined on line 730, but no explicit reference was found in the text == Unused Reference: 'SC-MobileNetwork' is defined on line 733, but no explicit reference was found in the text == Unused Reference: 'Application-SDN' is defined on line 736, but no explicit reference was found in the text == Unused Reference: 'SC-Use-Case' is defined on line 739, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-boucadair-sfc-framework-00 == Outdated reference: A later version (-02) exists of draft-merged-sfc-architecture-00 == Outdated reference: A later version (-02) exists of draft-quinn-nsh-01 == Outdated reference: A later version (-02) exists of draft-liu-service-chaining-use-cases-00 Summary: 0 errors (**), 0 flaws (~~), 12 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network working group L. Dunbar 2 Internet Draft Huawei 3 Intended status: Informational Ron Parker 4 Expires: January 2015 Affirmed Networks 5 I. Smith; S. Majee 6 F5 Networks 7 N. So 8 Vinci Systems 9 Donald Eastlake 10 Huawei 11 July 4, 2014 13 Architecture for Chaining Legacy Layer 4-7 Service Functions 14 draft-dunbar-sfc-legacy-l4-l7-chain-architecture-05.txt 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. This document may not be modified, 23 and derivative works of it may not be created, except to publish it 24 as an RFC and to translate it into languages other than English. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six 32 months and may be updated, replaced, or obsoleted by other documents 33 at any time. It is inappropriate to use Internet-Drafts as 34 reference material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html 42 This Internet-Draft will expire on November 4, 2014. 44 Copyright Notice 46 Copyright (c) 2014 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with 54 respect to this document. Code Components extracted from this 55 document must include Simplified BSD License text as described in 56 Section 4.e of the Trust Legal Provisions and are provided without 57 warranty as described in the Simplified BSD License. 59 Abstract 61 This draft describes the architecture for chaining existing Layer 4- 62 7 service functions that are not aware of newly defined SFC header. 63 The intent is to identify optimal architecture for flexibly chaining 64 existing Layer 4-7 functions to meet various service needs. 66 Table of Contents 68 1. Introduction...................................................3 69 2. Conventions used in this document..............................3 70 3. Legacy Layer 4-7 Service Functions and Chaining................4 71 3.1. Layer 4-7 Service Functions...............................4 72 3.2. Metadata to Layer 4-7 Service Functions...................4 73 3.2.1. Metadata at different OSI Layers.....................5 74 3.2.2. Framework of carrying the metadata...................5 75 4. Architecture for Chaining Legacy Layer 4-7 Service Functions...6 76 4.1. Service Function Forwarder for Layer 4-7 Service Functions7 77 4.2. Layer 4-7 nodes connection to SFF Nodes...................9 78 4.3. Traffic Steering at SFF Nodes............................10 79 5. Control Plane for Layer 4-7 Service Function Chain............11 80 5.1. Multiple Instances of a Service Function.................11 81 5.2. Service Chain Re-Classification..........................13 82 5.3. Layer 4-7 traffic Steering...............................14 83 6. Service Chain from the Layer 7 Perspective....................16 84 7. Conclusion and Recommendation.................................16 85 8. Manageability Considerations..................................17 86 9. Security Considerations.......................................17 87 10. IANA Considerations..........................................17 88 11. References...................................................17 89 11.1. Normative References....................................17 90 11.2. Informative References..................................17 91 12. Acknowledgments..............................................18 93 1. Introduction 95 This draft describes the architecture for chaining existing Layer 4- 96 7 service functions that are not aware of newly defined SFC header. 97 The intent is to identify optimal architecture for flexibly chaining 98 existing Layer 4-7 functions to meet various service needs. 100 2. Conventions used in this document 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in RFC-2119 [RFC2119]. 106 In this document, these words will appear with that interpretation 107 only when in ALL CAPS. Lower case uses of these words are not to be 108 interpreted as carrying RFC-2119 significance. 110 Chain Classifier: A component that performs traffic classification 111 and potentially encodes a unique identifier or the SF MAP Index 112 introduced by [SFC-Framework] to the packets. The unique identifier 113 in the packets can be used by other nodes to associate the packets 114 to a specific service chain and/or steer the packets to the 115 designated service functions. 117 DPI: Deep Packet Inspection 119 FW: Firewall 121 Legacy Layer 4-7 Service Function: Same as the Service Functions 122 defined in [SFC-Problem] except that they may not be aware of the 123 new service function chain header encapsulations. Many of existing 124 Layer 4-7 service functions fall into this category. Exemplary 125 functional modules include Firewall, Deep Packet Inspection (DPI), 126 Encryption, Packet De-duplication, Compression, TCP Acceleration, 127 NAT, and etc 129 Service Function Instance: One instantiation of a service function. 131 One service function could have multiple identical instances. For a 132 service function with different functional instantiations, e.g. one 133 instantiation applies policy-set-A (NAT44-A) and other applies 134 policy-set-B (NAT44-B), they are considered as two different service 135 functions." 136 Some Service Function Instances are visible to Service Chain Path. 137 Sometimes a collection of service function instances can appear as 138 one single entity to the Service Chain Path, leaving the instance 139 selection to local nodes. 141 3. Legacy Layer 4-7 Service Functions and Chaining 143 Legacy Layer 4-7 service functions are the existing service 144 functions that may not be aware of any new service encapsulation 145 layers being proposed in SFC WG. 147 3.1. Layer 4-7 Service Functions 149 A Layer 4-7 service function performs certain action to the packets 150 traversed through. By Layer 4-7, it means that those functions don't 151 participate in network layer routing protocols. The implementation 152 of such service function can be either Proxy based or Packet Based, 153 or a hybrid of both when more than one function is performed to the 154 same packet flow. Multiple service functions can be instantiated on 155 a single service node as defined by [SFC-ARCH], or embedded in a 156 L2/L3 network node. 158 o Proxy based service functions: these service functions terminate 159 original packets, may reassemble multiple packets, reopen a new 160 connection, or formulate new packets based on the received 161 packets. 163 o Packet based service functions: these service functions maintain 164 original packets, i.e. they don't make changes to packets 165 traversed through except possibly making changes to metadata 166 attached to the packet or the packet's outer header fields. 168 Some Layer 4-7 service functions might have intelligence to choose 169 the subsequent service functions on a service chain and pass data 170 packets directly to the selected service functions. However, most 171 existing Layer 4-7 service functions don't have this capability. 173 3.2. Metadata to Layer 4-7 Service Functions 175 Strictly speaking, everything carrying the information that is not 176 in the payload data is metadata. IETF has standardized many types of 177 metadata exchanged among L2/L3 nodes, e.g. QoS bits, MPLS labels, 178 etc. Those metadata are out of the scope of SFC. 180 Metadata in the SFC sense must mean something more specific such as 181 "the information added to the packet to be carried along with the 182 packet for the consumption of the service function nodes along the 183 chain". 185 This section classifies the metadata that are meaningful to SFC. 187 3.2.1. Metadata at different OSI Layers 189 o Application Layer metadata: 191 Some Layer 4-7 service functions, especially the proxy based 192 service functions, exchange metadata among themselves by changing 193 the payload of the data packets, e.g. attaching a cookie to the 194 payload or initiating a new TCP session. 196 Those metadata, especially the metadata among L7 Service 197 Functions, are considered as part of payload. Most likely they are 198 proprietary to application layer. Therefore, they should be out of 199 the scope of SFC. 201 o Layer 4-7 Service Function Layer Metadata 203 Some service functions exchange information among themselves. 204 Today, most of those metadata exchanges between legacy Layer 4-7 205 service functions are vendor specific. 207 o Network Layer metadata 209 Some Layer 4-7 service functions exchange metadata with L2/L3 210 nodes to achieve desired network forwarding behavior. 212 3.2.2. Framework of carrying the metadata 214 o Message based metadata: 216 Some service functions receive metadata from external entities 217 (e.g. policy engines, controller, etc). In Mobile environment, 218 some service functions receive metadata from PCRF via Diameter 219 interfaces. Those metadata are normally flow based, e.g. applying 220 a specific QoS priority for data packets with specific 221 Source/Destination Address(es), TCP port number, etc. Those 222 metadata don't have to be attached to every data packet. 224 o Data Packet attached Metadata: 226 Some metadata has to be attached to packets to facilitate proper 227 treatment by service functions. 229 o Hybrid Method: 231 Attaching extra metadata to every packet increases the likelihood 232 of packet size exceeding MTU, which lead to packet fragmentation. 233 Therefore, the metadata attached to packets have to be compact. 235 To reduce the metadata size attached to data packets, it is worth 236 considering combining the "messaged based metadata" and the 237 "Packet attached Metadata". I.e. attaching compact index to 238 packets that can correlate to complete metadata passed down from 239 separate messages from external systems. 241 4. Architecture for Chaining Legacy Layer 4-7 Service Functions 243 Chaining Layer 4-7 Service Functions not only needs the network that 244 steers data flows to their designated service functions, but also 245 needs an Service Chain Controller that can update the steering 246 policies to the relevant forwarding nodes when changes occurs. 248 | 249 +---+------+ +---+---+ +--+-----+ 250 |controller| |Service| |Service | 251 | | |Func-1 | |Func- m | 252 +---+------+ +----+--+ +--+--+--+ 253 / \ \ \ / 254 Interface A +------------------+ Interface C 255 / \ \ \ / 256 / \ \ +---------+ 257 / \ \ |Proxy | 258 +-----------+ +--------+ +---------+-+ 259 -- >|Classifier | --> |SFF |------> | SFF | ------> 260 | node | |Node-1 | Interface B | Node-2 | 261 +-----------+ +--------+ +---------+ 263 Figure 1 Interfaces needed for Chaining Service Functions 265 There are 3 types of interfaces to be addressed by the architecture: 267 o Interface A: this is the interface between the Service Chain 268 controller and the relevant classifier/steering nodes to exchange 269 the steering policies or/and other information for the service 270 chains. 272 o Interface B: this is the network layer that transports the 273 packets among SFF nodes. Proper tunnels might be needed among SFF 274 nodes so that traffic can traverse the legacy network segments. 276 o Interface C: this is the interconnection between SFF function and 277 Service Functions. Since some legacy SFs can't recognize the SFC 278 header, a proxy entity is needed to convert the information 279 extracted from SFC header to existing header or tags (e.g. VLANs) 280 recognizable by the SFs for packets traversed on this interface. 282 4.1. Service Function Forwarder for Layer 4-7 Service Functions 284 For chaining together legacy Layer 4-7 service functions, the 285 Service Function Forwarder (SFF) defined by [SFC-Arch] may need to 286 terminate the service layer encapsulation on behalf of service 287 functions/nodes that are not aware of the SFC header. There can be 288 multiple SFF nodes in the Service Chain domains [SFC-Framework]. 290 Even though Layer 4-7 Service functions can be instantiated 291 anywhere, it is not uncommon to have multiple service functions 292 instantiated on nodes in close vicinity to a Service Function 293 Forwarder node. The following figure depicts the architecture for 294 chaining those Layer 4-7 service nodes that are not aware of service 295 layer encapsulation. Each SFF is responsible for steering the 296 traffic to their designated local service functions and for 297 forwarding the traffic to the next hop SFF after the local service 298 functions treatment. 300 |1 ----- |n |21 ---- |2m 301 +---+---+ +---+---+ +-+---+ +--+-----+ 302 | SF#1 | |SF#n | |SF#i1| |SF#im | 303 | | | | | | | | 304 +---+---+ +---+---+ +--+--+ +--+--+--+ 305 : : : : : 306 : : : : : 307 \ / \ / 308 +--------+ +---------+ 309 |proxy | |proxy | 310 +--------------+ +--------+ +---------+ 311 -- >| Chain | | SFF | ------ | SFF | ----> 312 |classifier | |Node-1 | | Node-i | 313 +--------------+ +----+---+ +----+--+-+ 314 \ | / 315 \ | SFC Encapsulation / 316 \ | / 317 ,. ......................................._ 318 ,-' `-. 319 / `. 320 | Network | 321 `. / 322 `.__.................................. _,-' 324 Figure 2 Chaining existing Layer 4-7 service nodes 326 The "Chain Classifier" node in the figure is to classify the 327 incoming packets/frames into different service flows based on their 328 service characteristics or policies from service chain orchestration 329 or controller. Different service flows can be differentiated by some 330 fields in the packets or can be encapsulated with the corresponding 331 SFC header. 333 The steering policies for flows arriving at SFF Nodes can be carried 334 by the SFC header in the data packets, separate out-of-band messages 335 from Chain Classier or external controllers, or combination of both. 337 The SFF nodes can be standalone devices, or can be embedded within 338 network forwarding nodes. Overlay tunnels are expected to connect 339 the "SFF nodes" together. 341 4.2. Layer 4-7 nodes connection to SFF Nodes 343 Since the legacy SFs can't terminate the newly defined SFC header, 344 there has to be a proxy entity either attached to or embedded in a 345 SFF node. Here are the major responsibilities of the proxy entity: 347 - SFF-> SF direction: 349 The proxy entity is needed to decapsulate the SFC header from the 350 packets if the SFC header is not recognizable by the SF, extract 351 the service chain identifier from the SFC header, map the service 352 chain identifier to a locally significant tag or header that is 353 recognizable by the legacy SF, and encapsulate the tag or the 354 header to the data packets before sending the packets to the SF. 356 By locally significant, it means that the tag or the header is 357 only local to the link/path between the SFF Proxy entity and the 358 SF, and is capable of differentiating packets from different 359 service chains that traverse the link/path. 361 Examples of locally significant tags include VLANs, GRE key, etc. 362 Examples of locally significant header include encapsulating 363 additional IP, MAC, or GRE header, etc. 365 If there are metadata carried by the SFC header that are needed by 366 the SF, the proxy entity is responsible for extracting the 367 metadata from the SFC header and passing them to the Service 368 Functions via a method that is supported by the Service Function. 370 - SF -> SFF direction: 371 The proxy entity is responsible for constructing the SFC header 372 expected by next SFF nodes from the locally significant tag/header 373 when packets come back from the SF, encapsulating the SFC header 374 back to the data packets before passing to the next SFF nodes. 376 Layer 4-7 Service nodes can be connected to SFF nodes in various 377 ways. The topology could be bump in a wire or one armed topology. 379 o A service function can be embedded in a SFF node (i.e. embedded 380 in a router or a switch). In this case, the combined entity forms 381 the SF node described in the [SFC-ARCH]. 383 o A service node can be one hop away from a SFF node 384 The one hop between the SFF node and the service node can be a 385 physical link (e.g. Ethernet link). Under this scenario, there 386 would be a Link Header, i.e. an outer MAC header, added to the 387 data packets that meet the steering criteria. 389 The one hop link can be a transparent link, i.e. no link address 390 is added to the data packets on the link between the SFF node and 391 Service node. I.e. the service nodes can apply treatment to data 392 frames arrived at the ingress port regardless of the Link 393 Destination address. 395 o A service node can be multiple hops away, such as when a service 396 function is deployed in an on-net or private *aaS offering. Under 397 this scenario, a tunnel is needed between the service node and 398 the SFF node. 400 4.3. Traffic Steering at SFF Nodes 402 The forwarding (or steering) policies for data packets received by 403 the SFF Nodes can be carried by the SFC header in the data packets 404 or combined with separate out-of-band messages from external 405 controller(s) or the Chain Classifier. When using the out-of-band 406 messages to carry the steering policies to SFF nodes, the steering 407 policies have to be correlated with some fields in the data packets. 408 Those fields of the data packets play the role of differentiating 409 packets belong to different service chains. 411 It worth noting that when one SFF node have multiple Service 412 Functions (SF) attached, there could be two different Chains going 413 through one common SF#1, but the Chain #1 needs to go to SF#4 after 414 SF#1, and the Chain #2 needs to go to another SFF node after the 415 SF#1. The SFF node has to re-classify traffic coming back from a 416 port connected to a SF if the Chain identifier is not carried by the 417 data packets. 419 The policies to steer traffic to their corresponding service 420 functions or service function instances can change. Those steering 421 policies can be dynamically updated by SFC Header or the out-of-band 422 messages. 424 There are many types of policies for SFF to steer data packets to 425 their designated service functions, for example: 427 o Fixed header based forwarding: traffic steering based on header 428 fields that have fixed position in the data packets: 430 o Forwarding based on Layer 2-3 header fields, such as MAC or 431 IP Destination Address, Source Addresses, MPLS label, VLAN 432 ID, or combination of multiple Layer 2-3 header fields. 434 o Forwarding based on Layer 4 header (TCP or UDP). 436 o QoS header based forwarding. 438 o Layer 7 based forwarding: traffic steering (or forwarding) based 439 on the payload (L7) of data packets. 441 Multiple data packets may carry some meaningful data, like one 442 HTTP message. Under this scenario, multiple data packets have to 443 be examined before meaningful data can be extracted for making 444 Layer 7 based forwarding decision. 446 o Metadata based steering: traffic steering (or forwarding) based 447 on the identity of the initiating user, the UE model or type, the 448 site name or FQDN, or network conditions (congestion, 449 utilization, etc.). 451 However those metadata might not necessarily be carried by each 452 data packet due to extended bits required that can cause high 453 probability of packet fragmentation. Those metadata can be 454 dynamically passed down to steering nodes in some forms of 455 steering policies from network controller(s). 457 5. Control Plane for Layer 4-7 Service Function Chain 459 5.1. Multiple Instances of a Service Function 461 One service function could have multiple identical instances, 462 potentially attached to different SFF nodes. It is also possible to 463 have multiple identical service function instances attached to one 464 Service Function Forwarder (SFF) node, especially in an environment 465 where service function instances are running on virtual machines 466 with each having limited capacity. 468 At functional level, the order of service functions, e.g. Chain#1 469 {s1, s4, s6}, Chain#2{s4, s7}, is important, but very often which 470 instance of the Service Function "s1" is selected for the Chain #1 471 is not. It is also possible that multiple instances of one service 472 function can be reached by different network nodes. The actual 473 instance selected for a service chain is called "Service Chain 474 Instance Path". 476 There are various policies that could be employed to select 477 instances for service chain instance path. Some Service Function 478 Instances are visible to Service Chain Path. Sometimes a collection 479 of service function instances can appear as one single entity to the 480 Service Chain Path, leaving the instance selection to local nodes. 482 When there is change to the instances selected for a Service Chain 483 Instance Path, either in-band or out-of-band messages can be sent to 484 the SFF nodes to update the steering policies dynamically. 486 The downside with out-of-band messages is synchronization and race 487 conditions. For a newly recognized flow, it is not scalable to 488 expect the classifier node to queue the packets until the out-of- 489 band notification is acknowledged by every Service Function 490 Forwarder node. On the other hand, it is reasonable to use out-of- 491 band messages to inform steering policies on SFF nodes if the 492 steering policies can be pre-established before traffic arrives at 493 the Classifier nodes, e.g. subscriber profile basis service chain 494 instance path. 496 | 497 +---+------+ +---+---+ +--+-----+ 498 |controller| |Service| |Service | 499 | | |Func-1 | |Func- m | 500 +---+------+ +----+--+ +--+--+--+ 501 / \ \ : / 502 / \ +---------------+ : / 503 / \ \ : / 504 +-----------+ +--------+ +---------+ 505 -- >|Classifier | --> |SFF |------> | SFF | ------> 506 | node | |Node-1 | | Node-2 | 507 +-----------+ +--------+ +---------+ 509 Figure 3 Controller for Service Chain Instance Path 511 Some service functions make changes to data packets, such as NAT 512 changing the address fields. If any of those fields are used in 513 traffic steering along the service chain, the criteria can be 514 different before and after those the service functions. 516 5.2. Service Chain Re-Classification 518 The policy for associating flows with their service chains can be 519 complicated and could be dynamic due to different behavior 520 associated with chains. 522 For a chain of {FW, Header_enrichment, smart_node, Video_opt, 523 Parental Control}, the video optimizer really needs to work on the 524 response path. It may also use completely different encapsulation 525 e.g. ICAP for example. There could be Smart-Node to further classify 526 a particular part of the flow and bypass something, say the 527 "video_opt". Therefore, the classification done by the service chain 528 classification nodes at the network entrance can't completely 529 dictate the exact sequence of service functions. 531 Basically, some service functions, especially Layer 7 service 532 functions, can re-classify the service chain. So a chain could be 533 constructed explicitly like below: 535 Classifier -> (SF-A) -> (SF-B) -> (SF-L7 Classifier) -- Chain -X 536 | 537 +-- Chain Y 538 Essentially SF-L7 is more like deep classification engine that might 539 analyze individual http transaction and classify them differently. 540 In reality SF-L7 can be a reverse proxy that is then capable of 541 handling individual http transaction and select appropriate chain. 543 For Chain Re-classification, it is necessary to have message level 544 coordination among those SFs and Service Chain Orchestration or/and 545 Controller entities, as shown in the following figure: 547 +-------------------+ 548 |Chain Orchestration| 549 | | 550 | | 551 | | +------------+ 552 | <----------|-------------|Chain Adjust| 553 +--------|----------+ | Entity | 554 | | +------------+ 555 | | / \ 556 | V / \ 557 +---+------+ +---+---+ +--+-----+ 558 |controller| |Service| |Service | 559 | | |Func-1 | |Func- m | 560 +---+------+ +----+--+ +--+--+--+ 561 / \ \ : / 562 / \ +---------------+ : / 563 / \ \ : / 564 +-----------+ +--------+ +---------+ 565 -- >|Classifier | --> |SFF |------> | SFF | ------> 566 | node | |Node-1 | | Node-2 | 567 +-----------+ +--------+ +---------+ 569 Figure 4 Service Chain Re-classification 571 The Service Chain Classification node can encounter flows that don't 572 match with any policies. There should be a default policy that 573 applies all statutorily required policies to the unknown flows. 575 Multiple flows can share one service chain. The criteria to select 576 flows to be associated with their service chain could be different. 577 For example, for one service chain "A" shared by Flow X, Y, Z: 579 o Criteria for Flow X to the Service Chain "A" are TCP port 581 o Criteria for Flow Y to the Service Chain "A" are Destination 582 Address 584 o Criteria for Flow Z to the Service Chain "A" are MPLS label. 586 5.3. Layer 4-7 traffic Steering 588 Very often the criteria for steering flows to service functions are 589 based on higher layer headers, such as TCP header, HTTP header, etc. 591 Most of deployed switches/routers are very efficient in forwarding 592 packets based on Layer 2 or Layer 3 headers, such as MAC/IP 593 destination addresses, or VLAN/MPLS labels but have limited capacity 594 for forwarding data packets based on higher layer header. As of 595 today, differentiating data packets based on higher layer headers 596 depends on ACLs (Access Control List field matching) or DPI, both of 597 which are relatively expensive and extensive use of such facilities 598 may limit the bandwidth of switches/routers. 600 The Service Chain classification node introduced by [Boucadair- 601 framework] and [SFC-ARCH] can alleviate the workload on large number 602 of nodes in the network, including SFF nodes, from steering traffic 603 based on higher layer fields. 605 |1 ----- |n |21 ---- |2m 606 +---+---+ +---+---+ +-+---+ +--+-----+ 607 | Ad | |Content| |Video| |Security| 608 |Insert | | Opt | | Opt | | App | 609 +---+---+ +---+---+ +--+--+ +--+--+--+ 610 : : : : : 611 : : : : : 612 \ / \ / 613 +--------------+ +--------+ +---------+ 614 - >| Chain | ->| SFF |--------> | SFF | ---> 615 |classification| |Node-1 | | Node-2 | 616 +--------------+ +--------+ +---------+ 618 Figure 5 Service Chain Marking At Ingress 620 A Service Chain Classification node can associate a unique Service 621 Chain Label (e.g. Layer 2 or 3 Label) or SF MAP Index to the packets 622 in the flow. Such a Layer 2 or 3 Label makes it easier for 623 subsequent nodes along the flow path to steer the flow to the 624 service functions specified by the flow's service chain. 626 The Service Chain Classification Function usually resides on the 627 ingress edge nodes of the service chain domain, such as Wireless 628 Packet Gateway, Broadband Network Gateways, Cell Site Gateways, etc. 630 In some situations, like service chain for wireless subscribers, 631 many flows (i.e. subscribers) have common service chain 632 requirements. Under those situations, the Service Chain 633 classification Functional can mark multiple flows with the same 634 service chain requirement using the same Layer 2 or 3 Label, which 635 effectively aggregates those flows into one service chain. 637 For service chains that are shared by a great number of flows, they 638 can be pre-provisioned. For example, if VLAN ID=10 is the service 639 chain that need to traverse "Service-1" at SFF Node #1 and "Service- 640 3" at SFF Node #2, the steering policy for VLAN ID=10 can be 641 dynamically changed by controllers. 643 6. Service Chain from the Layer 7 Perspective 645 From the Layer 7 perspective, the service chain can be much more 646 complex. As shown in the figure below, the service functions to be 647 chained can depend on the HTTP message request and reply. The 648 service chain classification nodes may have to examine the whole 649 HTTP message to determine the specific sequence of service functions 650 for the flows. The HTTP message might have to be extracted from 651 multiple data packets. Sometimes, the logic to steer traffic to 652 chain of service functions might depend on the data retrieved from a 653 database based on messages constructed from packets. The decision 654 may depend on the HTTP response rather than the request, or it may 655 depend on a particular sequence of request-response messages. The 656 message handler may also alter the Layer 7 service chain based on 657 hints or modification done by previous service function. HTTP based 658 service function may insert HTTP header to add further criterion for 659 service selection in the next round of classification. 661 +----------+ 662 Client --------->( Layer 7 )---------> Internet 663 <---------( Message )<--------- 664 ( Handler ) 665 --------( )--------________ 666 / +----------+ \ 667 / / \ \ 668 |1 |2 |3 |4 669 +---+---+ +---+---+ +-+---+ +--+-----+ 670 | Ad | |Content| |Video| |Security| 671 |Insert | | Opt | | Opt | | App | 672 +---+---+ +---+---+ +--+--+ +--+--+--+ 673 : : : : : 674 : : : : : 676 Figure 6 Layer 7 Service Chain Complexity 678 7. Conclusion and Recommendation 680 There are many Layer 4-7 service functions being deployed in the 681 network. Many of them are not capable to adapt to new service chain 682 encapsulation layer. 684 This document provides architecture framework for chaining those 685 Layer 4-7 service functions that are not aware of new service layer 686 encapsulation. 688 8. Manageability Considerations 690 There currently exists no single management methodology to control 691 the L2-4 packet-based forwarding device, the L4-7 service delivery 692 device, and the L7+ application server. Such unified management of 693 configuration state is required for service function chaining to be 694 a practical solution. 696 9. Security Considerations 698 TBD 700 10. IANA Considerations 702 This document requires no IANA actions. RFC Editor: Please remove 703 this section before publication. 705 11. References 707 11.1. Normative References 709 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 710 Requirement Levels", BCP 14, RFC 2119, March 1997. 712 11.2. Informative References 714 [Boucadair-framework] M. Boucadair, et al, "Differentiated Service 715 Function Chaining Framework", < draft-boucadair-service- 716 chaining-framework-00>; Aug 2013 718 [SFC-Problem] P. Quinn, et al, "Service Function Chaining Problem 719 statement", , Dec 9, 720 2013 722 [SFC-Framework] M. Boucadair, et al, "Service Function Chaining: 723 Framework & Architecture", < draft-boucadair-sfc- 724 framework-00>; Oct 2013 726 [SFC-Arch] J. Halpern, et al, "Service Function Chaining (SFC) 727 Architecture", < draft-merged-sfc-architecture-00>, July 728 2014. 730 [NSH-Header] P. Quinn, et al, "Network Service Header", < draft- 731 quinn-nsh-01>, July 12, 2013 733 [SC-MobileNetwork] W. Haeffner, N. Leymann, "Network Based Services 734 in Mobile Network", IETF87 Berlin, July 29 2013 736 [Application-SDN] J. Giacomonni, "Application Layer SDN", Layer 123 737 ONF Presentation, Singapore, June 2013 739 [SC-Use-Case] Liu, et, al., "Service Chaining Use Cases", < draft- 740 liu-service-chaining-use-cases-00>, Sept, 2013 742 12. Acknowledgments 744 This draft has merged some sections from 745 http://datatracker.ietf.org/doc/draft-parker-sfc-chain-to-path/. 747 This draft has taken input from "Application Layer SDN" presentation 748 given by John Giacomoni of F5 at Layer 123 conference. Thanks to 749 Huang Shi Bi and Li Hong Yu for the valuable comments and 750 suggestions. 752 This document was prepared using 2-Word-v2.0.template.dot. 754 Authors' Addresses 756 Linda Dunbar 757 Huawei Technologies 758 5340 Legacy Drive, Suite 175 759 Plano, TX 75024, USA 760 Phone: (469) 277 5840 761 Email: ldunbar@huawei.com 763 Ron Parker 764 Affirmed Networks 765 Acton, MA 01720 766 USA 767 Email: ron_parker@affirmednetworks.com 769 Ian Smith 770 F5 Networks 771 Email: I.Smith@F5.com 773 Sumandra Majee 774 F5 Networks 775 Email: S.Majee@F5.com 777 Ning So 778 Vinci Systems 779 Email: ning.so@vinci-systems.com 781 Donald Eastlake 782 Huawei Technologies 783 155 Beaver Street 784 Milford, MA 01757 USA 785 Phone: 1-508-333-2270 786 Email: d3e3e3@gmail.com