One document matched: draft-dolson-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 RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!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-01.xml">
<!ENTITY I-D.draft-ietf-sfc-nsh SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-sfc-nsh-00.xml">
<!ENTITY I-D.draft-ietf-sfc-architecture SYSTEM
"http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-sfc-architecture-07.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">
]>
<?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-dolson-sfc-hierarchical-00" ipr="trust200902">
<!-- ***** FRONT MATTER ***** -->
<front>
<title>Hierarchical Service Chaining</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>
<date month="May" year="2015" />
<!-- Meta-data Declarations -->
<area>Routing Area</area>
<workgroup>Service Function Chaining</workgroup>
<keyword>sfc</keyword>
<keyword>hierarchical</keyword>
<abstract>
<t>
This document describes a network architecture for deploying service
function chaining with multiple levels of administration within an
organization.
</t>
<t>
The multiple levels of administration allow operators to
compartmentalize a large network into multiple domains of
responsibility, with each domain being independently managed and
consequently easier to reason about.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
Service Function Chaining (SFC) allows an operator to prescribe packet
paths taken through their network. SFC is described in detail in the
<xref target="I-D.ietf-sfc-architecture">
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.
We expect asymmetrical routing is inherent in the network, while
recognizing that some Service Functions require bidirectional traffic
for transport-layer sessions. We expect some paths need to be selected
on the basis of application metadata accessible to the network, with
5-tuple stickiness to specific Service Function instances.
</t>
<t>
Difficult problems are often made easier by decomposing them in a
hierarchical (nested) manner. So instead of considering an omniscient
controller that can create complete paths from one end of the network to
the other, we break the network into smaller pieces. Each piece may
support a subset of the network applications or a subset of the users.
</t>
<t>
A previous example of simplifying a network by using multiple SF domains
can be seen in
<xref target="I-D.ietf-sfc-dc-use-cases">
draft-ietf-sfc-dc-use-cases
</xref>.
</t>
<t>
We assume the SF technology uses
<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 here 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 title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</section>
</section>
<section title="Hierarchical Service Chaining">
<t>
A hierarchy has multiple conceptual levels. In Hierarchical Service
Chaining, the top-most level encompasses the entire network domain to be
managed. Lower levels encompass smaller portions of the network.
</t>
<section title="Top Level">
<t>
Considering example <xref target="fig_hierarchical_top"/>, a top-level
network domain includes SFC 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
service function components.
</t>
<t>
Top-level service function paths carry packets from classifiers to
egress via SFFs and sub-domains, with the operations within
sub-domains being opaque to the higher levels.
</t>
<t>
Network-wide Service Chaining orchestration is only concerned
with creating service paths from network edge points to
sub-domains within data centers and configuring classifiers
at a coarse level (e.g., based on source or destination host) to get
traffic onto paths that will arrive at appropriate sub-domains. The
figure shows one possible service chain passing from edge, through
two sub-domains, to network egress.
</t>
<t>
At this high level, the number of SF Paths required is on the order of
the number of ways in which a packet needs to traverse different
sub-domains and egress the network.
</t>
<t>
It should be assumed that some service functions in the network
require bidirectional symmetry of paths (see more in section
<xref target="section_classifier"/>). Therefore the classifiers at the
top level need to ensure server-to-client packets take the reverse
path of client-to-server packet 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 to
SFF1 to SFF2 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 system unto itself.
</t>
<t>
Unlike the top level, however, data packets entering the sub-domain
are already encapsulated within SFC transport.
<xref target="fig_hierarchical_lower"/> shows a sub-domain interfaced
to a higher-level domain by means of an SF-Domain Gateway.
It is the purpose of the SF Domain Gateway to remove packets from the
SFC transport, apply Classification, and direct the packets to the
selected local service function paths ending back at the SF Domain
Gateway. The SF Domain Gateway finally restores packets to the
original SFC transport 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 SF Domain Gateway is concerned
with higher-level paths, but only those traversing the sub-domain.
The top-level controller configures top-level paths at the SF Domain
Gateway, but the top-level paths are otherwise unknown within the
sub-domain. The SF Domain Gateway provides adaptation between the
levels.
</t>
<figure anchor="fig_hierarchical_lower"
title="Sub-domain within a higher-level domain">
<artwork><![CDATA[
+----+ +-----+ +----------------------+ +-----+
| |SC#1| SFF | | SF Domain Gateway 1 | | SFF |
->| |================* *===============>
| | +-----+ | # (in DC 1) # | +-----+
| CF | | V # |
| | |+---+ +---+| Top domain
| | * * * * *||CF | * * * * * *|SFF|| * * * * *
| | * |+---+ +-+-+| *
+----+ * | | | | | | 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="SF Domain Gateway">
<t>
A network element termed "SF Domain Gateway" bridges packets between
domains. It looks like 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 SF Domain Gateway should be
making more granular traffic classifications at the lower level than the
traffic passed to it. This means that the number of SF Paths within the
lower level is larger than the number of SF Paths arriving to the
gateway.
</t>
<t>
The SF Domain Gateway is also the termination of lower-level SF paths.
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="SF Domain Gateway Path Configuration">
<t>
An operator of a lower-level SF Domain may be aware of which
high-level paths transit their domain, or they may wish to accept any
paths.
</t>
<t>
After exiting a path in the sub-domain, packets can be restored to an
upper-level SF path by these methods:
<list style="numbers">
<t>
Statefully per flow,
</t>
<t>
Pushing path identifier into meta-data,
</t>
<t>
Using unique lower-level paths per upper-level path.
</t>
</list>
</t>
<section title="Flow-Stateful SF Domain Gateway">
<t>
An SF Domain Gateway can be flow-aware, returning
packets to the correct higher-level SF path on the basis of 5-tuple
of packets exiting the lower-level SF paths.
</t>
<t>
When packets are received by the SF Domain Gateway on a higher-level
path, the encapsulated packets are parsed for IP and transport-layer
(TCP or UDP) coordinates. State is created, indexed by the 5-tuple
of {source-ip, destination-ip, source-port, destination-port and
transport protocol}. The state contains critical fields of the
encapsulating SFC header (or perhaps the entire header).
</t>
<t>
When a packet returns to the SF Domain Gateway 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 by the 5-tuple
of the packet. The state contains the information required to
forward the packet within the higher-level service chain.
</t>
<t>
In the stateful approach, there are issues caused by the state, such
as how long the state should be retained, 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 disposable, since it can be
re-created by each new packet arriving from the higher-level domain.
For example, if an SF-Domain Gateway loses all flow state, the state
is re-created by an end-point retransmitting a TCP packet.
</t>
<t>
If a network handles multiple routing domains, the 5-tuple may be
augmented with a 6th parameter, perhaps using some meta-data to
identify the routing domain.
</t>
<t>
In this stateful approach, it is not necessary for the sub-domain's
controller 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="Saving Upper-Level Path in Meta-Data">
<t>
An SF Domain Gateway can push the upper-level service path
identifier (SPI) and service index (SI) into a meta-data field of
the lower-level NSH encapsulation. When packets exit the lower-level
path, the upper-level SPI and SI can be restored from the meta-data
retrieved from the packet.
</t>
<t>
This approach requires the SFs in the path to be capable of
forwarding the meta-data and to appropriately apply meta-data to any
packets injected for a flow.
</t>
<t>
Using new meta-data may inflate packet size when variable-length
meta-data (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 meta-data slots of
the Mandatory Context Header could be repurposed within the
lower-level domain. (And restored when leaving.)
</t>
<t>
In this meta-data approach, it is not necessary for the sub-domain's
controller 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">
<t>
In this approach, paths within the sub-domain are constrained so
that a path identifier (of the sub-domain) unambiguously indicates
the egress path (of the upper domain).
</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 for each combination of upper Path identifier and
lower path.)
</t>
</section>
</section>
<section title="Gluing Levels Together">
<t>
The path identifier or metadata on a packet received by the SF Domain
Gateway 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 meta-data,
communicated by some organizational registry.
</t>
<t>
Another approach is to use well-known labels for path identifiers or
meta-data, as an indirection to the actual identifiers. The actual
identifiers can be assigned by control 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>
<section title="Sub-domain Classifier" anchor="section_classifier">
<t>
Within the sub-domain (referring to <xref target="fig_hierarchical_lower"/>),
after the SF Domain Gateway removes incoming packets from the
higher-level encapsulation, 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 tractable 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
classifier to be aware of symmetric paths and 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 to 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="Controllers">
<t>
Controllers have been mentioned in this document without being
explained. Although controllers have not yet been standardized, from the
point of view of hierarchical service chaining we have these
expectations:
<list style="symbol">
<t>
Each controller manages a single level of hierarchy.
</t>
<t>
Each controller is agnostic about other levels of hierarchy.
</t>
<t>
Sub-domain controllers are agnostic about controllers of other
sub-domains.
</t>
</list>
</t>
</section>
<section title="Summary">
<t>
The goals of the hierarchical SFC architecture are to make a large-scale
network easier to reason about, simpler to control and allow
independent domains of administration. This document has outlined an
approach that serves those goals, with some suggested approaches to
implementing the SF Domain Gateway.
</t>
</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">
draft-homma-sfc-forwarding-methods-analysis-01</xref>
as a means to improve scalability of service chaining in large networks.
</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 chaining makes use of service chaining
architecture, and hence inherits the security considerations described
in the architecture document.
</t>
<t>
Furthermore, hierarchical service 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>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
&RFC2119;
</references>
<references title="Informative References">
&I-D.draft-homma-sfc-forwarding-methods-analysis;
&I-D.draft-ietf-sfc-nsh;
&I-D.draft-ietf-sfc-architecture;
&I-D.draft-ietf-sfc-dc-use-cases;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:55:24 |