draft-ietf-bess-nsh-bgp-control-plane-13.txt   draft-ietf-bess-nsh-bgp-control-plane-14.txt 
BESS Working Group A. Farrel BESS Working Group A. Farrel
Internet-Draft Old Dog Consulting Internet-Draft Old Dog Consulting
Intended status: Standards Track J. Drake Intended status: Standards Track J. Drake
Expires: June 15, 2020 E. Rosen Expires: December 4, 2020 E. Rosen
Juniper Networks Juniper Networks
J. Uttaro J. Uttaro
AT&T AT&T
L. Jalil L. Jalil
Verizon Verizon
December 13, 2019 June 2, 2020
BGP Control Plane for NSH SFC BGP Control Plane for the Network Service Header in Service Function
draft-ietf-bess-nsh-bgp-control-plane-13 Chaining
draft-ietf-bess-nsh-bgp-control-plane-14
Abstract Abstract
This document describes the use of BGP as a control plane for This document describes the use of BGP as a control plane for
networks that support Service Function Chaining (SFC). The document networks that support Service Function Chaining (SFC). The document
introduces a new BGP address family called the SFC AFI/SAFI with two introduces a new BGP address family called the SFC Address Family
route types. One route type is originated by a node to advertise Identifier / Subsequent Address Family Identifier (SFC AFI/SAFI) with
two route types. One route type is originated by a node to advertise
that it hosts a particular instance of a specified service function. that it hosts a particular instance of a specified service function.
This route type also provides "instructions" on how to send a packet This route type also provides "instructions" on how to send a packet
to the hosting node in a way that indicates that the service function to the hosting node in a way that indicates that the service function
has to be applied to the packet. The other route type is used by a has to be applied to the packet. The other route type is used by a
Controller to advertise the paths of "chains" of service functions, Controller to advertise the paths of "chains" of service functions,
and to give a unique designator to each such path so that they can be and to give a unique designator to each such path so that they can be
used in conjunction with the Network Service Header defined in RFC used in conjunction with the Network Service Header defined in RFC
8300. 8300.
This document adopts the SFC architecture described in RFC 7665. This document adopts the SFC architecture described in RFC 7665.
skipping to change at page 1, line 48 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 4, 2020.
This Internet-Draft will expire on June 15, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Overview of Service Function Chaining . . . . . . . . . . 6 2.1. Overview of Service Function Chaining . . . . . . . . . . 6
2.2. Control Plane Overview . . . . . . . . . . . . . . . . . 8 2.2. Control Plane Overview . . . . . . . . . . . . . . . . . 8
3. BGP SFC Routes . . . . . . . . . . . . . . . . . . . . . . . 11 3. BGP SFC Routes . . . . . . . . . . . . . . . . . . . . . . . 12
3.1. Service Function Instance Route (SFIR) . . . . . . . . . 12 3.1. Service Function Instance Route (SFIR) . . . . . . . . . 13
3.1.1. SFIR Pool Identifier Extended Community . . . . . . . 13 3.1.1. SFIR Pool Identifier Extended Community . . . . . . . 14
3.1.2. MPLS Mixed Swapping/Stacking Extended Community . . . 14 3.1.2. MPLS Mixed Swapping/Stacking Extended Community . . . 15
3.2. Service Function Path Route (SFPR) . . . . . . . . . . . 14 3.2. Service Function Path Route (SFPR) . . . . . . . . . . . 16
3.2.1. The SFP Attribute . . . . . . . . . . . . . . . . . . 15 3.2.1. The SFP Attribute . . . . . . . . . . . . . . . . . . 16
3.2.2. General Rules For The SFP Attribute . . . . . . . . . 21 3.2.2. General Rules For The SFP Attribute . . . . . . . . . 22
4. Mode of Operation . . . . . . . . . . . . . . . . . . . . . . 22 4. Mode of Operation . . . . . . . . . . . . . . . . . . . . . . 23
4.1. Route Targets . . . . . . . . . . . . . . . . . . . . . . 22 4.1. Route Targets . . . . . . . . . . . . . . . . . . . . . . 23
4.2. Service Function Instance Routes . . . . . . . . . . . . 22 4.2. Service Function Instance Routes . . . . . . . . . . . . 24
4.3. Service Function Path Routes . . . . . . . . . . . . . . 22 4.3. Service Function Path Routes . . . . . . . . . . . . . . 24
4.4. Classifier Operation . . . . . . . . . . . . . . . . . . 24 4.4. Classifier Operation . . . . . . . . . . . . . . . . . . 26
4.5. Service Function Forwarder Operation . . . . . . . . . . 25 4.5. Service Function Forwarder Operation . . . . . . . . . . 26
4.5.1. Processing With 'Gaps' in the SI Sequence . . . . . . 26 4.5.1. Processing With 'Gaps' in the SI Sequence . . . . . . 27
5. Selection within Service Function Paths . . . . . . . . . . . 27 5. Selection within Service Function Paths . . . . . . . . . . . 29
6. Looping, Jumping, and Branching . . . . . . . . . . . . . . . 29 6. Looping, Jumping, and Branching . . . . . . . . . . . . . . . 31
6.1. Protocol Control of Looping, Jumping, and Branching . . . 30 6.1. Protocol Control of Looping, Jumping, and Branching . . . 31
6.2. Implications for Forwarding State . . . . . . . . . . . . 30 6.2. Implications for Forwarding State . . . . . . . . . . . . 32
7. Advanced Topics . . . . . . . . . . . . . . . . . . . . . . . 31 7. Advanced Topics . . . . . . . . . . . . . . . . . . . . . . . 33
7.1. Correlating Service Function Path Instances . . . . . . . 31 7.1. Correlating Service Function Path Instances . . . . . . . 33
7.2. Considerations for Stateful Service Functions . . . . . . 32 7.2. Considerations for Stateful Service Functions . . . . . . 34
7.3. VPN Considerations and Private Service Functions . . . . 33 7.3. VPN Considerations and Private Service Functions . . . . 35
7.4. Flow Spec for SFC Classifiers . . . . . . . . . . . . . . 33 7.4. Flow Specification for SFC Classifiers . . . . . . . . . 35
7.5. Choice of Data Plane SPI/SI Representation . . . . . . . 34 7.5. Choice of Data Plane SPI/SI Representation . . . . . . . 37
7.5.1. MPLS Representation of the SPI/SI . . . . . . . . . . 36 7.5.1. MPLS Representation of the SPI/SI . . . . . . . . . . 38
7.6. MPLS Label Swapping/Stacking Operation . . . . . . . . . 38
7.6. MPLS Label Swapping/Stacking Operation . . . . . . . . . 36 7.7. Support for MPLS-Encapsulated NSH Packets . . . . . . . . 39
7.7. Support for MPLS-Encapsulated NSH Packets . . . . . . . . 36 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 39
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 37 8.1. Example Explicit SFP With No Choices . . . . . . . . . . 41
8.1. Example Explicit SFP With No Choices . . . . . . . . . . 38 8.2. Example SFP With Choice of SFIs . . . . . . . . . . . . . 41
8.2. Example SFP With Choice of SFIs . . . . . . . . . . . . . 39 8.3. Example SFP With Open Choice of SFIs . . . . . . . . . . 42
8.3. Example SFP With Open Choice of SFIs . . . . . . . . . . 40 8.4. Example SFP With Choice of SFTs . . . . . . . . . . . . . 42
8.4. Example SFP With Choice of SFTs . . . . . . . . . . . . . 40 8.5. Example Correlated Bidirectional SFPs . . . . . . . . . . 43
8.5. Example Correlated Bidirectional SFPs . . . . . . . . . . 41 8.6. Example Correlated Asymmetrical Bidirectional SFPs . . . 43
8.6. Example Correlated Asymmetrical Bidirectional SFPs . . . 41 8.7. Example Looping in an SFP . . . . . . . . . . . . . . . . 44
8.7. Example Looping in an SFP . . . . . . . . . . . . . . . . 42 8.8. Example Branching in an SFP . . . . . . . . . . . . . . . 45
8.8. Example Branching in an SFP . . . . . . . . . . . . . . . 43 8.9. Examples of SFPs with Stateful Service Functions . . . . 45
8.9. Examples of SFPs with Stateful Service Functions . . . . 43 8.9.1. Forward and Reverse Choice Made at the SFF . . . . . 46
8.9.1. Forward and Reverse Choice Made at the SFF . . . . . 44 8.9.2. Parallel End-to-End SFPs with Shared SFF . . . . . . 47
8.9.2. Parallel End-to-End SFPs with Shared SFF . . . . . . 45 8.9.3. Parallel End-to-End SFPs with Separate SFFs . . . . . 49
8.9.3. Parallel End-to-End SFPs with Separate SFFs . . . . . 47 8.9.4. Parallel SFPs Downstream of the Choice . . . . . . . 51
8.9.4. Parallel SFPs Downstream of the Choice . . . . . . . 49 8.10. Examples Using IPv6 Addressing . . . . . . . . . . . . . 54
9. Security Considerations . . . . . . . . . . . . . . . . . . . 52 8.10.1. Example Explicit SFP With No Choices . . . . . . . . 56
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 8.10.2. Example SFP With Choice of SFIs . . . . . . . . . . 56
10.1. New BGP AF/SAFI . . . . . . . . . . . . . . . . . . . . 53 8.10.3. Example SFP With Open Choice of SFIs . . . . . . . . 57
10.2. New BGP Path Attribute . . . . . . . . . . . . . . . . . 53 8.10.4. Example SFP With Choice of SFTs . . . . . . . . . . 57
10.3. New SFP Attribute TLVs Type Registry . . . . . . . . . . 53 9. Security Considerations . . . . . . . . . . . . . . . . . . . 58
10.4. New SFP Association Type Registry . . . . . . . . . . . 54 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 60
10.5. New Service Function Type Registry . . . . . . . . . . . 55 10.1. New BGP AF/SAFI . . . . . . . . . . . . . . . . . . . . 60
10.2. New BGP Path Attribute . . . . . . . . . . . . . . . . . 60
10.3. New SFP Attribute TLVs Type Registry . . . . . . . . . . 61
10.4. New SFP Association Type Registry . . . . . . . . . . . 61
10.5. New Service Function Type Registry . . . . . . . . . . . 62
10.6. New Generic Transitive Experimental Use Extended 10.6. New Generic Transitive Experimental Use Extended
Community Sub-Types . . . . . . . . . . . . . . . . . . 56 Community Sub-Types . . . . . . . . . . . . . . . . . . 63
10.7. New BGP Transitive Extended Community Types . . . . . . 56 10.7. New BGP Transitive Extended Community Type . . . . . . . 63
10.8. SPI/SI Representation . . . . . . . . . . . . . . . . . 56 10.8. New SFC Extended Community Sub-Types Registry . . . . . 64
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 56 10.9. SPI/SI Representation . . . . . . . . . . . . . . . . . 64
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 57 10.10. SFC SPI/SI Representation Flags Registry . . . . . . . . 64
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 57 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 65
13.1. Normative References . . . . . . . . . . . . . . . . . . 57 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 65
13.2. Informative References . . . . . . . . . . . . . . . . . 59 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 66
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59 13.1. Normative References . . . . . . . . . . . . . . . . . . 66
13.2. Informative References . . . . . . . . . . . . . . . . . 67
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 68
1. Introduction 1. Introduction
As described in [RFC7498], the delivery of end-to-end services can As described in [RFC7498], the delivery of end-to-end services can
require a packet to pass through a series of Service Functions (SFs) require a packet to pass through a series of Service Functions (SFs)
(e.g., WAN and application accelerators, Deep Packet Inspection (DPI) (e.g., WAN and application accelerators, Deep Packet Inspection (DPI)
engines, firewalls, TCP optimizers, and server load balancers) in a engines, firewalls, TCP optimizers, and server load balancers) in a
specified order: this is termed "Service Function Chaining" (SFC). specified order: this is termed "Service Function Chaining" (SFC).
There are a number of issues associated with deploying and There are a number of issues associated with deploying and
maintaining service function chaining in production networks, which maintaining service function chaining in production networks, which
skipping to change at page 6, line 13 skipping to change at page 6, line 17
tunnels through underlay transport networks. tunnels through underlay transport networks.
o Service Function Path Route (SFPR). A new BGP Route Type o Service Function Path Route (SFPR). A new BGP Route Type
originated by Controllers to advertise the details of each SFP. originated by Controllers to advertise the details of each SFP.
o Service Function Type (SFT). An indication of the function and o Service Function Type (SFT). An indication of the function and
features of an SFI. features of an SFI.
2. Overview 2. Overview
This section provides an overview of Service Function Chaining in
general, and the control plane defined in this document. After
reading this section, readers may find it helpful to look through
Section 8 for some simple worked examples.
2.1. Overview of Service Function Chaining 2.1. Overview of Service Function Chaining
In [RFC8300] a Service Function Chain (SFC) is an ordered list of In [RFC8300] a Service Function Chain (SFC) is an ordered list of
Service Functions (SFs). A Service Function Path (SFP) is an Service Functions (SFs). A Service Function Path (SFP) is an
indication of which instances of SFs are acceptable to be traversed indication of which instances of SFs are acceptable to be traversed
in an instantiation of an SFC in a service function overlay network. in an instantiation of an SFC in a service function overlay network.
The Service Path Identifier (SPI) is a 24-bit number that identifies The Service Path Identifier (SPI) is a 24-bit number that identifies
a specific SFP, and a Service Index (SI) is an 8-bit number that a specific SFP, and a Service Index (SI) is an 8-bit number that
identifies a specific point in that path. In the context of a identifies a specific point in that path. In the context of a
particular SFP (identified by an SPI), an SI represents a particular particular SFP (identified by an SPI), an SI represents a particular
Service Function, and indicates the order of that SF in the SFP. Service Function, and indicates the order of that SF in the SFP.
In fact, each SI is mapped to one or more SFs that are implemented by Within the context of a specific SFP, an SI references a set of one
one or more Service Function Instances (SFIs) that support those or more SFs. Each of those SFs may be supported by one or more
specified SFs. Thus an SI may represent a choice of SFIs of one or Service Function Instances (SFIs). Thus an SI may represent a choice
more Service Function Types. By deploying multiple SFIs for a single of SFIs of one or more Service Function Types. By deploying multiple
SF, one can provide load balancing and redundancy. SFIs for a single SF, one can provide load balancing and redundancy.
A special functional element, called a Classifier, is located at each A special functional element, called a Classifier, is located at each
ingress point to a service function overlay network. It assigns the ingress point to a service function overlay network. It assigns the
packets of a given packet flow to a specific Service Function Path. packets of a given packet flow to a specific Service Function Path.
This may be done by comparing specific fields in a packet's header This may be done by comparing specific fields in a packet's header
with local policy, which may be customer/network/service specific. with local policy, which may be customer/network/service specific.
The classifier picks an SFP and sets the SPI accordingly, it then The Classifier picks an SFP and sets the SPI accordingly, it then
sets the SI to the value of the SI for the first hop in the SFP, and sets the SI to the value of the SI for the first hop in the SFP, and
then prepends a Network Services Header (NSH) [RFC8300] containing then prepends a Network Services Header (NSH) [RFC8300] containing
the assigned SPI/SI to that packet. Note that the Classifier and the the assigned SPI/SI to that packet. Note that the Classifier and the
node that hosts the first Service Function in a Service Function Path node that hosts the first Service Function in a Service Function Path
need not be located at the same point in the service function overlay need not be located at the same point in the service function overlay
network. network.
Note that the presence of the NSH can make it difficult for nodes in Note that the presence of the NSH can make it difficult for nodes in
the underlay network to locate the fields in the original packet that the underlay network to locate the fields in the original packet that
would normally be used to constrain equal cost multipath (ECMP) would normally be used to constrain equal cost multipath (ECMP)
forwarding. Therefore, it is recommended that the node prepending forwarding. Therefore, it is recommended that the node prepending
the NSH also provide some form of entropy indicator that can be used the NSH also provide some form of entropy indicator that can be used
in the underlay network. How this indicator is generated and in the underlay network. How this indicator is generated and
supplied, and how an SFF generates a new entropy indicator when it supplied, and how an SFF generates a new entropy indicator when it
forwards a packet to the next SFF are out of scope of this document. forwards a packet to the next SFF, are out of scope of this document.
The Service Function Forwarder (SFF) receives a packet from the The Service Function Forwarder (SFF) receives a packet from the
previous node in a Service Function Path, removes the packet's link previous node in a Service Function Path, removes the packet's link
layer or tunnel encapsulation and hands the packet and the NSH to the layer or tunnel encapsulation and hands the packet and the NSH to the
Service Function Instance for processing. The SFI has no knowledge Service Function Instance for processing. The SFI has no knowledge
of the SFP. of the SFP.
When the SFF receives the packet and the NSH back from the SFI it When the SFF receives the packet and the NSH back from the SFI it
must select the next SFI along the path using the SPI and SI in the must select the next SFI along the path using the SPI and SI in the
NSH and potentially choosing between multiple SFIs (possibly of NSH and potentially choosing between multiple SFIs (possibly of
skipping to change at page 7, line 42 skipping to change at page 7, line 51
service function overlay network. Furthermore, the new SI value is service function overlay network. Furthermore, the new SI value is
interpreted in the context of the SFP identified by the SPI. interpreted in the context of the SFP identified by the SPI.
As described in [RFC8300], an unknown or invalid SPI is treated as an As described in [RFC8300], an unknown or invalid SPI is treated as an
error and the SFF drops the packet: such errors should be logged, and error and the SFF drops the packet: such errors should be logged, and
such logs are subject to rate limits. such logs are subject to rate limits.
Also, as described in [RFC8300], an SFF receiving an SI that is Also, as described in [RFC8300], an SFF receiving an SI that is
unknown in the context of the SPI can reduce the value to the next unknown in the context of the SPI can reduce the value to the next
meaningful SI value in the SFP indicated by the SPI. If no such meaningful SI value in the SFP indicated by the SPI. If no such
value exists or if the SFF does not support this function, the SFF value exists or if the SFF does not support reducing the SI, the SFF
drops the packet and should log the event: such logs are also subject drops the packet and should log the event: such logs are also subject
to rate limits. to rate limits.
The SFF then selects an SFI that provides the SF denoted by the SPI/ The SFF then selects an SFI that provides the SF denoted by the SPI/
SI, and forwards the packet to the SFF that supports that SFI. SI, and forwards the packet to the SFF that supports that SFI.
[RFC8300] makes it clear that the intended scope is for use within a [RFC8300] makes it clear that the intended scope is for use within a
single provider's operational domain. single provider's operational domain.
This document adopts the SFC architecture described in [RFC7665] and This document adopts the SFC architecture described in [RFC7665] and
skipping to change at page 8, line 19 skipping to change at page 8, line 27
SFPs within the network. It gathers information about the SFPs within the network. It gathers information about the
availability of SFIs and SFFs, instructs the control plane about the availability of SFIs and SFFs, instructs the control plane about the
SFPs to be programmed, and instructs the Classifiers how to assign SFPs to be programmed, and instructs the Classifiers how to assign
traffic flows to individual SFPs. traffic flows to individual SFPs.
2.2. Control Plane Overview 2.2. Control Plane Overview
To accomplish the function described in Section 2.1, this document To accomplish the function described in Section 2.1, this document
introduces the Service Function Type (SFT) that is the category of SF introduces the Service Function Type (SFT) that is the category of SF
that is supported by an SFF (such as "firewall"). An IANA registry that is supported by an SFF (such as "firewall"). An IANA registry
of Service Function Types is introduced in Section 10. An SFF may of Service Function Types is introduced in Section 10 and is
support SFs of multiple different SFTs, and may support multiple SFIs consistent with types used in other work such as
of each SF. [I-D.dawra-idr-bgp-ls-sr-service-segments]. An SFF may support SFs
of multiple different SFTs, and may support multiple SFIs of each SF.
This document also introduces a new BGP AFI/SAFI (values to be This document also introduces a new BGP AFI/SAFI (values to be
assigned by IANA) for "SFC Routes". Two SFC Route Types are defined assigned by IANA) for "SFC Routes". Two SFC Route Types are defined
by this document: the Service Function Instance Route (SFIR), and the by this document: the Service Function Instance Route (SFIR), and the
Service Function Path Route (SFPR). As detailed in Section 3, the Service Function Path Route (SFPR). As detailed in Section 3, the
route type is indicated by a sub-field in the NLRI. route type is indicated by a sub-field in the NLRI.
o The SFIR is advertised by the node hosting the service function o The SFIR is advertised by the node hosting the service function
instance. The SFIR describes a particular instance of a instance (i.e., the SFF). The SFIR describes a particular
particular Service Function (i.e., an SFI) and the way to forward instance of a particular Service Function (i.e., an SFI) and the
a packet to it through the underlay network, i.e., IP address and way to forward a packet to it through the underlay network, i.e.,
encapsulation information. IP address and encapsulation information.
o The SFPRs are originated by Controllers. One SFPR is originated o The SFPRs are originated by Controllers. One SFPR is originated
for each Service Function Path. The SFPR specifies: for each Service Function Path. The SFPR specifies:
A. the SPI of the path A. the SPI of the path
B. the sequence of SFTs and/or SFIs of which the path consists B. the sequence of SFTs and/or SFIs of which the path consists
C. for each such SFT or SFI, the SI that represents it in the C. for each such SFT or SFI, the SI that represents it in the
identified path. identified path.
This approach assumes that there is an underlay network that provides This approach assumes that there is an underlay network that provides
connectivity between SFFs and Controllers, and that the SFFs are connectivity between SFFs and Controllers, and that the SFFs are
grouped to form one or more service function overlay networks through grouped to form one or more service function overlay networks through
which SFPs are built. We assume BGP connectivity between the which SFPs are built. We assume the the Controllers have BGP
Controllers and all SFFs within each service function overlay connectivity to all SFFs and all Classifiers within each service
network. function overlay network.
When choosing the next SFI in a path, the SFF uses the SPI and SI as When choosing the next SFI in a path, the SFF uses the SPI and SI as
well as the SFT to choose among the SFIs, applying, for example, a well as the SFT to choose among the SFIs, applying, for example, a
load balancing algorithm or direct knowledge of the underlay network load balancing algorithm or direct knowledge of the underlay network
topology as described in Section 4. topology as described in Section 4.
The SFF then encapsulates the packet using the encapsulation The SFF then encapsulates the packet using the encapsulation
specified by the SFIR of the selected SFI and forwards the packet. specified by the SFIR of the selected SFI and forwards the packet.
See Figure 1. See Figure 1.
Thus the SFF can be seen as a portal in the underlay network through Thus the SFF can be seen as a portal in the underlay network through
which a particular SFI is reached. which a particular SFI is reached.
Figure 1 shows a reference model for the SFC architecture. There are Figure 1 shows a reference model for the SFC architecture. There are
four SFFs (SFF-1 through SFF-4) connected by tunnels across the four SFFs (SFF-1 through SFF-4) connected by tunnels across the
underlay network. Packets arrive at a Classifier and are channelled underlay network. Packets arrive at a Classifier and are channeled
along SFPs to destinations reachable through SFF-4. along SFPs to destinations reachable through SFF-4.
SFF-1 and SFF-4 each have one instance of one SF attached (SFa and SFF-1 and SFF-4 each have one instance of one SF attached (SFa and
SFe). SFF-2 has two types of SF attached: there is one instance of SFe). SFF-2 has two types of SF attached: there is one instance of
one (SFc), and three instances of the other (SFb). SFF-3 has just one (SFc), and three instances of the other (SFb). SFF-3 has just
one instance of an SF (SFd), but it in this case the type of SFd is one instance of an SF (SFd), but it in this case the type of SFd is
the same type as SFb (SFTx). the same type as SFb (SFTx).
This figure demonstrates how load balancing can be achieved by This figure demonstrates how load balancing can be achieved by
creating several SFPs that satisfy the same SFC. Suppose an SFC creating several SFPs that satisfy the same SFC. Suppose an SFC
skipping to change at page 10, line 4 skipping to change at page 10, line 5
o The Classifier may distribute different flows onto different SFPs o The Classifier may distribute different flows onto different SFPs
to share the load in the network and across SFIs. to share the load in the network and across SFIs.
o SFF-2 may distribute different flows (on the same SFP) to o SFF-2 may distribute different flows (on the same SFP) to
different instances of SFb to share the processing load. different instances of SFb to share the processing load.
Note that, for convenience and clarity, Figure 1 shows only a few Note that, for convenience and clarity, Figure 1 shows only a few
tunnels between SFFs. There could be a full mesh of such tunnels, or tunnels between SFFs. There could be a full mesh of such tunnels, or
more likely, a selection of tunnels connecting key SFFs to enable the more likely, a selection of tunnels connecting key SFFs to enable the
construction of SFPs and to balance load and traffic in the network. construction of SFPs and to balance load and traffic in the network.
Further, the figure does not show any controllers: these would each
have BGP connectivity to the Classifier and all of the SFFs.
Packets Packets
| | | | | |
------------ ------------
| | | |
| Classifier | | Classifier |
| | | |
------+----- ------+-----
| |
---+--- --------- ------- ---+--- --------- -------
skipping to change at page 11, line 9 skipping to change at page 12, line 9
: | SFI | : : | SFI | : : | SFI | : : | SFI | :
: ----- : : ----- : : ----- : : ----- :
......... ......... ......... .........
Figure 1: The SFC Architecture Reference Model Figure 1: The SFC Architecture Reference Model
As previously noted, [RFC8300] makes it clear that the mechanisms it As previously noted, [RFC8300] makes it clear that the mechanisms it
defines are intended for use within a single provider's operational defines are intended for use within a single provider's operational
domain. This reduces the requirements on the control plane function. domain. This reduces the requirements on the control plane function.
[RFC7665] sets out the functions provided by a control plane for an
SFC network in Section 5.2. The functions are broken down into six
items the first four of which are completely covered by the
mechanisms described in this document:
1. Visiblity of all SFs and the SFFs through which they are reached.
2. Computation of SFPs and progrmming into the network.
3. Selection of SFIs explicitly in the SFP or dynamically within the
network.
4. Programming of SFFs with forwarding path information.
The fifth and six items in the list in RFC 7665 concern the use of
metadata. These are more peripheral to the control plane mechanisms
defined in this document, but are discussed in Section 4.4.
3. BGP SFC Routes 3. BGP SFC Routes
This document defines a new AFI/SAFI for BGP, known as "SFC", with an This document defines a new AFI/SAFI for BGP, known as "SFC", with an
NLRI that is described in this section. NLRI that is described in this section.
The format of the SFC NLRI is shown in Figure 2. The format of the SFC NLRI is shown in Figure 2.
+---------------------------------------+ +---------------------------------------+
| Route Type (2 octets) | | Route Type (2 octets) |
+---------------------------------------+ +---------------------------------------+
skipping to change at page 12, line 12 skipping to change at page 13, line 30
field in the MP_REACH_NLRI/MP_UNREACH_NLRI attribute contains the SFC field in the MP_REACH_NLRI/MP_UNREACH_NLRI attribute contains the SFC
NLRI, encoded as specified above. NLRI, encoded as specified above.
In order for two BGP speakers to exchange SFC NLRIs, they MUST use In order for two BGP speakers to exchange SFC NLRIs, they MUST use
BGP Capabilities Advertisements to ensure that they both are capable BGP Capabilities Advertisements to ensure that they both are capable
of properly processing such NLRIs. This is done as specified in of properly processing such NLRIs. This is done as specified in
[RFC4760], by using capability code 1 (Multiprotocol BGP) with an AFI [RFC4760], by using capability code 1 (Multiprotocol BGP) with an AFI
of TBD1 and a SAFI of TBD2. of TBD1 and a SAFI of TBD2.
The nexthop field of the MP_REACH_NLRI attribute of the SFC NLRI MUST The nexthop field of the MP_REACH_NLRI attribute of the SFC NLRI MUST
be set to loopback address of the advertising SFF. be set to a loopback address of the advertising SFF.
3.1. Service Function Instance Route (SFIR) 3.1. Service Function Instance Route (SFIR)
Figure 3 shows the Route Type specific NLRI of the SFIR. Figure 3 shows the Route Type specific NLRI of the SFIR.
+--------------------------------------------+ +--------------------------------------------+
| Route Distinguisher (RD) (8 octets) | | Route Distinguisher (RD) (8 octets) |
+--------------------------------------------+ +--------------------------------------------+
| Service Function Type (2 octets) | | Service Function Type (2 octets) |
+--------------------------------------------+ +--------------------------------------------+
Figure 3: SFIR Route Type specific NLRI Figure 3: SFIR Route Type specific NLRI
Per [RFC4364] the RD field comprises a two byte Type field and a six Per [RFC4364] the RD field comprises a two byte Type field and a six
byte Value field. If two SFIRs are originated from different byte Value field. If two SFIRs are originated from different
administrative domains, they MUST have different RDs. In particular, administrative domains (within the same provier's operational
SFIRs from different VPNs (for different service function overlay domain), they MUST have different RDs. In particular, SFIRs from
networks) MUST have different RDs, and those RDs MUST be different different VPNs (for different service function overlay networks) MUST
from any non-VPN SFIRs. have different RDs, and those RDs MUST be different from any non-VPN
SFIRs.
The Service Function Type identifies the functions/features of The Service Function Type identifies the functions/features a service
service function can offer, e.g., classifier, firewall, load function can offer, e.g., Classifier, firewall, load balancer. There
balancer, etc. There may be several SFIs that can perform a given may be several SFIs that can perform a given Service Function. Each
Service Function. Each node hosting an SFI MUST originate an SFIR node hosting an SFI MUST originate an SFIR for each type of SF that
for each type of SF that it hosts, and it may advertise an SFIR for it hosts (as indicated by the SFT value), and it MAY advertise an
each instance of each type of SF. The minimal advertisement allows SFIR for each instance of each type of SF. The minimal advertisement
construction of valid SFPs and leaves the selection of SFIs to the allows construction of valid SFPs and leaves the selection of SFIs to
local SFF; the detailed advertisement may have scaling concerns, but the local SFF; the detailed advertisement may have scaling concerns,
allows a Controller that constructs an SFP to make an explicit choice but allows a Controller that constructs an SFP to make an explicit
of SFI. choice of SFI.
Note that a node may advertise all SFIs of one SFT in one shot using Note that a node may advertise all its SFIs of one SFT in one shot
normal BGP Update packing. That is, all of the SFIRs in an Update using normal BGP Update packing. That is, all of the SFIRs in an
share a common Tunnel Encapsulation and RT attribute. See also Update share a common Tunnel Encapsulation and Route Target (RT)
Section 3.2.1. attribute. See also Section 3.2.1.
The SFIR representing a given SFI will contain an NLRI with RD field The SFIR representing a given SFI will contain an NLRI with RD field
set to an RD as specified above, and with SFT field set to identify set to an RD as specified above, and with SFT field set to identify
that SFI's Service Function Type. The values for the SFT field are that SFI's Service Function Type. The values for the SFT field are
taken from a registry administered by IANA (see Section 10). A BGP taken from a registry administered by IANA (see Section 10). A BGP
Update containing one or more SFIRs MUST also include a Tunnel Update containing one or more SFIRs MUST also include a Tunnel
Encapsulation attribute [I-D.ietf-idr-tunnel-encaps]. If a data Encapsulation attribute [I-D.ietf-idr-tunnel-encaps]. If a data
packet needs to be sent to an SFI identified in one of the SFIRs, it packet needs to be sent to an SFI identified in one of the SFIRs, it
will be encapsulated as specified by the Tunnel Encapsulation will be encapsulated as specified by the Tunnel Encapsulation
attribute, and then transmitted through the underlay network. attribute, and then transmitted through the underlay network.
Note that the Tunnel Encapsulation attribute MUST contain sufficient Note that the Tunnel Encapsulation attribute MUST contain sufficient
information to allow the advertising SFF to identify the overlay or information to allow the advertising SFF to identify the overlay or
VPN network which a received packet is transiting. This is because VPN network which a received packet is transiting. This is because
the [SPI, SI] in a received packet is specific to a particular the [SPI, SI] in a received packet is specific to a particular
overlay or VPN network. overlay or VPN network.
3.1.1. SFIR Pool Identifier Extended Community 3.1.1. SFIR Pool Identifier Extended Community
This document defines a new transitive extended community of type This document defines a new transitive extended community [RFC4360]
TBD6 with Sub-Type 0x00 called the SFIR Pool Identifier extended of type TBD6 called the SFC extended community. When used with Sub-
Type TBD7, this is called the SFIR Pool Identifier extended
community. It MAY be included in SFIR advertisements, and is used to community. It MAY be included in SFIR advertisements, and is used to
indicate the identity of a pool of SFIRs to which an SFIR belongs. indicate the identity of a pool of SFIRs to which an SFIR belongs.
Since an SFIR may be a member of multiple pools, multiple of these Since an SFIR may be a member of multiple pools, multiple of these
extended communities may be present on a single SFIR advertisement. extended communities may be present on a single SFIR advertisement.
SFIR pools allow SFIRs to be grouped for any purpose. Possible uses SFIR pools allow SFIRs to be grouped for any purpose. Possible uses
include control plane scalability and stability. A pool identifier include control plane scalability and stability. A pool identifier
may be included in an SFPR to indicate a set of SFIs that are may be included in an SFPR to indicate a set of SFIs that are
acceptable at a specific point on an SFP (see Section 3.2.1.3 and acceptable at a specific point on an SFP (see Section 3.2.1.3 and
Section 4.3). Section 4.3).
The SFIR Pool Identifier extended community is encoded in 8 octets as The SFIR Pool Identifier extended community is encoded in 8 octets as
shown in Figure 4. shown in Figure 4.
+--------------------------------------------+ +--------------------------------------------+
| Type = TBD6 (1 octet) | | Type = TBD6 (1 octet) |
+--------------------------------------------+ +--------------------------------------------+
| Sub-Type = 0x00 (1 octet) | | Sub-Type = TBD7 (1 octet) |
+--------------------------------------------+ +--------------------------------------------+
| SFIR Pool Identifier Value (6 octets) | | SFIR Pool Identifier Value (6 octets) |
+--------------------------------------------+ +--------------------------------------------+
Figure 4: The SFIR Pool Identifier Extended Community Figure 4: The SFIR Pool Identifier Extended Community
The SFIR Pool Identifier Value is encoded in a 6 octet field in The SFIR Pool Identifier Value is encoded in a 6 octet field in
network byte order, and is a globally unique value. This means that network byte order, and the value is unique within the scope of an
pool identifiers need to be centrally managed, which is consistent overlay network. This means that pool identifiers need to be
with the assignment of SFIs to pools. centrally managed, which is consistent with the assignment of SFIs to
pools.
3.1.2. MPLS Mixed Swapping/Stacking Extended Community 3.1.2. MPLS Mixed Swapping/Stacking Extended Community
This document defines a new transitive extended community of type As noted in Section 3.1.1, this document defines a new transitive
TBD7 with Sub-Type 0x00 called the MPLS Mixed Swapping/Stacking extended community of type TBD6 called the SFC extended community.
Labels. The community is encoded as shown in Figure 5. It contains When used with Sub-Type TBD8, this is called the MPLS Mixed Swapping/
a pair of MPLS labels: an SFC Context Label and an SF Label as Stacking Labels extended community. The community is encoded as
described in [RFC8595]. Each label is 20 bits encoded in a 3-octet shown in Figure 5. It contains a pair of MPLS labels: an SFC Context
(24 bit) field with 4 trailing bits that MUST be set to zero. Label and an SF Label as described in [RFC8595]. Each label is 20
bits encoded in a 3-octet (24 bit) field with 4 trailing bits that
MUST be set to zero.
+--------------------------------------------+ +--------------------------------------------+
| Type = TBD7 (1 octet) | | Type = TBD6 (1 octet) |
+--------------------------------------------| +--------------------------------------------|
| Sub-Type = 0x00 (1 octet) | | Sub-Type = TBD8 (1 octet) |
+--------------------------------------------| +--------------------------------------------|
| SFC Context Label (3 octets) | | SFC Context Label (3 octets) |
+--------------------------------------------| +--------------------------------------------|
| SF Label (3 octets) | | SF Label (3 octets) |
+--------------------------------------------+ +--------------------------------------------+
Figure 5: The MPLS Mixed Swapping/Stacking Extended Community Figure 5: The MPLS Mixed Swapping/Stacking Extended Community
Note that it is assumed that each SFF has one or more globally unique Note that it is assumed that each SFF has one or more globally unique
SFC Context Labels and that the context label space and the SPI SFC Context Labels and that the context label space and the SPI
address space are disjoint. address space are disjoint (i.e., a label value cannot be used both
to indicate an SFC context and an SPI, and it can be determined from
knowledge of the label spaces whether a label indicates an SFC
context or an SPI).
If an SFF supports SFP Traversal with an MPLS Label Stack it MUST If an SFF supports SFP Traversal with an MPLS Label Stack it MUST
include this extended community with the SFIRs that it advertises. include this extended community with the SFIRs that it advertises.
See Section 7.6 for a description of how this extended community is See Section 7.6 for a description of how this extended community is
used. used.
3.2. Service Function Path Route (SFPR) 3.2. Service Function Path Route (SFPR)
Figure 6 shows the Route Type specific NLRI of the SFPR. Figure 6 shows the Route Type specific NLRI of the SFPR.
+-----------------------------------------------+ +-----------------------------------------------+
| Route Distinguisher (RD) (8 octets) | | Route Distinguisher (RD) (8 octets) |
+-----------------------------------------------+ +-----------------------------------------------+
| Service Path Identifier (SPI) (3 octets) | | Service Path Identifier (SPI) (3 octets) |
+-----------------------------------------------+ +-----------------------------------------------+
Figure 6: SFPR Route Type Specific NLRI Figure 6: SFPR Route Type Specific NLRI
Per [RFC4364] the RD field comprises a two byte Type field and a six Per [RFC4364] the RD field comprises a two byte Type field and a six
byte Value field. All SFPs MUST be associated with different RDs. byte Value field. All SFPs MUST be associated with an RD. The
The association of an SFP with an RD is determined by provisioning. association of an SFP with an RD is determined by provisioning. If
If two SFPRs are originated from different Controllers they MUST have two SFPRs are originated from different Controllers they MUST have
different RDs. Additionally, SFPRs from different VPNs (i.e., in different RDs. Additionally, SFPRs from different VPNs (i.e., in
different service function overlay networks) MUST have different RDs, different service function overlay networks) MUST have different RDs,
and those RDs MUST be different from any non-VPN SFPRs. and those RDs MUST be different from any non-VPN SFPRs.
The Service Path Identifier is defined in [RFC8300] and is the value The Service Path Identifier is defined in [RFC8300] and is the value
to be placed in the Service Path Identifier field of the NSH header to be placed in the Service Path Identifier field of the NSH header
of any packet sent on this Service Function Path. It is expected of any packet sent on this Service Function Path. It is expected
that one or more Controllers will originate these routes in order to that one or more Controllers will originate these routes in order to
configure a service function overlay network. configure a service function overlay network.
The SFP is described in a new BGP Path attribute, the SFP attribute. The SFP is described in a new BGP Path attribute, the SFP attribute.
Section 3.2.1 shows the format of that attribute. Section 3.2.1 shows the format of that attribute.
3.2.1. The SFP Attribute 3.2.1. The SFP Attribute
[RFC4271] defines the BGP Path attribute. This document introduces a [RFC4271] defines BGP Path attributes. This document introduces a
new Optional Transitive Path attribute called the SFP attribute with new Optional Transitive Path attribute called the SFP attribute with
value TBD3 to be assigned by IANA. The first SFP attribute MUST be value TBD3 to be assigned by IANA. The first SFP attribute MUST be
processed and subsequent instances MUST be ignored. processed and subsequent instances MUST be ignored.
The common fields of the SFP attribute are set as follows: The common fields of the SFP attribute are set as follows:
o Optional bit is set to 1 to indicate that this is an optional o Optional bit is set to 1 to indicate that this is an optional
attribute. attribute.
o The Transitive bit is set to 1 to indicate that this is a o The Transitive bit is set to 1 to indicate that this is a
transitive attribute. transitive attribute.
o The Extended Length bit is set according to the length of the SFP o The Extended Length bit is set if the length of the SFP attribute
attribute as defined in [RFC4271]. is encoded in one octet (set to 0) or two octets (set to 1) as
described in [RFC4271].
o The Attribute Type Code is set to TBD3. o The Attribute Type Code is set to TBD3.
The content of the SFP attribute is a series of Type-Length-Value The content of the SFP attribute is a series of Type-Length-Value
(TLV) constructs. Each TLV may include sub-TLVs. All TLVs and sub- (TLV) constructs. Some TLVs may include sub-TLVs. All TLVs and sub-
TLVs have a common format that is: TLVs have a common format that is:
o Type: A single octet indicating the type of the SFP attribute TLV. o Type: A single octet indicating the type of the SFP attribute TLV.
Values are taken from the registry described in Section 10.3. Values are taken from the registry described in Section 10.3.
o Length: A two octet field indicating the length of the data o Length: A two octet field indicating the length of the data
following the Length field counted in octets. following the Length field counted in octets.
o Value: The contents of the TLV. o Value: The contents of the TLV.
skipping to change at page 16, line 26 skipping to change at page 17, line 52
the SFP. the SFP.
o Each Hop TLV contains an SI value and a sequence of one or more o Each Hop TLV contains an SI value and a sequence of one or more
SFT TLVs. Each SFT TLV contains an SFI reference for each SFT TLVs. Each SFT TLV contains an SFI reference for each
instance of an SF that is allowed at this hop of the SFP for the instance of an SF that is allowed at this hop of the SFP for the
specific SFT. Each SFI is indicated using the RD with which it is specific SFT. Each SFI is indicated using the RD with which it is
advertised (we say the SFIR-RD to avoid ambiguity). advertised (we say the SFIR-RD to avoid ambiguity).
Section 6 of [RFC4271] describes the handling of malformed BGP Section 6 of [RFC4271] describes the handling of malformed BGP
attributes, or those that are in error in some way. [RFC7606] attributes, or those that are in error in some way. [RFC7606]
revises BGP error handling specifically for the for UPDATE message, revises BGP error handling specifically for the UPDATE message,
provides guidelines for the authors of documents defining new provides guidelines for the authors of documents defining new
attributes, and revises the error handling procedures for a number of attributes, and revises the error handling procedures for a number of
existing attributes. This document introduces the SFP attribute and existing attributes. This document introduces the SFP attribute and
so defines error handling as follows: so defines error handling as follows:
o When parsing a message, an unknown Attribute Type code or a length o When parsing a message, an unknown Attribute Type code or a length
that suggests that the attribute is longer than the remaining that suggests that the attribute is longer than the remaining
message is treated as a malformed message and the "treat-as- message is treated as a malformed message and the "treat-as-
withdraw" approach used as per [RFC7606]. withdraw" approach used as per [RFC7606].
skipping to change at page 17, line 7 skipping to change at page 18, line 32
4. TLV length that suggests the TLV extends beyond the end of the 4. TLV length that suggests the TLV extends beyond the end of the
SFP attribute. SFP attribute.
5. Association TLV contains an unknown SFPR-RD. 5. Association TLV contains an unknown SFPR-RD.
6. No Hop TLV found in the SFP attribute. 6. No Hop TLV found in the SFP attribute.
7. No sub-TLV found in a Hop TLV. 7. No sub-TLV found in a Hop TLV.
8. Unknown SFIR-RD found in a Hop TLV. 8. Unknown SFIR-RD found in an SFT TLV.
o The errors listed above are treated as follows: o The errors listed above are treated as follows:
1., 2., 6., 7.: The attribute MUST be treated as malformed and 1., 2., 4., 6., 7.: The attribute MUST be treated as malformed
the "treat-as-withdraw" approach used as per [RFC7606]. and the "treat-as-withdraw" approach used as per [RFC7606].
3.: Unknown TLVs SHOULD be ignored, and message processing SHOULD 3.: Unknown TLVs MUST be ignored, and message processing MUST
continue. continue.
4.: Treated as a malformed message and the "treat-as-withdraw"
approach used as per [RFC7606]
5., 8.: The absence of an RD with which to correlate is nothing 5., 8.: The absence of an RD with which to correlate is nothing
more than a soft error. The receiver SHOULD store the more than a soft error. The receiver SHOULD store the
information from the SFP attribute until a corresponding information from the SFP attribute until a corresponding
advertisement is received. advertisement is received.
3.2.1.1. The Association TLV 3.2.1.1. The Association TLV
The Association TLV is an optional TLV in the SFP attribute. It MAY The Association TLV is an optional TLV in the SFP attribute. It MAY
be present multiple times. Each occurrence provides an association be present multiple times. Each occurrence provides an association
with another SFP as advertised in another SFPR. The format of the with another SFP as advertised in another SFPR. The format of the
skipping to change at page 18, line 30 skipping to change at page 20, line 4
advertised in an SFPR. advertised in an SFPR.
The Associated SPI contains the SPI of the associated SFP as The Associated SPI contains the SPI of the associated SFP as
advertised in an SFPR. advertised in an SFPR.
Association TLVs with unknown Association Type values SHOULD be Association TLVs with unknown Association Type values SHOULD be
ignored. Association TLVs that contain an Associated SFPR-RD value ignored. Association TLVs that contain an Associated SFPR-RD value
equal to the RD of the SFPR in which they are contained SHOULD be equal to the RD of the SFPR in which they are contained SHOULD be
ignored. If the Associated SPI is not equal to the SPI advertised in ignored. If the Associated SPI is not equal to the SPI advertised in
the SFPR indicated by the Associated SFPR-RD then the Association TLV the SFPR indicated by the Associated SFPR-RD then the Association TLV
SHOULD be ignored. SHOULD be ignored. In all three of these cases an implementation MAY
reject the SFP attribute as malformed and use the "treat-as-withdraw"
approach per [RFC7606], however implementers are cautioned that such
an approach may make an implementation less flexible in the event of
future extensions to this protocol.
Note that when two SFPRs reference each other using the Association Note that when two SFPRs reference each other using the Association
TLV, one SFPR advertisement will be received before the other. TLV, one SFPR advertisement will be received before the other.
Therefore, processing of an association MUST NOT be rejected simply Therefore, processing of an association MUST NOT be rejected simply
because the Associated SFPR-RD is unknown. because the Associated SFPR-RD is unknown.
Further discussion of correlation of SFPRs is provided in Further discussion of correlation of SFPRs is provided in
Section 7.1. Section 7.1.
3.2.1.2. The Hop TLV 3.2.1.2. The Hop TLV
skipping to change at page 19, line 33 skipping to change at page 21, line 7
The Service Index is defined in [RFC8300] and is the value found The Service Index is defined in [RFC8300] and is the value found
in the Service Index field of the NSH header that an SFF will use in the Service Index field of the NSH header that an SFF will use
to lookup to which next SFI a packet is to be sent. to lookup to which next SFI a packet is to be sent.
The Hop Details field consists of a sequence of one or more sub- The Hop Details field consists of a sequence of one or more sub-
TLVs. TLVs.
Each hop of the SFP may demand that a specific type of SF is Each hop of the SFP may demand that a specific type of SF is
executed, and that type is indicated in sub-TLVs of the Hop TLV. At executed, and that type is indicated in sub-TLVs of the Hop TLV. At
least one sub-TLV MUST be present. This provides a list of which least one sub-TLV MUST be present. This document defines the SFT
types of SF are acceptable at a specific hop, and for each type it Sub-TLV (see Section 3.2.1.3 and the MPLS Swapping/Stacking Sub-TLV
allows a degree of control to be imposed on the choice of SFIs of (see Section Section 3.2.1.4: other sub-TLVs may be defined in
that particular type. future. This provides a list of which types of SF are acceptable at
a specific hop, and for each type it allows a degree of control to be
imposed on the choice of SFIs of that particular type.
If no Hop TLV is present in an SFP Attribute, it is a malformed If no Hop TLV is present in an SFP Attribute, it is a malformed
attribute attribute
3.2.1.3. The SFT TLV 3.2.1.3. The SFT Sub-TLV
The SFT TLV MAY be included in the list of sub-TLVs of the Hop TLV. The SFT Sub-TLV MAY be included in the list of sub-TLVs of the Hop
The format of the SFT TLV is shown in Figure 9. The TLV contains a TLV. The format of the SFT Sub-TLV is shown in Figure 9. The Sub-
list of SFIR-RD values each taken from the advertisement of an SFI. TLV contains a list of SFIR-RD values each taken from the
Together they form a list of acceptable SFIs of the indicated type. advertisement of an SFI. Together they form a list of acceptable
SFIs of the indicated type.
+--------------------------------------------+ +--------------------------------------------+
| Type = 3 (1 octet) | | Type = 3 (1 octet) |
+--------------------------------------------| +--------------------------------------------|
| Length (2 octets) | | Length (2 octets) |
+--------------------------------------------| +--------------------------------------------|
| Service Function Type (2 octets) | | Service Function Type (2 octets) |
+--------------------------------------------| +--------------------------------------------|
| SFIR-RD List (variable) | | SFIR-RD List (variable) |
+--------------------------------------------+ +--------------------------------------------+
Figure 9: The Format of the SFT TLV Figure 9: The Format of the SFT Sub-TLV
The fields are as follows: The fields are as follows:
Type is set to 3 to indicate an SFT TLV. Type is set to 3 to indicate an SFT Sub-TLV.
Length indicates the length in octets of the Service Function Type Length indicates the length in octets of the Service Function Type
and SFIR-RD List fields. and SFIR-RD List fields.
The Service Function Type value indicates the category (type) of The Service Function Type value indicates the category (type) of
SF that is to be executed at this hop. The types are as SF that is to be executed at this hop. The types are as
advertised for the SFs supported by the SFFs. SFT values in the advertised for the SFs supported by the SFFs. SFT values in the
range 1-31 are Special Purpose SFT values and have meanings range 1-31 are Special Purpose SFT values and have meanings
defined by the documents that describe them - the value 'Change defined by the documents that describe them - the value 'Change
Sequence' is defined in Section 6.1 of this document. Sequence' is defined in Section 6.1 of this document.
skipping to change at page 20, line 43 skipping to change at page 22, line 17
may be used at the hop. The SFIs are identified using the SFIR- may be used at the hop. The SFIs are identified using the SFIR-
RDs from the advertisements of the SFIs in the SFIRs. Note that RDs from the advertisements of the SFIs in the SFIRs. Note that
if the list contains one or more SFIR Pool Identifiers, then for if the list contains one or more SFIR Pool Identifiers, then for
each the SFIR-RD list is effectively expanded to include the SFIR- each the SFIR-RD list is effectively expanded to include the SFIR-
RD of each SFIR advertised with that SFIR Pool Identifier. An RD of each SFIR advertised with that SFIR Pool Identifier. An
SFIR-RD of value zero has special meaning as described in SFIR-RD of value zero has special meaning as described in
Section 5. Each entry in the list is eight octets long, and the Section 5. Each entry in the list is eight octets long, and the
number of entries in the list can be deduced from the value of the number of entries in the list can be deduced from the value of the
Length field. Length field.
3.2.1.4. MPLS Swapping/Stacking TLV 3.2.1.4. MPLS Swapping/Stacking Sub-TLV
The MPLS Swapping/Stacking TLV (Type value 4) is a zero length sub- The MPLS Swapping/Stacking Sub-TLV (Type value 4) is a zero length
TLV that is OPTIONAL in the Hop TLV and is used when the data sub-TLV that is OPTIONAL in the Hop TLV and is used when the data
representation is MPLS (see Section 7.5). When present it indicates representation is MPLS (see Section 7.5). When present it indicates
to the Classifier imposing an MPLS label stack that the current hop to the Classifier imposing an MPLS label stack that the current hop
is to use an {SFC Context Label, SF label} rather than an {SPI, SF} is to use an {SFC Context Label, SF label} rather than an {SPI, SF}
label pair. See Section 7.6 for more details. label pair. See Section 7.6 for more details.
3.2.1.5. SFP Traversal With MPLS Label Stack TLV 3.2.1.5. SFP Traversal With MPLS Label Stack TLV
The SFP Traversal With MPLS Label Stack TLV (Type value 5) is a zero The SFP Traversal With MPLS Label Stack TLV (Type value 5) is a zero
length sub-TLV that can be carried in the SFP Attribute and indicates length TLV that can be carried in the SFP Attribute and indicates to
to the Classifier and the SFFs on the SFP that an MPLS label stack the Classifier and the SFFs on the SFP that an MPLS label stack with
with label swapping/stacking is to be used for packets traversing the label swapping/stacking is to be used for packets traversing the SFP.
SFP. All of the SFF specified at each the SFP's hops MUST have All of the SFF specified at each the SFP's hops MUST have advertised
advertised an MPLS Mixed Swapping/Stacking Extended Community (see an MPLS Mixed Swapping/Stacking Extended Community (see
Section 3.1.2) for the SFP to be considered usable. Section 3.1.2) for the SFP to be considered usable.
3.2.2. General Rules For The SFP Attribute 3.2.2. General Rules For The SFP Attribute
It is possible for the same SFI, as described by an SFIR, to be used It is possible for the same SFI, as described by an SFIR, to be used
in multiple SFPRs. in multiple SFPRs.
When two SFPRs have the same SPI but different SFPR-RDs there can be When two SFPRs have the same SPI but different SFPR-RDs there can be
three cases: three cases:
skipping to change at page 21, line 38 skipping to change at page 23, line 11
o There is a transition in content of the advertised SFP and the o There is a transition in content of the advertised SFP and the
advertisements may originate from one or more Controllers. In advertisements may originate from one or more Controllers. In
this case the content of the SFPRs will be different. this case the content of the SFPRs will be different.
o The reuse of an SPI may result from a configuration error. o The reuse of an SPI may result from a configuration error.
In all cases, there is no way for the receiving SFF to know which In all cases, there is no way for the receiving SFF to know which
SFPR to process, and the SFPRs could be received in any order. At SFPR to process, and the SFPRs could be received in any order. At
any point in time, when multiple SFPRs have the same SPI but any point in time, when multiple SFPRs have the same SPI but
different SFPR-RDs, the SFF MUST use the SFPR with the numerically different SFPR-RDs, the SFF MUST use the SFPR with the numerically
lowest SFPR-RD. The SFF SHOULD log this occurrence to assist with lowest SFPR-RD when interpretting the RDs as 8-octet integers in
debugging. network byte order. The SFF SHOULD log this occurrence to assist
with debugging.
Furthermore, a Controller that wants to change the content of an SFP Furthermore, a Controller that wants to change the content of an SFP
is RECOMMENDED to use a new SPI and so create a new SFP onto which is RECOMMENDED to use a new SPI and so create a new SFP onto which
the Classifiers can transition packet flows before the SFPR for the the Classifiers can transition packet flows before the SFPR for the
old SFP is withdrawn. This avoids any race conditions with SFPR old SFP is withdrawn. This avoids any race conditions with SFPR
advertisements. advertisements.
Additionally, a Controller SHOULD NOT re-use an SPI after it has Additionally, a Controller SHOULD NOT re-use an SPI after it has
withdrawn the SFPR that used it until at least a configurable amount withdrawn the SFPR that used it until at least a configurable amount
of time has passed. This timer SHOULD have a default of one hour. of time has passed. This timer SHOULD have a default of one hour.
skipping to change at page 22, line 39 skipping to change at page 24, line 15
4.2. Service Function Instance Routes 4.2. Service Function Instance Routes
The SFIR (see Section 3.1) is used to advertise the existence and The SFIR (see Section 3.1) is used to advertise the existence and
location of a specific Service Function Instance and consists of: location of a specific Service Function Instance and consists of:
o The RT as just described. o The RT as just described.
o A Service Function Type (SFT) that is the type of service function o A Service Function Type (SFT) that is the type of service function
that is provided (such as "firewall"). that is provided (such as "firewall").
o A Route Distinguisher (RD) that is unique to a specific instance o A Route Distinguisher (RD) that is unique to a specific overlay.
of a service function.
4.3. Service Function Path Routes 4.3. Service Function Path Routes
The SFPR (see Section 3.2) describes a specific path of a Service The SFPR (see Section 3.2) describes a specific path of a Service
Function Chain. The SFPR contains the Service Path Identifier (SPI) Function Chain. The SFPR contains the Service Path Identifier (SPI)
used to identify the SFP in the NSH in the data plane. It also used to identify the SFP in the NSH in the data plane. It also
contains a sequence of Service Indexes (SIs). Each SI identifies a contains a sequence of Service Indexes (SIs). Each SI identifies a
hop in the SFP, and each hop is a choice between one of more SFIs. hop in the SFP, and each hop is a choice between one of more SFIs.
As described in this document, each Service Function Path Route is As described in this document, each Service Function Path Route is
skipping to change at page 23, line 42 skipping to change at page 25, line 17
o Each Service Index is associated with a set of one or more Service o Each Service Index is associated with a set of one or more Service
Function Instances that can be used to provide the indexed Service Function Instances that can be used to provide the indexed Service
Function within the path. Each member of the set comprises: Function within the path. Each member of the set comprises:
* The RD used in an SFIR advertisement of the SFI. * The RD used in an SFIR advertisement of the SFI.
* The SFT that indicates the type of function as used in the same * The SFT that indicates the type of function as used in the same
SFIR advertisement of the SFI. SFIR advertisement of the SFI.
This may be summarized as follows where the notations "SFPR-RD" and This may be summarized as follows where the notations "SFPR-RD" and
"SFIR-RD" are used to distinguish the two different RDs: "SFIR-RD" are used to distinguish the two different RDs, and where
"*" indicates a multiplier:
RT, {SFPR-RD, SPI}, m * {SI, {n * {SFT, p * SFIR-RD} } } RT, {SFPR-RD, SPI}, m * {SI, {n * {SFT, p * SFIR-RD} } }
Where: Where:
RT: Route Target RT: Route Target
SFPR-RD: The Route Descriptor of the Service Function Path Route SFPR-RD: The Route Descriptor of the Service Function Path Route
advertisement advertisement
SPI: Service Path Identifier used in the NSH SPI: Service Path Identifier used in the NSH
m: The number of hops in the Service Function Path m: The number of hops in the Service Function Path
n: The number of choices of Service Function Type for a specific n: The number of choices of Service Function Type for a specific
hop hop
p: The number of choices of Service Function Instance for given p: The number of choices of Service Function Instance for given
Service Function Type in a specific hop Service Function Type in a specific hop
skipping to change at page 25, line 5 skipping to change at page 26, line 30
4.4. Classifier Operation 4.4. Classifier Operation
As shown in Figure 1, the Classifier is a component that is used to As shown in Figure 1, the Classifier is a component that is used to
assign packets to an SFP. assign packets to an SFP.
The Classifier is responsible for determining to which packet flow a The Classifier is responsible for determining to which packet flow a
packet belongs. The mechanism it uses to achieve that classification packet belongs. The mechanism it uses to achieve that classification
is out of scope of this document, but might include inspection of the is out of scope of this document, but might include inspection of the
packet header. The Classifier has been instructed (by the Controller packet header. The Classifier has been instructed (by the Controller
or through some other configuration mechanism) which flows are to be or through some other configuration mechanism - see Section 7.4)
assigned to which SFPs, and so it can impose an NSH on each packet which flows are to be assigned to which SFPs, and so it can impose an
and initialize the NSH with the SPI of the selected SFP and the SI of NSH on each packet and initialize the NSH with the SPI of the
its first hop. selected SFP and the SI of its first hop.
Note that instructions delivered to the Classifier may include
information about the metadata to encode (and the format for that
encoding) on packets that are classified by the Classifier to a
particular SFP. As mentioned in Section 2.2, this corresponds to the
fifth element of control plane functionality described in [RFC7665].
Such instructions fall outside the scope of this specification
(although, see Section 7.4), as do instructions to other SFC elements
on how to interpret metadata (as described in the sixth element of
control plane functionality described in [RFC7665].
4.5. Service Function Forwarder Operation 4.5. Service Function Forwarder Operation
Each packet sent to an SFF is transmitted encapsulated in an NSH. Each packet sent to an SFF is transmitted encapsulated in an NSH.
The NSH includes an SPI and SI: the SPI indicates the SFPR The NSH includes an SPI and SI: the SPI indicates the SFPR
advertisement that announced the Service Function Path; the tuple advertisement that announced the Service Function Path; the tuple
SPI/SI indicates a specific hop in a specific path and maps to the SPI/SI indicates a specific hop in a specific path and maps to the
RD/SFT of a particular SFIR advertisement. RD/SFT of a particular SFIR advertisement.
When an SFF gets an SFPR advertisement it will first determine When an SFF gets an SFPR advertisement it will first determine
whether to import the route by examining the RT. If the SFPR is whether to import the route by examining the RT. If the SFPR is
imported the SFF then determines whether it is on the SFP by looking imported the SFF then determines whether it is on the SFP by looking
for its own SFIR-RDs in the SFPR. For each occurrence in the SFP, for its own SFIR-RDs or any SFIR-RD with value zero in the SFPR. For
the SFF creates forwarding state for incoming packets and forwarding each occurrence in the SFP, the SFF creates forwarding state for
state for outgoing packets that have been processed by the specified incoming packets and forwarding state for outgoing packets that have
SFI. been processed by the specified SFI.
The SFF creates local forwarding state for packets that it receives The SFF creates local forwarding state for packets that it receives
from other SFFs. This state makes the association between the SPI/SI from other SFFs. This state makes the association between the SPI/SI
in the NSH of the received packet and one or more specific local SFIs in the NSH of the received packet and one or more specific local SFIs
as identified by the SFIR-RD/SFT. If there are multiple local SFIs as identified by the SFIR-RD/SFT. If there are multiple local SFIs
that match this is because a single advertisement was made for a set that match this is because a single advertisement was made for a set
of equivalent SFIs and the SFF may use local policy (such as load of equivalent SFIs and the SFF may use local policy (such as load
balancing) to determine to which SFI to forward a received packet. balancing) to determine to which SFI to forward a received packet.
The SFF also creates next hop forwarding state for packets received The SFF also creates next hop forwarding state for packets received
skipping to change at page 27, line 19 skipping to change at page 29, line 5
local SFI to deliver the packet. local SFI to deliver the packet.
o If the SI does not match an entry in the SFP, the SFF MUST reduce o If the SI does not match an entry in the SFP, the SFF MUST reduce
the SI value to the next (smaller) value present in the SFP and the SI value to the next (smaller) value present in the SFP and
process the packet using that SI. process the packet using that SI.
o If there is no smaller SI (i.e., if the end of the SFP has been o If there is no smaller SI (i.e., if the end of the SFP has been
reached) the SFF MUST treat the SI value as invalid as described reached) the SFF MUST treat the SI value as invalid as described
in [RFC8300]. in [RFC8300].
This makes the bevahior described in this document a superset of the This makes the behavior described in this document a superset of the
function in [RFC8300]. That is, an implementation that strictly function in [RFC8300]. That is, an implementation that strictly
follows RFC 8300 in performing SI decrements in units of one, is follows RFC 8300 in performing SI decrements in units of one, is
perfectly in line with the mechanisms defined in this document. perfectly in line with the mechanisms defined in this document.
SFF implementations MAY choose to only support contiguous SI values SFF implementations MAY choose to only support contiguous SI values
in an SFP. Such an implementation will not support receiving an SI in an SFP. Such an implementation will not support receiving an SI
value that is not present in the SFP and will discard the packets as value that is not present in the SFP and will discard the packets as
described in [RFC8300]. described in [RFC8300].
5. Selection within Service Function Paths 5. Selection within Service Function Paths
skipping to change at page 29, line 8 skipping to change at page 30, line 41
matches the SFT value in one of the SFT TLVs, and the RD matches the SFT value in one of the SFT TLVs, and the RD
value in its NLRI matches an entry in the list of SFIR-RDs in value in its NLRI matches an entry in the list of SFIR-RDs in
that SFT TLV. that SFT TLV.
B. If an entry in the SFIR-RD list of an SFT TLV contains the B. If an entry in the SFIR-RD list of an SFT TLV contains the
value zero, then an SFIR is relevant if it carries RT-z and value zero, then an SFIR is relevant if it carries RT-z and
the SFT in its NLRI matches the SFT value in that SFT TLV. the SFT in its NLRI matches the SFT value in that SFT TLV.
I.e., any SFIR in the service function overlay network I.e., any SFIR in the service function overlay network
defined by RT-z and with the correct SFT is relevant. defined by RT-z and with the correct SFT is relevant.
C. If a pool identifier is in use then an SFIR is relevant if it
is a member of the pool.
Each of the relevant SFIRs identifies a single SFI, and contains a Each of the relevant SFIRs identifies a single SFI, and contains a
Tunnel Encapsulation attribute that specifies how to send a packet to Tunnel Encapsulation attribute that specifies how to send a packet to
that SFI. For a particular packet, the SFF chooses a particular SFI that SFI. For a particular packet, the SFF chooses a particular SFI
from the set of relevant SFIRs. This choice is made according to from the set of relevant SFIRs. This choice is made according to
local policy. local policy.
A typical policy might be to figure out the set of SFIs that are A typical policy might be to figure out the set of SFIs that are
closest, and to load balance among them. But this is not the only closest, and to load balance among them. But this is not the only
possible policy. possible policy.
Thus, at any point in time when an SFF selects its next hop, it Thus, at any point in time when an SFF selects its next hop, it
chooses from the intersection of the set of next hop RDs contained in chooses from the intersection of the set of next hop RDs contained in
the SFPR and the RDs contained in its local set of SFIRs. If the the SFPR and the RDs contained in the SFF's local set of SFIRs (i.e.,
according to the determination of "relevance", above). If the
intersection is null, the SFPR is unusable. Similarly, when this intersection is null, the SFPR is unusable. Similarly, when this
condition obtains the originator of the SFPR SHOULD either withdraw condition applies on the controller that originated the SFPR, it
the SFPR or re-advertise it with a new set of RDs for the affected SHOULD either withdraw the SFPR or re-advertise it with a new set of
hop. RDs for the affected hop.
6. Looping, Jumping, and Branching 6. Looping, Jumping, and Branching
As described in Section 2 an SFI or an SFF may cause a packet to As described in Section 2 an SFI or an SFF may cause a packet to
"loop back" to a previous SF on a path in order that a sequence of "loop back" to a previous SF on a path in order that a sequence of
functions may be re-executed. This is simply achieved by replacing functions may be re-executed. This is simply achieved by replacing
the SI in the NSH with a higher value instead of decreasing it as the SI in the NSH with a higher value instead of decreasing it as
would normally be the case to determine the next hop in the path. would normally be the case to determine the next hop in the path.
Section 2 also describes how an SFI or an SFF may cause a packets to Section 2 also describes how an SFI or an SFF may cause a packets to
skipping to change at page 29, line 50 skipping to change at page 31, line 38
A more complex option to move packets from one SFP to another is A more complex option to move packets from one SFP to another is
described in [RFC8300] and Section 2 where it is termed "branching". described in [RFC8300] and Section 2 where it is termed "branching".
This mechanism allows an SFI or SFF to make a choice of downstream This mechanism allows an SFI or SFF to make a choice of downstream
treatments for packets based on local policy and output of the local treatments for packets based on local policy and output of the local
SF. Branching is achieved by changing the SPI in the NSH to indicate SF. Branching is achieved by changing the SPI in the NSH to indicate
the new path and setting the SI to indicate the point in the path at the new path and setting the SI to indicate the point in the path at
which the packets enter. which the packets enter.
Note that the NSH does not include a marker to indicate whether a Note that the NSH does not include a marker to indicate whether a
specific packet has been around a loop before. Therefore, the use of specific packet has been around a loop before. Therefore, the use of
NSH metadata may be required in order to prevent infinite loops. NSH metadata ([RFC8300]) may be required in order to prevent infinite
loops.
6.1. Protocol Control of Looping, Jumping, and Branching 6.1. Protocol Control of Looping, Jumping, and Branching
If the SFT value in an SFT TLV in an SFPR has the Special Purpose SFT If the SFT value in an SFT TLV in an SFPR has the Special Purpose SFT
value "Change Sequence" (see Section 10) then this is an indication value "Change Sequence" (see Section 10) then this is an indication
that the SFF may make a loop, jump, or branch according to local that the SFF may make a loop, jump, or branch according to local
policy and information returned by the local SFI. policy and information returned by the local SFI.
In this case, the SPI and SI of the next hop is encoded in the eight In this case, the SPI and SI of the next hop are encoded in the eight
bytes of an entry in the SFIR-RD list as follows: bytes of an entry in the SFIR-RD list as follows:
3 bytes SPI 3 bytes SPI
1 bytes SI
2 bytes SI 4 bytes Reserved (SHOULD be set to zero and ignored)
3 bytes Reserved (SHOULD be set to zero and ignored)
If the SI in this encoding is not part of the SFPR indicated by the If the SI in this encoding is not part of the SFPR indicated by the
SPI in this encoding, then this is an explicit error that SHOULD be SPI in this encoding, then this is an explicit error that SHOULD be
detected by the SFF when it parses the SFPR. The SFPR SHOULD NOT detected by the SFF when it parses the SFPR. The SFPR SHOULD NOT
cause any forwarding state to be installed in the SFF and packets cause any forwarding state to be installed in the SFF and packets
received with the SPI that indicates this SFPR SHOULD be silently received with the SPI that indicates this SFPR SHOULD be silently
discarded. discarded.
If the SPI in this encoding is unknown, the SFF SHOULD NOT install If the SPI in this encoding is unknown, the SFF SHOULD NOT install
any forwarding state for this SFPR, but MAY hold the SFPR pending any forwarding state for this SFPR, but MAY hold the SFPR pending
receipt of another SFPR that does use the encoded SPI. receipt of another SFPR that does use the encoded SPI.
If the SPI matches the current SPI for the path, this is a loop or If the SPI matches the current SPI for the path, this is a loop or
jump. In this case, if the SI is greater than to the current SI it jump. In this case, if the SI is greater than to the current SI it
is a loop. If the SPI matches and the SI is less than the next SI, is a loop. If the SPI matches and the SI is less than the next SI,
it is a jump. it is a jump.
If the SPI indicates anther path, this is a branch and the SI If the SPI indicates another path, this is a branch and the SI
indicates the point at which to enter that path. indicates the point at which to enter that path.
The Change Sequence SFT is just another SFT that may appear in a set The Change Sequence SFT is just another SFT that may appear in a set
of SFI/SFT tuples within an SI and is selected as described in of SFI/SFT tuples within an SI and is selected as described in
Section 5. Section 5.
Note that Special Purpose SFTs MUST NOT be advertised in SFIRs. Note that Special Purpose SFTs MUST NOT be advertised in SFIRs. If
such an SFIR is received it SHOULD be ignored.
6.2. Implications for Forwarding State 6.2. Implications for Forwarding State
Support for looping and jumping requires that the SFF has forwarding Support for looping and jumping requires that the SFF has forwarding
state established to an SFF that provides access to an instance of state established to an SFF that provides access to an instance of
the appropriate SF. This means that the SFF must have seen the the appropriate SF. This means that the SFF must have seen the
relevant SFIR advertisements and known that it needed to create the relevant SFIR advertisements and known that it needed to create the
forwarding state. This is a matter of local configuration and forwarding state. This is a matter of local configuration and
implementation: for example, an implementation could be configured to implementation: for example, an implementation could be configured to
install forwarding state for specific looping/jumping. install forwarding state for specific looping/jumping.
skipping to change at page 31, line 39 skipping to change at page 33, line 28
As described in Section 3.2.1.1 an SFPR can contain one or more As described in Section 3.2.1.1 an SFPR can contain one or more
correlators encoded in Association TLVs. If the Association Type correlators encoded in Association TLVs. If the Association Type
indicates "Bidirectional SFP" then the SFP advertised in the SFPR is indicates "Bidirectional SFP" then the SFP advertised in the SFPR is
one direction of a bidirectional pair of SFPs where the other in the one direction of a bidirectional pair of SFPs where the other in the
pair is advertised in the SFPR with RD as carried in the Associated pair is advertised in the SFPR with RD as carried in the Associated
SFPR-RD field of the Association TLV. The SPI carried in the SFPR-RD field of the Association TLV. The SPI carried in the
Associated SPI field of the Association TLV provides a cross-check Associated SPI field of the Association TLV provides a cross-check
against the SPI advertised in the SFPR with RD as carried in the against the SPI advertised in the SFPR with RD as carried in the
Associated SFPR-RD field of the Association TLV. Associated SFPR-RD field of the Association TLV.
As noted in Section 3.2.1.1 SFPRs reference each other one SFPR As noted in Section 3.2.1.1, when SFPRs reference each other, one
advertisement will be received before the other. Therefore SFPR advertisement will be received before the other. Therefore,
processing of an association will require that the first SFPR is not processing of an association will require that the first SFPR is not
rejected simply because the Associated SFPR-RD it carries is unknown. rejected simply because the Associated SFPR-RD it carries is unknown.
However, the SFP defined by the first SFPR is valid and SHOULD be However, the SFP defined by the first SFPR is valid and SHOULD be
available for use as a unidirectional SFP even in the absence of an available for use as a unidirectional SFP even in the absence of an
advertisement of its partner. advertisement of its partner.
Furthermore, in error cases where SFPR-a associates with SFPR-b, but Furthermore, in error cases where SFPR-a associates with SFPR-b, but
SFPR-b associates with SFPR-c such that a bidirectional pair of SFPs SFPR-b associates with SFPR-c such that a bidirectional pair of SFPs
cannot be formed, the individual SFPs are still valid and SHOULD be cannot be formed, the individual SFPs are still valid and SHOULD be
available for use as unidirectional SFPs. An implementation SHOULD available for use as unidirectional SFPs. An implementation SHOULD
skipping to change at page 33, line 23 skipping to change at page 35, line 18
Functions for specific customers or allowing customers to deploy Functions for specific customers or allowing customers to deploy
their own Service Functions within the network. Building Service their own Service Functions within the network. Building Service
Functions in such environments requires that suitable identifiers are Functions in such environments requires that suitable identifiers are
used to ensure that SFFs distinguish which SFIs can be used and which used to ensure that SFFs distinguish which SFIs can be used and which
cannot. cannot.
This problem is similar to how VPNs are supported and is solved in a This problem is similar to how VPNs are supported and is solved in a
similar way. The RT field is used to indicate a set of Service similar way. The RT field is used to indicate a set of Service
Functions from which all choices must be made. Functions from which all choices must be made.
7.4. Flow Spec for SFC Classifiers 7.4. Flow Specification for SFC Classifiers
[RFC5575] and [I-D.ietf-idr-rfc5575bis] define a set of BGP routes [RFC5575] and [I-D.ietf-idr-rfc5575bis] define a set of BGP routes
that can be used to identify the packets in a given flow using fields that can be used to identify the packets in a given flow using fields
in the header of each packet, and a set of actions, encoded as in the header of each packet, and a set of actions, encoded as
extended communities, that can be used to disposition those packets. extended communities, that can be used to disposition those packets.
This document enables the use of these mechanisms by SFC Classifiers This document enables the use of these mechanisms by SFC Classifiers
by defining a new action extended community called "Flow Spec for SFC by defining a new action extended community called "Flow
Classifiers" identified by the value TBD4. Note that other action Specification for SFC Classifiers" identified by the value TBD4.
extended communities MUST NOT be present at the same time: the Note that implementation of this specification MUST NOT include other
inclusion of the "Flow Spec for SFC Classifiers" action extended action extended communities at the same time as an SFC Classifier:
community along with any other action MUST be treated as an error the inclusion of the "Flow Specification for SFC Classifiers" action
which SHOULD result in the Flow Specification UPDATE message being extended community along with any other action MUST be treated by
handled as Treat-as-withdraw according to [RFC7606] Section 2. implementation of this specification as an error which SHOULD result
in the Flow Specification UPDATE message being handled as Treat-as-
withdraw according to [RFC7606] Section 2.
To put the Flow Specification into context when multiple SFC overlays
are present in one network, each FlowSpec update MUST be tagged with
the route target of the overlay or VPN network for which it is
intended.
This extended community is encoded as an 8-octet value, as shown in This extended community is encoded as an 8-octet value, as shown in
Figure 10. Figure 10.
1 2 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0x80 | Sub-Type=TBD4 | SPI | | Type=0x80 | Sub-Type=TBD4 | SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI (cont.) | SI | SFT | | SPI (cont.) | SI | SFT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: The Format of the Flow Spec for SFC Classifiers Extended Figure 10: The Format of the Flow Specification for SFC Classifiers
Community Extended Community
The extended community contains the Service Path Identifier (SPI), The extended community contains the Service Path Identifier (SPI),
Service Index (SI), and Service Function Type (SFT) as defined Service Index (SI), and Service Function Type (SFT) as defined
elsewhere in this document. Thus, each action extended community elsewhere in this document. Thus, each action extended community
defines the entry point (not necessarily the first hop) into a defines the entry point (not necessarily the first hop) into a
specific service function path. This allows, for example, different specific service function path. This allows, for example, different
flows to enter the same service function path at different points. flows to enter the same service function path at different points.
Note that a given Flow Spec update according to [RFC5575] and Note that a given Flow Specification update according to [RFC5575]
[I-D.ietf-idr-rfc5575bis] may include multiple of these action and [I-D.ietf-idr-rfc5575bis] may include multiple of these action
extended communities, and that if a given action extended community extended communities, and that if a given action extended community
does not contain an installed SFPR with the specified {SPI, SI, SFT} does not contain an installed SFPR with the specified {SPI, SI, SFT}
it MUST NOT be used for dispositioning the packets of the specified it MUST NOT be used for dispositioning the packets of the specified
flow. flow.
The normal case of packet classification for SFC will see a packet The normal case of packet classification for SFC will see a packet
enter the SFP at its first hop. In this case the SI in the extended enter the SFP at its first hop. In this case the SI in the extended
community is superfluous and the SFT may also be unnecessary. To community is superfluous and the SFT may also be unnecessary. To
allow these cases to be handled, a special meaning is assigned to a allow these cases to be handled, a special meaning is assigned to a
Service Index of zero (not a valid value) and an SFT of zero (a Service Index of zero (not a valid value) and an SFT of zero (a
skipping to change at page 34, line 41 skipping to change at page 37, line 5
then there are two sub-cases: then there are two sub-cases:
* If there is a choice of SFT in the hop indicated by the value * If there is a choice of SFT in the hop indicated by the value
of the SI (including SI = 0) then SFT = 0 means there is a free of the SI (including SI = 0) then SFT = 0 means there is a free
choice according to local policy of which SFT to use). choice according to local policy of which SFT to use).
* If there is no choice of SFT in the hop indicated by the value * If there is no choice of SFT in the hop indicated by the value
of SI, then SFT = 0 means that the value of the SFT at that hop of SI, then SFT = 0 means that the value of the SFT at that hop
as indicated in the SFPR for the indicated SPI MUST be used. as indicated in the SFPR for the indicated SPI MUST be used.
One of the filters that the Flow Spec may describe is the VPN to One of the filters that the Flow Specification may describe is the
which the traffic belongs. Additionally, note that to put the VPN to which the traffic belongs. Additionally, as noted above, to
indicated SPI into context when multiple SFC overlays are present in put the indicated SPI into context when multiple SFC overlays are
one network, each FlowSpec update MUST be tagged with the route present in one network, each FlowSpec update MUST be tagged with the
target of the overlay or VPN network for which it is intended. route target of the overlay or VPN network for which it is intended.
Note that future extensions might be made to the Flow Specification
for SFC Classifiers Extended Community to provide instruction to the
Classifier about what metadata to add to packets that it classifies
for forwarding on a specific SFP, but that is outside the scope of
this document.
7.5. Choice of Data Plane SPI/SI Representation 7.5. Choice of Data Plane SPI/SI Representation
This document ties together the control and data planes of an SFC This document ties together the control and data planes of an SFC
overlay network through the use of the SPI/SI which is nominally overlay network through the use of the SPI/SI which is nominally
carried in the NSH of a given packet. However, in order to handle carried in the NSH of a given packet. However, in order to handle
situations in which the NSH is not ubiquitously deployed, it is also situations in which the NSH is not ubiquitously deployed, it is also
possible to use alternative data plane representations of the SPI/SI possible to use alternative data plane representations of the SPI/SI
by carrying the identical semantics in other protocol fields such as by carrying the identical semantics in other protocol fields such as
MPLS labels [RFC8595]. MPLS labels [RFC8595].
This document defines a new sub-TLV for the Tunnel Encapsulation This document defines a new sub-TLV for the Tunnel Encapsulation
attribute, the SPI/SI Representation sub-TLV of type TBD5. This sub- attribute [I-D.ietf-idr-tunnel-encaps], the SPI/SI Representation
TLV MAY be present in each Tunnel TLV contained in a Tunnel sub-TLV of type TBD5. This sub-TLV MAY be present in each Tunnel TLV
Encapsulation attribute when the attribute is carried by an SFIR. contained in a Tunnel Encapsulation attribute when the attribute is
The value field of this sub-TLV is a two octet field of flags, each carried by an SFIR. The value field of this sub-TLV is a two octet
of which describes how the originating SFF expects to see the SPI/SI field of flags numbered counting from the the most significant bit,
represented in the data plane for packets carried in the tunnels each of which describes how the originating SFF expects to see the
described by the Tunnel TLV. SPI/SI represented in the data plane for packets carried in the
tunnels described by the Tunnel TLV.
The following bits are defined by this document: The following bits are defined by this document and are tracked in an
IANA registry desribed in Section 10.10:
Bit 0: If this bit is set the NSH is to be used to carry the SPI/SI Bit TBD9: If this bit is set the NSH is to be used to carry the SPI/
in the data plane. SI in the data plane.
Bit 1: If this bit is set two labels in an MPLS label stack are to Bit TBD10: If this bit is set two labels in an MPLS label stack are
be used as described in Section 7.5.1. to be used as described in Section 7.5.1.
If a given Tunnel TLV does not contain an SPI/SI Representation sub- If a given Tunnel TLV does not contain an SPI/SI Representation sub-
TLV then it MUST be processed as if such a sub-TLV is present with TLV then it MUST be processed as if such a sub-TLV is present with
Bit 0 set and no other bits set. That is, the absence of the sub-TLV Bit TBD9 set and no other bits set. That is, the absence of the sub-
SHALL be interpreted to mean that the NSH is to be used. TLV SHALL be interpreted to mean that the NSH is to be used.
If a given Tunnel TLV contains an SPI/SI Representation sub-TLV with If a given Tunnel TLV contains an SPI/SI Representation sub-TLV with
value field that has no flag set then the tunnel indicated by the value field that has no flag set then the tunnel indicated by the
Tunnel TLV MUST NOT be used for forwarding SFC packets. If a given Tunnel TLV MUST NOT be used for forwarding SFC packets. If a given
Tunnel TLV contains an SPI/SI Representation sub-TLV with both bit 0 Tunnel TLV contains an SPI/SI Representation sub-TLV with both bit
and bit 1 set then the tunnel indicated by the Tunnel TLV MUST NOT be TBD9 and bit TBD10 set then the tunnel indicated by the Tunnel TLV
used for forwarding SFC packets. The meaning and rules for presence MUST NOT be used for forwarding SFC packets. The meaning and rules
of other bits is to be defined in future documents, but for presence of other bits is to be defined in future documents, but
implementations of this specification MUST set other bits to zero and implementations of this specification MUST set other bits to zero and
ignore them on receipt. ignore them on receipt.
If a given Tunnel TLV contains more than one SPI/SI Representation If a given Tunnel TLV contains more than one SPI/SI Representation
sub-TLV then the first one MUST be considered and subsequent sub-TLV then the first one MUST be considered and subsequent
instances MUST be ignored. instances MUST be ignored.
Note that the MPLS representation of the logical NSH may be used even Note that the MPLS representation of the logical NSH may be used even
if the tunnel is not an MPLS tunnel. Conversely, MPLS tunnels may be if the tunnel is not an MPLS tunnel. Conversely, MPLS tunnels may be
used to carry other encodings of the logical NSH (specifically, the used to carry other encodings of the logical NSH (specifically, the
NSH itself). It is a requirement that both ends of a tunnel over the NSH itself). It is a requirement that both ends of a tunnel over the
underlay network know that the tunnel is used for SFC and know what underlay network know that the tunnel is used for SFC and know what
form of NSH representation is used. The signaling mechanism form of NSH representation is used. The signaling mechanism
described here allows coordination of this information. described here allows coordination of this information.
7.5.1. MPLS Representation of the SPI/SI 7.5.1. MPLS Representation of the SPI/SI
If bit 1 is set in the in the SPI/SI Representation sub-TLV then If bit TBD10 is set in the in the SPI/SI Representation sub-TLV then
labels in the MPLS label stack are used to indicate SFC forwarding labels in the MPLS label stack are used to indicate SFC forwarding
and processing instructions to achieve the semantics of a logical and processing instructions to achieve the semantics of a logical
NSH. The label stack is encoded as shown in [RFC8595]. NSH. The label stack is encoded as shown in [RFC8595].
7.6. MPLS Label Swapping/Stacking Operation 7.6. MPLS Label Swapping/Stacking Operation
When a classifier constructs an MPLS label stack for an SFP it starts When a Classifier constructs an MPLS label stack for an SFP it starts
with that SFP' last hop. If the last hop requires an {SPI, SI} label with that SFP's last hop. If the last hop requires an {SPI, SI}
pair for label swapping, it pushes the SI (set to the SI value of the label pair for label swapping, it pushes the SI (set to the SI value
last hop) and the SFP's SPI onto the MPLS label stack. If the last of the last hop) and the SFP's SPI onto the MPLS label stack. If the
hop requires a {context label, SFI label} label pair for label last hop requires a {context label, SFI label} label pair for label
stacking it selects a specific SFIR and pushes that SFIR's SFI label stacking it selects a specific SFIR and pushes that SFIR's SFI label
and context label onto the MPLS label stack. and context label onto the MPLS label stack.
The classifier then moves sequentially back through the SFP one hop The Classifier then moves sequentially back through the SFP one hop
at a time. For each hop, if the hop requires an {SPI, SI]} and there at a time. For each hop, if the hop requires an {SPI, SI]} and there
is an {SPI, SI} at the top of the MPLS label stack, the SI is set to is an {SPI, SI} at the top of the MPLS label stack, the SI is set to
the SI value of the current hop. If there is not an {SPI, SI} at the the SI value of the current hop. If there is not an {SPI, SI} at the
top of the MPLS label stack, it pushes the SI (set to the SI value of top of the MPLS label stack, it pushes the SI (set to the SI value of
the current hop) and the SFP's SPI onto the MPLS label stack. the current hop) and the SFP's SPI onto the MPLS label stack.
If the hop requires a {context label, SFI label}, it selects a If the hop requires a {context label, SFI label}, it selects a
specific SFIR and pushes that SFIR's SFI label and context label onto specific SFIR and pushes that SFIR's SFI label and context label onto
the MPLS label stack. the MPLS label stack.
7.7. Support for MPLS-Encapsulated NSH Packets 7.7. Support for MPLS-Encapsulated NSH Packets
[RFC8596] describes how to transport SFC packets using the NSH over [RFC8596] describes how to transport SFC packets using the NSH over
an MPLS transport network. Signaling MPLS encapsulation of SFC an MPLS transport network. Signaling MPLS encapsulation of SFC
packets using the NSH is also supported by this document by using the packets using the NSH is also supported by this document by using the
"BGP Tunnel Encapsulation Attribute Sub-TLV" with the codepoint 10 "BGP Tunnel Encapsulation Attribute Sub-TLV" with the codepoint 10
(representing "MPLS Label Stack") from the "BGP Tunnel Encapsulation (representing "MPLS Label Stack") from the "BGP Tunnel Encapsulation
Attribute Sub-TLVs" registry defined in [I-D.ietf-idr-tunnel-encaps], Attribute Sub-TLVs" registry defined in [I-D.ietf-idr-tunnel-encaps],
and also using the "SFP Traversal With MPLS Label Stack TLV" and the and also using the "SFP Traversal With MPLS Label Stack TLV" and the
"SPI/SI Representation sub-TLV" with bit 0 set and bit 1 cleared. "SPI/SI Representation sub-TLV" with bit TBD9 set and bit TBD10
cleared.
In this case the MPLS label stack constructed by the SFF to forward a In this case the MPLS label stack constructed by the SFF to forward a
packet to the next SFF on the SFP will consist of the labels needed packet to the next SFF on the SFP will consist of the labels needed
to reach that SFF, and if label stacking is used it will also include to reach that SFF, and if label stacking is used it will also include
the labels advertised in the MPLS Label Stack sub-TLV and the labels the labels advertised in the MPLS Label Stack sub-TLV and the labels
remaining in the stack needed to traverse the remainder of the SFP. remaining in the stack needed to traverse the remainder of the SFP.
8. Examples 8. Examples
Most of the examples in this section use IPv4 addressing. But there
is nothing special about IPv4 in the mechanisms described in this
document, and they are equally applicable to IPv6. A few examples
using IPv6 addressing are provided in Section 8.10.
Assume we have a service function overlay network with four SFFs Assume we have a service function overlay network with four SFFs
(SFF1, SFF3, SFF3, and SFF4). The SFFs have addresses in the (SFF1, SFF3, SFF3, and SFF4). The SFFs have addresses in the
underlay network as follows: underlay network as follows:
SFF1 192.0.2.1 SFF1 192.0.2.1
SFF2 192.0.2.2 SFF2 192.0.2.2
SFF3 192.0.2.3 SFF3 192.0.2.3
SFF4 192.0.2.4 SFF4 192.0.2.4
Each SFF provides access to some SFIs from the four Service Function Each SFF provides access to some SFIs from the four Service Function
skipping to change at page 38, line 32 skipping to change at page 40, line 34
------ ------ ------ ------ ------ ------ ------ ------
| SFI | | SFI | | SFI | | SFI | | SFI | | SFI | | SFI | | SFI |
|SFT=42| |SFT=44| |SFT=43| |SFT=44| |SFT=42| |SFT=44| |SFT=43| |SFT=44|
------ ------ ------ ------ ------ ------ ------ ------
Figure 11: Example Service Function Overlay Network Figure 11: Example Service Function Overlay Network
The SFFs advertise routes to the SFIs they support. So we see the The SFFs advertise routes to the SFIs they support. So we see the
following SFIRs: following SFIRs:
RD = 192.0.2.1:1, SFT = 41 RD = 192.0.2.1/1, SFT = 41
RD = 192.0.2.1:2, SFT = 42 RD = 192.0.2.1/2, SFT = 42
RD = 192.0.2.2:1, SFT = 41 RD = 192.0.2.2/1, SFT = 41
RD = 192.0.2.2:2, SFT = 43 RD = 192.0.2.2/2, SFT = 43
RD = 192.0.2.3:7, SFT = 42 RD = 192.0.2.3/7, SFT = 42
RD = 192.0.2.3:8, SFT = 44 RD = 192.0.2.3/8, SFT = 44
RD = 192.0.2.4:5, SFT = 43 RD = 192.0.2.4/5, SFT = 43
RD = 192.0.2.4:6, SFT = 44 RD = 192.0.2.4/6, SFT = 44
Note that the addressing used for communicating between SFFs is taken Note that the addressing used for communicating between SFFs is taken
from the Tunnel Encapsulation attribute of the SFIR and not from the from the Tunnel Encapsulation attribute of the SFIR and not from the
SFIR-RD. SFIR-RD.
8.1. Example Explicit SFP With No Choices 8.1. Example Explicit SFP With No Choices
Consider the following SFPR. Consider the following SFPR.
SFP1: RD = 198.51.100.1:101, SPI = 15, SFP1: RD = 198.51.100.1/101, SPI = 15,
[SI = 255, SFT = 41, RD = 192.0.2.1:1], [SI = 255, SFT = 41, RD = 192.0.2.1/1],
[SI = 250, SFT = 43, RD = 192.0.2.2:2] [SI = 250, SFT = 43, RD = 192.0.2.2/2]
The Service Function Path consists of an SF of type 41 located at The Service Function Path consists of an SF of type 41 located at
SFF1 followed by an SF of type 43 located at SFF2. This path is SFF1 followed by an SF of type 43 located at SFF2. This path is
fully explicit and each SFF is offered no choice in forwarding packet fully explicit and each SFF is offered no choice in forwarding
along the path. packets along the path.
SFF1 will receive packets on the path from the Classifier and will SFF1 will receive packets on the path from the Classifier and will
identify the path from the SPI (15). The initial SI will be 255 and identify the path from the SPI (15). The initial SI will be 255 and
so SFF1 will deliver the packets to the SFI for SFT 41. so SFF1 will deliver the packets to the SFI for SFT 41.
When the packets are returned to SFF1 by the SFI the SI will be When the packets are returned to SFF1 by the SFI the SI will be
decreased to 250 for the next hop. SFF1 has no flexibility in the decreased to 250 for the next hop. SFF1 has no flexibility in the
choice of SFF to support the next hop SFI and will forward the packet choice of SFF to support the next hop SFI and will forward the packet
to SFF2 which will send the packets to the SFI that supports SFT 43 to SFF2 which will send the packets to the SFI that supports SFT 43
before forwarding the packets to their destinations. before forwarding the packets to their destinations.
8.2. Example SFP With Choice of SFIs 8.2. Example SFP With Choice of SFIs
SFP2: RD = 198.51.100.1:102, SPI = 16, SFP2: RD = 198.51.100.1/102, SPI = 16,
[SI = 255, SFT = 41, RD = 192.0.2.1:1], [SI = 255, SFT = 41, RD = 192.0.2.1/1],
[SI = 250, SFT = 43, {RD = 192.0.2.2:2, [SI = 250, SFT = 43, {RD = 192.0.2.2/2,
RD = 192.0.2.4:5 } ] RD = 192.0.2.4/5 } ]
In this example the path also consists of an SF of type 41 located at In this example the path also consists of an SF of type 41 located at
SFF1 and this is followed by an SF of type 43, but in this case the SFF1 and this is followed by an SF of type 43, but in this case the
SI = 250 contains a choice between the SFI located at SFF2 and the SI = 250 contains a choice between the SFI located at SFF2 and the
SFI located at SFF4. SFI located at SFF4.
SFF1 will receive packets on the path from the Classifier and will SFF1 will receive packets on the path from the Classifier and will
identify the path from the SPI (16). The initial SI will be 255 and identify the path from the SPI (16). The initial SI will be 255 and
so SFF1 will deliver the packets to the SFI for SFT 41. so SFF1 will deliver the packets to the SFI for SFT 41.
When the packets are returned to SFF1 by the SFI the SI will be When the packets are returned to SFF1 by the SFI the SI will be
decreased to 250 for the next hop. SFF1 now has a choice of next hop decreased to 250 for the next hop. SFF1 now has a choice of next hop
SFF to execute the next hop in the path. It can either forward SFF to execute the next hop in the path. It can either forward
packets to SFF2 or SFF4 to execute a function of type 43. It uses packets to SFF2 or SFF4 to execute a function of type 43. It uses
its local load balancing algorithm to make this choice. The chosen its local load balancing algorithm to make this choice. The chosen
SFF will send the packets to the SFI that supports SFT 43 before SFF will send the packets to the SFI that supports SFT 43 before
forwarding the packets to their destinations. forwarding the packets to their destinations.
8.3. Example SFP With Open Choice of SFIs 8.3. Example SFP With Open Choice of SFIs
SFP3: RD = 198.51.100.1:103, SPI = 17, SFP3: RD = 198.51.100.1/103, SPI = 17,
[SI = 255, SFT = 41, RD = 192.0.2.1:1], [SI = 255, SFT = 41, RD = 192.0.2.1/1],
[SI = 250, SFT = 44, RD = 0] [SI = 250, SFT = 44, RD = 0]
In this example the path also consists of an SF of type 41 located at In this example the path also consists of an SF of type 41 located at
SFF1 and this is followed by an SI with an RD of zero and SF of type SFF1 and this is followed by an SI with an RD of zero and SF of type
44. This means that a choice can be made between any SFF that 44. This means that a choice can be made between any SFF that
supports an SFI of type 44. supports an SFI of type 44.
SFF1 will receive packets on the path from the Classifier and will SFF1 will receive packets on the path from the Classifier and will
identify the path from the SPI (17). The initial SI will be 255 and identify the path from the SPI (17). The initial SI will be 255 and
so SFF1 will deliver the packets to the SFI for SFT 41. so SFF1 will deliver the packets to the SFI for SFT 41.
skipping to change at page 40, line 31 skipping to change at page 42, line 33
decreased to 250 for the next hop. SFF1 now has a free choice of decreased to 250 for the next hop. SFF1 now has a free choice of
next hop SFF to execute the next hop in the path selecting between next hop SFF to execute the next hop in the path selecting between
all SFFs that support SFs of type 44. Looking at the SFIRs it has all SFFs that support SFs of type 44. Looking at the SFIRs it has
received, SFF1 knows that SF type 44 is supported by SFF3 and SFF4. received, SFF1 knows that SF type 44 is supported by SFF3 and SFF4.
SFF1 uses its local load balancing algorithm to make this choice. SFF1 uses its local load balancing algorithm to make this choice.
The chosen SFF will send the packets to the SFI that supports SFT 44 The chosen SFF will send the packets to the SFI that supports SFT 44
before forwarding the packets to their destinations. before forwarding the packets to their destinations.
8.4. Example SFP With Choice of SFTs 8.4. Example SFP With Choice of SFTs
SFP4: RD = 198.51.100.1:104, SPI = 18, SFP4: RD = 198.51.100.1/104, SPI = 18,
[SI = 255, SFT = 41, RD = 192.0.2.1:1], [SI = 255, SFT = 41, RD = 192.0.2.1/1],
[SI = 250, {SFT = 43, RD = 192.0.2.2:2, [SI = 250, {SFT = 43, RD = 192.0.2.2/2,
SFT = 44, RD = 192.0.2.3:8 } ] SFT = 44, RD = 192.0.2.3/8 } ]
This example provides a choice of SF type in the second hop in the This example provides a choice of SF type in the second hop in the
path. The SI of 250 indicates a choice between SF type 43 located path. The SI of 250 indicates a choice between SF type 43 located at
through SF2 and SF type 44 located at SF3. SF2 and SF type 44 located at SF3.
SFF1 will receive packets on the path from the Classifier and will SFF1 will receive packets on the path from the Classifier and will
identify the path from the SPI (18). The initial SI will be 255 and identify the path from the SPI (18). The initial SI will be 255 and
so SFF1 will deliver the packets to the SFI for SFT 41. so SFF1 will deliver the packets to the SFI for SFT 41.
When the packets are returned to SFF1 by the SFI the SI will be When the packets are returned to SFF1 by the SFI the SI will be
decreased to 250 for the next hop. SFF1 now has a free choice of decreased to 250 for the next hop. SFF1 now has a free choice of
next hop SFF to execute the next hop in the path selecting between next hop SFF to execute the next hop in the path selecting between
all SFF2 that support an SF of type 43 and SFF3 that supports an SF all SFFs that support an SF of type 43 and SFF3 that supports an SF
of type 44. These may be completely different functions that are to of type 44. These may be completely different functions that are to
be executed dependent on specific conditions, or may be similar be executed dependent on specific conditions, or may be similar
functions identified with different type identifiers (such as functions identified with different type identifiers (such as
firewalls from different vendors). SFF1 uses its local policy and firewalls from different vendors). SFF1 uses its local policy and
load balancing algorithm to make this choice, and may use additional load balancing algorithm to make this choice, and may use additional
information passed back from the local SFI to help inform its information passed back from the local SFI to help inform its
selection. The chosen SFF will send the packets to the SFI that selection. The chosen SFF will send the packets to the SFI that
supports the chose SFT before forwarding the packets to their supports the chose SFT before forwarding the packets to their
destinations. destinations.
8.5. Example Correlated Bidirectional SFPs 8.5. Example Correlated Bidirectional SFPs
SFP5: RD = 198.51.100.1:105, SPI = 19, SFP5: RD = 198.51.100.1/105, SPI = 19,
Assoc-Type = 1, Assoc-RD = 198.51.100.1:106, Assoc-SPI = 20, Assoc-Type = 1, Assoc-RD = 198.51.100.1/106, Assoc-SPI = 20,
[SI = 255, SFT = 41, RD = 192.0.2.1:1], [SI = 255, SFT = 41, RD = 192.0.2.1/1],
[SI = 250, SFT = 43, RD = 192.0.2.2:2] [SI = 250, SFT = 43, RD = 192.0.2.2/2]
SFP6: RD = 198.51.100.1:106, SPI = 20, SFP6: RD = 198.51.100.1/106, SPI = 20,
Assoc-Type = 1, Assoc-RD = 198.51.100.1:105, Assoc-SPI = 19, Assoc-Type = 1, Assoc-RD = 198.51.100.1/105, Assoc-SPI = 19,
[SI = 254, SFT = 43, RD = 192.0.2.2:2], [SI = 254, SFT = 43, RD = 192.0.2.2/2],
[SI = 249, SFT = 41, RD = 192.0.2.1:1] [SI = 249, SFT = 41, RD = 192.0.2.1/1]
This example demonstrates correlation of two SFPs to form a This example demonstrates correlation of two SFPs to form a
bidirectional SFP as described in Section 7.1. bidirectional SFP as described in Section 7.1.
Two SFPRs are advertised by the Controller. They have different SPIs Two SFPRs are advertised by the Controller. They have different SPIs
(19 and 20) so they are known to be separate SFPs, but they both have (19 and 20) so they are known to be separate SFPs, but they both have
Association TLVs with Association Type set to 1 indicating Association TLVs with Association Type set to 1 indicating
bidirectional SFPs. Each has an Associated SFPR-RD fields containing bidirectional SFPs. Each has an Associated SFPR-RD field containing
the value of the other SFPR-RD to correlated the two SFPs as a the value of the other SFPR-RD to correlated the two SFPs as a
bidirectional pair. bidirectional pair.
As can be seen from the SFPRs in this example, the paths are As can be seen from the SFPRs in this example, the paths are
symmetric: the hops in SFP5 appear in the reverse order in SFP6. symmetric: the hops in SFP5 appear in the reverse order in SFP6.
8.6. Example Correlated Asymmetrical Bidirectional SFPs 8.6. Example Correlated Asymmetrical Bidirectional SFPs
SFP7: RD = 198.51.100.1:107, SPI = 21, SFP7: RD = 198.51.100.1/107, SPI = 21,
Assoc-Type = 1, Assoc-RD = 198.51.100.1:108, Assoc-SPI = 22, Assoc-Type = 1, Assoc-RD = 198.51.100.1/108, Assoc-SPI = 22,
[SI = 255, SFT = 41, RD = 192.0.2.1:1], [SI = 255, SFT = 41, RD = 192.0.2.1/1],
[SI = 250, SFT = 43, RD = 192.0.2.2:2] [SI = 250, SFT = 43, RD = 192.0.2.2/2]
SFP8: RD = 198.51.100.1:108, SPI = 22, SFP8: RD = 198.51.100.1/108, SPI = 22,
Assoc-Type = 1, Assoc-RD = 198.51.100.1:107, Assoc-SPI = 21, Assoc-Type = 1, Assoc-RD = 198.51.100.1/107, Assoc-SPI = 21,
[SI = 254, SFT = 44, RD = 192.0.2.4:6], [SI = 254, SFT = 44, RD = 192.0.2.4/6],
[SI = 249, SFT = 41, RD = 192.0.2.1:1] [SI = 249, SFT = 41, RD = 192.0.2.1/1]
Asymmetric bidirectional SFPs can also be created. This example Asymmetric bidirectional SFPs can also be created. This example
shows a pair of SFPs with distinct SPIs (21 and 22) that are shows a pair of SFPs with distinct SPIs (21 and 22) that are
correlated in the same way as in the example in Section 8.5. correlated in the same way as in the example in Section 8.5.
However, unlike in that example, the SFPs are different in each However, unlike in that example, the SFPs are different in each
direction. Both paths include a hop of SF type 41, but SFP7 includes direction. Both paths include a hop of SF type 41, but SFP7 includes
a hop of SF type 43 supported at SFF2 while SFP8 includes a hop of SF a hop of SF type 43 supported at SFF2 while SFP8 includes a hop of SF
type 44 supported at SFF4. type 44 supported at SFF4.
8.7. Example Looping in an SFP 8.7. Example Looping in an SFP
SFP9: RD = 198.51.100.1:109: SPI = 23, SFP9: RD = 198.51.100.1/109, SPI = 23,
[SI = 255, SFT = 41, RD = 192.0.2.1:1], [SI = 255, SFT = 41, RD = 192.0.2.1/1],
[SI = 250, SFT = 44, RD = 192.0.2.4:5], [SI = 250, SFT = 44, RD = 192.0.2.4/5],
[SI = 245, SFT = 1, RD = {SPI=23, SI=255, Rsv=0}], [SI = 245, {SFT = 1, RD = {SPI=23, SI=255, Rsv=0},
[SI = 245, SFT = 42, RD = 192.0.2.3:7] SFT = 42, RD = 192.0.2.3/7 } ]
Looping and jumping are described in Section 6. This example shows Looping and jumping are described in Section 6. This example shows
an SFP that contains an explicit loop-back instruction that is an SFP that contains an explicit loop-back instruction that is
presented as a choice within an SFP hop. presented as a choice within an SFP hop.
The first two hops in the path (SI = 255 and SI = 250) are normal. The first two hops in the path (SI = 255 and SI = 250) are normal.
That is, the packets will be delivered to SFF1 and SFF4 in turn for That is, the packets will be delivered to SFF1 and SFF4 in turn for
execution of SFs of type 41 and 44 respectively. execution of SFs of type 41 and 44 respectively.
The third hop (SI = 245) presents SFF4 with a choice of next hop. It The third hop (SI = 245) presents SFF4 with a choice of next hop. It
skipping to change at page 43, line 16 skipping to change at page 45, line 16
SFF4 must make a choice between these two next hops. Either the SFF4 must make a choice between these two next hops. Either the
packets will be forwarded to SFF3 with the NSH SI decreased to 245 or packets will be forwarded to SFF3 with the NSH SI decreased to 245 or
looped back to SFF1 with the NSH SI reset to 255. This choice will looped back to SFF1 with the NSH SI reset to 255. This choice will
be made according to local policy, information passed back by the be made according to local policy, information passed back by the
local SFI, and details in the packets' metadata that are used to local SFI, and details in the packets' metadata that are used to
prevent infinite looping. prevent infinite looping.
8.8. Example Branching in an SFP 8.8. Example Branching in an SFP
SFP10: RD = 198.51.100.1:110, SPI = 24, SFP10: RD = 198.51.100.1/110, SPI = 24,
[SI = 254, SFT = 42, RD = 192.0.2.3:7], [SI = 254, SFT = 42, RD = 192.0.2.3/7],
[SI = 249, SFT = 43, RD = 192.0.2.2:2] [SI = 249, SFT = 43, RD = 192.0.2.2/2]
SFP11: RD = 198.51.100.1:111, SPI = 25, SFP11: RD = 198.51.100.1/111, SPI = 25,
[SI = 255, SFT = 41, RD = 192.0.2.1:1], [SI = 255, SFT = 41, RD = 192.0.2.1/1],
[SI = 250, SFT = 1, RD = {SPI=24, SI=254, Rsv=0}] [SI = 250, SFT = 1, RD = {SPI=24, SI=254, Rsv=0}]
Branching follows a similar procedure to that for looping (and Branching follows a similar procedure to that for looping (and
jumping) as shown in Section 8.7 however there are two SFPs involved. jumping) as shown in Section 8.7 however there are two SFPs involved.
SFP10 shows a normal path with packets forwarded to SFF3 and SFF2 for SFP10 shows a normal path with packets forwarded to SFF3 and SFF2 for
execution of service functions of type 42 and 43 respectively. execution of service functions of type 42 and 43 respectively.
SFP11 starts as normal (SFF1 for an SF of type 41), but then SFF1 SFP11 starts as normal (SFF1 for an SF of type 41), but then SFF1
processes the next hop in the path and finds a "Change Sequence" processes the next hop in the path and finds a "Change Sequence"
skipping to change at page 44, line 28 skipping to change at page 46, line 28
---------- | SFF1 | | SFF2 | | SFF3 | ---------- | SFF1 | | SFF2 | | SFF3 |
--> | |..|192.0.2.1|...|192.0.2.2|...|192.0.2.3|--> --> | |..|192.0.2.1|...|192.0.2.2|...|192.0.2.3|-->
--> |Classifier| --------- --------- --------- --> |Classifier| --------- --------- ---------
| | | |
---------- ----------
Figure 12: Example Where Choice is Made at the SFF Figure 12: Example Where Choice is Made at the SFF
This leads to the following SFIRs being advertised. This leads to the following SFIRs being advertised.
RD = 192.0.2.1:11, SFT = 41 RD = 192.0.2.1/11, SFT = 41
RD = 192.0.2.2:11, SFT = 42 (for SFIa) RD = 192.0.2.2/11, SFT = 42 (for SFIa)
RD = 192.0.2.2:12, SFT = 42 (for SFIb) RD = 192.0.2.2/12, SFT = 42 (for SFIb)
RD = 192.0.2.2:13, SFT = 42 (for SFIc) RD = 192.0.2.2/13, SFT = 42 (for SFIc)
RD = 192.0.2.3:11, SFT = 43 RD = 192.0.2.3/11, SFT = 43
The controller can create a single forward SFP giving SFF2 the choice The controller can create a single forward SFP (SFP12) giving SFF2
of which SFI to use to provide function of SFT 42 as follows. The the choice of which SFI to use to provide function of SFT 42 as
load-balancing choice between the three available SFIs is assumed to follows. The load-balancing choice between the three available SFIs
be within the capabilities of the SFF and if the SFs are stateful it is assumed to be within the capabilities of the SFF and if the SFs
is assumed that the SFF knows this and arranges load balancing in a are stateful it is assumed that the SFF knows this and arranges load
stable, flow-dependent way. balancing in a stable, flow-dependent way.
SFP12: RD = 198.51.100.1:112, SPI = 26, SFP12: RD = 198.51.100.1/112, SPI = 26,
Assoc-Type = 1, Assoc-RD = 198.51.100.1:113, Assoc-SPI = 27, Assoc-Type = 1, Assoc-RD = 198.51.100.1/113, Assoc-SPI = 27,
[SI = 255, SFT = 41, RD = 192.0.2.1:11], [SI = 255, SFT = 41, RD = 192.0.2.1/11],
[SI = 254, SFT = 42, {RD = 192.0.2.2:11, [SI = 254, SFT = 42, {RD = 192.0.2.2/11,
192.0.2.2:12, 192.0.2.2/12,
192.0.2.2:13 }], 192.0.2.2/13 }],
[SI = 253, SFT = 43, RD = 192.0.2.3:11] [SI = 253, SFT = 43, RD = 192.0.2.3/11]
The reverse SFP in this case may also be created as shown below using The reverse SFP (SFP13) in this case may also be created as shown
association with the forward SFP and giving the load-balancing choice below using association with the forward SFP and giving the load-
to SFF2. This is safe, even in the case that the SFs of type 42 are balancing choice to SFF2. This is safe, even in the case that the
stateful because SFF2 is doing the load balancing in both directions SFs of type 42 are stateful because SFF2 is doing the load balancing
and can apply the same algorithm to ensure that packets associated in both directions and can apply the same algorithm to ensure that
with the same flow use the same SFI regardless of the direction of packets associated with the same flow use the same SFI regardless of
travel. the direction of travel.
How an SFF knows that an attached SFI is stateful is is out of scope SFP13: RD = 198.51.100.1/113, SPI = 27,
of this document. It is assumed that this will form part of the Assoc-Type = 1, Assoc-RD = 198.51.100.1/112, Assoc-SPI = 26,
process by which SFIs are registered as local to SFFs. Section 7.2 [SI = 255, SFT = 43, RD = 192.0.2.3/11],
provides additional observations about the coordination of the use of [SI = 254, SFT = 42, {RD = 192.0.2.2/11,
stateful SFIs in the case of bidirectional SFPs. 192.0.2.2/12,
192.0.2.2/13 }],
[SI = 253, SFT = 41, RD = 192.0.2.1/11]
How an SFF knows that an attached SFI is stateful is out of scope of
this document. It is assumed that this will form part of the process
by which SFIs are registered as local to SFFs. Section 7.2 provides
additional observations about the coordination of the use of stateful
SFIs in the case of bidirectional SFPs.
In general, the problems of load balancing and the selection of the In general, the problems of load balancing and the selection of the
same SFIs in both directions of a bidirectional SFP can be addressed same SFIs in both directions of a bidirectional SFP can be addressed
by using sufficiently precisely specified SFPs (specifying the exact by using sufficiently precisely specified SFPs (specifying the exact
SFIs to use) and suitable programming of the Classifiers at each end SFIs to use) and suitable programming of the Classifiers at each end
of the SFPs to make sure that the matching pair of SFPs are used. of the SFPs to make sure that the matching pair of SFPs are used.
SFP13: RD = 198.51.100.1:113, SPI = 27,
Assoc-Type = 1, Assoc-RD = 198.51.100.1:112, Assoc-SPI = 26,
[SI = 255, SFT = 43, RD = 192.0.2.3:11],
[SI = 254, SFT = 42, {RD = 192.0.2.2:11,
192.0.2.2:12,
192.0.2.2:13 }],
[SI = 253, SFT = 41, RD = 192.0.2.1:11]
8.9.2. Parallel End-to-End SFPs with Shared SFF 8.9.2. Parallel End-to-End SFPs with Shared SFF
The mechanism described in Section 8.9.1 might not be desirable The mechanism described in Section 8.9.1 might not be desirable
because of the functional assumptions it places on SFF2 to be able to because of the functional assumptions it places on SFF2 to be able to
load balance with suitable flow identification, stability, and load balance with suitable flow identification, stability, and
equality in both directions. Instead, it may be desirable to place equality in both directions. Instead, it may be desirable to place
the responsibility for flow classification in the Classifier and let the responsibility for flow classification in the Classifier and let
it determine load balancing with the implied choice of SFIs. it determine load balancing with the implied choice of SFIs.
Consider the network graph as shown in Figure 12 and with the same Consider the network graph as shown in Figure 12 and with the same
set of SFIRs as listed in Section 8.9.1. In this case the controller set of SFIRs as listed in Section 8.9.1. In this case the controller
could specify three forward SFPs with their corresponding associated could specify three forward SFPs with their corresponding associated
reverse SFPs. Each bidirectional pair of SFPs uses a different SFI reverse SFPs. Each bidirectional pair of SFPs uses a different SFI
for the SF of type 42. The controller can instruct the Classifier for the SF of type 42. The controller can instruct the Classifier
how to place traffic on the three bidirectional SFPs, or can treat how to place traffic on the three bidirectional SFPs, or can treat
them as a group leaving the Classifier responsible for balancing the them as a group leaving the Classifier responsible for balancing the
load. load.
SFP14: RD = 198.51.100.1:114, SPI = 28, SFP14: RD = 198.51.100.1/114, SPI = 28,
Assoc-Type = 1, Assoc-RD = 198.51.100.1:117, Assoc-SPI = 31, Assoc-Type = 1, Assoc-RD = 198.51.100.1/117, Assoc-SPI = 31,
[SI = 255, SFT = 41, RD = 192.0.2.1:11], [SI = 255, SFT = 41, RD = 192.0.2.1/11],
[SI = 254, SFT = 42, RD = 192.0.2.2:11], [SI = 254, SFT = 42, RD = 192.0.2.2/11],
[SI = 253, SFT = 43, RD = 192.0.2.3:11] [SI = 253, SFT = 43, RD = 192.0.2.3/11]
SFP15: RD = 198.51.100.1:115, SPI = 29, SFP15: RD = 198.51.100.1/115, SPI = 29,
Assoc-Type = 1, Assoc-RD = 198.51.100.1:118, Assoc-SPI = 32, Assoc-Type = 1, Assoc-RD = 198.51.100.1/118, Assoc-SPI = 32,
[SI = 255, SFT = 41, RD = 192.0.2.1:11], [SI = 255, SFT = 41, RD = 192.0.2.1/11],
[SI = 254, SFT = 42, RD = 192.0.2.2:12], [SI = 254, SFT = 42, RD = 192.0.2.2/12],
[SI = 253, SFT = 43, RD = 192.0.2.3:11] [SI = 253, SFT = 43, RD = 192.0.2.3/11]
SFP16: RD = 198.51.100.1:116, SPI = 30, SFP16: RD = 198.51.100.1/116, SPI = 30,
Assoc-Type = 1, Assoc-RD = 198.51.100.1:119, Assoc-SPI = 33, Assoc-Type = 1, Assoc-RD = 198.51.100.1/119, Assoc-SPI = 33,
[SI = 255, SFT = 41, RD = 192.0.2.1:11], [SI = 255, SFT = 41, RD = 192.0.2.1/11],
[SI = 254, SFT = 42, RD = 192.0.2.2:13], [SI = 254, SFT = 42, RD = 192.0.2.2/13],
[SI = 253, SFT = 43, RD = 192.0.2.3:11] [SI = 253, SFT = 43, RD = 192.0.2.3/11]
SFP17: RD = 198.51.100.1:117, SPI = 31, SFP17: RD = 198.51.100.1/117, SPI = 31,
Assoc-Type = 1, Assoc-RD = 198.51.100.1:114, Assoc-SPI = 28, Assoc-Type = 1, Assoc-RD = 198.51.100.1/114, Assoc-SPI = 28,
[SI = 255, SFT = 43, RD = 192.0.2.3:11], [SI = 255, SFT = 43, RD = 192.0.2.3/11],
[SI = 254, SFT = 42, RD = 192.0.2.2:11], [SI = 254, SFT = 42, RD = 192.0.2.2/11],
[SI = 253, SFT = 41, RD = 192.0.2.1:11] [SI = 253, SFT = 41, RD = 192.0.2.1/11]
SFP18: RD = 198.51.100.1:118, SPI = 32, SFP18: RD = 198.51.100.1/118, SPI = 32,
Assoc-Type = 1, Assoc-RD = 198.51.100.1:115, Assoc-SPI = 29, Assoc-Type = 1, Assoc-RD = 198.51.100.1/115, Assoc-SPI = 29,
[SI = 255, SFT = 43, RD = 192.0.2.3:11], [SI = 255, SFT = 43, RD = 192.0.2.3/11],
[SI = 254, SFT = 42, RD = 192.0.2.2:12], [SI = 254, SFT = 42, RD = 192.0.2.2/12],
[SI = 253, SFT = 41, RD = 192.0.2.1:11] [SI = 253, SFT = 41, RD = 192.0.2.1/11]
SFP19: RD = 198.51.100.1:119, SPI = 33, SFP19: RD = 198.51.100.1/119, SPI = 33,
Assoc-Type = 1, Assoc-RD = 198.51.100.1:116, Assoc-SPI = 30, Assoc-Type = 1, Assoc-RD = 198.51.100.1/116, Assoc-SPI = 30,
[SI = 255, SFT = 43, RD = 192.0.2.3:11], [SI = 255, SFT = 43, RD = 192.0.2.3/11],
[SI = 254, SFT = 42, RD = 192.0.2.2:13], [SI = 254, SFT = 42, RD = 192.0.2.2/13],
[SI = 253, SFT = 41, RD = 192.0.2.1:11] [SI = 253, SFT = 41, RD = 192.0.2.1/11]
8.9.3. Parallel End-to-End SFPs with Separate SFFs 8.9.3. Parallel End-to-End SFPs with Separate SFFs
While the examples in Section 8.9.1 and Section 8.9.2 place the While the examples in Section 8.9.1 and Section 8.9.2 place the
choice of SFI as subtended from the same SFF, it is also possible choice of SFI as subtended from the same SFF, it is also possible
that the SFIs are each subtended from a different SFF as shown in that the SFIs are each subtended from a different SFF as shown in
Figure 13. In this case it is harder to coordinate the choices for Figure 13. In this case it is harder to coordinate the choices for
forward and reverse paths without some form of coordination between forward and reverse paths without some form of coordination between
SFF1 and SFF3. Therefore it would be normal to consider end-to-end SFF1 and SFF3. Therefore it would be normal to consider end-to-end
parallel SFPs as described in Section 8.9.2. parallel SFPs as described in Section 8.9.2.
skipping to change at page 48, line 5 skipping to change at page 50, line 5
| |
------ ------
| SFIc | | SFIc |
|SFT=42| |SFT=42|
------ ------
Figure 13: Second Example With Parallel End-to-End SFPs Figure 13: Second Example With Parallel End-to-End SFPs
In this case, five SFIRs are advertised as follows: In this case, five SFIRs are advertised as follows:
RD = 192.0.2.1:11, SFT = 41 RD = 192.0.2.1/11, SFT = 41
RD = 192.0.2.5:11, SFT = 42 (for SFIa) RD = 192.0.2.5/11, SFT = 42 (for SFIa)
RD = 192.0.2.6:11, SFT = 42 (for SFIb) RD = 192.0.2.6/11, SFT = 42 (for SFIb)
RD = 192.0.2.7:11, SFT = 42 (for SFIc) RD = 192.0.2.7/11, SFT = 42 (for SFIc)
RD = 192.0.2.3:11, SFT = 43 RD = 192.0.2.3/11, SFT = 43
In this case the controller could specify three forward SFPs with In this case the controller could specify three forward SFPs with
their corresponding associated reverse SFPs. Each bidirectional pair their corresponding associated reverse SFPs. Each bidirectional pair
of SFPs uses a different SFF and SFI for middle hop (for an SF of of SFPs uses a different SFF and SFI for middle hop (for an SF of
type 42). The controller can instruct the Classifier how to place type 42). The controller can instruct the Classifier how to place
traffic on the three bidirectional SFPs, or can treat them as a group traffic on the three bidirectional SFPs, or can treat them as a group
leaving the Classifier responsible for balancing the load. leaving the Classifier responsible for balancing the load.
SFP20: RD = 198.51.100.1:120, SPI = 34, SFP20: RD = 198.51.100.1/120, SPI = 34,
Assoc-Type = 1, Assoc-RD = 198.51.100.1:123, Assoc-SPI = 37, Assoc-Type = 1, Assoc-RD = 198.51.100.1/123, Assoc-SPI = 37,
[SI = 255, SFT = 41, RD = 192.0.2.1:11], [SI = 255, SFT = 41, RD = 192.0.2.1/11],
[SI = 254, SFT = 42, RD = 192.0.2.5:11], [SI = 254, SFT = 42, RD = 192.0.2.5/11],
[SI = 253, SFT = 43, RD = 192.0.2.3:11] [SI = 253, SFT = 43, RD = 192.0.2.3/11]
SFP21: RD = 198.51.100.1:121, SPI = 35, SFP21: RD = 198.51.100.1/121, SPI = 35,
Assoc-Type = 1, Assoc-RD = 198.51.100.1:124, Assoc-SPI = 38, Assoc-Type = 1, Assoc-RD = 198.51.100.1/124, Assoc-SPI = 38,
[SI = 255, SFT = 41, RD = 192.0.2.1:11], [SI = 255, SFT = 41, RD = 192.0.2.1/11],
[SI = 254, SFT = 42, RD = 192.0.2.6:11], [SI = 254, SFT = 42, RD = 192.0.2.6/11],
[SI = 253, SFT = 43, RD = 192.0.2.3:11] [SI = 253, SFT = 43, RD = 192.0.2.3/11]
SFP22: RD = 198.51.100.1:122, SPI = 36, SFP22: RD = 198.51.100.1/122, SPI = 36,
Assoc-Type = 1, Assoc-RD = 198.51.100.1:125, Assoc-SPI = 39, Assoc-Type = 1, Assoc-RD = 198.51.100.1/125, Assoc-SPI = 39,
[SI = 255, SFT = 41, RD = 192.0.2.1:11], [SI = 255, SFT = 41, RD = 192.0.2.1/11],
[SI = 254, SFT = 42, RD = 192.0.2.7:11], [SI = 254, SFT = 42, RD = 192.0.2.7/11],
[SI = 253, SFT = 43, RD = 192.0.2.3:11] [SI = 253, SFT = 43, RD = 192.0.2.3/11]
SFP23: RD = 198.51.100.1:123, SPI = 37, SFP23: RD = 198.51.100.1/123, SPI = 37,
Assoc-Type = 1, Assoc-RD = 198.51.100.1:120, Assoc-SPI = 34, Assoc-Type = 1, Assoc-RD = 198.51.100.1/120, Assoc-SPI = 34,
[SI = 255, SFT = 43, RD = 192.0.2.3:11], [SI = 255, SFT = 43, RD = 192.0.2.3/11],
[SI = 254, SFT = 42, RD = 192.0.2.5:11], [SI = 254, SFT = 42, RD = 192.0.2.5/11],
[SI = 253, SFT = 41, RD = 192.0.2.1:11] [SI = 253, SFT = 41, RD = 192.0.2.1/11]
SFP24: RD = 198.51.100.1:124, SPI = 38, SFP24: RD = 198.51.100.1/124, SPI = 38,
Assoc-Type = 1, Assoc-RD = 198.51.100.1:121, Assoc-SPI = 35, Assoc-Type = 1, Assoc-RD = 198.51.100.1/121, Assoc-SPI = 35,
[SI = 255, SFT = 43, RD = 192.0.2.3:11], [SI = 255, SFT = 43, RD = 192.0.2.3/11],
[SI = 254, SFT = 42, RD = 192.0.2.6:11], [SI = 254, SFT = 42, RD = 192.0.2.6/11],
[SI = 253, SFT = 41, RD = 192.0.2.1:11] [SI = 253, SFT = 41, RD = 192.0.2.1/11]
SFP25: RD = 198.51.100.1:125, SPI = 39, SFP25: RD = 198.51.100.1/125, SPI = 39,
Assoc-Type = 1, Assoc-RD = 198.51.100.1:122, Assoc-SPI = 36, Assoc-Type = 1, Assoc-RD = 198.51.100.1/122, Assoc-SPI = 36,
[SI = 255, SFT = 43, RD = 192.0.2.3:11], [SI = 255, SFT = 43, RD = 192.0.2.3/11],
[SI = 254, SFT = 42, RD = 192.0.2.7:11], [SI = 254, SFT = 42, RD = 192.0.2.7/11],
[SI = 253, SFT = 41, RD = 192.0.2.1:11] [SI = 253, SFT = 41, RD = 192.0.2.1/11]
8.9.4. Parallel SFPs Downstream of the Choice 8.9.4. Parallel SFPs Downstream of the Choice
The mechanism of parallel SFPs demonstrated in Section 8.9.3 is The mechanism of parallel SFPs demonstrated in Section 8.9.3 is
perfectly functional and may be practical in many environments. perfectly functional and may be practical in many environments.
However, there may be scaling concerns because of the large amount of However, there may be scaling concerns because of the large amount of
state (knowledge of SFPs, i.e., SFPR advertisements retained) if state (knowledge of SFPs, i.e., SFPR advertisements retained) if
there is a very large amount of choice of SFIs (for example, tens of there is a very large amount of choice of SFIs (for example, tens of
instances of the same stateful SF), or if there are multiple choices instances of the same stateful SF), or if there are multiple choices
of stateful SF along a path. This situation may be mitigated using of stateful SF along a path. This situation may be mitigated using
skipping to change at page 50, line 42 skipping to change at page 52, line 42
| |
------ ------
| SFIc | | SFIc |
|SFT=43| |SFT=43|
------ ------
Figure 14: Example With Parallel SFPs Downstream of Choice Figure 14: Example With Parallel SFPs Downstream of Choice
The six SFIs are advertised as follows: The six SFIs are advertised as follows:
RD = 192.0.2.1:11, SFT = 41 RD = 192.0.2.1/11, SFT = 41
RD = 192.0.2.2:11, SFT = 42 RD = 192.0.2.2/11, SFT = 42
RD = 192.0.2.5:11, SFT = 43 (for SFIa) RD = 192.0.2.5/11, SFT = 43 (for SFIa)
RD = 192.0.2.6:11, SFT = 43 (for SFIb) RD = 192.0.2.6/11, SFT = 43 (for SFIb)
RD = 192.0.2.7:11, SFT = 43 (for SFIc) RD = 192.0.2.7/11, SFT = 43 (for SFIc)
RD = 192.0.2.3:11, SFT = 44 RD = 192.0.2.3/11, SFT = 44
SFF2 is the point at which a load balancing choice must be made. So SFF2 is the point at which a load balancing choice must be made. So
"tail-end" SFPs are constructed as follows. Each takes in a "tail-end" SFPs are constructed as follows. Each takes in a
different SFF that provides access to an SF of type 43. different SFF that provides access to an SF of type 43.
SFP26: RD = 198.51.100.1:126, SPI = 40, SFP26: RD = 198.51.100.1/126, SPI = 40,
Assoc-Type = 1, Assoc-RD = 198.51.100.1:130, Assoc-SPI = 44, Assoc-Type = 1, Assoc-RD = 198.51.100.1/130, Assoc-SPI = 44,
[SI = 255, SFT = 43, RD = 192.0.2.5:11], [SI = 255, SFT = 43, RD = 192.0.2.5/11],
[SI = 254, SFT = 44, RD = 192.0.2.3:11] [SI = 254, SFT = 44, RD = 192.0.2.3/11]
SFP27: RD = 198.51.100.1:127, SPI = 41, SFP27: RD = 198.51.100.1/127, SPI = 41,
Assoc-Type = 1, Assoc-RD = 198.51.100.1:131, Assoc-SPI = 45, Assoc-Type = 1, Assoc-RD = 198.51.100.1/131, Assoc-SPI = 45,
[SI = 255, SFT = 43, RD = 192.0.2.6:11], [SI = 255, SFT = 43, RD = 192.0.2.6/11],
[SI = 254, SFT = 44, RD = 192.0.2.3:11] [SI = 254, SFT = 44, RD = 192.0.2.3/11]
SFP28: RD = 198.51.100.1:128, SPI = 42, SFP28: RD = 198.51.100.1/128, SPI = 42,
Assoc-Type = 1, Assoc-RD = 198.51.100.1:132, Assoc-SPI = 46, Assoc-Type = 1, Assoc-RD = 198.51.100.1/132, Assoc-SPI = 46,
[SI = 255, SFT = 43, RD = 192.0.2.7:11], [SI = 255, SFT = 43, RD = 192.0.2.7/11],
[SI = 254, SFT = 44, RD = 192.0.2.3:11] [SI = 254, SFT = 44, RD = 192.0.2.3/11]
Now an end-to-end SFP with load balancing choice can be constructed Now an end-to-end SFP with load balancing choice can be constructed
as follows. The choice made by SFF2 is expressed in terms of as follows. The choice made by SFF2 is expressed in terms of
entering one of the three "tail end" SFPs. entering one of the three "tail end" SFPs.
SFP29: RD = 198.51.100.1:129, SPI = 43, SFP29: RD = 198.51.100.1/129, SPI = 43,
[SI = 255, SFT = 41, RD = 192.0.2.1:11], [SI = 255, SFT = 41, RD = 192.0.2.1/11],
[SI = 254, SFT = 42, RD = 192.0.2.2:11], [SI = 254, SFT = 42, RD = 192.0.2.2/11],
[SI = 253, {SFT = 1, RD = {SPI=40, SI=255, Rsv=0}, [SI = 253, {SFT = 1, RD = {SPI=40, SI=255, Rsv=0},
RD = {SPI=41, SI=255, Rsv=0}, RD = {SPI=41, SI=255, Rsv=0},
RD = {SPI=42, SI=255, Rsv=0} } ] RD = {SPI=42, SI=255, Rsv=0} } ]
Now, despite the load balancing choice being made other than at the Now, despite the load balancing choice being made other than at the
initial classifier, it is possible for the reverse SFPs to be well- initial Classifier, it is possible for the reverse SFPs to be well-
constructed without any ambiguity. The three reverse paths appear as constructed without any ambiguity. The three reverse paths appear as
follows. follows.
SFP30: RD = 198.51.100.1:130, SPI = 44, SFP30: RD = 198.51.100.1/130, SPI = 44,
Assoc-Type = 1, Assoc-RD = 198.51.100.1:126, Assoc-SPI = 40, Assoc-Type = 1, Assoc-RD = 198.51.100.1/126, Assoc-SPI = 40,
[SI = 255, SFT = 44, RD = 192.0.2.4:11], [SI = 255, SFT = 44, RD = 192.0.2.4/11],
[SI = 254, SFT = 43, RD = 192.0.2.5:11], [SI = 254, SFT = 43, RD = 192.0.2.5/11],
[SI = 253, SFT = 42, RD = 192.0.2.2:11], [SI = 253, SFT = 42, RD = 192.0.2.2/11],
[SI = 252, SFT = 41, RD = 192.0.2.1:11] [SI = 252, SFT = 41, RD = 192.0.2.1/11]
SFP31: RD = 198.51.100.1:131, SPI = 45, SFP31: RD = 198.51.100.1/131, SPI = 45,
Assoc-Type = 1, Assoc-RD = 198.51.100.1:127, Assoc-SPI = 41, Assoc-Type = 1, Assoc-RD = 198.51.100.1/127, Assoc-SPI = 41,
[SI = 255, SFT = 44, RD = 192.0.2.4:11], [SI = 255, SFT = 44, RD = 192.0.2.4/11],
[SI = 254, SFT = 43, RD = 192.0.2.6:11], [SI = 254, SFT = 43, RD = 192.0.2.6/11],
[SI = 253, SFT = 42, RD = 192.0.2.2:11], [SI = 253, SFT = 42, RD = 192.0.2.2/11],
[SI = 252, SFT = 41, RD = 192.0.2.1:11] [SI = 252, SFT = 41, RD = 192.0.2.1/11]
SFP32: RD = 198.51.100.1:132, SPI = 46, SFP32: RD = 198.51.100.1/132, SPI = 46,
Assoc-Type = 1, Assoc-RD = 198.51.100.1:128, Assoc-SPI = 42, Assoc-Type = 1, Assoc-RD = 198.51.100.1/128, Assoc-SPI = 42,
[SI = 255, SFT = 44, RD = 192.0.2.4:11], [SI = 255, SFT = 44, RD = 192.0.2.4/11],
[SI = 254, SFT = 43, RD = 192.0.2.7:11], [SI = 254, SFT = 43, RD = 192.0.2.7/11],
[SI = 253, SFT = 42, RD = 192.0.2.2:11], [SI = 253, SFT = 42, RD = 192.0.2.2/11],
[SI = 252, SFT = 41, RD = 192.0.2.1:11] [SI = 252, SFT = 41, RD = 192.0.2.1/11]
8.10. Examples Using IPv6 Addressing
This section provides several examples using IPv6 addressing. As
will be seen from the examples, there is nothing special or clever
about using IPv6 addressing rather than IPv4 addressing.
The reference network for these IPv6 examples is based on that
described at the top of Section 8 and shown in Figure 11.
Assume we have a service function overlay network with four SFFs
(SFF1, SFF3, SFF3, and SFF4). The SFFs have addresses in the
underlay network as follows:
SFF1 2001:db8::192:0:2:1
SFF2 2001:db8::192:0:2:2
SFF3 2001:db8::192:0:2:3
SFF4 2001:db8::192:0:2:4
Each SFF provides access to some SFIs from the four Service Function
Types SFT=41, SFT=42, SFT=43, and SFT=44 just as before:
SFF1 SFT=41 and SFT=42
SFF2 SFT=41 and SFT=43
SFF3 SFT=42 and SFT=44
SFF4 SFT=43 and SFT=44
The service function network also contains a Controller with address
2001:db8::198:51:100:1.
This example service function overlay network is shown in Figure 15.
------------------------
| Controller |
| 2001:db8::198:51:100:1 |
------------------------
------ ------ ------ ------
| SFI | | SFI | | SFI | | SFI |
|SFT=41| |SFT=42| |SFT=41| |SFT=43|
------ ------ ------ ------
\ / \ /
------------------- -------------------
| SFF1 | | SFF2 |
|2001:db8::192:0:2:1| |2001:db8::192:0:2:2|
------------------- -------------------
----------
Packet --> | | -->
Flows --> |Classifier| -->Dest
| | -->
----------
------------------- -------------------
| SFF3 | | SFF4 |
|2001:db8::192:0:2:3| |2001:db8::192:0:2:4|
------------------- -------------------
/ \ / \
------ ------ ------ ------
| SFI | | SFI | | SFI | | SFI |
|SFT=42| |SFT=44| |SFT=43| |SFT=44|
------ ------ ------ ------
Figure 15: Example Service Function Overlay Network
The SFFs advertise routes to the SFIs they support. So we see the
following SFIRs:
RD = 2001:db8::192:0:2:1/1, SFT = 41
RD = 2001:db8::192:0:2:1/2, SFT = 42
RD = 2001:db8::192:0:2:2/1, SFT = 41
RD = 2001:db8::192:0:2:2/2, SFT = 43
RD = 2001:db8::192:0:2:3/7, SFT = 42
RD = 2001:db8::192:0:2:3/8, SFT = 44
RD = 2001:db8::192:0:2:4/5, SFT = 43
RD = 2001:db8::192:0:2:4/6, SFT = 44
Note that the addressing used for communicating between SFFs is taken
from the Tunnel Encapsulation attribute of the SFIR and not from the
SFIR-RD.
8.10.1. Example Explicit SFP With No Choices
Consider the following SFPR similar to that in Section 8.1.
SFP1: RD = 2001:db8::198:51:100:1/101, SPI = 15,
[SI = 255, SFT = 41, RD = 2001:db8::192:0:2:1/1],
[SI = 250, SFT = 43, RD = 2001:db8::192:0:2:2/2]
The Service Function Path consists of an SF of type 41 located at
SFF1 followed by an SF of type 43 located at SFF2. This path is
fully explicit and each SFF is offered no choice in forwarding packet
along the path.
SFF1 will receive packets on the path from the Classifier and will
identify the path from the SPI (15). The initial SI will be 255 and
so SFF1 will deliver the packets to the SFI for SFT 41.
When the packets are returned to SFF1 by the SFI the SI will be
decreased to 250 for the next hop. SFF1 has no flexibility in the
choice of SFF to support the next hop SFI and will forward the packet
to SFF2 which will send the packets to the SFI that supports SFT 43
before forwarding the packets to their destinations.
8.10.2. Example SFP With Choice of SFIs
SFP2: RD = 2001:db8::198:51:100:1/102, SPI = 16,
[SI = 255, SFT = 41, RD = 2001:db8::192:0:2:1/1],
[SI = 250, SFT = 43, {RD = 2001:db8::192:0:2:2/2,
RD = 2001:db8::192:0:2:4/5 } ]
In this example, like that in Section 8.2, the path also consists of
an SF of type 41 located at SFF1 and this is followed by an SF of
type 43, but in this case the SI = 250 contains a choice between the
SFI located at SFF2 and the SFI located at SFF4.
SFF1 will receive packets on the path from the Classifier and will
identify the path from the SPI (16). The initial SI will be 255 and
so SFF1 will deliver the packets to the SFI for SFT 41.
When the packets are returned to SFF1 by the SFI the SI will be
decreased to 250 for the next hop. SFF1 now has a choice of next hop
SFF to execute the next hop in the path. It can either forward
packets to SFF2 or SFF4 to execute a function of type 43. It uses
its local load balancing algorithm to make this choice. The chosen
SFF will send the packets to the SFI that supports SFT 43 before
forwarding the packets to their destinations.
8.10.3. Example SFP With Open Choice of SFIs
SFP3: RD = 2001:db8::198:51:100:1/103, SPI = 17,
[SI = 255, SFT = 41, RD = 2001:db8::192:0:2:1/1],
[SI = 250, SFT = 44, RD = 0]
In this example, like that in Section 8.3 the path also consists of
an SF of type 41 located at SFF1 and this is followed by an SI with
an RD of zero and SF of type 44. This means that a choice can be
made between any SFF that supports an SFI of type 44.
SFF1 will receive packets on the path from the Classifier and will
identify the path from the SPI (17). The initial SI will be 255 and
so SFF1 will deliver the packets to the SFI for SFT 41.
When the packets are returned to SFF1 by the SFI the SI will be
decreased to 250 for the next hop. SFF1 now has a free choice of
next hop SFF to execute the next hop in the path selecting between
all SFFs that support SFs of type 44. Looking at the SFIRs it has
received, SFF1 knows that SF type 44 is supported by SFF3 and SFF4.
SFF1 uses its local load balancing algorithm to make this choice.
The chosen SFF will send the packets to the SFI that supports SFT 44
before forwarding the packets to their destinations.
8.10.4. Example SFP With Choice of SFTs
SFP4: RD = 2001:db8::198:51:100:1/104, SPI = 18,
[SI = 255, SFT = 41, RD = 2001:db8::192:0:2:1/1],
[SI = 250, {SFT = 43, RD = 2001:db8::192:0:2:2/2,
SFT = 44, RD = 2001:db8::192:0:2:3/8 } ]
This example, similar to that in Section 8.4 provides a choice of SF
type in the second hop in the path. The SI of 250 indicates a choice
between SF type 43 located through SF2 and SF type 44 located at SF3.
SFF1 will receive packets on the path from the Classifier and will
identify the path from the SPI (18). The initial SI will be 255 and
so SFF1 will deliver the packets to the SFI for SFT 41.
When the packets are returned to SFF1 by the SFI the SI will be
decreased to 250 for the next hop. SFF1 now has a free choice of
next hop SFF to execute the next hop in the path selecting between
all SFF2 that support an SF of type 43 and SFF3 that supports an SF
of type 44. These may be completely different functions that are to
be executed dependent on specific conditions, or may be similar
functions identified with different type identifiers (such as
firewalls from different vendors). SFF1 uses its local policy and
load balancing algorithm to make this choice, and may use additional
information passed back from the local SFI to help inform its
selection. The chosen SFF will send the packets to the SFI that
supports the chose SFT before forwarding the packets to their
destinations.
9. Security Considerations 9. Security Considerations
This document inherits all the security considerations discussed in The mechanisms in this document use BGP for the control plane.
the documents that specify BGP, the documents that specify BGP Hence, techniques such as those discussed in [RFC5925]] can be used
Multiprotocol Extensions, and the documents that define the to help authenticate BGP sessions and thus the messages between BGP
attributes that are carried by BGP UPDATEs of the SFC AFI/SAFI. For peers, making it harder to spoof updates (which could be used to
more information look in [RFC4271], [RFC4760], and install bogus SFPs or to advertise false SIs) or withdrawals.
Further discussion of security considerations for BGP may be found in
the BGP specification itself [RFC4271] and in the security analysis
for BGP [RFC4272]. The original discussion of the use of the TCP MD5
signature option to protect BGP sessions is found in [RFC5925], while
[RFC6952] includes an analysis of BGP keying and authentication
issues.
Additionally, this document depends on other documents that specify
BGP Multiprotocol Extensions and the documents that define the
attributes that are carried by BGP UPDATEs of the SFC AFI/SAFI.
Relevant additional security measures are considered in [RFC4760] and
[I-D.ietf-idr-tunnel-encaps]. [I-D.ietf-idr-tunnel-encaps].
This document does not fundamentally change the security behavior of
BGP deployments which depend considerably on the network operator's
perception of risk in their network. It may be observed that the
application of the mechanisms described in this document are scoped
to a single domain as implied by [RFC8300] noted in Section 2.1.
Applicability of BGP within a single domain may enable a network
operator to make easier and more consistent decisions about what
security measures to apply, and the domain boundary, which BGP
enforces by definition, provides a safeguard that prevents leakage of
SFC programming in either direction at the boundary.
Service Function Chaining provides a significant attack opportunity: Service Function Chaining provides a significant attack opportunity:
packets can be diverted from their normal paths through the network, packets can be diverted from their normal paths through the network,
can be made to execute unexpected functions, and the functions that packets can be made to execute unexpected functions, and the
are instantiated in software can be subverted. However, this functions that are instantiated in software can be subverted.
specification does not change the existence of Service Function However, this specification does not change the existence of Service
Chaining and security issues specific to Service Function Chaining Function Chaining and security issues specific to Service Function
are covered in [RFC7665] and [RFC8300]. Chaining are covered in [RFC7665] and [RFC8300].
This document defines a control plane for Service Function Chaining. This document defines a control plane for Service Function Chaining.
Clearly, this provides an attack vector for a Service Function Clearly, this provides an attack vector for a Service Function
Chaining system as an attack on this control plane could be used to Chaining system as an attack on this control plane could be used to
make the system misbehave. Thus, the security of the BGP system is make the system misbehave. Thus, the security of the BGP system is
critically important to the security of the whole Service Function critically important to the security of the whole Service Function
Chaining system. The control plane mechanisms are very similar to Chaining system. The control plane mechanisms are very similar to
those used for BGP/MPLS IP VPNs as described in [RFC4364], and so the those used for BGP/MPLS IP VPNs as described in [RFC4364], and so the
security considerations in that document (Section 23) provide good security considerations in that document (Section 13) provide good
guidance for securing SFC systems reliant on this specification. guidance for securing SFC systems reliant on this specification. Of
particular relevance is the need to securely distinguish between
messages intended for the control of different SFC overlays which is
similar to the need to distinguish between different VPNs.
Section 19 of [RFC7432] also provides useful guidance on the use of Section 19 of [RFC7432] also provides useful guidance on the use of
BGP in a similar environment. BGP in a similar environment.
Note that a component of an SFC system that uses the procedures Note that a component of an SFC system that uses the procedures
described in this document also requires communications between a described in this document also requires communications between a
controller and the SFC network elements. This communication covers controller and the SFC network elements. This communication covers
instructing the Classifiers using BGP mechanisms (see Section 7.4) instructing the Classifiers using BGP mechanisms (see Section 7.4),
which is covered by BGP security. But it also covers other thus the use of BGP security is strongly recommended.. But it also
mechanisms for programming the Classifier and instructing the SFFs covers other mechanisms for programming the Classifier and
and SFs (for example, to bind SFs to an SFF, and to cause the instructing the SFFs and SFs (for example, to bind SFs to an SFF, and
establishment of tunnels between SFFs). This document does not cover to cause the establishment of tunnels between SFFs). This document
these latter mechanisms and so their security is out of scope, but it does not cover these latter mechanisms and so their security is out
should be noted that these communications provide an attack vector on of scope, but it should be noted that these communications provide an
the SFC system and so attention must be paid to ensuring that they attack vector on the SFC system and so attention must be paid to
are secure. ensuring that they are secure.
There is an intrinsic assumption in SFC systems that nodes that
announce support for specific SFs actually offer those functions, and
that SFs are not, themselves, attacked or subverted. This is
particularly important when the SFs are implemented as software that
can be updated. Protection against this sort of concern forms part
of the security of any SFC system and so is outside the scope of the
control plane mechanisms described in this document.
Similarly, there is a vulnerablity if a rogue or subverted controller
announces SFPs especially if that controller "takes over" an existing
SFP and changes its contents. This is corresponds to a rogue BGP
speaker entering a routing system, or even to a Route Reflector
becoming subverted. Protection mechanisms, as above, include
securing BGP sessions and protecting software loads on the
controllers.
Lastly, note that Section 3.2.2 makes two operational suggestions
that have implications for the stability and security of the
mechanisms described in this document:
o That modifications to active SFPs not be made.
o That SPIs not be immediately re-used.
10. IANA Considerations 10. IANA Considerations
10.1. New BGP AF/SAFI 10.1. New BGP AF/SAFI
IANA maintains a registry of "Address Family Numbers". IANA is IANA maintains a registry of "Address Family Numbers". IANA is
requested to assign a new Address Family Number from the "Standards requested to assign a new Address Family Number from the "Standards
Action" range called "BGP SFC" (TBD1 in this document) with this Action" range called "BGP SFC" (TBD1 in this document) with this
document as a reference. document as a reference.
skipping to change at page 55, line 39 skipping to change at page 63, line 4
This document should be given as a reference for this registry. This document should be given as a reference for this registry.
The new registry should track: The new registry should track:
o Value o Value
o Name o Name
o Reference Document or Contact o Reference Document or Contact
o Registration Date o Registration Date
The registry should initially be populated as follows: The registry should initially be populated as follows:
Value | Name | Reference | Date Value | Name | Reference | Date
------+-----------------------+---------------+--------------- ------+-------------------------------+------------+---------------
1 | Change Sequence | [This.I-D] | Date-to-be-set 0 | Reserved, not to be allocated | [This.I-D] | Date-to-be-set
1 | Change Sequence | [This.I-D] | Date-to-be-set
2-31 | Unassigned | |
32 | Classifier | [This.I-D] | Date-to-be-set
33 | Firewall | [This.I-D] | Date-to-be-set
34 | Load balancer | [This.I-D] | Date-to-be-set
35 | Deep packet inspection engine | [This.I-D] | Date-to-be-set
36 | Penalty box | [This.I-D] | Date-to-be-set
37 | WAN accelerator | [This.I-D] | Date-to-be-set
38 | Application accelerator | [This.I-D] | Date-to-be-set
39 | TCP optimizer | [This.I-D] | Date-to-be-set
40 | Network Address Translator | [This.I-D] | Date-to-be-set
41 | NAT44 | [This.I-D] | Date-to-be-set
42 | NAT64 | [This.I-D] | Date-to-be-set
43 | NPTv6 | [This.I-D] | Date-to-be-set
44 | Lawful intercept | [This.I-D] | Date-to-be-set
45 | HOST_ID injection | [This.I-D] | Date-to-be-set
46 | HTTP header enrichment | [This.I-D] | Date-to-be-set
47 | Caching engine | [This.I-D] | Date-to-be-set
48- | | |
-65534|Unassigned | |
65535 | Reserved, not to be allocated | [This.I-D] | Date-to-be-set
10.6. New Generic Transitive Experimental Use Extended Community Sub- 10.6. New Generic Transitive Experimental Use Extended Community Sub-
Types Types
IANA maintains a registry of "Border Gateway Protocol (BGP) IANA maintains a registry of "Border Gateway Protocol (BGP)
Parameters" with a subregistry of "Generic Transitive Experimental Parameters" with a subregistry of "Generic Transitive Experimental
Use Extended Community Sub-Type". IANA is requested to assign a new Use Extended Community Sub-Type". IANA is requested to assign a new
sub-type as follows: sub-type as follows:
"Flow Spec for SFC Classifiers" (TBD4 in this document) with this "Flow Specification for SFC Classifiers" (TBD4 in this document)
document as the reference. with this document as the reference.
10.7. New BGP Transitive Extended Community Types 10.7. New BGP Transitive Extended Community Type
IANA maintains a registry of "Border Gateway Protocol (BGP) IANA maintains a registry of "Border Gateway Protocol (BGP)
Parameters" with a subregistry of "BGP Transitive Extended Community Parameters" with a subregistry of "BGP Transitive Extended Community
Types". IANA is requested to assign new types as follows: Types". IANA is requested to assign a new type as follows:
"SFIR Pool Identifier" (TBD6 in this document) with this document o SFC (Sub-Types are defined in the "SFC Extended Community Sub-
as the reference. Types" registry) (TBD6 in this document) with this document as the
reference.
"MPLS Label Stack Mixed Swapping/Stacking Labels" (TBD7 in this 10.8. New SFC Extended Community Sub-Types Registry
document) with this document as the reference.
10.8. SPI/SI Representation IANA maintains a registry of "Border Gateway Protocol (BGP)
Parameters". IANA is requested to create a new sub-registry called
the "SFC Extended Community Sub-Types Registry".
IANA should include the following note replacing the string "TBD6"
with the value assigned for Section 10.7:
This registry contains values of the second octet (the "Sub-Type"
field) of an extended community when the value of the first octet
(the "Type" field) is set to TBD6.
The allocation policy for this registry should be First Come First
Served.
IANA is requested to populate this registry with the following
entries:
Sub-Type | | |
Value | Name | Reference | Date
---------+----------------------+-------------+---------------
TBD7 | SFIR Pool Identifier | [This.I-D] | Date-to-be-set
TBD8 | MPLS Label Stack | [This.I-D] | Date-to-be-set
| Mixed Swapping/ | |
| Stacking Labels | |
All other values should be marked "Unassigned".
10.9. SPI/SI Representation
IANA is requested to assign a codepoint from the "BGP Tunnel IANA is requested to assign a codepoint from the "BGP Tunnel
Encapsulation Attribute Sub-TLVs" registry for the "SPI/SI Encapsulation Attribute Sub-TLVs" registry for the "SPI/SI
Representation Sub-TLV" (TBD5 in this document) with this document Representation Sub-TLV" (TBD5 in this document) with this document
being the reference. being the reference.
10.10. SFC SPI/SI Representation Flags Registry
IANA maintains the "BGP Tunnel Encapsulation Attribute Sub-TLVs"
registry and is requested to create an associated registry called the
"SFC SPI/SI Representation Flags" registry.
Bits are to be assigned by Standards Action. The field is 16 bits
long, and bits are counted from the the most significant bit as bit
zero.
IANA is requested to populate the registry as follows:
Bit number | Name | Reference
-----------+----------------------+-----------
TBD9 | NSH data plane | [This.I-D]
TBD10 | MPLS data plane | [This.I-D]
11. Contributors 11. Contributors
Stuart Mackie Stuart Mackie
Juniper Networks Juniper Networks
Email: wsmackie@juinper.net Email: wsmackie@juinper.net
Keyur Patel Keyur Patel
Arrcus, Inc. Arrcus, Inc.
skipping to change at page 57, line 16 skipping to change at page 65, line 44
Thanks to Tony Przygienda, Jeff Haas, and Andy Malis for helpful Thanks to Tony Przygienda, Jeff Haas, and Andy Malis for helpful
comments, and to Joel Halpern for discussions that improved this comments, and to Joel Halpern for discussions that improved this
document. Yuanlong Jiang provided a useful review and caught some document. Yuanlong Jiang provided a useful review and caught some
important issues. Stephane Litkowski did an exceptionally good and important issues. Stephane Litkowski did an exceptionally good and
detailed document shepherd review. detailed document shepherd review.
Andy Malis contributed text that formed the basis of Section 7.7. Andy Malis contributed text that formed the basis of Section 7.7.
Brian Carpenter and Martin Vigoureux provided useful reviews during Brian Carpenter and Martin Vigoureux provided useful reviews during
IETF last call. IETF last call. Thanks also to Sheng Jiang, Ravi Singh, Benjamin
Kaduk, Roman Danyliw, Adam Roach, and Barry Leiba for review
comments.
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.ietf-idr-rfc5575bis] [I-D.ietf-idr-rfc5575bis]
Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M.
Bacher, "Dissemination of Flow Specification Rules", Bacher, "Dissemination of Flow Specification Rules",
draft-ietf-idr-rfc5575bis-18 (work in progress), November draft-ietf-idr-rfc5575bis-25 (work in progress), May 2020.
2019.
[I-D.ietf-idr-tunnel-encaps] [I-D.ietf-idr-tunnel-encaps]
Patel, K., Velde, G., and S. Ramachandra, "The BGP Tunnel Patel, K., Velde, G., and S. Ramachandra, "The BGP Tunnel
Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-15 Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-15
(work in progress), December 2019. (work in progress), December 4019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271, Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006, DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>. <https://www.rfc-editor.org/info/rfc4271>.
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,
February 2006, <https://www.rfc-editor.org/info/rfc4360>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <https://www.rfc-editor.org/info/rfc4364>. 2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760, "Multiprotocol Extensions for BGP-4", RFC 4760,
DOI 10.17487/RFC4760, January 2007, DOI 10.17487/RFC4760, January 2007,
<https://www.rfc-editor.org/info/rfc4760>. <https://www.rfc-editor.org/info/rfc4760>.
[RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J.,
skipping to change at page 59, line 7 skipping to change at page 67, line 42
<https://www.rfc-editor.org/info/rfc8595>. <https://www.rfc-editor.org/info/rfc8595>.
[RFC8596] Malis, A., Bryant, S., Halpern, J., and W. Henderickx, [RFC8596] Malis, A., Bryant, S., Halpern, J., and W. Henderickx,
"MPLS Transport Encapsulation for the Service Function "MPLS Transport Encapsulation for the Service Function
Chaining (SFC) Network Service Header (NSH)", RFC 8596, Chaining (SFC) Network Service Header (NSH)", RFC 8596,
DOI 10.17487/RFC8596, June 2019, DOI 10.17487/RFC8596, June 2019,
<https://www.rfc-editor.org/info/rfc8596>. <https://www.rfc-editor.org/info/rfc8596>.
13.2. Informative References 13.2. Informative References
[I-D.dawra-idr-bgp-ls-sr-service-segments]
Dawra, G., Filsfils, C., Talaulikar, K., Clad, F.,
daniel.bernier@bell.ca, d., Uttaro, J., Decraene, B.,
Elmalky, H., Xu, X., Guichard, J., and C. Li, "BGP-LS
Advertisement of Segment Routing Service Segments", draft-
dawra-idr-bgp-ls-sr-service-segments-03 (work in
progress), January 2020.
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",
RFC 4272, DOI 10.17487/RFC4272, January 2006,
<https://www.rfc-editor.org/info/rfc4272>.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
BGP, LDP, PCEP, and MSDP Issues According to the Keying
and Authentication for Routing Protocols (KARP) Design
Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013,
<https://www.rfc-editor.org/info/rfc6952>.
[RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for
Service Function Chaining", RFC 7498, Service Function Chaining", RFC 7498,
DOI 10.17487/RFC7498, April 2015, DOI 10.17487/RFC7498, April 2015,
<https://www.rfc-editor.org/info/rfc7498>. <https://www.rfc-editor.org/info/rfc7498>.
Authors' Addresses Authors' Addresses
Adrian Farrel Adrian Farrel
Old Dog Consulting Old Dog Consulting
 End of changes. 146 change blocks. 
460 lines changed or deleted 861 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/