Network working group L. Dunbar Internet Draft Huawei Intended status: Informational Ron Parker Expires: August 2014 Affirmed Networks I. Smith; S. Majee F5 Networks N. So Tata Communications Donald Eastlake Huawei February 7, 2014 Architecture for Chaining Legacy Layer 4-7 Service Functions draft-dunbar-sfc-legacy-l4-l7-chain-architecture-02.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, except to publish it as an RFC and to translate it into languages other than English. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on August 8, 2014. Dunbar, et al. Expires August 7, 2014 [Page 1] Internet-Draft Chaining Legacy Layer 4-7 SF February 2014 Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract This draft analyzes the issues associated with chaining existing Layer 4-7 service functions that are not aware of service encapsulation layers. This draft also examines the network architecture for chaining existing L4-L7 service functions. The intent is to identify optimal architecture for flexibly chaining existing Layer 4-7 functions to meet various service needs. Table of Contents 1. Introduction...................................................3 2. Conventions used in this document..............................3 3. Legacy Layer 4-7 Service Functions and Chaining................4 3.1. Layer 4-7 Service Functions...............................4 3.2. Service Functions Chaining for Wireless network...........4 4. Architecture for Chaining Legacy Layer 4-7 Service Functions...6 4.1. Service Function Forwarder for Layer 4-7 Service Functions6 4.2. L4-L7 nodes connection to SFF Nodes.......................7 4.3. Traffic Steering at SFF Nodes.............................7 5. Challenges of Chaining L4-L7 Service Function..................9 5.1. Challenge of Multiple Instances of a Service Function.....9 5.2. Challenges of Layer 4-7 traffic Steering.................10 5.3. Challenges of Service Chain Classification...............11 6. Challenge of Service Chain from the Layer 7 Perspective.......12 7. Conclusion and Recommendation.................................13 8. Manageability Considerations..................................13 9. Security Considerations.......................................13 10. IANA Considerations..........................................13 11. References...................................................14 11.1. Normative References....................................14 Dunbar, et al. Expires August 7, 2014 [Page 2] Internet-Draft Chaining Legacy Layer 4-7 SF February 2014 11.2. Informative References..................................14 12. Acknowledgments..............................................14 1. Introduction This draft analyzes the issues associated with chaining existing Layer 4-7 service functions that are not aware of service encapsulation layers. This draft also examines the network architecture for chaining existing L4-L7 service functions. The intent is to identify optimal architecture for flexibly chaining existing Layer 4-7 functions to meet various service needs. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying RFC-2119 significance. Chain Classifier: A component that performs traffic classification and potentially encodes a unique identifier or the SF MAP Index introduced by [SFC-Framework] to the packets. The unique identifier in the packets can be used by other nodes to associate the packets to a specific service chain and/or steer the packets to the designated service functions. DPI: Deep Packet Inspection FW: Firewall Layer 4-7 Service Function: Same as the Service Functions defined in [SFC-Problem] except that they don't have the Layer 2/3 forwarding capability and are not aware of the new service function header encapsulations. Many of existing Layer 4-7 service functions fall into this category. Exemplary functional modules include Firewall, Deep Packet Inspection (DPI), Encryption, Packet De-duplication, Compression, TCP Acceleration, NAT, and etc Layer 4-7 service functions can be instantiated on a standalone physical or virtual device, which is called "Service Node" by [SFC- Problem]. Layer 4-7 functions can also be embedded in another device, such as router/switch or other devices. Dunbar, et al. Expires August 7, 2014 [Page 3] Internet-Draft Chaining Legacy Layer 4-7 SF February 2014 3. Legacy Layer 4-7 Service Functions and Chaining Legacy Layer 4-7 service functions are the existing service functions that don't have Layer 2/3 forwarding capability and may not be aware of any new service encapsulation layers or overlay encapsulation layer being discussed in SFC WG. 3.1. Layer 4-7 Service Functions A Layer 4-7 service function performs certain action to the packets belonging to an end-to end flow. The implementation of such service function can be either Proxy based or Packet Based, or a hybrid of both when more than one function is performed to the same packet flow. Multiple service functions can be instantiated on a single service node as defined by [SFC-ARCH], or embedded in a L2/L3 network node. o Proxy based service functions: these service functions terminate original packets, may reassemble multiple packets, reopen a new connection, or formulate new packets based on the received packets. o Packet based service functions: these service functions maintain original packets, i.e. they don't make changes to packets traversed through except possibly making changes to metadata attached to the packet or the packet's outer header fields. Some Layer 4-7 service functions might have intelligence to choose different subsequent service functions and pass data packets directly to the selected service functions. However, most existing Layer 4-7 service functions don't have this capability. 3.2. Service Functions Chaining for Wireless network [SFC-MobileNetwork] and [SFC-use-cases] have provided examples of service chain in mobile network. In particular, the P-GW/PCEF (per 3GPP terminology) determines the desired service treatment, i.e. desired sequence of service functions, to specific flows based on the policies from PCRF. The P-GW in the figure acts as the Service Chain Classification Node. P-GW separates the traffic into different categories (or flows) based on the policies from PCRF. The traffic in each category (or flow) is mapped to a unique interface (a physical or virtual Dunbar, et al. Expires August 7, 2014 [Page 4] Internet-Draft Chaining Legacy Layer 4-7 SF February 2014 port) or a tunnel that is connected to the needed sequence of service functions. | Mobile backhaul Network +-----+ | +---+---+ |PCRF | | |Network| | | < ---- > |Ctrller| +-----+ | +----+--+ | | | | +---------+ | +--------+ +----+ +---------+ -- >| P-GW | --> |LB |---| FW |--> | Web | ------> | | | | | | | | Proxy | --->| | | +--------+ +----+ +---------+ --->| | | +---------+ +----+ -- >| | --> |Video |---| FW |--> ----------- ------> | [PCEF]| | |Optimizer| | | | | | +---------+ +----+ --->| | | +--------+ +-----+ -- >| | --> |SBC |---| ACL |--> ----------- ------> | | | | | | | +---------+ | +--------+ +-----+ Figure 1 Service Chain for Mobile Network Here are some of the issues of service chain in wireless network: o large number of permutations of service functions to be chained together o The sequence of services functions applied to selective flows can change. Sometimes, the change may be triggered by some service functions on the chain, e.g. DPI. New service functions may need to be inserted; existing service functions may need to be removed or changed. o The criteria for applying service functions can take combination of application classification, packet headers, and/or other factors. For example, the factors that have direct association with the packet flow include packet source address, destination address, TCP ports. The factors that do not have association with the packet flow include user/source location, account status, time of day, network condition, and etc. Dunbar, et al. Expires August 7, 2014 [Page 5] Internet-Draft Chaining Legacy Layer 4-7 SF February 2014 4. Architecture for Chaining Legacy Layer 4-7 Service Functions 4.1. Service Function Forwarder for Layer 4-7 Service Functions For chaining together legacy Layer 4-7 service functions, the Service Function Forwarder (SFF) defined by [SFC-Arch] has be a separate entity. The SFF can terminate service layer encapsulation on behalf of service functions/nodes that are not aware service layer encapsulation. There can be multiple SFF nodes in the Service Chain domains [SFC-Framework]. Even though Layer 4-7 Service functions can be instantiated anywhere, it is not uncommon to have multiple service functions instantiated on nodes in close vicinity to a Service Function Forwarder node. The following figure depicts the architecture for chaining those Layer 4-7 service nodes that are not aware of service layer encapsulation. Each SFF is responsible for forwarding the traffic to their designated local service functions and for forwarding the traffic to the next hop SFF after the local service functions treatment. |1 ----- |n |21 ---- |2m +---+---+ +---+---+ +-+---+ +--+-----+ | Ad | |Content| |Video| |Security| |Insert | | Opt | | Opt | | App | +---+---+ +---+---+ +--+--+ +--+--+--+ : : : : : : : : : : \ / \ / +--------------+ +--------+ +---------+ -- >| Chain | ->| SFF |---------> | SFF | ----> |classifier | |Node-1 | | Node-i | +--------------+ +----+---+ +----+--+-+ |-- | | V +---> +--------+ | SN | | -j |-----> +--------+ Figure 2 Chaining existing Layer 4-7 service nodes Dunbar, et al. Expires August 7, 2014 [Page 6] Internet-Draft Chaining Legacy Layer 4-7 SF February 2014 The "Chain Classifier" node in the figure is to classify the traffic, encode a unique SF MAP Index [SFC-Framework] to packets or encapsulate the packets with the SFC header. The forwarding policies for data packets received by the SFF Nodes can be carried by the SFC header in the data packets or separate out-of-band messages from Chain Classier or external controllers. The SFF nodes can be standalone devices, or can be embedded within network forwarding nodes. Overlay tunnels are expected to connect the "SFF nodes" together. 4.2. L4-L7 nodes connection to SFF Nodes L4-L7 Service nodes can be connected to SFF nodes in various ways. The topology could be bump in a wire or one armed topology. o A service function can be embedded in a SFF node (i.e. embedded in a router or a switch). In this case, the combined entity forms the SF node described in the [SFC-ARCH]. o A service node can be one hop away from a SFF node The one hop between the SFF node and the service node can be a physical link (e.g. Ethernet link). Under this scenario, there would be a Link Header, i.e. an outer MAC header, added to the data packets that meet the steering criteria. The one hop link can be a transparent link, i.e. no link address is added to the data packets on the link between the SFF node and Service node. I.e. the service nodes can apply treatment to data frames arrived at the ingress port regardless of the Link Destination address. o A service node can be multiple hops away, such as when a service function is deployed in an on-net or private *aaS offering. Under this scenario, a tunnel is needed between the service node and the SFF node. 4.3. Traffic Steering at SFF Nodes The forwarding (or steering) policies for data packets received by the SFF Nodes can be carried by the SFC header in the data packets or via separate out-of-band messages from external controller(s) or the Chain Classifier. When using the out-of-band messages to carry Dunbar, et al. Expires August 7, 2014 [Page 7] Internet-Draft Chaining Legacy Layer 4-7 SF February 2014 the steering policies to SFF nodes, the SF MAP Index in the data packets is used to correlate the steering policies for the data packets. The policies to steer traffic to their corresponding service functions or service function instances can change. Those steering policies can be dynamically updated by SFC Header or the out-of-band messages. Some service chains may require steering traffic to their corresponding Layer 4-7 functions based on Layer 1 (e.g. ingress port), Layer 2 or 3 fields of the data packets. Some service chains may require steering traffic to their Layer 4-7 service functions based on some higher layer fields in the data packets, i.e. Layer 4 to Layer 7 fields. There are multiple types of traffic steering: o Fixed header based forwarding: traffic steering based on header fields that have fixed position in the data packets: o Forwarding based on Layer 2-3 header fields, such as MAC or IP Destination Address, Source Addresses, MPLS label, VLAN ID, or combination of multiple Layer 2-3 header fields. o Forwarding based on Layer 4 header (TCP or UDP). o QoS header based forwarding. o Layer 7 based forwarding: traffic steering (or forwarding) based on the payload (L7) of data packets. Multiple data packets may carry some meaningful data, like one HTTP message. Under this scenario, multiple data packets have to be examined before meaningful data can be extracted for making Layer 7 based forwarding decision. o Metadata based steering: traffic steering (or forwarding) based on the identity of the initiating user, the UE model or type, the site name or FQDN, or network conditions (congestion, utilization, etc.). However those metadata might not necessarily be carried by each data packet due to extended bits required that can cause high probability of packet fragmentation. Those metadata can be dynamically passed down to steering nodes in some forms of steering policies from network controller(s). Dunbar, et al. Expires August 7, 2014 [Page 8] Internet-Draft Chaining Legacy Layer 4-7 SF February 2014 5. Challenges of Chaining L4-L7 Service Function 5.1. Challenge of Multiple Instances of a Service Function Each service function could have multiple instances, with some in close proximity and others far apart being attached to different Service Function Forwarder (SFF) nodes. In Network Function Virtualization (NFV) environment, there could be very large number of service function instances for each service function. NFV imposes higher chance of state or attachment change for service function instances due to virtual instances' creation/deletion/migration. From user's perspective, the order of service functions, e.g. Chain#1 {s1, s4, s6}, Chain#2{s4, s7}, is important, but very often which instance of the Service Function "s1" is selected for the Chain #1 is not. It is also possible that multiple instances of one service function can be reached by different network nodes. The actual instances selected for a service chain is called "Service Chain Instance Path". There are various policies that could be employed to select instances for service chain instance path. The SFC WG should stay away from (or open to all possible ways of) specifying the way policy decisions are performed. Some Service Chain Classifier can specify exact service chain instance path. Under other scenarios where there is large number of instances per function, it should be acceptable for Service Chain classifier to only identify the chaining at function level and have another entity managing the detailed service instance path. When there is change to instances selected for a service chain, either in-band or out-of-band messages can be sent to the SFF nodes to update the steering policies dynamically. The downside with out-of-band messages is synchronization and race conditions. For a newly recognized flow, it is not scalable to expect the classifier node to queue the packets until the out-of- band notification is acknowledged by every Service Function Forwarder node. On the other hand, it is reasonable to use out-of- band messages to inform forwarding policies on SFF nodes if the forwarding policies can be pre-established before traffic arrives at the Classifier nodes, e.g. subscriber profile basis service chain instance path. Dunbar, et al. Expires August 7, 2014 [Page 9] Internet-Draft Chaining Legacy Layer 4-7 SF February 2014 | +---+------+ +---+---+ +--+-----+ |controller| |Service| |Service | | | |Func-1 | |Func- m | +---+------+ +----+--+ +--+--+--+ / \ \ : / / \ +---------------+ : / / \ \ : / +-----------+ +--------+ +---------+ -- >|Classifier | --> |SFF |------> | SFF | ------> | node | |Node-1 | | Node-2 | +-----------+ +--------+ +---------+ Figure 3 Service Chain from Traffic Steering Point of View Some service functions make changes to data packets, such as NAT changing the address fields. If any of those fields are used in traffic steering along the service chain, the criteria can be different before and after those the service functions. 5.2. Challenges of Layer 4-7 traffic Steering Very often the criteria for steering flows to service functions are based on higher layer headers, such as TCP header, HTTP header, etc. Most of deployed switches/routers are very efficient in forwarding packets based on Layer 2 or Layer 3 headers, such as MAC/IP destination addresses, or VLAN/MPLS labels but have limited capacity for forwarding data packets based on higher layer header. As of today, differentiating data packets based on higher layer headers depends on ACLs (Access Control List field matching) or DPI, both of which are relatively expensive and extensive use of such facilities may limit the bandwidth of switches/routers. The Service Chain classification node introduced by [Boucadair- framework] and [SFC-ARCH] can alleviate the workload on large number of nodes in the network, including SFF nodes, from steering traffic based on higher layer fields. Dunbar, et al. Expires August 7, 2014 [Page 10] Internet-Draft Chaining Legacy Layer 4-7 SF February 2014 |1 ----- |n |21 ---- |2m +---+---+ +---+---+ +-+---+ +--+-----+ | Ad | |Content| |Video| |Security| |Insert | | Opt | | Opt | | App | +---+---+ +---+---+ +--+--+ +--+--+--+ : : : : : : : : : : \ / \ / +--------------+ +--------+ +---------+ - >| Chain | ->| SFF |--------> | SFF | ---> |classification| |Node-1 | | Node-2 | +--------------+ +--------+ +---------+ Figure 4 Service Chain Marking At Ingress A Service Chain Classification node can associate a unique Service Chain Label (e.g. Layer 2 or 3 Label) or SF MAP Index to the packets in the flow. Such a Layer 2 or 3 Label makes it easier for subsequent nodes along the flow path to steer the flow to the service functions specified by the flow's service chain. The network elements that have the Service Chain Classification Function are most likely network ingress edge nodes, such as Wireless Packet Gateway, Broadband Network Gateways, Cell Site Gateways, etc. In some situations, like service chain for wireless subscribers, many flows (i.e. subscribers) have common service chain requirements. Under those situations, the Service Chain classification Functional can mark multiple flows with the same service chain requirement using the same Layer 2 or 3 Label, which effectively aggregates those flows into one service chain. For service chains that are shared by a great number of flows, they can be pre-provisioned. For example, if VLAN ID=10 is the service chain that need to traverse "Service-1" at SFF Node #1 and "Service- 3" at SFF Node #2, the steering policy for VLAN ID=10 can be dynamically changed by controllers. 5.3. Challenges of Service Chain Classification The policy for associating flows with their service chains can be complicated and could be dynamic due to different behavior associated with chains, balancing load among multiple instances for one service function, and instance failure. Dunbar, et al. Expires August 7, 2014 [Page 11] Internet-Draft Chaining Legacy Layer 4-7 SF February 2014 For a chain of {FW, Header_enrichment, smart_node, Video_opt, Parental Control}, the video optimizer really needs to work on the response path. It may also use completely different encapsulation e.g. ICAP for example. There could be Smart-Node to further classify a particular part of the flow and bypass something, say the video_opt. Therefore, the classification done by the service chain classification nodes at the network entrance can't completely dictate the exact sequence of service functions. The Service Chain Classification node can encounter flows that don't match with any policies. There is a default policy that applies all statutorily required policies to the unknown flows. Multiple flows can share one service chain. The criteria to select flows to be associated with their service chain could be different. For example, for one service chain "A" shared by Flow X, Y, Z: o Criteria for Flow X to the Service Chain "A" are TCP port o Criteria for Flow Y to the Service Chain "A" are Destination Address o Criteria for Flow Z to the Service Chain "A" are MPLS label. 6. Challenge of Service Chain from the Layer 7 Perspective From the Layer 7 perspective, the service chain can be much more complex. As shown in the figure below, the service functions to be chained can depend on the HTTP message request and reply. The service chain classification nodes may have to examine the whole HTTP message to determine the specific sequence of service functions for the flows. The HTTP message might have to be extracted from multiple data packets. Sometimes, the logic to steer traffic to chain of service functions might depend on the data retrieved from a database based on messages constructed from packets. The decision may depend on the HTTP response rather than the request, or it may depend on a particular sequence of request-response messages. The message handler may also alter the Layer 7 service chain based on hints or modification done by previous service function. HTTP based service function may insert HTTP header to add further criterion for service selection in the next round of classification. Dunbar, et al. Expires August 7, 2014 [Page 12] Internet-Draft Chaining Legacy Layer 4-7 SF February 2014 +----------+ Client --------->( Layer 7 )---------> Internet <---------( Message )<--------- ( Handler ) --------( )--------________ / +----------+ \ / / \ \ |1 |2 |3 |4 +---+---+ +---+---+ +-+---+ +--+-----+ | Ad | |Content| |Video| |Security| |Insert | | Opt | | Opt | | App | +---+---+ +---+---+ +--+--+ +--+--+--+ : : : : : : : : : : Figure 5 Layer 7 Service Chain Complexity 7. Conclusion and Recommendation There are many service functions being deployed already in the network. Many of them are not capable to adapt to new service chain encapsulation layer. This document provides architecture framework for chaining those Layer 4-7 service functions that are not aware of new service layer encapsulation. 8. Manageability Considerations There currently exists no single management methodology to control the L2-4 packet-based forwarding device, the L4-7 service delivery device, and the L7+ application server. Such unified management of configuration state is required for service function chaining to be a practical solution. 9. Security Considerations TBD 10. IANA Considerations This document requires no IANA actions. RFC Editor: Please remove this section before publication. Dunbar, et al. Expires August 7, 2014 [Page 13] Internet-Draft Chaining Legacy Layer 4-7 SF February 2014 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 11.2. Informative References [Boucadair-framework] M. Boucadair, et al, "Differentiated Service Function Chaining Framework", < draft-boucadair-service- chaining-framework-00>; Aug 2013 [SFC-Problem] P. Quinn, et al, "Service Function Chaining Problem statement", , Dec 9, 2013 [SFC-Framework] M. Boucadair, et al, "Service Function Chaining: Framework & Architecture", < draft-boucadair-sfc- framework-00>; Oct 2013 [SFC-Arch] P. Quinn, et al, "Service Function Chaining (SFC) Architecture", < draft-quinn-nsc-arch-04>, Jan 2014. [NSH-Header] P. Quinn, et al, "Network Service Header", < draft- quinn-nsh-01>, July 12, 2013 [SC-MobileNetwork] W. Haeffner, N. Leymann, "Network Based Services in Mobile Network", IETF87 Berlin, July 29 2013 [Application-SDN] J. Giacomonni, "Application Layer SDN", Layer 123 ONF Presentation, Singapore, June 2013 [SC-Use-Case] Liu, et, al., "Service Chaining Use Cases", < draft- liu-service-chaining-use-cases-00>, Sept, 2013 12. Acknowledgments This draft has merged some sections from http://datatracker.ietf.org/doc/draft-parker-sfc-chain-to-path/. This draft has taken input from "Application Layer SDN" presentation given by John Giacomoni of F5 at Layer 123 conference. Thanks to Huang Shi Bi and Li Hong Yu for the valuable comments and suggestions. This document was prepared using 2-Word-v2.0.template.dot. Dunbar, et al. Expires August 7, 2014 [Page 14] Internet-Draft Chaining Legacy Layer 4-7 SF February 2014 Authors' Addresses Linda Dunbar Huawei Technologies 1700 Alma Drive, Suite 500 Plano, TX 75075, USA Phone: (469) 277 5840 Email: ldunbar@huawei.com Ron Parker Affirmed Networks Acton, MA 01720 USA Email: ron_parker@affirmednetworks.com Ian Smith F5 Networks Email: I.Smith@F5.com Sumandra Majee F5 Networks Email: S.Majee@F5.com Ning So Tata Communications Email: Ning.So@tatacommunications.com Donald Eastlake Huawei Technologies 155 Beaver Street Milford, MA 01757 USA Phone: 1-508-333-2270 Email: d3e3e3@gmail.com Dunbar, et al. Expires August 7, 2014 [Page 15]