Internet DRAFT - draft-niu-sfc-mechanism
draft-niu-sfc-mechanism
Internet Working Group L. Niu
H. Li
Y. Jiang
L.Yong
Internet Draft Huawei
Intended status: Standards Track
Expires: October 2014 April 11, 2014
A Service Function Chaining Header and Forwarding Mechanism
draft-niu-sfc-mechanism-01.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 October 11, 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
Niu and et al Expires October 11, 2014 [Page 1]
Internet-Draft SFC Header and Forwarding Mechanism April 2014
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.
Abstract
This document proposes a service function chain header and describes
forwarding mechanism, including processing procedures for each
component in a generic service function chain.
Table of Contents
1. Introduction .............................................. 2
2. Conventions used in this document ......................... 3
3. Terminology ............................................... 3
4. Design Principles.......................................... 4
5. SFC Header ................................................ 4
5.1. Metadata ............................................... 6
6. Service Function Chain Process Procedures ................. 7
6.1. Classifier ............................................. 9
6.2. Service Forwarding Entity (SFE) ........................ 9
6.3. Service Function (SF) .................................. 9
7. Underlay Network Interconnection ......................... 10
7.1 SF Attachment .......................................... 11
8. Underlay network encapsulation ........................... 11
9. Security Considerations .................................. 12
10. IANA Considerations ...................................... 12
11. References ............................................... 12
11.1. Normative References ............................... 12
11.2. Informative References ............................. 12
12. Acknowledgments .......................................... 13
1. Introduction
Service Function Chain (SFC) is an abstracted view of required
service functions in a specific order that packets pass through for a
given service. Service function chain network architecture contains
three components that packets will traverse: classifier, service
functions (SFs), and Service Forwarding Entities (SFEs) as described
in [draft-jiang-sfc-arch].
Niu and et al Expires October 11, 2014 [Page 2]
Internet-Draft SFC Header and Forwarding Mechanism April 2014
This document proposes a Service Function Chain header format and
describes forwarding mechanism and the processing procedure on each
component following the architecture [I-D.jiang-sfc-arch].
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 Function (SF): a logical entity which provides 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. It can
be realized as a dedicated hardware device, a server or a virtual
machine hosted in a server.
Service Forwarding Entity (SFE): a logical entity that forwards
service packets between SFs through service chain forwarding
mechanism. Optionally, it provides mapping, insertion and removal of
header(s) in packets/frames. SFE may be implemented as dedicated
hardware, or as virtual functions embedded in physical IT servers in
NFV(network function virtualization) deployment situation.
SFC Header: a header added specifically for a service function chain,
and it is used by SFEs in forwarding packets.
SFC Packet: a packet that encapsulated with an SFC header.
Service Function Chain (SFC): an abstracted view of required service
functions in a specific order that packets pass through for a given
service.
Service Path: a data plane mapping of a service function chain. A
service path consists of a sequence of SF instances and SFEs which
SFC packets in a service function chain pass through. Note service
path may not be the shortest path for packets to its destination.
Classifier (CLF): a logical entity classifies packets/frames based on
service characteristics or policies and encapsulates them with SFC
Niu and et al Expires October 11, 2014 [Page 3]
Internet-Draft SFC Header and Forwarding Mechanism April 2014
headers. A classifier may reclassify SFC packets based on the SFC
header information, and generating a new SFC header for these packets.
Underlay Network: a network that transports SFC packets between SFE
and SF or between SFEs. It may be an IP network, an Ethernet network,
or an MPLS network, etc.
SFC Forwarding Table: a forwarding table that is used by an SFE to
look up the next SF for an SFC packet. It indicates the next SF to be
associated with a certain Service chain in a service path.
4. Design Principles
SFC header and forwarding mechanism in this draft are designed to
fulfill following SFC requirements as described in [SFCREQ]:
1) Ability to convey path information of SFC via SFC packets.
2) Ability to convey metadata via SFC packets.
3) A Service Function may serve for one or more SFCs.
4) Decouple the functionality of SF from service chain forwarding
function.
5) Decouple the underlay network transport function from the Service
chain forwarding function.
6) Ability to support SFC OAM.
5. SFC Header
An SFC header is proposed and depicted in Figure 1.
Niu and et al Expires October 11, 2014 [Page 4]
Internet-Draft SFC Header and Forwarding Mechanism April 2014
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|M|O| Reserved | Protocol Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SF ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metadata (Optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OAM (Optional) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 SFC header
o Version: version of the SFC header. This field is 4 bits long, and
it MUST be set to 0x1 for this version.
o M: value 1 indicates that metadata is present following the basic
header, and value 0 indicates otherwise.
o O: value 1 indicates that OAM is present following the basic
header, and value 0 indicates otherwise.
o Reserved: this field is reserved for future extension, and MUST be
set to zero for this version.
o Protocol Type: indicate the protocol type of the original packet
in the SFC packet per IANA definition.
o Path ID: the Service Path identifier, assigned for the traffic
along the same Service Path in a service domain. The path ID field
is set or changed by Classifier. This field is 32 bits long.
o SF ID: This field is used to carry the previous SF or next SF ID
in an SFC header. Each SF instance is assigned a unique value for
its identification in an SFC domain. This field is usually set by
an SFE before sending an SFC packet to its local SF. It may also
be a Classifier ID when the SFC header is added by a classifier.
Each SFE can look up its SFC Forwarding Table by use of the SF ID
and Path ID in an SFC packet to get the next SF in the service
path.
o Metadata: optional, its format is defined in Section 5.1.
o OAM: optional, its format will be specified in another document.
Niu and et al Expires October 11, 2014 [Page 5]
Internet-Draft SFC Header and Forwarding Mechanism April 2014
5.1. Metadata
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|S| Reserved | Metadata Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MetaData ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 Basic metadata
o F: FORWARDING type metadata, indicates there is metadata after the
basic metadata header which can be used by an SFE in forwarding
decision.
o S: SERVICE type metadata, indicates there is metadata inserted by
one or more SFs after the basic metadata header which can be used
by other SFs in their service processing.
o Reserved bits: 8 bits reserved for future extension, must be set
to zero.
o Metadata Length, the total length of Metadata in terms of a unit
of 4 bytes.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SF Process Result |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 FORWARDING type metadata
o SF Process Result: the SF processing result of an SFC packet. This
field is 32 bits long. SFC packets may be forwarded by an SFE to
different next SFs based on the SF processing results.
Note only one FORWARDING type metadata can be appended in an SFC
header.
Niu and et al Expires October 11, 2014 [Page 6]
Internet-Draft SFC Header and Forwarding Mechanism April 2014
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SF ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SERVICE MetaData( TLV ) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 SERVICE type metadata
o SF ID, identifies the SF that adds the SERVICE type metadata.
o Length, length of SERVICE Metadata.
o SERVICE MetaData (TLV), Type-length-value form metadata parameters,
detailed information of this TLV will be specified in a future
version.
6. Service Function Chain Process Procedures
In general, there are three types of components in a service function
chain, i.e. classier, SFE and SF, and each component is configured
with a unique identifier.
A classifier may be integrated in SFE or individual implemented,
which performs:
-classifying original data packets based on service characteristics
(may be mapped to a tuple of fields in the packet), and building SFC
packets by encapsulating these packets with an SFC header. Or
-reclassifying SFC packets based on the SFC header information, and
generating a new SFC header for the packets.
An SF in SFC provides a specific service to the original packets
encapsulated in Service Function Chain Header. Examples of SFs are
firewall, load balancer, Intrusion detection system (IDS), etc. An SF
may utilize SERVICE type metadata carried in the SFC packets for
service processing. For example, SERVICE type metadata may be a
subscriber ID that the packets are associated with.
An SFE provides following functions:
Niu and et al Expires October 11, 2014 [Page 7]
Internet-Draft SFC Header and Forwarding Mechanism April 2014
- based on the SFC forwarding table configured in the SFE, forwarding
SFC packets to next SF attached to it or to another SFE which next SF
is attached to.
- insert a transport header on SFC packets and send the packets to
attached SFs or to other SFEs; process received packets from the
transport network.
- remove SFC header from an SFC packet, and send the original packet
out of the SFC network.
For example, two service paths are illustrated in Fig.5:
Service Path 1: CLF1 -> A1 -> B1 -> C1.
Service Path 2: CLF1 -> A1 -> B1 -> C2.
In this example, CLF1 is a classifier; Service Function A1 and B1 are
attached to SFE 1, and Service Function C1 and C2 are attached to SFE
2. Furthermore, A1 and B1 are local SFs to SFE1, while C1 and C2 are
not.
.............................................
. +----+ +----+ +----+ +----+ .
. | SF | | SF | | SF | | SF | .
. | A1 | | B1 | | C1 | | C2 | .
. +-+--+ +-+--+ +--+-+ +-+--+ .
. | | | | .
. | | | | .
. | | | | .
+-----+ pkt +-----+ +-+------+--+ +--+-----+--+ . pkt +-----+
|Orig-| in | | | | | | . out |Orig-|
|inal |---->| CLF1+----+ SFE 1 +----+ SFE 2 +--------->|inal |
|Net- | | | | | | | . >|Net- |
|work | +-----+ +-----------+ +-----------+ . |work |
+-----+ . . +-----+
. SFC domain .
.................... ........................
Figure 5 An Example of Service Path
Niu and et al Expires October 11, 2014 [Page 8]
Internet-Draft SFC Header and Forwarding Mechanism April 2014
Following sections describe the processing procedures for each type
of SFC component.
6.1. Classifier
Upon receiving a packet from a non-SFC network, the classifier
performs the traffic classification on packets based on locally
configured policy, and determines which service function chain it
should pass through. Based on the classification result, an SFC
header is appended. Parameters set in this SFC header include:
- The Path ID field MUST be filled with a value that represents a
particular service path corresponds to this service function chain.
- The SF ID field MUST be set to the ID of this Classifier.
- If metadata is needed, a metadata field can be added to the SFC
header and the M flag MUST be set.
- Protocol Type, MUST be set to correctly identify the original
packet type.
6.2. Service Forwarding Entity (SFE)
Upon receiving an SFC packet, an SFE looks up its SFC Forwarding Table
with the Path ID and SF ID in the SFC header. If the lookup result
points to a next SF that is local, the SF ID field of the SFC header
is updated with the result, and the updated SFC packet is sent to the
next SF; if the lookup result points to a next SF that is not local,
the SFC packet is sent to the SFE with which the SF is attached to and
with no change on the SF-ID; if the result is NULL, the SFC header is
removed from the SFC packet, and the original packet is sent to the
non-SFC network.
6.3. Service Function (SF)
Upon receiving an SFC packet from an SFE, an SF retrieves the
original packets carried in the SFC packet and performs service
processing; and then adds the same SFC header to the original packets
and sends the SFC packet back to the SFE where it came from.
If an SF requires use of metadata in service processing, it SHOULD
retrieve SERVICE type metadata from SFC packets.
Niu and et al Expires October 11, 2014 [Page 9]
Internet-Draft SFC Header and Forwarding Mechanism April 2014
If an SF needs to pass metadata to other SFs, it MUST append the
specific SERVICE type metadata to the SFC header and set SF ID to
itself.
7. Underlay Network Interconnection
The underlay network is used to transport SFC packets between SFC
components. Underlay networks between SFEs or between an SF and an SFE
may be the same or different from one another.
Figure 6 depicts an example of underlay network used to connect SFC
components. CLF1 is connected to SFE1 with a GRE tunnel. Other local
components are connected with IP network or Ethernet network.
............................................
. +----+ +----+ +----+ +----+ .
. | SF | | SF | | SF | | SF | .
. | A1 | | B1 | | C1 | | C2 | .
. +--+-+ ++---+ +--+-+ ++---+ .
. | | | | .
. +-+----+-+ +-+----+-+ .
. | IP | |Ethernet| .
. |Network | |Network | .
. +---+----+ +---+----+ .
. | | .
+-----+ +--+--+ +----+------+ +----+------+ . +-----+
|Orig-| | | | | | | . |Orig-|
|inal |---->| CLF1| | SFE1 | | SFE2 +-------->|inal |
|Net- | | | | | | | . |Net- |
|work | +--+--+ +-+------+--+ +-----+-----+ . |work |
+-----+ . | | | | . +-----+
. | +-----+--+ | +--------+ | .
. +---+ GRE | +--+ IP +-+ .
. | Tunnel | |Network | .
. +--------+ +--------+ .
. .
. SFC domain .
............................................
Figure 6 SFC underlay network interconnection
Niu and et al Expires October 11, 2014 [Page 10]
Internet-Draft SFC Header and Forwarding Mechanism April 2014
7.1 SF Attachment
In order to transport SFC packets over various underlay networks, SFC
components need to maintain necessary information, for example,
underlay network type, underlay network addresses and etc. The
information is obtained by an SF attachment procedure.
In the SF attachment procedure, SFEs get the following SF information:
-SF ID, identifier of the attached SF.
-Local flag: indicate whether or not packets can be forwarded to an SF
from this SFE without going through another SFE.
-underlay network type: if the SF is locally attached, this field is
the underlay network type connecting to this SF; otherwise, it is the
underlay network type connecting to another SFE which the SF is
locally attached to.
-underlay network address: if the SF is locally attached, this field
is the underlay network address of this SF; otherwise, it is the
underlay network address of another SFE which the SF is locally
attached to.
The SF attachment procedure MAY be done by management provisioning,
or dynamic signaling.
8. Underlay network encapsulation
SFC packets can be transported over any underlay network. Two
examples are shown here.
UDP encapsulated SFC packet is formatted as following:
+--------+--------+------------------+-----------------+
| IP | UDP | SFC | Original Packet |
| Header | Header | Header | |
+--------+--------+------------------+-----------------+
Figure 7 IP/UDP as underlay network
A special UDP port value should be assigned by IANA to identify that
the UDP payload is an SFC packet.
Niu and et al Expires October 11, 2014 [Page 11]
Internet-Draft SFC Header and Forwarding Mechanism April 2014
SFC header can also be encapsulated in a GRE header as following:
+------------+-------------------------+----------------------+
| GRE header | SFC Header | original data packet |
+------------+-------------------------+----------------------+
Figure 8 GRE as underlay network
A special GRE Protocol Type value should be assigned by IANA to
identify that the GRE payload is an SFC packet.
9. Security Considerations
It will be considered in a future revision.
10. IANA Considerations
For IP/UDP underlay network, a specific UDP port value should be
assigned by IANA to identify the UDP payload is service chaining
packet.
For GRE underlay network, a specific GRE protocol type should be
assigned by IANA to identify the GRE payload is service chaining
packet.
11. References
11.1. Normative References
[RFC2784] D. Farinacci, T. Li, S. Hanks, D. Meyer, P. Traina; Generic
Routing Encapsulation (GRE); March 2000
11.2. Informative References
[I-D.jiang-sfc-arch] Y. Jiang, H. Li; An Architecture of Service
Function Chaining; February, 2014
[SFCREQ] Boucadair, M., and et al, "Requirements for Service Function
Chaining", draft-boucadair-sfc-requirements-03, February
2014.
Niu and et al Expires October 11, 2014 [Page 12]
Internet-Draft SFC Header and Forwarding Mechanism April 2014
12. 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
Lucy Yong
Huawei Technologies Co., Ltd.
1700 Alma Drive, Suite 100 Plano, TX USA
Email: lucy.yong@huawei.com
Niu and et al Expires October 11, 2014 [Page 13]
