[Search] [pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01                                                         
     Internet Engineering Task Force
     I2RS working group                                        N. Bitar
     Internet Draft                                             Verizon
     Category: Informational                                   G. Heron
                                                                L. Fang
                                                                  Cisco
                                                            R. Krishnan
                                                 Brocade Communications
                                                             N. Leymann
                                                        Deutshe Telekom
                                                                H. Shah
                                                                  Ciena
                                                         S. Chakrabarti
                                                              W. Haddad
                                                               Ericsson
     
     
     
     
     Expires: January 2014                                July 15, 2013
     
     
         Interface to the Routing System (I2RS) for Service Chaining:
                          Use Cases and Requirements
     
                     draft-bitar-i2rs-service-chaining-00
     
     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 January 2014            [Page 1]

Internet-Draft          I2RS for Service Chaining        July 2013
     
     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 January 14, 2014.
     
     Copyright Notice
     
        Copyright (c) 2013 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 January 2014            [ Page 2]
     
     
     
     
     
     
     
     Internet-Draft          I2RS for Service Chaining        July 2013
     
     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.10
        4. Service Chaining via BGP-based Redirection............... 12
     
        5. Operational Considerations............................... 12
        6. IANA Considerations...................................... 12
        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 January 2014            [ Page 3]
     
     
     
     
     
     
     
     Internet-Draft          I2RS for Service Chaining        July 2013
     
     
     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
     
     
     
     
     bitar, et al.           Expires January 2014            [ Page 4]
     
     
     
     
     
     
     
     Internet-Draft          I2RS for Service Chaining        July 2013
     
        requirements for controlling the forwarding of a packet/flow
        along a service chain based on packet/flow attributes.
     
     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 of customer VPNs. the terms
        "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.
     
     
     
     
     bitar, et al.           Expires January 2014            [ Page 5]
     
     
     
     
     
     
     
     Internet-Draft          I2RS for Service Chaining        July 2013
     
        A services topology description requires the following
        information:
     
          . Service node address: A service node must have a unique
            address in a service topology. A service node identifier
            address can be:
     
                 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 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
     
     
     
     
     bitar, et al.           Expires January 2014            [ Page 6]
     
     
     
     
     
     
     
     Internet-Draft          I2RS for Service Chaining        July 2013
     
                   a degenerate case. This will be the global
                   context for a given customer on a service node.
     
            . 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
     
                    - Supported Packet rate
     
                    - Supported Bandwidth (e,g, 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
     
     
     
     bitar, et al.           Expires January 2014            [ Page 7]
     
     
     
     
     
     
     
     Internet-Draft          I2RS for Service Chaining        July 2013
     
        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:
     
            . 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., kbps)
     
          .  Packet rate utilization
     
          .  Bandwidth utilization per CoS (e.g., 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
     
     
     
     
     bitar, et al.           Expires January 2014            [ Page 8]
     
     
     
     
     
     
     
     Internet-Draft          I2RS for Service Chaining        July 2013
     
        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)
     
          .  Packet rate utilization
     
          .  Bandwidth utilization per Class of Service (CoS)
     
          .  Packet rate per CoS
     
          .  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.
     
     
     
     bitar, et al.           Expires January 2014            [ Page 9]
     
     
     
     
     
     
     
     Internet-Draft          I2RS for Service Chaining        July 2013
     
     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
        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 should 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 forwarding action(s). Thus, the following
        actions should be supported:
     
           . Forward to a specified Outgoing port (physical or
             logical):
     
     
     
     bitar, et al.           Expires January 2014            [ Page 10]
     
     
     
     
     
     
     
     Internet-Draft          I2RS for Service Chaining        July 2013
     
                o VLAN ID
     
                o IP/GRE tunnel
     
                o RSVP-TE tunnel
     
                o Pseudowire (PW)
     
                o Other types of tunneling protocols
     
     
           . Steer the packet to a VRF
     
           . Mirror packet to an IP destination
     
           . Lookup up in the FIB. This could be the default behavior at
               the tail end of a chain or the result of no match.
     
           . Forward the packet to a specific system that is multiple
             IP hops away (Layer 3 PBR). 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.
     
           . 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 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
     
     
     
     bitar, et al.           Expires January 2014            [ Page 11]
     
     
     
     
     
     
     
     Internet-Draft          I2RS for Service Chaining        July 2013
     
        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]. An I2RS interface to the
        advertising system from a control plane can help provisioning
        the advertising 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.
     
     5. Operational Considerations
     
     6. IANA Considerations
     
        There is no IANA action required by this document.
     
     
     
     
     
     bitar, et al.           Expires January 2014            [ Page 12]
     
     
     
     
     
     
     
     Internet-Draft          I2RS for Service Chaining        July 2013
     
     7. Security Considerations
     
        Service chaining imposes several security issues that must be
        addressed. First, the control system that installs policies in
        the forwarding plane must be trusted by the forwarding plane
        entity. 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 a forwarding plane entity
        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 effectively may 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 are thankful to David Allan for his valuable input
        and comments.
     
     9. References
     
     9.1. Normative References
     
     [i2rs-prob] Atlas, A., Nadeau, T., and Ward, D., "Interface to the
     Routing System Problem Statement", draft-atlas-i2rs-problem-
     statement-01, July 2013. Work in progress.
     
     [i2rs-topology-reqts] Medved, J., et al., "Topology API
     Requirements", draft-medved-i2rs-topology-requirements-00, 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 January 2014            [ Page 13]
     
     
     
     
     
     
     
     Internet-Draft          I2RS for Service Chaining        July 2013
     
     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
        Cisco Systems
        111 Wood Avenue South
        Iselin, NJ 08830
        EMail: lufang@cisco.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
     
     
     
     bitar, et al.           Expires January 2014            [ Page 14]
     
     
     
     
     
     
     
     Internet-Draft          I2RS for Service Chaining        July 2013
     
        Wassim Haddad
        Ericsson
        EMail: wassim.haddad@ericsson.com
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     bitar, et al.           Expires January 2014            [ Page 15]