Internet DRAFT - draft-li-service-chaining-requirements
draft-li-service-chaining-requirements
Network Working Group H. Li
Internet-Draft Y. Jiang
Intended status: Informational Huawei Technologies
Expires: December 29, 2013 June 27, 2013
Requirements for Service Chaining
draft-li-service-chaining-requirements-00
Abstract
Chaining some service processing functions may provide services in a
flexible way. Such a method is called service chaining. This
document presents a list of general requirements service chaining
should support. Solutions of service chaining are not presented in
this document.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on December 29, 2013.
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.
Li & Jiang Expires December 29, 2013 [Page 1]
Internet-Draft Service Chaining Requirements June 2013
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Basic Requirements . . . . . . . . . . . . . . . . . . . 3
3.2. Enhanced Requirements . . . . . . . . . . . . . . . . . . 4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
Chaining some service processing functions may provide services in a
flexible way. There are many type of service processing functions,
which have different ways of processing packets. For example,
firewall may transparently forward or drop a packet, while NAT
changes the IP header of a packet. A service chain may consist of
several types of service processing functions. One service
processing function may be shared by multiple service chains. A
packet must be correctly identified and forwarded after being
processed by such a shared service processing function. Service
chain may be implemented in different environment, e.g. in physical
networks, in a Datacenter, etc. There are some necessary
requirements for a service chain to be constructed and work properly.
2. Terminology
The following terms are used in this document:
Service Processing Function: a logical entity which can provide one
or more service processing functions for packets/frames such as
firewall, DPI (Deep Packet Inspection), LI (Lawful Intercept) and
etc. Usually these processing functions are computation intensive.
Service Flow: packets/frames with specific service characteristics
(e.g., packets matching a specific tuple of fields in Ethernet, IP,
TCP, HTTP headers and etc.) or determined by some service policies
(such as access port and etc.)
Service Chain: one or more service processing functions in a specific
order which are chained to provide a composite service, and packets/
frames from one or more service flow should follow.
Service Chaining: a mechanism of building service chains and
forwarding packets/frames of service flows through them.
Li & Jiang Expires December 29, 2013 [Page 2]
Internet-Draft Service Chaining Requirements June 2013
3. Requirements
Service chains exist in many different scenarios, and have some
requirements in common, which are basic requirements and must be
supported. In some scenarios, more complex service chains are
constructed and some enhanced requirements should be satisfied.
3.1. Basic Requirements
- Service chaining MUST support classifying traffic and direct it
into a service chain. Service chain may be a bypass and different
from normal L2 or L3 forwarding. Service chaining needs a traffic
classification function to identify traffic needs to be directed into
a service chain.
- Service chaining MUST be able to forward traffic through service
processing functions in a sequence without relying on destination
address of packets. This means service chaining must support
forwarding packets to a path where they will not go through in case
of normal switching or routing per destination addresses. Service
chain is usually a bypass different from normal forwarding path of
switching or routing. Traffic is redirected into a chain of service
processing functions for service processing purpose when necessary.
Therefore, such redirection is based on policy or service
characteristics of traffic or policy.
- Service chaining MUST be able to forward service flow traffic
through various forms of service processing functions. Service
processing functions could be implemented as physical nodes, virtual
machines, or even processes in a server. Service chaining must
support all these implementations and allow different implementations
co-exist in a same chain.
-Service chaining MUST support coexistence of different types of
service processing functions in a same service chain. Some service
processing functions forward traffic transparently, e.g. load
balancer, some service processing functions forward and modify
traffic, e.g. NAT, while some other service processing functions
terminate traffic, e.g. cache.
- Service chaining MUST be able to support multiple service chains/
paths share the same group of service processing functions. With a
group of service processing functions available, more than one
service chain can be built with same or different subset of service
processing functions in any reasonable sequence.
- Service Chaining MUST support multiple service chains sharing one
or more service processing function(s). For given several service
Li & Jiang Expires December 29, 2013 [Page 3]
Internet-Draft Service Chaining Requirements June 2013
chains, they may have different service processing functions, while
sharing one or more service processing functions, or , they may have
same service processing functions but in different order. Service
chaining must be able to identify service flows of these different
service chains and forward them correctly, after the flow is
processed by a shared service processing function.
- Service chaining MUST support statically configuring forwarding
path of a service chain. Purpose of a service chain is to build a
service, which is usually designed in advance. Sequence of service
processing functions, the path, is part of the design of a service.
To direct traffic through this path, forwarding functions in a
service chain must be configured of forwarding path in advance, which
could be done statically.
- Service chaining MUST be able to identify a flow and forward it to
the correct next hop in the service chain it belongs to, even if it
is changed by a service processing function. An example of this is a
flow going through a NAT, where IP headers of packets in this flow
are changed. The flow MUST be correctly identified after been
processed by NAT and forwarded to its next hop in the service chain.
3.2. Enhanced Requirements
- Service chaining SHOULD support forwarding traffic across various
underlay networks. Service processing functions may exist in
different forms and underlay network providing connection between
them may vary. Service chaining should support forwarding traffic
through service chains over L2, L3 and VPN networks.
- Service chaining SHOULD support service chains over heterogeneous
underlay networks. A service chain may chain service processing
functions located in different types of networks, e.g. L2 or L3.
Service chaining should be able to transport traffic through these
service processing functions even if they are in different types of
underlay networks.
- Service chaining SHOULD support forwarding traffic to different
paths according to process result of a service processing function.
In case DPI is in a service chain, the next service processing
function after DPI may be selected according to the result of DPI.
Thus, traffic after DPI may be directed to different paths
accordingly.
4. IANA Considerations
This document makes no request for IANA action.
Li & Jiang Expires December 29, 2013 [Page 4]
Internet-Draft Service Chaining Requirements June 2013
5. Security Considerations
Service chaining should consider security issues and will be
discussed in future revisions.
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Authors' Addresses
Hongyu Li
Huawei Technologies
Huawei Industrial Base
Shenzhen
China
Email: hongyu.li@huawei.com
Yuanlong
Huawei Technologies
Huawei Industrial Base
Shenzhen
China
Email: jiangyuanlong@huawei.com
Li & Jiang Expires December 29, 2013 [Page 5]
