Internet DRAFT - draft-bitar-i2rs-service-chaining

draft-bitar-i2rs-service-chaining










      
     Internet Engineering Task Force 
     I2RS working group                                        N. Bitar 
     Internet Draft                                             Verizon 
     Category: Informational                                   G. Heron 
                                                                L. Fang  
                                                              Microsoft               
                                                            R. Krishnan 
                                                 Brocade Communications 
                                                             N. Leymann  
                                                        Deutshe Telekom 
                                                                H. Shah 
                                                                  Ciena 
                                                         S. Chakrabarti 
                                                              W. Haddad 
                                                               Ericsson 
                     
                                                                      
      
                                                                
     Expires: August 2014                            February 14, 2014 
                                                                                      
                                        
         Interface to the Routing System (I2RS) for Service Chaining: 
                          Use Cases and Requirements 
                                        
                     draft-bitar-i2rs-service-chaining-01 

     Abstract 

        Service chaining is the concept of applying an ordered set of 
        services to a packet or a flow. Services in the chain may 
        include network services such as load-balancing, firewalling, 
        intrusion prevention, and routing among others. Criteria for 
        applying a service chain to a packet or flow can be based on 
        packet/flow attributes that span the OSI layers (e.g., physical 
        port, Ethernet MAC header information, IP header information, 
        transport, and application layer information). This document 
        describes use cases and I2RS (Information to the Rousting 
        System) requirements for the discovery and maintenance of 
        services topology and resources. It also describes use cases 
        and I2RS requirements for controlling the forwarding of a 
        packet/flow along a service chain based on packet/flow 
        attributes.  




      
      
     bitar, et al.          Expires August 2014             [Page 1] 
      






     Internet-Draft        I2RS for Service Chaining    February 2014 
      
     Status of this Memo 

        This Internet-Draft is submitted to IETF in full conformance 
        with the provisions of BCP 78 and BCP 79. 

        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 14, 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. 

     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]. 



          
     bitar, et al.            Expires August 2014            [Page 2] 
         






     Internet-Draft        I2RS for Service Chaining    February 2014 
      
     Table of Contents 

         
        1. Introduction..............................................4 
        2. Abbreviations and Definitions.............................5 
           2.1. Abbreviations........................................5 
           2.2. Definitions..........................................5 
        3. Service Chaining Use Cases and Requirements...............5
           3.1. Services topology....................................5 
           3.2. Monitoring Information...............................8 
           3.3. Traffic Redirection, Forwarding and Service Chaining.9 
        4. Service Chaining via BGP-based Redirection...............12
        5. Operational Considerations...............................13
        6. IANA Considerations......................................13
        7. Security Considerations..................................13
        8. Acknowledgements.........................................13
        9. References...............................................13
           9.1. Normative References................................13 
           9.2. Informative References..............................14 
        Authors' Addresses..........................................14
                             



























           
     bitar, et al.            Expires August 2014            [Page 3] 
         






     Internet-Draft        I2RS for Service Chaining    February 2014 
      
     1. Introduction 

        Several networking scenarios involve applying a set of services 
        to a packet or flow. For instance, when a host in a protected 
        zone initiates a session to a server outside the zone, the 
        session may be directed to a chain of a Wide Area Network (WAN) 
        application acceleration service, a network address and port 
        translation (NAPT) service, and a firewall. On the server side, 
        another set of services may also be applied. Such a sequence of 
        services applied to a packet or flow is referred to as a 
        service chain. Services in the chain may include deep packet 
        inspection (DPI), load-balancing, firewalling, intrusion 
        prevention, and routing among others. 

        Criteria for applying a service chain to a packet or flow can 
        be based on packet/flow attributes that span the OSI layers. 
        Such attributes may include the physical/virtual port on which 
        the packet arrives, Ethernet MAC header information (e.g., VLAN 
        ID), IP header information (e.g., source IP address), transport 
        header information (e.g., TCP destination port number), and 
        application layer information among others.  

        The transition from one service to the next in a service chain 
        may be conditioned on the output of the current service, or may 
        be non-conditional (pre-determined). A new mechanism, to be 
        defined, may also enrich the packet transition in a service 
        chain by passing service-specific information and/or 
        information pertaining to preceding services in the chain along 
        with the packet being processed. This type of mechanism and its 
        influence are outside the scope of this document. In addition, 
        this version of the document addresses the simple use case of 
        pre-determined service chains applied to non-dropped packets 
        with no additional information from preceding services. The 
        service path for a packet/flow may be established via a 
        management plane or routing, and may be enforced in the data 
        plane via different mechanisms, as discussed in this document.  

        Services in a chain can be co-located on one system and/or 
        physically separated across systems. In either case, a service 
        may be running in its own virtualized system space or natively 
        on the hosting system. 

        This document describes use cases and I2RS [i2rs-prob] 
        requirements for the discovery and maintenance of services 
        topology and resources. It also describes use cases and I2RS 
        requirements for controlling the forwarding of a packet/flow 
        along a service chain based on packet/flow attributes. 

           
     bitar, et al.            Expires August 2014            [Page 4] 
         






     Internet-Draft        I2RS for Service Chaining    February 2014 
      
     2. Abbreviations and Definitions 

     2.1. Abbreviations 

     2.2. Definitions 

     3. Service Chaining Use Cases and Requirements 

        A service chain is an ordered set of services applied to a 
        packet or flow. It is often the case that when a flow in a 
        bidirectional session is assigned to a service chain, the 
        reverse flow of the same session is required to traverse the 
        same chain in the reverse order. Assigning a flow to a service 
        chain is often defined at an abstract level. Mapping a service 
        chain to a network requires knowledge of the available services, 
        their locations and available resources so that services are 
        properly engineered on the services infrastructure. This 
        section describes requirements and applicability for such 
        information, and for directing traffic through a service chain. 

     3.1. Services topology 

        In order to establish a service chain that applies to a 
        packet/flow, it is important to have a topology of the service 
        nodes. A service node can be a service running natively within 
        a system (e.g., a service card or a service engine in a 
        router), a virtual machine (VM) hosted on a server, a VM hosted 
        on a service engine within a system (e.g., a service card in a 
        router), or a dedicated standalone service hardware appliance. 
        In addition, a service node may be dedicated to a customer 
        (e.g., an IPVPN customer), globally shared across customers or 
        a customer set of VPNs, or available to be assigned in whole or 
        in part to a customer or a set customer VPNs. A customer and 
        tenant are used synonymously in this document. How a service 
        node is created is outside the scope of this document. 
        Resources on a service node that are not assigned to a customer 
        context (e.g., VRF) will be logically referred to as a non-
        assigned service node with free available resources. A service 
        node that can be shared in a global context will be referred to 
        as a global service node. It should be noted, that once a 
        service node is bound to a context, then it is only available 
        for a virtual network (VN) associated with that context. 

        Different service node types may have information specific to 
        the service(s) they provide. A service node information model 
        needs to describe information common (generic) to all service 
        node types and extensible to be sub-classed so that the service 

      
     bitar, et al.            Expires August 2014            [Page 5] 
         






     Internet-Draft        I2RS for Service Chaining    February 2014 
       specific information can be represented. The common information 
       is: 

          . 
Service node address: A service node must have a unique 
            address in a service topology. A service node identifier 
            address can be:  

               o An IP address when feasible. Such a service node can 
                 be a VM, a services engine within a system, or a 
                 hardware appliance. 

               o The tuple (service node IP address, hosting system IP 
                 address). This applies when there is need to identify 
                 the system hosting the service node or when the 
                 service node IP address is only reachable within the 
                 hosting system.  

               o The tuple (hosting system IP-address, system internal 
                 identifier for the service engine). This applies when 
                 the service engine is not IP addressable and is within 
                 a system. A potential system internal identifier for a 
                 service engine may be 
                 (system_slot_number.subslot_number.engine_number).  

          . 
For each service node, the following information is 
            required: 

               o Supported service type (e.g., NAT, FW). A node may 
                 support multiple service types.  

               o Number of virtual contexts (tenants) that can be 
                 supported. This parameter will indicate the maximum 
                 number of contexts that can be created on the service 
                 node. 

               o Number of virtual contexts (e.g., VRFs) available.  

               o Supported context type (e.g., VRF). 

               o Customer ID if the service node is dedicated to a 
                 customer. This indicates who can use this service 
                 node. 

               o List of supported (customer ID, virtual contexts). 
                 Note that one context per customer is a degenerate 
                 case. This will be the global context for a given 
                 customer on a service node. 
     bitar, et al.            Expires August 2014            [Page 6] 
         






     Internet-Draft        I2RS for Service Chaining    February 2014 
      
            For each service node, virtual context and service type, 
            the following information may be specified, depending on 
            the service resource requirement. That is, some of the 
            information listed here may not be relevant for some 
            services. 

               o Service bandwidth capacity 

               o Supported Packet rate (packets per second) 

               o Supported Bandwidth (e.g., in kbps) 

               o IP Forwarding Information Base size per address family  

               o Routing Information Base size 

               o MAC Forwarding database size 

               o Number of 64-bit statistics counters for policy-based 
                 accounting 

               o Number of supported Access lists (ACLs) per type 
                 (e.g., number of bits per ACL, and ACL type if 
                 applicable) 

               o Number of supported flows for services that require it 
                 (e.g., Firewall, NAT, stateful load-balancing, Deep 
                 Packet Inspection (DPI)) per flow type (i.e., fields 
                 identifying a flow) or flow identification key size. 
                 For systems that allow flexible memory usage across 
                 flow types and/or key sizes, it is sufficient to track 
                 available memory allocated for flows.  

        In addition to the services topology, it is important to have a 
        view of the Virtual Network (VN) topology (VNT) and access 
        points to which a services topology applies. The topology of 
        such a VN could be relatively static, but it may also be 
        dynamic, especially in a cloud environment where compute, 
        storage, applications and associated networks may be created 
        and removed over a short time scale. The description of a VN 
        topology encompassing the access points is important in order 
        to enable installation of policies for service chaining at the 
        right access points, instantiate the services if needed, and 
        perform the necessary monitoring as described in later 
        sections. VN topology information requirements are described in 
        [i2rs-topology-reqts], but they need to be augmented with the 
        following information: 

        
     bitar, et al.            Expires August 2014            [Page 7] 
         






     Internet-Draft        I2RS for Service Chaining    February 2014 
      
           . Access ports (systems and ports) per VN. A port may be 
             physical or logical on a physical port. 

           . Addresses reachable on an access port.  

     3.2. Monitoring Information 

        Service chaining requires the ability to monitor the state of 
        each service node, including liveliness and resource 
        utilization. If a service node failure is detected, an action 
        may be taken to create another service node and steer traffic 
        to it.  If a service node is hitting a resource utilization 
        threshold, traffic may be directed to other service nodes, 
        and/or additional service nodes may be created.  

        The following is a set of parameters that needs be monitored    
        per service node per virtual context, and per service type as 
        applicable. It should be noted that some services may not 
        require all the parameters listed here to be monitored.   

          . Bandwidth utilization (e.g., in kbps) 

          . Packet rate utilization (packets per second) 

          . Bandwidth utilization per CoS (e.g., in kbps) 

          . Packet rate utilization per Cos 

          . Memory utilization and available memory 

          . RIB utilization per address family  

          . FIB utilization per address family 

          . Flow resource utilization per flow type 

          . CPU utilization as applicable 

          . Available storage 

        The following is a set of parameters that needs to be monitored 
        globally per physical system (e.g., host server) providing 
        services or hosting service nodes. Note that some parameters 
        may not be needed for some services:  

          . Bandwidth utilization (e.g., in kbps) 


           
     bitar, et al.            Expires August 2014            [Page 8] 
         






     Internet-Draft        I2RS for Service Chaining    February 2014 
      
          . Packet rate utilization (packets per second) 

          . Bandwidth utilization per Class of Service (CoS) 

          . Packet rate per CoS (packets per second) 

          . Memory utilization and available memory 

          . RIB utilization and available RIB memory if applicable per 
             address family 

          . FIB utilization and available FIB entries if applicable 
             per address family 

          . Flow resource utilization per flow type if applicable 

          . CPU utilization if applicable 

          . Power utilization 

          . Available storage 

        Such information needs to be maintained on the distributed 
        system hosting a service node, and/or service node as 
        applicable. In addition, a mechanism to monitor the liveliness 
        of a service node must be available. For some use cases, 
        liveliness and resource utilization information needs to be 
        accessible to a management/control plane that provides for 
        creation of service nodes and orchestration of service chains. 
        Some of this information may also be maintained in the 
        management/orchestration system and validated with the 
        distributed system where the services are instantiated. For 
        some other use cases, a service node and/or hosting system may 
        need to be programmed to update a management system with that 
        information periodically or when a configured high watermark or 
        low watermark is reached for a parameter. Thus, the interface 
        to the service nodes and/or hosting systems must provide a 
        mechanism that enables a management/control system to pull 
        resource utilization information from these nodes and systems, 
        and for these nodes and system to send updates on resource 
        utilization to a designated system.   

     3.3. Traffic Redirection, Forwarding and Service Chaining 

        In a service chain, it is important to be able to direct 
        traffic from one service node to another. Some solutions may 
        provide this capability via dynamic routing, data-plane based 

      
     bitar, et al.            Expires August 2014            [Page 9] 
         






     Internet-Draft        I2RS for Service Chaining    February 2014 
      
        policy-based routing, source based routing or a combination. 
        Traffic redirection to a service chain requires the ability to 
        program the routing system with a classification rule that 
        identifies a packet/flow and an associated action that directs 
        the corresponding packet(s) to the first node in the service 
        chain. The focus in this section is on a hop-by-hop policy-
        based routing (PBR) and source based service routing. At the 
        redirection point, classification rules MUST support the 
        following information that encompasses Layer1-7 information, 
        any of which may be wild-carded or left unspecified for a 
        particular case: 

          . Port  

          . VLAN/VLAN stack 

          . MAC source address 

          . MAC destination address 

          . Host/subnet Source IP address 

          . Host/subnet Destination IP address 

          . IP version 

          . IP protocol 

          . Source port/port-range 

          . Destination port/port-range 

          . Optionally, application-layer information such as key 
             words in a URI, content type or user agent 

        As a result of the classification, an action will need to be 
        specified to direct the matching packet to a service node, or 
        to perform other action(s). The following actions MUST be 
        supported: 

           . Forward to a specified Outgoing port (physical or 
             logical): 

                o VLAN ID 

                o IP/GRE tunnel 


           
     bitar, et al.            Expires August 2014            [Page 10] 
         






     Internet-Draft        I2RS for Service Chaining    February 2014 
      
                o RSVP-TE tunnel 

                o Pseudowire (PW) 

                o Other types of tunneling protocols 

           . Steer the packet to a VRF 

           . Mirror packet: 

                o  To an IP destination 

                o  To a port 

                o  over a VLAN 

                o  over an IP/GRE tunnel  

                o  over an RSVP-TE tunnel 

                o  over a Pseudowire 

                o  over other types of tunneling  

           . Route. This could be the default behavior at the tail end 
             of a chain or the result of no match. 

           . Route the packet to a specific system that is multiple IP 
             hops away (Layer 3 policy based routing). The destination 
             system IP address must be specified along with the 
             tunneling type. The action must result in encapsulating 
             the packet to the destination. At the destination, a 
             policy must be installed to apply a service in a specific 
             context to the arriving packet, or direct the traffic to a 
             local service node. 

           . Insert a source route header in the transmitted packet 
             that identifies the nodes along the service path. The 
             service route may be composed of IPv4 routes, IPv6 routes 
             and/or a stack of MPLS labels. The source route may 
             capitalize on existing mechanism or new mechanisms that 
             are outside the scope of this document. At the 
             destination, a policy must be installed to apply a service 
             in a specific context to the arriving packet, or direct 
             the traffic to a local service node. 

      
     bitar, et al.            Expires August 2014            [Page 11] 
         






     Internet-Draft        I2RS for Service Chaining    February 2014 
           . Insert a source route+service header that identifies the 
             service path and the service type to be applied at each 
             node. This will require the definition of a new data plane 
             header that carries such information.  

        The number of classification rules and associated actions, as 
        well as the rate of programmability/removal of these rules will 
        be highly application dependent. When the service chain is 
        based on static policy (e.g., applied to a port, a source 
        subnet, a VN), these rules will be programmed on a system at 
        the rate of provisioning. When the attributes of the policies 
        are relatively static (e.g., applied to a fixed port in fixed 
        wireline access), the rate of provisioning on the forwarding 
        system could be low, on the order of few hundred per day. When 
        the attributes are more dynamic, such as in a mobile 
        environment on a system handling a large number of users, that 
        rate could be much higher. In a cloud environment where tenant 
        systems may be spun up and removed on a relatively short time 
        scale this rate could be on the order of few hundreds to 
        thousands a minute at a DC GW for instance. In all cases, if 
        the state is not kept in a persistent storage on the forwarding 
        system(s), system reboot actions will trigger the need for a 
        high provisioning rate, on the order at few thousands per 
        second. When policies are triggered by data-plane, the rate of 
        policy provisioning will be on the order of flow rates and 
        removal will be dependent on the flow duration. These rates 
        will be highly dependent on the applications as well, but at a 
        system that is handling a large number of flows, the protocol 
        used in provisioning must be very efficient to handle a very 
        large number of flows. 

     4. Service Chaining via BGP-based Redirection 

        BGP-based steering of a traffic flow to a first service point 
        may be required in certain cases. In this case, a router 
        hosting a service node or connected to a service node will 
        advertise a flow specification that causes a system that 
        receives the advertisement to redirect a packet or mirror a 
        copy of the packet that matches the flow specification to the 
        advertising route [BGP-flowspec]. When the advertising router 
        supports the i2rs BGP service, ann I2RS interface to the router 
        can provision the router with the appropriate BGP policy as 
        well as install on that router a forwarding policy that directs 
        the packet when received to the appropriate service node. Such 
        BGP advertisements can be chained to effect the chaining of 
        multiple services. 


        
     bitar, et al.            Expires August 2014            [Page 12] 
         






     Internet-Draft        I2RS for Service Chaining    February 2014 
      
     5. Operational Considerations 

     6. IANA Considerations 

        There is IANA action required by this document. 

     7. Security Considerations 

        Service chaining imposes several security issues that must be 
        addressed. First, the control system that installs policies on 
        the routing system must be trusted by that system. An untrusted 
        control system may install policies that hijack traffic, cause 
        denial of service, or mirror traffic to an untrusted entity for 
        eavesdropping. Thus the communication channel between a control 
        system and routing system must be authenticated, and may be 
        encrypted. In addition, when services are being offered to 
        multiple VPN customers with overlapping IP addresses, it is 
        important that the customer privacy is maintained when applying 
        a service chain to a customer packet/flow. Thus, the ability to 
        identify the context in which a service needs to be applied is 
        important. In addition, policies must be installed in the 
        appropriate context. Finally, congesting a service node can 
        result in packet drops that may effectively result in a denial 
        of service. Thus, obtaining information about the performance 
        of a service node is important to detect overload conditions 
        and take corrective action. 

     8. Acknowledgements 

     The authors thank David McDysan and Alia Atlas for their comments. 

     9. References 

     9.1. Normative References 
     [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
     Requirement Levels", BCP 14, RFC 2119, March 1997.
     
     [i2rs-prob] Atlas, A., Nadeau, T., and Ward, D., "Interface to the 
     Routing System Problem Statement", draft-ietf-i2rs-problem-
     statement-00, August 2013. Work in progress. 
      
     [i2rs-topology-reqts] Medved, J., et al., "Topology API 
     Requirements", draft-medved-i2rs-topology-requirements, February 
     2013. Work in progress. 
      
     [BGP-flowspec] Uttaro, J., et al., "BGP Flow-Spec Extended 
     Community for Traffic Redirect to IP Next Hop", draft-simpson-idr-
     flowspec-redirect-02, November 2012. Work in Progress.  
        
     bitar, et al.            Expires August 2014            [Page 13] 
         






     Internet-Draft        I2RS for Service Chaining    February 2014 
      
      

     9.2. Informative References 

      

     Authors' Addresses 

        Nabil Bitar 
        Verizon 
        60 Sylvan Rd. 
        Waltham, MA 02145 
        EMail: nabil.n.bitar@verizon.com 

        Giles Heron 
        Cisco Systems 
        EMail: giheron@cisco.com 

        Luyuan Fang 
        Microsoft 
        EMail: luyuanf@gmail.com 

        Ram Krishnan 
        Brocade Communications 
        San Jose, CA 95134 
        EMail: ramk@brocade.com 

        Nicolai Leymann 
        Deutsche Telekom 
        Winterfeldtstrasse 21-27 
        10781 Berlin 
        Germany 
        EMail: n.leymann@telekom.de    
      
        Himanshu Shah 
        Ciena 
        EMail: hshah@ciena.com 
      
        Samita Chakrabatri 
        Ericsson 
        EMail: samita.chakrabarti@ericsson.com 
         

        Wassim Haddad 
      
      
     bitar, et al.            Expires August 2014            [Page 14] 
         






     Internet-Draft        I2RS for Service Chaining    February 2014 
      
        Ericsson 
        EMail: wassim.haddad@ericsson.com  
         












































      
      
     bitar, et al.            Expires August 2014            [Page 15]