One document matched: draft-ietf-sfc-hierarchical-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY I-D.draft-homma-sfc-forwarding-methods-analysis SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-homma-sfc-forwarding-methods-analysis-05.xml">
<!ENTITY I-D.draft-ietf-sfc-nsh SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-sfc-nsh-05.xml">
<!ENTITY RFC7665 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7665.xml">
<!ENTITY I-D.draft-ietf-sfc-dc-use-cases SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-sfc-dc-use-cases-02.xml">
<!ENTITY I-D.draft-ao-sfc-for-dc-interconnect SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ao-sfc-for-dc-interconnect-01.xml">
<!ENTITY I-D.draft-ietf-sfc-control-plane SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-sfc-control-plane-06.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-ietf-sfc-hierarchical-00" ipr="trust200902">
<!-- ***** FRONT MATTER ***** -->
<front>
<title>Hierarchical Service Function Chaining (hSFC)</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<author fullname="David Dolson" initials="D." surname="Dolson">
<organization>Sandvine</organization>
<address>
<postal>
<street>408 Albert Street</street>
<!-- Reorder these if your country does things differently -->
<city>Waterloo</city>
<region>ON</region>
<code>N2L 3V3</code>
<country>Canada</country>
</postal>
<phone>+1 519 880 2400</phone>
<email>ddolson@sandvine.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Shunsuke Homma" initials="S." surname="Homma">
<organization abbrev="NTT">NTT, Corp.</organization>
<address>
<postal>
<street>3-9-11, Midori-cho</street>
<city>Musashino-shi</city>
<region>Tokyo</region>
<code>180-8585</code>
<country>Japan</country>
</postal>
<email>homma.shunsuke@lab.ntt.co.jp</email>
</address>
</author>
<author fullname="Diego R. Lopez" initials="D. R." surname="Lopez">
<organization>Telefonica I+D</organization>
<address>
<postal>
<street>Don Ramon de la Cruz, 82</street>
<city>Madrid</city>
<region></region>
<code>28006</code>
<country>Spain</country>
</postal>
<phone>+34 913 129 041</phone>
<email>diego.r.lopez@telefonica.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
<organization>Orange</organization>
<address>
<postal>
<street></street>
<city>Rennes</city>
<code>35000</code>
<country>France</country>
</postal>
<email> mohamed.boucadair@orange.com </email>
</address>
</author>
<author fullname="Dapeng Liu" initials="D." surname="Liu">
<organization>Alibaba Group</organization>
<address>
<postal>
<street></street>
<city>Beijing</city>
<code>100022</code>
<country>China</country>
</postal>
<email> max.ldp@alibaba-inc.com </email>
</address>
</author>
<author fullname="Ting Ao" initials="T." surname="Ao">
<organization>ZTE Corporation</organization>
<address>
<postal>
<street>No.889,Bibo Rd.,Zhangjiang Hi-tech Park</street>
<!-- Reorder these if your country does things differently -->
<city>Shanghai </city>
<region></region>
<code>201203 </code>
<country>China </country>
</postal>
<phone>+86-21-688976442</phone>
<email>ao.ting@zte.com.cn </email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Vu Anh Vu" initials="V." surname="Vu">
<organization abbrev="SSU ">Soongsil University</organization>
<address>
<postal>
<street>369 Sangdo-ro</street>
<city>Seoul</city>
<region>Dongjak-gu</region>
<code>06978</code>
<country>Korea </country>
</postal>
<email>vuva@dcn.ssu.ac.kr</email>
</address>
</author>
<date month="July" year="2016" />
<!-- Meta-data Declarations -->
<area>Routing Area</area>
<workgroup>Service Function Chaining</workgroup>
<keyword>sfc</keyword>
<keyword>hierarchical</keyword>
<abstract>
<t>
Hierarchical Service Function Chaining (hSFC) is a network architecture
allowing an organization to compartmentalize a large-scale network into
multiple domains of administration.
</t>
<t>
The goals of hSFC are to make a large-scale network easier to reason
about, simpler to control and to able support independent functional groups
within large operators.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
Service Function Chaining (SFC) is a technique for prescribing
differentiated traffic forwarding policies within an SFC-enabled domain.
SFC is described in detail in the
<xref target="RFC7665">
SFC architecture document
</xref>,
and is not repeated here.
</t>
<t>
In this document we consider the difficult problem of implementing SFC
across a large, geographically dispersed network comprised of millions
of hosts and thousands of network forwarding elements, involving
multiple operational teams (with varying functional responsibilities).
We expect asymmetrical routing is inherent in the network, while
recognizing that some Service Functions (SFs) require bidirectional
traffic for transport-layer sessions (e.g., NATs, firewalls). We assume
that some Service Function Paths (SFPs) need to be selected on the
basis of application-specific
data visible to the network, with transport-layer coordinate (typically,
5-tuple) stickiness to specific SF instances.
</t>
<t>
Note: in this document, the notion of the "path" of a packet is the
series of SF instances traversed by a packet. The means of delivering
packets between SFs (the forwarding mechanisms enforced in the
underlying network) is not relevant to the discussion.
</t>
<t>
Difficult problems are often made easier by decomposing them in a
hierarchical (nested) manner. So instead of considering an omniscient
SFC Control Plane that can manage (create, withdraw, supervise, etc.)
complete SFPs from one end of the network to the other, we decompose
the network into smaller sub-domains. Each sub-domain may support a
subset of the network applications or a subset of the users. The
criteria for determining decomposition into SFC-enabled sub-domains are
beyond the scope of this document.
</t>
<t>
Note that decomposing a network into multiple SFC-enabled domains should
permit end-to-end visibility of SFs and SFPs.
Decomposition should also be implemented with special care to
ease monitoring and troubleshooting of the network and services as a whole.
</t>
<t>
An example of simplifying a network by using multiple SF domains is
further discussed in <xref target="I-D.ietf-sfc-dc-use-cases"/>.
</t>
<t>
We assume the SFC-aware nodes use
<xref target="I-D.ietf-sfc-nsh">NSH</xref> or a similar labeling
mechanism.
</t>
<t>
The "domains" discussed in this document are assumed to be under control
of a single organization, such that there is a strong trust relationship
between the domains. The intention of creating multiple domains is to
improve the ability to operate a network. It is outside of the scope of
the document to consider domains operated by different organizations.
</t>
</section>
<section title="Hierarchical Service Function Chaining (hSFC)">
<t>
A hierarchy has multiple levels. The top-most level encompasses the
entire network domain to be managed, and lower levels encompass
portions of the network.
</t>
<section title="Top Level">
<t>
Considering the example depicted in <xref target="fig_hierarchical_top"/>, a
top-level network domain includes SFC data plane components distributed over a
wide area, including:
<list style="symbols">
<t>Classifiers (CFs),</t>
<t>Service Function Forwarders (SFFs) and</t>
<t>Sub-domains.</t>
</list>
For the sake of clarity, components of the underlay network are not
shown; an underlay network is assumed to provide connectivity between
SFC data plane components.
</t>
<t>
Top-level SFPs carry packets from classifiers
through a series of SFFs and sub-domains, with the operations within
sub-domains being opaque to the higher levels.
</t>
<t>
We expect the system to include a top-level control-plane having
responsibility for configuring forwarding and classification
(see <xref target="I-D.ietf-sfc-control-plane"/>).
The top-level Service Chaining control-plane manages end-to-end
service chains and associated service function paths from network edge
points to sub-domains and configuring top-level classifiers at a
coarse level (e.g., based on source or destination host) to forward
traffic along paths that will transit appropriate sub-domains.
<xref target="fig_hierarchical_top"/> shows one possible service chain
passing from edge, through two
sub-domains, to network egress. The top-level control plane does not
configure classification or forwarding within the sub-domains.
</t>
<t>
At this network-wide level, the number of SFPs required is a linear
function of the number of ways in which a packet is required to
traverse different sub-domains and egress the network. Note that the
various paths which may be taken within a sub-domain are not
represented by distinct network-wide SFPs; specific policies at the
ingress nodes of each sub-domain bind flows to sub-domain paths.
</t>
<t>
Packets are classified at the edge of the network to select the paths
by which sub-domains are to be traversed. At the ingress of each
sub-domain, paths are reclassified to select the paths by which SFs in
the sub-domain are to be traversed. At the egress of each sub-domain,
packets are returned to the top-level paths. Contrast this with an
approach requiring the top-level classifier to select paths to specify
all of the SFs in each sub-domain.
</t>
<t>
It should be assumed that some SFs
require bidirectional symmetry of paths (see more in
<xref target="section_classifier"/>). Therefore the classifiers at the
top level must be configured with policies ensuring outgoing
packets take the reverse path of incoming packets through
sub-domains.
</t>
<figure anchor="fig_hierarchical_top"
title="Network-wide view of top level of hierarchy">
<artwork><![CDATA[
+------------+
|Sub-domain#1|
| in DC1 |
+----+-------+
|
.---- SFF1 ------. +--+
+--+ / / | \--|CF|
--->|CF|--/---->' | \ +--+
+--+ / SC#1 | \
| | |
| V .------>|--->
| / / |
\ | / /
+--+ \ | / / +--+
|CF|---\ | / /---|CF|
+--+ '---- SFF2 ------' +--+
|
+----+-------+
|Sub-domain#2|
| in DC2 |
+------------+
]]> </artwork>
<postamble>
One path is shown from edge classifier to SFF1 to Sub-domain#1
(residing in data-center1) to SFF1 to SFF2 (residing in data-center
2) to Sub-domain#2 to SFF2 to network egress.
</postamble>
</figure>
</section>
<section title="Lower Levels">
<t>
Each of the sub-domains in <xref target="fig_hierarchical_top"/> is an
SFC-enabled domain.
</t>
<t>
Unlike the top level, data packets entering the sub-domain
are already SFC-encapsulated.
<xref target="fig_hierarchical_lower"/> shows a sub-domain interfaced
with a higher-level domain by means of an Internal Boundary Node
(IBN). It is the purpose of the IBN to apply classification rules and
direct the packets to the selected local SFPs terminating at an egress
IBN. The egress IBN finally restores packets to the
original SFC shim and hands them off to SFFs.
</t>
<t>
Each sub-domain intersects a subset of the total paths that are
possible in the higher-level domain. An IBN is concerned with
higher-level paths, but only those traversing its sub-domain. A
top-level control element may configure the IBN as an SF (i.e., the IBN plays the
SF role in the top-level domain).
</t>
<t>
Each sub-domain is likely to have a control-plane that can operate
independently of the top-level control-plane. The sub-domain
control-plane configures the classification and forwarding rules in
the sub-domain. The classification rules reside in the IBN, where
SFC encapsulation of the top-level domain is converted to/from
SFC encapsulation of the lower-level domain.
</t>
<figure anchor="fig_hierarchical_lower"
title="Sub-domain within a higher-level domain">
<artwork><![CDATA[
+----+ +-----+ +----------------------+ +-----+
| | | SFF | | IBN 1 (in DC 1) | | SFF |
| |SC#1| | | +----------------+ | | |
->| |===============>| SFF |================>
| | +-----+ | +----------------+ | +-----+
| CF | | | ^ |
| | | v | |
| | |+--------------------+| Top domain
| | ||CF, fwd/rev mapping ||
| | * * * * *|| and "glue" || * * * * *
| | * |+--------------------+| *
+----+ * | | | | | | Sub *
* +-o-o--------------o-o-+ domain*
* SC#2 | |SC#1 ^ ^ #1 *
* +-----+ | | | *
* | V | | *
* | +---+ +------+ | | *
* | |SFF|->|SF#1.1|--+ | *
* | +---+ +------+ | *
* V | *
* +---+ +------+ +---+ +------+ *
* |SFF|->|SF#2.1|->|SFF|->|SF#2.2| *
* +---+ +------+ +---+ +------+ *
* * * * * * * * * * * * * * * * * * * * * *
]]> </artwork>
<postamble>
*** Sub-domain boundary; === top-level chain; --- low-level chain.
</postamble>
</figure>
<t>
If desired, the pattern can be applied recursively. For example,
SF#1.1 in <xref target="fig_hierarchical_lower"/> could be a
sub-domain of the sub-domain.
</t>
</section>
</section>
<section title="Internal Boundary Node (IBN)">
<t>
A network element termed "Internal Boundary Node" (IBN) bridges packets
between domains. It behaves as an SF to the higher level, and looks like
a classifier and end-of-chain to the lower level.
</t>
<t>
To achieve the benefits of hierarchy, the IBN should be applying more
granular traffic classification rules at the lower level than the
traffic passed to it. This means that the number of SFPs within the
lower level is greater than the number of SFPs arriving to the
IBN.
</t>
<t>
The IBN is also the termination of lower-level SFPs. This is because
the packets exiting lower-level SF paths must be returned to the
higher-level SF paths and forwarded to the next hop in the higher-level
domain.
</t>
<section title="IBN Path Configuration"
anchor="section_strategies">
<t>
An operator of a lower-level domain may be aware of which
high-level paths transit their domain, or they may wish to accept any
paths.
</t>
<t>
When packets enter the sub-domain, the Service Path Identifier (SPI)
and Service Index (SI) are re-marked according to the path selected by
the classifier.
</t>
<t>
After exiting a path in the sub-domain, packets can be restored to an
original upper-level SFP by these methods:
<list style="numbers">
<t>
Saving SPI and SI in transport-layer flow state,
</t>
<t>
Pushing SPI and SI into metadata,
</t>
<t>
Using unique lower-level paths per upper-level path coordinates,
</t>
<t>
Nesting NSH headers, encapsulating the higher-level NSH headers
within the lower-level NSH headers,
</t>
<t>
Saving upper-level by a flow ID and placing an hSFC flow ID into metadata,
</t>
</list>
</t>
<section title="Flow-Stateful IBN" anchor="section_flow_stateful">
<t>
An IBN can be flow-aware, returning packets to the correct
higher-level SFP on the basis of the transport-layer
coordinates (typically, a 5-tuple) of packets exiting the
lower-level SFPs.
</t>
<t>
When packets are received by the IBN on a higher-level path, the
encapsulated packets are parsed for IP and transport-layer (TCP,
UDP, etc.) coordinates. State is created, indexed by these coordinates
({source-IP, destination-IP, source-port,
destination-port and transport protocol} typically). The
state contains at least critical fields of the encapsulating SFC header
(or perhaps the entire header).
</t>
<t>
The simplest approach has the packets return to the same IBN at the
end of the chain that classified the packet at the start of the
chain. This is because the required transport-coordinates state
is rapidly changing and most efficiently kept locally. If the packet is
returned to a different IBN for egress, transport-coordinates state
must be synchronized between the IBNs.
</t>
<t>
When a packet returns to the IBN at the end of a chain, the SFC
header is removed, the packet is parsed for IP and transport-layer
coordinates, and state is retrieved from them. The state contains
the information required to forward the packet within the
higher-level service chain.
</t>
<t>
State cannot be created by packets arriving from the lower-level
chain; when state cannot be found for such packets, they must be
dropped.
</t>
<t>
This stateful approach is limited to use with SFs that retain the
transport coordinates of the packet. This approach cannot be used
with SFs that modify those coordinates (e.g., NATs) or
otherwise create packets for new coordinates other than those
received (e.g., as an HTTP cache might do to retrieve content on
behalf of the original flow). In both cases, the fundamental
problem is the inability to forward packets when state cannot be
found for the packet transport-layer coordinates.
</t>
<t>
In the stateful approach, there are issues caused by having state, such
as how long the state should be maintained (it must time out
eventually), as well as whether the state needs to be replicated to
other devices to create a highly available network.
</t>
<t>
It is valid to consider the state to be disposable after failure, since it
can be re-created by each new packet arriving from the higher-level
domain. For example, if an IBN loses all flow state, the state is
re-created by an end-point retransmitting a TCP packet.
</t>
<t>
If an SFC domain handles multiple network regions (e.g., multiple
private networks), the coordinates may be augmented with additional
parameters, perhaps using some metadata to identify the network
region.
</t>
<t>
In this stateful approach, it is not necessary for the sub-domain's
control-plane to modify paths when higher-level paths are changed.
The complexity of the higher-level domain does not cause complexity
in the lower-level domain.
</t>
<t>
Since it doesn't depend on NSH in the lower domain,
this flow-stateful approach can be applied to translation methods
of converting NSH to other forwarding techniques.
(Refer to <xref target="section_other_forwarding"/>.)
</t>
</section>
<section title="Encoding Upper-Level Paths in Metadata">
<t>
An IBN can push the upper-level Service Path Identifier (SPI) and
Service Index (SI) (or encoding thereof) into a metadata field of
the lower-level encapsulation (e.g., placing upper-level path
information into a metadata field of NSH). When packets exit the
lower-level path, the upper-level SPI and SI can be restored from
the metadata retrieved from the packet.
</t>
<t>
This approach requires the SFs in the path to be capable of
forwarding the metadata and appropriately attaching metadata to any
packets injected for a flow.
</t>
<t>
Using new metadata may inflate packet size when variable-length
metadata (type 2 from <xref target="I-D.ietf-sfc-nsh">NSH</xref>)
is used.
</t>
<t>
It is conceivable that the MD-type 1 Mandatory Context Header fields
of <xref target="I-D.ietf-sfc-nsh">NSH</xref> are not all relevant
to the lower-level domain. In this case, one of the metadata slots
of the Mandatory Context Header could be repurposed within the
lower-level domain, and restored when leaving.
</t>
<t>
In this metadata approach, it is not necessary for the sub-domain's
control element to modify paths when higher-level paths are changed.
The complexity of the higher-level domain does not cause complexity
in the lower-level domain.
</t>
</section>
<section title="Using Unique Paths per Upper-Level Path" anchor="section_unique_paths">
<t>
In this approach, paths within the sub-domain are constrained so
that a SPI (of the sub-domain) unambiguously indicates the egress
SPI and SI (of the upper domain). This allows the original path
information to be restored at sub-domain egress from a look-up table
using the sub-domain SPI.
</t>
<t>
Whenever the upper-level domain provisions a path via the
lower-level domain, the lower-level domain controller must provision
corresponding paths to traverse the lower-level domain.
</t>
<t>
A down-side of this approach is that the number of paths in the
lower-level domain is multiplied by the number of paths in the
higher-level domain that traverse the lower-level domain.
I.e., a sub-path must be created for each combination of upper
SPI/SI and lower chain.
</t>
</section>
<section title="Nesting Upper-Level NSH within Lower-Level NSH">
<t>
In this approach, when packets arrive at the IBN in the top-level
domain, the classifier in the IBN determines the path for the
lower-level domain and pushes the new NSH header in front of the
original NSH header.
</t>
<t>
As shown in <xref target="fig_NSH_in_NSH"/>
the Lower-NSH Header used to forward packets in the lower-level
domain precedes the Upper-NSH Header from the top-level domain.
</t>
<figure anchor="fig_NSH_in_NSH"
title="Encapsulation of NSH within NSH">
<artwork align="center"><![CDATA[
+------------------+
| Overlay Header |
+------------------+
| Lower-NSH Header |
+------------------+
| Upper-NSH Header |
+------------------+
| Original Packet |
+------------------+
]]>
</artwork>
</figure>
<t>
The traffic with the above stack of two-layer-NSH header is to be
forwarded according to the Lower-NSH header in the lower-level SFC
domain. The Upper-NSH header is preserved in the packets but
not used for forwarding. At the last SFF of the
chain of the lower-level domain (which resides in the IBN),
the Lower-NSH header is removed from the packet, and then the packet
is forwarded by the IBN to an SFF of the upper-level domain,
which will be forwarded according to the Upper-NSH header.
</t>
<t>
With such encapsulation, Upper-NSH information is carried along the
extent of the lower-level chain without modification.
</t>
<t>
A benefit of this approach is that it does not require state in
the IBN or configuration to encode fields in meta-data.
</t>
<t>
However, the down-side is it does require SFs in
the lower-level domain to be able to parse multiple layers of NSH.
If the SF injects packets, it must also be able to deal with adding
appropriate multiple layers of headers to injected packets.
</t>
</section>
<section title="Stateful / Metadata Hybrid">
<t>
The basic idea of this approach is for the IBN to save upper domain
encapsulation information such that it can be retrieved by a
unique identifier, termed an "hSFC Flow ID". An example ID is
shown in <xref target="table_hybrid"/>.
</t>
<texttable title="Example Mapping of an hSFC Flow ID to Upper-Level Header"
anchor="table_hybrid">
<ttcol>hSFC Flow ID</ttcol>
<ttcol>SPI</ttcol>
<ttcol>SI</ttcol>
<ttcol>Context1</ttcol>
<ttcol>Context2</ttcol>
<ttcol>Context3</ttcol>
<ttcol>Context4</ttcol>
<c>1</c>
<c>45</c>
<c>254</c>
<c>100</c>
<c>2112</c>
<c>12345</c>
<c>7</c>
</texttable>
<t>
The ID is placed
in the metadata in NSH headers of the packet in the lower domain,
as shown in <xref target="fig_hybrid"/>.
When packets exit the lower domain, the IBN uses the ID to retrieve
the appropriate NSH encapsulation for returning the packet to the
upper domain.
</t>
<figure title="Storing hSFC Flow ID in lower-level metadata"
anchor="fig_hybrid">
<artwork align="center"><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver|O|C|R|R|R|R|R|R| Length | MD-type=0x1 | Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Path Identifer | Service Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| hSFC Flow ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mandatory Context Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mandatory Context Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mandatory Context Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
<t>
Advantages of this approach include:
<list style="symbols">
<t>Does not require state based on 5-tuple, so it works with
functions that change the IP addresses or ports of a packet
such as NATs,</t>
<t>Does not require all domains to have the same metadata scheme,</t>
<t>Can be used to restore any upper-domain information, not just
service path,</t>
<t>The lower domain only requires a single item of metadata
regardless of the number of items of metadata used in
the upper domain. (For MD-Type 1, this leaves 3 slots for
use in the lower domain.)</t>
<t>No special functionality is required of the SF, other than
the usual ability to preserve metadata and to apply
metadata to injected packets.</t>
</list>
</t>
<t>
Disadvantages include those of other stateful approaches,
including state timeout and replication mentioned in
<xref target="section_flow_stateful"/>.
</t>
<t>
There may be a large number of unique NSH encapsulations to be stored,
given that the hSFC Flow ID must represent all of the
bits in the upper-level encapsulation. This might consume
a lot of memory or create out-of-memory situations in which
IDs cannot be created or old IDs are discarded while still
in use.
</t>
</section>
</section>
<section title="Gluing Levels Together">
<t>
The SPI or metadata on a packet received by the IBN may be
used as input to reclassification and path selection within the
lower-level domain.
</t>
<t>
In some cases the meanings of the various path IDs and metadata must
be coordinated between domains.
</t>
<t>
One approach is to use well-known identifier values in metadata,
communicated by some organizational registry.
</t>
<t>
Another approach is to use well-known labels for chain identifiers or
metadata, as an indirection to the actual identifiers. The actual
identifiers can be assigned by control-plane systems. For example, a
sub-domain classifier could have a policy, "if pathID=classA then
chain packet to path 1234"; the higher-level controller would be
expected to configure the concrete higher-level pathID for classA.
</t>
</section>
<section title="Decrementing Service Index">
<t>
Because the IBN acts as a Service Function to the higher-level domain,
it must decrement the Service Index in the NSH headers of the
higher-level path.
</t>
<t>
A good strategy seems to be to do this when the packet is first received
by the IBN, before applying any of the strategies of
<xref target="section_strategies"/>, immediately prior to
classification.
</t>
</section>
</section>
<section title="Sub-domain Classifier" anchor="section_classifier">
<t>
Within the sub-domain (referring to <xref target="fig_hierarchical_lower"/>),
after the IBN removes higher-level encapsulation from incoming packets,
it sends the packets to the classifier, which selects the encapsulation
for the packet within the sub-domain.
</t>
<t>
One of the goals of the hierarchical approach is to make it easy to
have transport-flow-aware service chaining with bidirectional paths. For
example, it is desired that for each TCP flow, the client-to-server
packets traverse the same SFs as the server-to-client packets, but in
the opposite sequence. We call this bidirectional symmetry. If
bidirectional symmetry is required, it is the responsibility of the
control-plane to be aware of symmetric paths and configure the
classifier to chain the traffic in a symmetric manner.
</t>
<t>
Another goal of the hierarchical approach is to simplify the mechanisms
of scaling in and scaling out service functions.
All of the complexities of load-balancing among multiple SFs can be
handled within a sub-domain, under control of the classifier, allowing
the higher-level domain to be oblivious to the existence of multiple SF
instances.
</t>
<t>
Considering the requirements of bidirectional symmetry and
load-balancing, it is useful to have all packets entering a sub-domain
to be received by the same classifier or a coordinated cluster of
classifiers. There are both stateful and stateless approaches to
ensuring bidirectional symmetry.
</t>
</section>
<section title="Control Plane Elements">
<t>
Although control protocols have not yet been standardized,
from the point of view of hierarchical service function chaining we have
these expectations:
<list style="symbols">
<t>
Each control-plane instance manages a single level of hierarchy of a
single domain.
</t>
<t>
Each control-plane is agnostic about other levels of hierarchy. This
aspect allows humans to reason about the system within a single
domain and allows control-plane algorithms to use only domain-local
inputs. Top-level control does not need visibility to sub-domain
policies, nor does sub-domain control need visibility to
higher-level policies.
</t>
<t>
Sub-domain control-planes are agnostic about control-planes of other
sub-domains. This allows both humans and machines to manipulate
sub-domain policy without considering policies of other domains.
</t>
</list>
</t>
<t>
Recall that the IBN acts as an SF in the higher-level domain (receiving
SF instructions from the higher-level control-plane) and as a classifier
in the lower-level domain (receiving classification rules from the
sub-domain control-plane). In this view, it is the IBN that glues the
layers together.
</t>
<t>
The above expectations are not intended to prohibit network-wide
control. A control hierarchy can be envisaged to distribute information
and instructions to multiple domains and sub-domains. Control hierarchy
is outside the scope of this document.
</t>
</section>
<section title="Extension for Adopting to NSH-Unaware Service Functions"
anchor="section_other_forwarding">
<t>
The hierarchical approach can be used for dividing networks into NSH-aware
and NSH-unaware domains by converting NSH encapsulation to
other forwarding techniques (e.g., 5-tuple-based routing with OpenFlow),
as shown in <xref target="fig_dividing_chain_domains"/>.
</t>
<figure anchor="fig_dividing_chain_domains"
title="Dividing NSH-aware and NSH-unaware domains">
<artwork align="center"><![CDATA[
* * * * * * * * * * * * * * * * * *
* NSH-aware domain *
* +-------+ +-------+ *
* | SF#1 | | SF#5 | *
* +-o---o-+ +-o---o-+ *
* ^ | ^ | *
* +-|---|-+ +-|---|-+ *
* | |SFF| | | |SFF| | *
* +-|---|-+ +-|---|-+ *
* . | | . *
* +--+ / | | \ *
-->|CF|--' | | '------->
* +--+ v | *
* +---o-----------o---+ *
.*.*.*.*.| / | IBN | \ |*.*.*.
. +-o--o---------o--o-+ .
. | | ^ ^ .
. | +-+ +-+ | .
. +---+ v | +---+ .
. | +-o-----o-+ | .
. | | SF#2 | | .
. | +---------+ | .
. +--+ +--+ .
. | +---------+ | .
. v | v | .
. +-o---o-+ +-o---o-+ .
. | SF#3 | | SF#4 | .
. +-------+ +-------+ .
. NSH-unaware domain .
. . . . . . . . . . . . . . . . . .
]]>
</artwork>
<postamble>
SF#1 and SF#5 are NSH-aware and SF#2, SF#3 and SF#4 are
NSH-unaware. In the NSH-unaware domain, packets are conveyed
in a format supported by SFs which are deployed there.
</postamble>
</figure>
<section title="Purpose">
<t>
This approach is expected to facilitate service chaining in networks
in which NSH-aware and NSH-unaware SFs coexist.
Some examples of such situations are:
<list style="symbols">
<t>In a period of transition from legacy SFs to NSH-aware SFs and</t>
<t>Supporting multi-tenancy.</t>
</list>
</t>
</section>
<section title="Requirements for IBN">
<t>
In this usage, an IBN classifier is required to have an NSH
conversion table for applying packets to appropriate lower-level
paths and returning packets to the correct higher-level paths.
For example, the following methods would be
used for saving/restoring upper-level path information:
<list style="symbols">
<t>Saving SPI and SI in transport-layer flow state
(refer to <xref target="section_flow_stateful"/>) and</t>
<t> Using unique lower-level paths per upper-level NSH coordinates
(refer to <xref target="section_unique_paths"/>).</t>
</list>
</t>
<t>
Especially, the use of unique paths approach would be good for translating
NSH to a different forwarding technique in the lower level. A single
path in the upper level may be branched to multiple paths in the lower level
such that any lower-level path is only used by one upper-level path. This allows
unambiguous restoration to the upper-level path.
</t>
<t>
In addition, an IBN might be required to convert metadata contained in
NSH to the format appropriate to the packet in the lower-level path.
For example, some legacy SFs identify subscriber based on
information of network topology, such as VID, and IBN would be
required to create VLAN to packets from metadata if subscriber
identifier is conveyed as metadata in higher-level domains.
</t>
<t>
Other fundamental functions required as IBN (e.g., maintaining metadata of upper
level or decrementing Service Index) are same as normal usage.
</t>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The concept of Hierarchical Service Path Domains was introduced in
<xref target="I-D.homma-sfc-forwarding-methods-analysis"/>
as a means to improve scalability of service chaining in large networks.
</t>
<t>
The concept of nested NSH headers was introduced in
<xref target="I-D.ao-sfc-for-dc-interconnect"/>
as a means of creating hierarchical SFC in a data center.
</t>
<t>
The authors would like to thank the following individuals for
providing valuable feedback:
</t>
<t>
<list style="hanging">
<t> Ron Parker </t>
<t> Christian Jacquenet </t>
<t> Jie Cao </t>
</list>
</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>
Hierarchical service function chaining makes use of service chaining
architecture, and hence inherits the security considerations described
in the architecture document.
</t>
<t>
Furthermore, hierarchical service function chaining inherits security
considerations of the data-plane protocols (e.g., NSH) and control-plane
protocols used to realize the solution.
</t>
<t>
The systems described in this document bear responsibility for
forwarding internet traffic. In some cases the systems are responsible
for maintaining separation of traffic in private networks.
</t>
<t>
This document describes systems within different domains of
administration that must have consistent configurations in order to
properly forward traffic and to maintain private network separation.
Any protocol designed to distribute the configurations must be secure
from tampering.
</t>
<t>
All of the systems and protocols must be secure from modification by
untrusted agents.
</t>
<t>
Security considerations related to the control plane are discussed in
<xref target="I-D.ietf-sfc-control-plane"/>.
</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
&RFC7665;
&I-D.draft-ietf-sfc-nsh;
&I-D.draft-ietf-sfc-control-plane;
</references>
<references title="Informative References">
&I-D.draft-homma-sfc-forwarding-methods-analysis;
&I-D.draft-ietf-sfc-dc-use-cases;
&I-D.draft-ao-sfc-for-dc-interconnect;
</references>
<!-- Appendix -->
<section title="Examples of Hierarchical Service Function Chaining">
<t>
The advantage of hierarchical service function chaining compared with
normal or flat service function chaining is that it can reduce the
management complexity significantly. This section discusses examples
that show those advantages.
</t>
<section title="Reducing the Number of Service Function Paths">
<t>
In this case, hierarchical service function chaining is used to
simplify service function chaining management by reducing the number
of Service Function Paths.
</t>
<t>
As shown in <xref target="fig_example_flat"/>,
there are two domains, each with different concerns: a Security Domain
that selects Service Functions based on network conditions and an
Optimization Domain that selects Service Functions based on traffic
protocol.
</t>
<t>
In this example there are five security functions deployed in the Security Domain.
The Security Domain operator wants to enforce the five different security
policies, and the Optimization Domain operator wants to apply
different optimizations (either cache or video optimization) to each of
these two types of traffic. If we use flat SFC (normal branching), 10
SFPs are needed in each domain. In contrast, if we use hierarchical
SFC, only 5 SFPs in Security Domain and 2 SFPs in Optimization
Domain will be required, as shown in
<xref target="fig_example_hsfc"/>.
</t>
<t>
In the flat model, the number of SFPs is the product of the number of
functions in all of the domains. In the hSFC model, the number of SFPs
is the sum of the number of functions. For example, adding a "bypass"
path in the Optimization Domain would cause the flat model to require
15 paths (5 more), but cause the hSFC model to require one more path
in the Optimization Domain.
</t>
<figure anchor="fig_example_flat"
title="Flat SFC (normal branching)">
<artwork><![CDATA[
. . . . . . . . . . . . . . . . . . . . . . . . .
. Security Domain . . Optimization Domain .
. . . .
. +-1---[ ]----------------->[Cache ]------->
. | [ WAF ] . . .
. +-2-->[ ]----------------->[Video Opt.]---->
. | . . .
. +-3---[Anti ]----------------->[Cache ]------->
. | [Virus] . . .
. +-4-->[ ]----------------->[Video Opt.]---->
. | . . .
. +-5-->[ ]----------------->[Cache ]------->
[DPI]--->[CF]---| [ IPS ] . . .
. +-6-->[ ]----------------->[Video Opt.]---->
. | . . .
. +-7-->[ ]----------------->[Cache ]------->
. | [ IDS ] . . .
. +-8-->[ ]----------------->[Video Opt.]---->
. | . . .
. +-9-->[Traffic]--------------->[Cache ]------->
. | [Monitor] . . .
. +-10->[ ]--------------->[Video Opt.]---->
. . . . . . . . . . . . . . . . . . . . . . . . .
]]> </artwork>
<postamble>
The classifier must select paths that determine the combination of
Security and Optimization concerns. 1:WAF+Cache, 2:WAF+VideoOpt,
3:AntiVirus+Cache, 4:AntiVirus+VideoOpt, 5: IPS+Cache, 6:IPS+VideoOpt,
7:IDS+Cache, 8:IDS+VideoOpt, 9:TrafficMonitor+Cache,
10:TrafficMonitor+VideoOpt
</postamble>
</figure>
<figure anchor="fig_example_hsfc"
title="Simplified path management with Hierarchical SFC">
<artwork><![CDATA[
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. Security Domain . . Optimization Domain .
. . . .
[CF]---->[ [CF] IBN ]---------->[ [CF] IBN ]---->
. | ^ . . | ^ .
. +----->[ WAF ]-----+ . . +-->[ Cache ]---------+ .
. | | . . | | .
. +-->[Anti-Virus]---+ . . +-->[Video Opt]-------+ .
. | | . . .
. +----->[ IPS ]-----+ . . . . . . . . . . . . . . . .
. | | .
. +----->[ IDS ]-----+ .
. | | .
. +-->[ Traffic ]----+ .
. [ Monitor ] .
. . . . . . . . . . . . . . .
]]> </artwork>
</figure>
</section>
<section title="Managing a Distributed Data-Center Network">
<t>
Hierarchical service function chaining can be used to simplify
inter-data-center SFC management. In the example of
<xref target="fig_example_hsfc_inter_dc"/>,
shown below, there is a central data center (Central DC)
and multiple local data centers (Local DC#1, #2, #3)
that are deployed in a geographically distributed manner.
All of the data centers are under a single administrative domain.
</t>
<t>
The central DC may have some service functions that the local DC needs,
such that the local DC needs to chain traffic via the central DC.
This could be because:
<list style="symbols">
<t>
Some service functions are deployed as dedicated hardware
appliances, and there is a desire to lower the cost (both CAPEX
and OPEX) of deploying such service functions in all data centers.
</t>
<t>
Some service functions are being trialed,
introduced or otherwise handle a relatively small amount of
traffic. It may be cheaper to manage these service functions in a
single central data center and steer packets to the central data
center than to manage these service functions in all data centers.
</t>
</list>
</t>
<figure anchor="fig_example_hsfc_inter_dc"
title="Simplify inter-DC SFC management">
<artwork><![CDATA[
+-----------+
|Central DC |
+-----------+
^ ^ ^
| | |
.---|--|---|----.
/ / | | \
/ / | \ \
+-----+ / / | \ \ +-----+
|Local| | / | \ | |Local|
|DC#1 |--|--. | .----|----|DC#3 |
+-----+ | | | +-----+
\ | /
\ | /
\ | /
'----------------'
|
+-----+
|Local|
|DC#2 |
+-----+
]]>
</artwork>
</figure>
<t>
For large data center operators, one local DC may have tens of thousands of servers
and hundred of thousands of virtual machines. SFC can be used to manage user traffic.
For example, SFC can be used to classify user traffic based on service type, DDoS state etc.
</t>
<t>
In such large scale data center, using flat SFC
is very complex, requiring a super-controller to configure all data centers.
For example, any changes
to Service Functions or Service Function Paths in the central DC (e.g., deploying a new SF) would
require updates to all of the Service Function Paths in the local DCs accordingly.
Furthermore, requirements for symmetric paths add additional complexity when
flat SFC is used in this scenario.
</t>
<t>
Conversely, if using hierarchical SFC, each data center can be managed independently
to significantly reduce management complexity. Service Function Paths between
data centers can represent abstract notions without regard to details within data centers.
Independent controllers can be used for the top level (getting packets to pass the correct
data centers) and local levels (getting packets to specific SF instances).
</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 16:30:21 |