One document matched: draft-penno-sfc-packet-03.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<?rfc compact="no" ?>
<?rfc subcompact="no" ?>
<rfc category="std" docName="draft-penno-sfc-packet-03" ipr="trust200902">
<front>
<title abbrev="SFC packet reverse">Packet Generation in Service Function
Chains</title>
<author fullname="Reinaldo Penno" initials="R." surname="Penno">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>170 West Tasman Dr</street>
<code>CA</code>
<city>San Jose</city>
<country>USA</country>
</postal>
<email>repenno@cisco.com</email>
</address>
</author>
<author fullname="Carlos Pignataro" initials="C." surname="Pignataro">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>170 West Tasman Dr</street>
<code>CA</code>
<city>San Jose</city>
<country>USA</country>
</postal>
<email>cpignata@cisco.com</email>
</address>
</author>
<author fullname="Chui-Tin Yen" initials="C." surname="Yen">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>170 West Tasman Dr</street>
<city>San Jose</city>
<code>CA</code>
<country>USA</country>
</postal>
<email>tin@cisco.com</email>
</address>
</author>
<author fullname="Eric Wang" initials="E." surname="Wang">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>170 West Tasman Dr</street>
<city>San Jose</city>
<code>CA</code>
<country>USA</country>
</postal>
<email>ejwang@cisco.com</email>
</address>
</author>
<author fullname="Kent Leung" initials="K." surname="Leung">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>170 West Tasman Dr</street>
<city>San Jose</city>
<code>CA</code>
<country>USA</country>
</postal>
<email>kleung@cisco.com</email>
</address>
</author>
<author fullname="David Dolson" initials="D." surname="Dolson">
<organization>Sandvine</organization>
<address>
<postal>
<street>408 Albert Street</street>
<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>
</address>
</author>
<date day="29" month="April" year="2016"/>
<area>O&M</area>
<workgroup>SFC</workgroup>
<keyword>SFC</keyword>
<keyword>Chaining</keyword>
<keyword>Function</keyword>
<abstract>
<t>Service Functions (e.g., Firewall, NAT, Proxies and Intrusion
Prevention Systems) generate packets in the reverse flow direction to
the source of the current in-process packet/flow. In this document we
discuss and propose how to support this required functionality within
the SFC framework.</t>
</abstract>
<note 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>
</note>
</front>
<middle>
<section title="Introduction">
<t>Service Functions (e.g., Firewall, NAT, Proxies and Intrusion
Prevention Systems) generate packets in the reverse flow direction
destined to the source of the current in-process packet/flow.
In some cases, devices generate packets without any in-process packet.
Packet generation is a
basic intrinsic functionality and therefore needs to be supported in a
service function chaining deployment.</t>
</section>
<section title="Problem Statement">
<t>The challenge of this functionality in service chain environments is
that generated packets need to traverse in the reverse order the same
Service Functions traversed by original packet that triggered the packet
generation.</t>
<t>Although this might seem to be a straightforward problem, on further
inspection there are a few interesting challenges that need to be
solved. First and foremost a few requirements need to be met in order to
allow a packet to make its way through back to its source through the
service path:</t>
<t><list style="symbols">
<t>A symmetric path ID needs to exist. Symmetric path is discussed
in <xref target="SymmetricPaths"/></t>
<t>The SF needs to be able to encapsulate such error or proxy packets
in a encapsulation transport such as <xref
target="I-D.ietf-nvo3-vxlan-gpe">VXLAN-GPE </xref> + <xref
target="I-D.ietf-sfc-nsh">NSH header</xref></t>
<t>The SF needs to be able to determine, directly or indirectly, the
symmetric path ID and associated next service-hop index or,
alternatively, indicate reverse path for the service path ID in the
original packet</t>
</list></t>
</section>
<section title="Definitions and Acronyms">
<t>The reader should be familiar with the terms contained in <xref
target="I-D.ietf-sfc-nsh"/> ,<xref target="I-D.ietf-sfc-architecture"/>
and <xref target="I-D.ietf-nvo3-vxlan-gpe"/></t>
</section>
<section title="Assumptions">
<t>We make the following assumption throughout this document</t>
<t><list style="numbers">
<t>An SF could be connected to more than one SFF directly. In other
words, a SF can be multi-homed and each connection can use different
encapsulations.</t>
<t>After forwarding a packet to an SF, the SFF always has
connectivity to the next hop SFF to complete the path. This means
the following <xref target="fig_invalid"/> scenario is not permitted.
(SFF2 cannot complete the forward path which contains SFF3 and
potentially SFs connected to SFF3.)
<figure anchor="fig_invalid"
title="Arrangement not supported">
<artwork align="center"><![CDATA[
.-. .-.
/ \ / \
( SF1 ) ( SF2 )
\ / \ / \
`+' `+' \
| | \
| | \
+--+---+ +--+---+ \+------+
...---+ SFF1 +------+ SFF2 | | SFF3 +---...
+------+ +--+---+ +------+
|
|
+-----...
RSFP Forward -> SFF1 : SF1 : SFF1 : SFF2 : SF2 : SFF3 : ...]]></artwork>
</figure></t>
<t>Forward and reverse paths may be required to utilize different service
function forwarders. In the <xref target="fig_asym_sff"/> below, if
SF2 is directly connected to SFF2A and SFF2B, there could be a case
that SFF2A only has the forwarding rules for the forward path, and
SFF2B only has the forwarding rules for the reverse path.
<figure anchor="fig_asym_sff"
title="Supported SFF arrangement">
<artwork align="center"><![CDATA[ .-. .-. .-.
/ \ / \ / \
( SF1 ) ( SF2 ) ( SF3 )
\ /\ \ /\ \ /\
`+' \ `+' \ `+' \
| \ | \ | \
| | | | | |
+---+---+ | +-------+ | +---+---+ |
...---+ SFF1A +-|-----+ SFF2A +-|-----+ SFF3A +-|---...
+-------+ | +-------+ | +-------+ |
| | |
+---+---+ +---+---+ +---+---+
...---+ SFF1B +-------+ SFF2B +-------+ SFF3B +-----...
+-------+ +-------+ +-------+
Symmetric Paths:
RSFP Forward -> SFF1A : SF1 : SFF1A : SFF2A : SF2 :
SFF2A : SFF3A : SF3 : SFF3A ...
RSFP Reverse <- SFF1B : SF1 : SFF1B : SFF2B : SF2 :
SFF2B : SFF3B : SF3 : SFF3B
Asymmetric Paths (skipping SF2 on reverse):
RSFP Forward -> SFF1A : SF1 : SFF1A : SFF2A : SF2 : SFF2A :
SFF3A : SF3 : SFF3A ...
RSFP Reverse <- SFF1B : SF1 : SFF1B : SFF2B :
SFF3B : SF3 : SFF3B]]></artwork>
</figure></t>
</list></t>
<t>Assumption #2 allows an SF to always bounce a packet back to the
SFF that originally sent the packet. Due to #3, an SF has to
determine which SFF to send the generated packet to. It cannot treat
generated packet the same way as forwarded packet, as in #2.</t>
<t>These assumptions make sense for certain implementation. However,
some implementations are free of the constraints in #3, which will
simplify the SF logic in handling generated traffic.
</t>
</section>
<section title="Service Function Behavior">
<t>When a Service Function wants to send packets to the reverse
direction back to the source it needs to know the symmetric service path
ID (if it exists) and associated service index. This information is not
available to Service Functions since they do not need to perform a
next-hop service lookup. There are four recommended approaches to solve
this problem and we assume different implementations might make
different choices.</t>
<t><list style="numbers">
<t>The SF can receive service path forwarding information in the
same manner a SFF does.</t>
<t>The SF can send the packet in the forward direction but set
appropriate bits in the NSH header requesting a SFF to send the
packet back to the source</t>
<t>The classifier can encode all information the SF needs to send a
reverse packet in the metadata header</t>
<t>The controller uses a deterministic algorithm when creating the
associated symmetric path ID and service index.</t>
</list></t>
<t>We will discuss the ramifications of these approaches in the next
sections.</t>
<section title="SF receives Reverse Forwarding Information">
<t>This solution is easy to understand but brings a change on how
traditionally service functions operate. It requires SFs to receive
and process a subset of the information a SFF does. When a SF wants to
send a packet to the source, the SF uses information conveyed via the
control plane to impose the correct NSH header values.</t>
<t>Advantages:</t>
<t><list style="symbols">
<t>Changes are restricted to SF and controller, no changes to
SFF</t>
<t>Incremental deployment possible</t>
<t>No protocol between SF and SFF, which avoids interoperability
issues</t>
<t>No performance penalty on SFF due to in or out-of-band
protocol</t>
</list></t>
<t>Disadvantages:</t>
<t><list style="symbols">
<t>SFs need to process and understand Rendered Service Path
messages from controller</t>
</list></t>
<t>This solution can be characterized by putting the burden on the SF,
but that brings the advantage of being self-contained (as well as
providing a mechanism for other features). Also, many SFs have policy
or classification function which in fact makes them a classifier and
SF combination in practice.</t>
</section>
<section title="SF requests SFF cooperation">
<t>These solutions can be characterized by distributing the burden
between SF and SFF. In this section we discuss two possible in-band
solutions: using OAM header and using a reserved bit 'R' in the NSH
header.</t>
<section title="OAM Header">
<t>When the SF needs to send a packet in the reverse direction it
will set the OAM bit in the NSH header and use an OAM protocol <xref
target="I-D.penno-sfc-trace"> </xref> to request that the SFF impose
a new, reverse path NSH header. Post imposition, the SFF forwards
the packet correctly.</t>
<t><figure>
<preamble>SF Reverse Packet Request</preamble>
<artwork><![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|1|C|R|R|R|R|R|R| Length | MD-type=0x1 | OAM Protocol | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Service Path ID | Service Index | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Mandatory Context Header | |S
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F
| Mandatory Context Header | |C
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Mandatory Context Header | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Mandatory Context Header | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <
|Rev. Pkt Req | Original NSH headers (optional) | |O
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A
|M
/
]]></artwork>
<postamble>(postamble)</postamble>
</figure></t>
<t><list style="hanging">
<t hangText="Ver:">1</t>
<t hangText="OAM Bit:">1</t>
<t hangText="Length:">6</t>
<t hangText="MD-Type:">1</t>
<t hangText="Next Protocol:">OAM Protocol</t>
<t hangText="Rev. Pkt Req:">1 Reverse packet request</t>
</list></t>
<t>Advantages:</t>
<t><list style="symbols">
<t>SF does not need to process and understand control plane path
messages.</t>
<t>Clear division of labor between SF and SFF.</t>
<t>Extensible</t>
<t>Original NSH header could be carried inside OAM protocol
which leaves metadata headers available for SF-SFF
communication.</t>
</list></t>
<t>Disadvantages:</t>
<t><list style="symbols">
<t>SFFs need to process and understand a new OAM message
type</t>
<t>Possible interoperability issues between SF-SFF</t>
<t>SFF Performance penalty</t>
</list></t>
</section>
<section title="Service Function Forwarder Behavior">
<t/>
<t>In the case where the SF has all the information to send the
packet back to the origin no changes are needed at the SFF. When an
SF requests SFF cooperation the SFF MUST be able to process the OAM
message used to signal reverse path forwarding.</t>
<t><list style="symbols">
<t>Process/decode OAM message</t>
<t>Examine and act on any metadata present in the NSH header</t>
<t>Examine its forwarding tables and find the reverse path-id
and index of the next service-hop</t>
</list></t>
<t>The reverse path can be found in the Rendered Service Path Yang
model <xref target="RSPYang"/> that conveyed to the SFF when a path
is constructed.</t>
<t>If a SFF does not understand the OAM message it just forwards the
packet based on the original path-id and index. Since it is a
special OAM packet, it tells other SFFs and SFs that they should
process it differently. For example, a downstream intrusion
detection SF might not associate flow state with this packet.</t>
</section>
<section title="Reserved bit">
<t>In this solution the SF sets a reversed bit in the NSH that
carries the same semantic as in the OAM solution discussed
previously. This solution is simpler from a SF perspective but
requires allocating one of the reserved bits. Another issue is that
the metadata in the original packet might be overwritten by SFs or
SFFs in the path.</t>
<t>When a SFF receives a NSH packet with the reversed bit set, it
shall look up a preprogrammed table to map the Service Path ID and
Index in the NSH packet into the reverse Service Path ID and Index.
The SFF would then use the new reverse ID and Index pair to
determine the SF/SFF which is in the reverse direction.</t>
<t>Advantages:</t>
<t><list style="symbols">
<t>No protocol header overhead</t>
<t>Limited performance impact on SF</t>
</list></t>
<t>Disadvantages:</t>
<t><list style="symbols">
<t>Use of a reserved bit</t>
<t>SFF Performance penalty</t>
<t>Not extensible</t>
</list></t>
</section>
</section>
<section title="Classifier Encodes Information">
<t>This solution allows the Service Function to send a reverse packet
without interactions with the controller or SFF, therefore it is very
attractive. Also, it does not need to have the OAM bit set or use a
reserved bit. The penalty is that for a MD Type-1 packet a significant
amount of information (48 bits) need to be encoded in the metadata
section of the packet and this data cannot be overwritten. Ideally
this metadata would need to be added by the classifier.</t>
<t>The Rendered Service Path yang model <xref target="RSPYang"/>
already provides all the necessary information that a classifier would
need to add to the metadata header. An explanation of this method is
better served with an examples.</t>
<section title="Symmetric Service Paths"
anchor="section_symmetric">
<t><xref target="fig_example_sym"/> below shows a simple SFC with
symmetric service paths comprising three SFs.
</t>
<t><figure anchor="fig_example_sym"
title="SFC example with symmetric path">
<artwork><![CDATA[.....................SFP2 Forward........................>
Forward SI 253 252 251
+---+ .-. .-. .-. +---+
| | / \ / \ / \ | |
| A +-------( SF1 )------( SF2 )------( SF3 )----------+ B |
| | \ / \ / \ / | |
+---+ `-' `-' `-' +---+
Reverse SI 253 254 255
<....................SFP3 (Reverse of SFP2)....................
SFP2 Forward -> SF1 : SF2 : SF3
SFP3 Reverse <- SF1 : SF2 : SF3
RSP2 Forward -> SF1 : SF2 : SF3
RSP3 Reverse <- SF1 : SF2 : SF3]]></artwork>
</figure></t>
<t>Below we see the JSON objects of the two symmetric paths depicted
above.</t>
<t/>
<t><figure>
<artwork><![CDATA[RENDERED_SERVICE_PATH_RESP_JSON = """
{
"rendered-service-paths": {
"rendered-service-path": [
{
"name": "SFC1-SFP1-Path-2-Reverse",
"transport-type": "service-locator:vxlan-gpe",
"parent-service-function-path": "SFC1-SFP1",
"path-id": 3,
"service-chain-name": "SFC1",
"starting-index": 255,
"rendered-service-path-hop": [
{
"hop-number": 0,
"service-index": 255,
"service-function-forwarder-locator": "eth0",
"service-function-name": "SF3",
"service-function-forwarder": "SFF3"
},
{
"hop-number": 1,
"service-index": 254,
"service-function-forwarder-locator": "eth0",
"service-function-name": "SF2",
"service-function-forwarder": "SFF2"
},
{
"hop-number": 2,
"service-index": 253,
"service-function-forwarder-locator": "eth0",
"service-function-name": "SF1",
"service-function-forwarder": "SFF1"
}
],
"symmetric-path-id": 2
},
{
"name": "SFC1-SFP1-Path-2",
"transport-type": "service-locator:vxlan-gpe",
"parent-service-function-path": "SFC1-SFP1",
"path-id": 2,
"service-chain-name": "SFC1",
"starting-index": 253,
"rendered-service-path-hop": [
{
"hop-number": 0,
"service-index": 253,
"service-function-forwarder-locator": "eth0",
"service-function-name": "SF1",
"service-function-forwarder": "SFF1"
},
{
"hop-number": 1,
"service-index": 252,
"service-function-forwarder-locator": "eth0",
"service-function-name": "SF2",
"service-function-forwarder": "SFF2"
},
{
"hop-number": 2,
"service-index": 251,
"service-function-forwarder-locator": "eth0",
"service-function-name": "SF3",
"service-function-forwarder": "SFF3"
}
],
"symmetric-path-id": 3
}
]
}
}"""
]]></artwork>
</figure></t>
<t>We will assume the classifier will encode the following
information in the metadata:</t>
<t><list style="symbols">
<t>symmetric path-id = 2 (24 bits)</t>
<t>symmetric starting index = 253 (8 bits)</t>
<t>symmetric number of hops = 3 (8 bits)</t>
<t>starting index = 255 (8 bits)</t>
</list></t>
<t>In the method below we will assume SF will generate a reverse
packet after decrementing the index of the current packet. We will
call that current index.</t>
<t>If SF1 wants to generate a reverse packet it can find the
appropriate index by applying the following algorithm:</t>
<t><figure>
<artwork><![CDATA[current_index = 252
remaining_hops = symmetric_number_hops - (starting_index - current_index)
remaining_hops = 3 - (255 - 252) = 0
reverse_service_index = symmetric_starting_index - remaining_hops - 1
reverse_service_index = next_service_hop_index = 253 - 0 - 1 = 252
The "-1" is necessary for the service index to point to the next service_hop.]]></artwork>
</figure></t>
<t>If SF2 wants to send reverse packet:</t>
<t><figure>
<artwork><![CDATA[current index = 253
remaining_hops = 3 - (255 - 253) = 1
reverse_service_index = next_service_hop_index = 253 - 1 - 1 = 251]]></artwork>
</figure></t>
<t>If SF3 wants to send reverse packet:</t>
<t><figure>
<artwork><![CDATA[current index = 254
remaining_hops = 3 - (255 - 254) = 2
reverse_service_index = next_service_hop_index = 253 - 2 - 1 = 250]]></artwork>
</figure></t>
<t>The following tables in <xref target="fig_index_tables"/> summarize
the service indexes as calculated by each SF in the forward and
reverse paths respectively.
</t>
<t><figure anchor="fig_index_tables"
title="Service indexes generated by each SF in the
symmetric forward and reverse paths">
<artwork><![CDATA[Fwd SI = forward Service Index
Cur SI = Current Service Index
Gen SI = Service Index for Generated packets
RSFP1 Forward -
Number of Hops: 3
Forward Starting Index: 253
Reverse Starting Index: 255
+-------+--------+--------+--------+
| SF | SF1 | SF2 | SF3 |
+-------+--------+--------+--------+
|Fwd SI | 253 | 252 | 251 |
+-------+--------+--------+--------+
|Cur SI | 252 | 251 | 250 |
+-------+--------+--------+--------+
|Gen SI | 252 | 253 | 254 |
+-------+--------+--------+--------+
RSFP1 Reverse -
Number of Hops: 3
Reverse Starting Index: 255
Forward Starting Index: 253
+-------+--------+--------+--------+
| SF | SF1 | SF2 | SF3 |
+-------+--------+--------+--------+
|Rev SI | 253 | 254 | 255 |
+-------+--------+--------+--------+
|Cur SI | 252 | 253 | 254 |
+-------+--------+--------+--------+
|Gen SI | 252 | 251 | 250 |
+-------+--------+--------+--------+]]></artwork>
</figure></t>
</section>
<section title="Symmetric Service Paths, Optimized"
anchor="section_symmetric_paths_optimized">
<t>
This approach is effectively the same as <xref
target="section_symmetric"/>, but with redundant
information removed such that the reverse-path information
can be packed into 32 bits. This approach is obtained by
observing that the same arithmetic is always done on the
same constants of starting_index, symmetric_starting_index
and symmetric_number_hops.
</t>
<t>
As before, we require symmetric paths, meaning there are
two paths that are exactly the reverse of each other. We
assume that the classifier at each end has available the
following information:
</t>
<t><list style="symbols">
<t>symmetric path-id (24 bits)</t>
<t>starting index (8 bits)</t>
<t>symmetric starting index (8 bits)</t>
<t>symmetric number of hops, which is the same in both
directions (8 bits)</t>
</list></t>
<t>
The classifier computes, for each path, a "reverse service offset":
</t>
<figure>
<artwork align="center"><![CDATA[
# Compute using 8-bit, two's-complement arithmetic:
# (Overflow or underflow are okay)
reverse_service_offset = symmetric_starting_index
+ starting_index
- symmetric_number_of_hops
]]></artwork>
</figure>
<t>
This reverse_service_offset is an 8-bit value that is
encoded in metadata along with the 24 bits of
reverse_path_id.
</t>
<figure title="Metadata format of reverse_info_metadata (32 bits)">
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Reverse |
| Reverse Path ID | Service |
| | Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<t>
We'll refer to the 32-bit value as
reverse_info_metadata. Any Service Function may compute
the NSH fields of a reverse packet as follows from
the NSH fields of a forward packet.
</t>
<figure>
<artwork align="center"><![CDATA[
reverse.NSH.Service_Path_ID =
forward.NSH.reverse_info_metadata.Reverse_Path_ID
# Compute using 8-bit two's-complement arithmetic:
# (Overflow or underflow are okay)
reverse.NSH.Service_Index :=
forward.NSH.reverse_info_metadata.Reverse_Service_Offset
- forward.NSH.Service_Index - 1
reverse.NSH.reverse_info_metadata.Reverse_Service_Offset =
forward.NSH.reverse_info_metadata.Reverse_Service_Offset
reverse.NSH.reverse_info_metadata.Reverse_Path_ID =
forward.NSH.Service_Path_ID
]]></artwork>
</figure>
<t>
As you can see, this approach has the convenient property
that the reverse_info_metadata can be determined by a
Service Function while being agnostic about both forward
and reverse paths.
</t>
<t>
Using the example of <xref target="section_symmetric"/>,
these values are used for the SFP2 Forward path:
<list style="symbols">
<t>starting_index=253</t>
<t>symmetric_starting_index=255</t>
<t>symmetric_number_of_hops=3</t>
<t>reverse_service_offset=(253+255-3)=249 in 8-bit two's complement arithmetic</t>
</list>
</t>
<t>
At SF2 on the SFP2 Forward path, where the service index
is 251 after decrementing the index, the reverse service index is calculated as:
<list style="symbols">
<t>reverse_service_index = 249-251-1 = 253 using 8-bit two's complement arithmetic</t>
</list>
This is the correct index to forward to SF1 on SFP3.
</t>
</section>
<section title="Analysis">
<t/>
<t>Advantages of encoding information in the NSH frame:</t>
<t><list style="symbols">
<t>SF does not need to request SFF cooperation or contact
controller</t>
<t>No SFF performance impact</t>
</list></t>
<t>Disadvantages:</t>
<t><list style="symbols">
<t>Metadata overhead in case MD-Type 2 is used or use of
a metadata slot in case MD-Type 1 is used.</t>
<t>Relies on classifier to encode metadata
information</t>
<t> Requires perfectly symmetrical paths. E.g., one direction
cannot have more SFs than the other direction.</t>
<t>If classifier will encode information it needs to receive and
process rendered service path information</t>
</list></t>
</section>
</section>
<section title="Algorithmic Reversed Path ID Generation">
<t>In these proposals no extra storage is required from the NSH and
SFF does not need to know how to handle the reversed packet nor does
it know about it. Reverse Path is programmed by Orchestrator and used
by SF having the need to send upstream traffic.</t>
<section title="Same Path-ID and Disjoint Index Spaces">
<t>Instead of defining a new Service Path ID, the same Service Path
ID is used. The Orchestrator must define the reverse chain of
service using a different range of Service Path Index. It is also
assumed that the reverse packet must go through the same number of
Services as its forward path. It is proposed that Service Path Index
(SPI) 1..127 and 255..129 are the exact mirror of each other.</t>
<t>Here is an example: SF1, SF2, and SF3 are identified using
Service Path Index (SPI) 8, 7 and 6 respectively.</t>
<t>Path 100 Index 8 - SF1</t>
<t>Path 100 Index 7 - SF2</t>
<t>Path 100 Index 6 - SF3</t>
<t>Path 100 Index 5 - Terminate</t>
<t>At the same time, Orchestrator programs SPI 248, 249 and 250 as
SF1, SF2 and SF3. Orchestrator also programs SPI 247 as "terminate".
Reverse-SPI = 256 - SPI.</t>
<t>Path 100 Index 247 - Terminate</t>
<t>Path 100 Index 248 (256 - 8) - SF1</t>
<t>Path 100 Index 249 (256 - 7) - SF2</t>
<t>Path 100 Index 250 (256 - 6) - SF3</t>
<t>If SF3 needs to send the packet in reverse direction, it
calculates the new SPI as 256 - 6 (6 is the SPI of the packet) and
obtained 250. It then subtract the SPI by 1 and send the packet back
to SFF</t>
<t>Subsequently, SFF received the packet and sees the SPI 249. It
then diverts the packet to SF2, etc. Eventually, the packet SPI will
drop to 247 and the SFF will strip off the NSH and deliver the
packet.</t>
<t>The same mechanism works even if SF1 later decided to send back
another upstream packet. The packet can ping-pong between SF1 and
SF3 using existing mechanism.</t>
<t>Note that this mechanism is a special case of
<xref target="section_symmetric_paths_optimized"/>
wherein Reverse_Path_ID is the forward path ID and
Reverse_Service_Offset=255.
</t>
<t>Advantages:</t>
<t><list style="symbols">
<t>No precious NSH area is consumed</t>
<t>SF self-contained solution</t>
<t>No SFF performance impact and no cooperation needed</t>
<t>No Special Classification required</t>
</list></t>
<t>Disadvantages:</t>
<t><list style="symbols">
<t>SPI range is reduced and may become incompatible with
existing topology</t>
<t>Assumption that the reverse path Service Functions are the
same as forward path, only in reverse</t>
<t>Reverse paths need to use Service Index = 128 for loop
detection instead of SI = 0.</t>
</list></t>
<t>In either case, the SF must have the knowledge through
Orchestrator that the reverse path has been programmed and the
method (SPI only or SPI + SPID bit) to use.</t>
<t>The symmetrization mechanism keep reverse path symmetric as
described in section 6 can be applied in this method as well.</t>
</section>
<section title="Flip Path-Id and Index High Order bits">
<t>An alternative to reducing Service Path Index range is to make
use of a different Service Path ID, e.g. the most significant bit.
The bit can be flipped when the SF needs to send packet in reverse.
However, the negation of the SPI is still required, e.g. SPI 6
becomes SPI 134</t>
<t>This approach is fully compatible with the current NSH protocol
standard and provides a fully deterministic way of determining
reverse paths. It is the recommended approach.</t>
<t>Advantages:</t>
<t><list style="symbols">
<t>No precious NSH area is consumed</t>
<t>SF self-contained solution</t>
<t>No SFF performance impact and no cooperation needed</t>
<t>No Special Classification required</t>
</list></t>
<t>Disadvantages:</t>
<t><list style="symbols">
<t>Assumption that the reverse path Service Functions are the
same as forward path, only in reverse</t>
<t> Forward and Reverse Path IDs are algorithmically linked and
can not be chosen arbitrarily. </t>
</list></t>
<!-- FIXME This "recommended approach" has the least information of any solution.
It needs to be precisely explained, advantages/disadvantages provided.
-->
</section>
</section>
</section>
<section title="Asymmetric Service Paths">
<t>In real world the forward and reverse paths can be asymmetric,
comprising different set of SFs or SFs in different orders. The
following <xref target="fig_asym"/> illustrates an example. The forward
path is composed of SF1, SF2, SF4 and SF5, while the reverse path skips
SF5 and has SF3 in place of SF2.
</t>
<t><figure title="SFC example with asymmetric paths"
anchor="fig_asym">
<artwork><![CDATA[ .......... .........
. . . .
. 249 . . 246 .
. . . .
. .-. .. .-. .
.............. / \ / \ ....SFP1 Forward....>
( SF2 ) 247 ( SF5 )
Forward SI 250 / \ / \ / \ /\
/ `-' \ / `-' \
/ \ / \
+---+ .-./ `-./ \ +---+
| | / \ / \ \ | |
| A +-------( SF1 )----------( SF4 )-------------+-------------+ B |
| | \ / \ / | |
+---+ `-'\ ,-' +---+
\ /
\ .-. /
Reverse SI 251 \ / \ / 254
<........... ( SF3 ) .................SFP2 Reverse.....
. \ / .
. `-' .
. .
. .
. 253 .
..............
SFP1 Forward -> SF1 : SF2 : SF4 : SF5
SFP2 Reverse <- SF1 : SF3 : SF4
]]></artwork>
</figure></t>
<t/>
<t>An asymmetric SFC can have completely independent forward and reverse
paths. An SF’s location in the forward path can be different from
that in the reverse path. An SF may appear only in the forward path but
not reverse (and vice-versa). In order to use the same algorithm to
calculate the service index generated by an SF, one design option is to
insert special NOP SFs in the rendered service paths so that each SF is
positioned symmetrically in the forward and reverse rendered paths. The
SFP corresponding to the example above is:</t>
<t>SFP1 Forward -> SF1 : SF2 : NOP : SF4 : SF5</t>
<t>SFP2 Reverse <- SF1 : NOP : SF3 : SF4 : NOP</t>
<t>The NOP SF is assigned with a sequential service index the same way
as a regular SF. The SFF receiving a packet with the service path ID and
service index corresponding to a NOP SF should advance the service index
till the service index points to a regular SF. Implementation can use a
loopback interface or other methods on the SFF to skip the NOP SFs.</t>
<t>Once the NOP SF is inserted in the rendered service paths, the
forward and reverse paths become symmetric. The same algorithm can be
applied by the SFs to generate service indexes in the opposite
directional path. The following tables list the service indexes
corresponding to the example above.</t>
<t/>
<t><figure>
<artwork><![CDATA[Fwd SI = forward Service Index
Cur SI = Current Service Index
Gen SI = Service Index for Generated packets
RSP1 Forward -
Number of hops: 5
Forward Starting Index: 250
Reverse Starting Index: 255
+-------+--------+--------+--------+--------+--------+
| SF | SF1 | SF2 | NOP | SF4 | SF5 |
+-------+--------+--------+--------+--------+--------+
|Fwd SI | 250 | 249 | 248 | 247 | 246 |
+-------+--------+--------+--------+--------+--------+
|Cur SI | 249 | 248 | 247 | 246 | 245 |
+-------+--------+--------+--------+--------+--------+
|Gen SI | 250 | 251 | N/A | 253 | 254 |
+-------+--------+--------+--------+--------+--------+
RSP1 Reverse -
Number of hops: 5
Reverse Starting Index: 255
Forward Starting Index: 250
+-------+--------+--------+--------+--------+--------+
| SF | SF1 | NOP | SF3 | SF4 | NOP |
+-------+--------+--------+--------+--------+--------+
|Rev SI | 251 | 252 | 253 | 254 | 255 |
+-------+--------+--------+--------+--------+--------+
|Cur SI | 250 | 251 | 252 | 253 | 254 |
+-------+--------+--------+--------+--------+--------+
|Gen SI | 249 | N/A | 247 | 246 | N/A |
+-------+--------+--------+--------+--------+--------+]]></artwork>
</figure></t>
<t>This symmetrization of asymmetric paths could be performed by a
controller during path creation.</t>
</section>
<section title="Metadata">
<t>A crucial consideration when generating a packet is which metadata
should be included in the context headers. In some scenarios if the
metadata is not present the packet will not reach its intended
destination. Although one could think of many different ways to convey
this information, we believe the solution should be simple and require
little or no new Service Function functionality.</t>
<t>We assume that a Service Function normally needs to know the
semantics of the context headers in order to perform its functions. But
clearly knowing the semantics of the metadata is not enough. The issue
is that although the SF knows the semantics of the metadata when it
receives a packet, it might not be able to generate or retrieve the
correct metadata values to insert in the context headers when generating
a packet. It is usually the classifier that inserts the metadata in the
context headers.</t>
<section title="Service-Path-Invariant Metadata">
<t>In order to solve this problem we propose the notion of
service-path-invariant metadata. This is metadata that is the same for
all packets traversing a certain path. For example, if all packets
exiting a service-path need to be routed to a certain VPN, the VPN id
would be a path-invariant metadata.
</t>
<t>
To implement this, the controller needs to configure appropriate fixed
values of the metadata present in the context headers for each path
identifier in each Service Function that needs to inject packets.
The Service Function must store this information so that
when the Service Function generates a
packet it can insert the minimum required metadata for a packet to reach
its destination.
</t>
<t>
A disadvantage to path-invariant metadata is that it is a type of
metadata that adds no information beyond the information available in
the path identifier itself. The corollary is that if different
metadata is required, a different service paths must be created.
</t>
</section>
<section title="Service-Path-Default Metadata">
<t>
We also propose the notion of service-path-default metadata. This is
metadata that could vary for different packets on a path but has a
default value acceptable for any packet injected onto a certain path.
For example, metadata might indicate a quality-of-service (QoS)
treatment, and an operator considers it acceptable for injected
packets to have a default QoS treatment.
It might also be considered acceptable to not send a particular type
of metadata.
</t>
<t>
To implement this, the controller configures appropriate default metadata
values for each path identifier in Service Functions that need to
inject packets. The controller may also indicate a particular type
may be omitted.
The Service Function must store this information so that it can insert
the minimum required metadata for a packet to reach its destination.
</t>
<t>
The disadvantage of this approach is that it relies on the assumption
that there is a meaningful default metadata value, which may not
exist.
</t>
</section>
<section title="Bidirectional Clonable Metadata">
<t>
Some types of metadata may use values applicable to both directions
of traffic. An example is routing domain, for which an identifier
indicates a private network such that the value is the same for
both directions of traffic and may be copied from one packet to
another.
</t>
<t>
To implement this, the controller must indicate to each Service
Function that a particular metadata type is bidirectional-clonable.
The Service Function can therefore clone the metadata value from one
packet to a new packet that it creates, even in the reverse direction.
For this type, it is also considered safe to save a copy of metadata
for the transport flow. (E.g., to retransmit a TCP packet using
metadata cloned from another TCP packet of the same connection.)
</t>
<t>
Note that the Service Function need not know the meaning of the
metadata; it just needs to know it is safe to clone in this manner.
</t>
</section>
<section title="Unidirectional Clonable Metadata">
<t>
Some types of metadata may use values applicable to only one
direction of traffic, but a value may be cloned from one packet to
another in the same direction. An example is a destination identifier,
in which meatadata indicates a network egress point. Another example
is metadata indicating a property of either the source or destination
end-point of the packet.
</t>
<t>
To implement this, the controller must indicate to each Service
Function that a particular metadata type is unidirectional-clonable.
A transport-layer-stateful Service Function can therefore save away
metadata values that it has witnessed. An injected packet can
therefore be assigned a clone of metadata taken from an earlier packet
going in the same direction.
For example, a Service Function can send a TCP packet using metadata
cloned from another TCP packet of the same connection and direction.
</t>
<t>
Note that the Service Function need not know the meaning of the
metadata; it just needs to know it is safe to clone in this manner.
</t>
<t>
A disadvantage of unidirectional clonable metadata is that a device
cannot respond to a packet unless it has previously witnessed a packet
for the same connection in the opposite direction.
For example, a firewall cannot respond to the first packet of a
connection (since both directions have not been witnessed).
However, having seen a full hand-shake, a cache or optimizing proxy
can inject or retransmit packets.
</t>
</section>
<section title="Service-Function-Mastered Metadata">
<t>
The easiest case to reason about is a type of metadata for which the
Service Function can provide the appropriate values: specifically the
metadata that it would be responsible for inserting for all packets as
part of packet processing. We can assume this is configured by
Service-Function-Specific methods.
</t>
</section>
<section title="Metadata from Reclassification">
<t>Finally if the packet needs crucial metadata values that cannot be
supplied by the methods above then a reclassification is needed.
This reclassification would need to be done by the classifier that would
normally process packets in the reverse path or a SFF that had the same
rules and capabilities. Ideally the first SFF that processes the
generated packet.</t>
<t> If a packet needs to be sent to classifier then it should be carried
inside a NSH OAM packet that in turn is tunneled with a protocol
such as VXLAN-GPE with the classifier as its tunnel endpoint.</t>
<!--
FIXME: how is this made to happen? Does the packet go back to the start
of the chain?
-->
</section>
</section>
<section title="Other solutions">
<t>We explored other solution that we deemed too complex or that would
bring a severe performance penalty:</t>
<t><list style="symbols">
<t>An out-of-band request-response protocol between SF-SFF. Given
that some service functions need to be able to generate packets
quite often this will would create a considerable performance
penalty. Specially given the fact that path-ids (and their symmetric
counterpart) might change and SF would not be notified, therefore
caching benefits will be limited.</t>
<t>An out-of-band request-response protocol between SF-Controller.
Given that admin or network conditions can trigger service path
creation, update or deletions a SF would not be aware of new path
attributes. The controller should be able to push new information as
it becomes available to the interested parties.</t>
<t>SF (or SFF) punts the packet back to the controller. This
solution obviously has severe scaling limitations.</t>
</list></t>
</section>
<section title="Implementation">
<t>The solutions "Flip Path-Id and Index High Order bits" and
"SF receives Reverse Forwarding Information" were
implemented in Opendaylight.</t>
</section>
<section title="IANA Considerations">
<t>TBD</t>
</section>
<section title="Security Considerations">
<t>
Service Functions must be trusted entities, being permitted to
rewrite service path headers.
</t>
</section>
<section title="Acknowledgements">
<t>Paul Quinn, Jim Guichard</t>
</section>
<section title="Changes">
<t/>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.2616"?>
</references>
<references title="Informative References">
<?rfc include="reference.I-D.ietf-sfc-architecture"?>
<?rfc include="reference.I-D.penno-sfc-yang"?>
<?rfc include="reference.I-D.ietf-sfc-nsh"?>
<?rfc include="reference.I-D.ietf-nvo3-vxlan-gpe"?>
<?rfc include="reference.I-D.penno-sfc-trace"?>
<reference anchor="RSPYang"
target="https://github.com/opendaylight/sfc/blob/master/sfc-model/src/main/yang/rendered-service-path.yang">
<front>
<title>Rendered Service Path Yang Model</title>
<author fullname="Opendaylight" surname="Opendaylight">
<organization>Opendaylight</organization>
</author>
<date month="February" year="2011"/>
</front>
</reference>
<reference anchor="SymmetricPaths"
target="https://tools.ietf.org/html/draft-ietf-sfc-architecture-11#section-2.2">
<front>
<title>Symmetric Paths</title>
<author fullname="IETF" surname="IETF">
<organization>Opendaylight</organization>
</author>
<date month="February" year="2011"/>
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:40:12 |