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]
