Internet Working Group L. Niu
H. Li
Y. Jiang
Internet Draft Huawei
Intended status: Standards Track
Expires: July 2014 January 18, 2014
A Service Function Chaining Header and its Mechanism
draft-niu-sfc-mechanism-00.txt
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 July 18, 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
Niu and et al Expires July 18, 2014 [Page 1]
Internet-Draft A SFC Header and its Mechanism January 2014
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.
Abstract
This document describes a service chaining mechanism in the
forwarding plane, by which data packets can be forwarded to multiple
Service Processing Entities and processed by them in a preset order.
This document also describes a lightweight service chaining header to
facilitate packet forwarding in service function chains.
Table of Contents
1. Introduction .............................................. 2
2. Conventions used in this document ......................... 3
3. Terminology ............................................... 3
4. Service chaining header ................................... 4
5. Service classification mechanism .......................... 5
6. Service chaining mechanism ................................ 6
6.1. SFE behavior ........................................... 6
6.2. SPE behavior ........................................... 6
7. Underlay network encapsulation ............................ 7
8. Security Considerations ................................... 7
9. IANA Considerations ....................................... 8
10. References ................................................ 8
10.1. Normative References ................................ 8
10.2. Informative References .............................. 8
11. Acknowledgments ........................................... 9
1. Introduction
Service function chaining is a technology to direct packets going
through one or more Service Processing Entities (SPE). A service
chaining network includes one or multiple Service Forwarding Entities
(SFE) where SPEs are attached to. Service chaining architecture is
defined in [draft-jiang-service-chaining-arch].
SPE provides enhanced service processing such as load balancing, NAT,
network firewall, or URL filtering.
In this document, a SFE provides the following service chaining
functions:
Niu and et al Expires July 18, 2014 [Page 2]
Internet-Draft A SFC Header and its Mechanism January 2014
- classify original data packet based on service characteristics (may
be mapped to tuples of the packet), and add a service chaining header
in front of the packet. A packet with a service chaining header is
called a service chaining packet.
- forward service chaining packets between SPE and SFE or between SFE
and SFE, based on the service chaining forwarding table.
- remove service chaining header from a service chaining packet after
the last SPE finishing service processing, recover the original
packet, and send it out based on traditional forwarding mechanism
such as IP forwarding.
2. 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 [RFC2119].
3. Terminology
Service Processing Entity (SPE): 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. This
entity may also provide packet/frame encapsulation/decapsulation
capability.
Service Forwarding Entity (SFE): a logical entity which forwards
packets/frames to one or more SPEs in a same service chain.
Optionally, it provides mapping, insertion and removal of header(s)
in packets/frames. Note service forwarding path may not be the
shortest path to its destination.
Service Chaining Header: a header in front of packet, added by a SFE.
SFE uses service chaining header information to forward service
chaining packet.
Service Chaining Packet: an original packet added with a service
chaining header.
Niu and et al Expires July 18, 2014 [Page 3]
Internet-Draft A SFC Header and its Mechanism January 2014
Underlay Network: a network conveying service chaining packet between
SFE and SPE or between SFEs. It may be an IP network, an Ethernet
networks, or an MPLS networks, etc.
Service Chaining Table: Service chaining table is used to indicate
next hop of SFE forwarding service chaining packet.
4. Service chaining header
The service chaining header is depicted in Figure 1 below.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Previous SPE ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next SPE ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPE Process Result |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 service chaining header
o Version: represents the service chaining header version. This
field is 4 bits long, and current version is 0x0001.
o Reserved: this field is reserved for future extension.
o Path ID: the path identifier, assigned for the traffic along the
same service path in a service domain. The path ID field is set by
SFE based on result of traffic classification or SPE processing
result. This field is 32 bits long.
Niu and et al Expires July 18, 2014 [Page 4]
Internet-Draft A SFC Header and its Mechanism January 2014
o Previous SPE ID: the previous SPE that has handled the packet.
Each SPE instance is assigned a unique value for identification in
a service chaining domain. After processing the packet, the SPE
will replace the previous SPE ID value with its own SPE ID in the
service chaining header. This field is 32 bits long.
-special value of all zero means no previous SPE for current
packet.
o Next SPE ID: the next SPE that will handle the packet. When SFE
receives the packet from a SPE, it gets the next SPE ID based on
path ID, previous SPE ID and SPE Process Result, and fills the
next SPE ID value in Next SPE ID field. This field is 32 bits long.
-a special value of 0xffffffff means no next SPE for current
packet, and the SFE should remove the service chaining header.
o SPE Process Result: the SPE process result of a packet. If the SPE
has several different processing results for packets with the same
Path ID, and packets can go to different next SPEs based on the
SPE processing results. These paths are called branch paths. The
SPE Process Result field is filled by SPE, which is used to inform
the SFE. The SFE then uses this value and other fields in the
service chaining header to determine the next action to apply to
the packet. This field is 32 bits long.
-0x0000, a default value, indicate to SFE that the data packet
should be kept in the same service path.
5. Service classification mechanism
When a SFE receives an original packet at the boundary of a service
chaining domain, it performs service classification function. The
result of classification is used to determine the path ID of the
service chaining header.
The SFE adds a service chaining header for the packet that enters a
service chaining domain:
- set the same path ID for packets of the same service path.
Different service paths will have different service path ID;
-set initial SPE Process Result value to 0x00000000,
Niu and et al Expires July 18, 2014 [Page 5]
Internet-Draft A SFC Header and its Mechanism January 2014
-set the previous SPE ID field to all zero (a special value which
means no previous SPE for this data packet currently).
The service classification may be based on tuples of a packet, DPI
result of a packet, and etc.
6. Service chaining mechanism
6.1. SFE behavior
When a SFE receives a service chaining packet from its traffic
classifier module, from a SPE or another SFE, it performs following
actions:
1 get Path ID, SPE Process Result and Previous SPE ID from the
service chaining header in this service chaining packet,
2 look up its Service Chaining Table to get the new Path ID and next
SPE ID.
The Service Chaining Table should maintain the following information:
lookup key: Path ID + Previous SPE ID + SPE Process Result
lookup result new Path ID and next SPE ID
3 set Path ID field of the Service Chaining Header with the new Path
ID set Next SPE ID field of the Service Chaining Header with next SPE
ID.
--if next SPE ID=0xffffffff, meaning no next SPE for current
packet, the SFE should remove the service chaining header and send
the packet out of the service chaining domain;
4) get underlay network address that can reach the next SPE based on
the Next SPE ID, encapsulate a underlay network header before its
Service Chaining Header, and send out the packet.
6.2. SPE behavior
When a SPE receives a packet with underlay network header and service
chaining header from a SFE, it performs service processing function,
sets SPE Process Result field of the service chaining header based on
the processing result, sets the Previous SPE ID of the service
Niu and et al Expires July 18, 2014 [Page 6]
Internet-Draft A SFC Header and its Mechanism January 2014
chaining header to be the current SPE ID, encapsulates a new underlay
network header and send the packet back to the SFE.
7. Underlay network encapsulation
Service chaining header can be encapsulated in a UDP header or GRE
header.
Service chaining header can be encapsulated in a UDP header as
following:
+--------+--------+------------------+-----------------+
| IP | UDP | Service Chaining | Original Packet |
| Header | Header | Header | |
+--------+--------+------------------+-----------------+
Figure 2 IP/UDP as underlay network
A special UDP port value should be assigned by IANA to identify that
the UDP payload is a service chaining packet.
Service chaining header can also be encapsulated in a GRE header as
following:
+------------+-------------------------+----------------------+
| GRE header | Service Chaining Header | original data packet |
+------------+-------------------------+----------------------+
Figure 3 GRE as underlay network
A special GRE Protocol Type value should be assigned by IANA to
identify that the GRE payload is a service chaining packet.
8. Security Considerations
It will be considered in a future revision.
Niu and et al Expires July 18, 2014 [Page 7]
Internet-Draft A SFC Header and its Mechanism January 2014
9. IANA Considerations
If using IP/UDP as underlay network, a specific UDP port value should
be assigned by IANA to identify the UDP payload is service chaining
packet.
If using GRE as underlay network, a specific GRE protocol type should
be assigned by IANA to identify the GRE payload is service chaining
packet.
10. References
10.1. Normative References
[RFC2784] D. Farinacci, T. Li, S. Hanks, D. Meyer, P. Traina;
Generic Routing Encapsulation (GRE); March 2000
10.2. Informative References
[I-D.jiang-service-chaining-arch] Y. Jiang, H. Li; An Architecture of
Service Chaining; June, 2013
Niu and et al Expires July 18, 2014 [Page 8]
Internet-Draft A SFC Header and its Mechanism January 2014
11. Acknowledgments
TBD
Authors' Addresses
Lehong Niu
Huawei Technologies Co., Ltd.
Bantian, Longgang district
Shenzhen 518129, China
Email: niulehong@huawei.com
Hongyu Li
Huawei Technologies Co., Ltd.
Bantian, Longgang district
Shenzhen 518129, China
Email: hongyu.li@huawei.com
Yuanlong Jiang
Huawei Technologies Co., Ltd.
Bantian, Longgang district
Shenzhen 518129, China
Email: jiangyuanlong@huawei.com
Niu and et al Expires July 18, 2014 [Page 9]