Interface to the Routing System (I2RS) for Service Chaining: Use Cases and Requirements
draft-bitar-i2rs-service-chaining-01

Versions: 00 01                                                         
     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]