Internet DRAFT - draft-lan-sfp-establishment
draft-lan-sfp-establishment
INTERNET-DRAFT J. Lan
Intended Status: Experimental Y. Hu
Expires: April 2, 2024 G. Cheng
P. Wang
T. Duan
NDSC P.R. China
October 2, 2023
Service Function Path Establishment
draft-lan-sfp-establishment-16
Abstract
Service Function Chain architecture leads to more adaptive network
nodes. It allows splitting the network function into fine-grained
build blocks --- service function, and combining the network
functions into service function chain to formulate complicated
services. Further, the service function chain should be instantiated
by selecting the optimal instance from the candidates for each
service function in it. This document discusses the required
components during the instantiation of service function chain in the
network.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Lan, et al Expires April 2, 2024 [Page 1]
INTERNET DRAFT Service Function Path Establishment October 2, 2023
Copyright and License Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 3
3. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3
3.1. The Terminology . . . . . . . . . . . . . . . . . . . . . 3
3.2. Acronyms and Abbreviations . . . . . . . . . . . . . . . . 4
4. Core components for SFP . . . . . . . . . . . . . . . . . . . 5
4.1. Framework . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. SIB structure . . . . . . . . . . . . . . . . . . . . . . 6
4.3. TIB structure . . . . . . . . . . . . . . . . . . . . . . 7
5. SFP management . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. SFP establishment . . . . . . . . . . . . . . . . . . . . 9
5.2. SFP deletion . . . . . . . . . . . . . . . . . . . . . . . 11
5.3. SFP update . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Lan, et al Expires April 2, 2024 [Page 2]
INTERNET DRAFT Service Function Path Establishment October 2, 2023
1. Introduction
The end-to-end services delivery often present various demands for
different functions including the traditional functions and
diversified novel ones such as application-specific features.
However, the rigidly fixed model of service function in the legacy
network chain lacks in adaptability for that circumstance. It cannot
fulfill the current various requirements of end users or
applications, such as cross layer in the wireless network.
Accordingly, service function chain is provided to enhance the
network flexibility and adaptability. It consists of several service
functions in a special order that the corresponding packets or flows
should drill through them. The network administrative entity could
"insert" or "disable" a service function in the service function
chain based on the new dynamic demands.
Service function chain architecture splits the network functions into
finer-grained service functions. It then decouples the service
functions from the underlying physical topology, and enables the new
placement and combination of service functions viable. In the SFC-
enabled domain, many service function instances will co-exist
provided by different vendors. Before SFC deploys to delivery packets
or flows, it must be instantiated by selecting instances distributed
in the network for each service functions.
This document outlines the required components regarding to the
service function path including the establishment, deletion,
modification/update based on the policy.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. Terminology and Abbreviations
3.1. The Terminology
This document uses the terminology defined in the SFC Problem
Statement [I-D.quinn-sfc-problem-statement] and the SFC Framework &
Architecture [I-D.boucadair-sfc-framework]. Additional terminology is
defined below:
Service Function Instance: A Service Function Instance locating in a
service node deals with the specific packets based on the function
Lan, et al Expires April 2, 2024 [Page 3]
INTERNET DRAFT Service Function Path Establishment October 2, 2023
logic declared.
Service Function Path: The Service Function Path is the instantiation
of a service function chain in the network. It consists of the
service function instances in the service function chain.
Service Information Base: A Service Information Base is a data
structure tracking the information about the service functions. It
must include the location of service functions, service type (e.g.,
load balancer, firewall), and managed information such as the load,
capacity and current status of service function. SIBs may be
configured and managed by the administrative entity that operates the
SFC-enabled domain. SIBs also may be automatically updated by the
service function discover. In the distributed mode, SIB's replicas
could be distributed over the SFC-enabled domain.
Topology Information Base: A Topology Information Base stores the
Physical network infrastructure topology. Its replicas can be placed
in the same network node with SIB, or in a separate one. In the
distributed mode, TIB's replicas could be distributed over the SFC-
enabled domain.
SFP-enabled Management Entity: SFP-enabled Management Entity is
responsible for the establishment, deletion, modification/update of
SFPs for various SFC.
3.2. Acronyms and Abbreviations
SFI Service Function Instance
SFP Service Function Path
SIB Service Information Base
TIB Topology Information Base
SFP-ME SFP-enabled Management Entity
SFPS Service Function Pre-Selection
SFPC Service Function Path Calculation
SCPB Service Chain-Path Base
Lan, et al Expires April 2, 2024 [Page 4]
INTERNET DRAFT Service Function Path Establishment October 2, 2023
4. Core components for SFP
The establishment of a SFP which consists of multiple service
functions (SFs), needs to select one service function instance
(SFI) from multiple SFIs distributed in the network for each
service function. To make decision, service function (SF) node
information and underlying topology information need to be
collected automatically and periodily. The following sections
describe the framework and data structures to store SF information
and topology information for the establishment of SFP.
4.1. Framework
policy +----------------------------------------+
| | +-------+ +-------+ +-------+ |
| | | | | | | | |
| |--->| SF1_1 |-->| SF1_2 | ... | SF1_n | |
| | | | | | | | |
V | +-------+ +-------+ +-------+ |
+-------+ | |
| | | |
+-->| PDP |--->| |
| | | | +-------+ +-------+ +-------+ |
| +-------+ | | | | | | | |
| |--->| SF2_1 |-->| SF2_2 | ... | SF2_m | |
+-------+ | | | | | | | | |
| | | | +-------+ +-------+ +-------+ |
| NIB |-->| +--------+-----------+-------------+-----+
| | | | | |
+-------+ | | | |
| +-------+ +----------------------------------------+
| | | | +-----------+ +-----+ |
|-->|SFP-ME |--->| +-------+ | SN2 | | SNi | |
| | | | | SN1 |-->+-----------+ +-----+ |
+-------+ | +-------+ | +-------+ |SF1_2 SF1_3| ... |SF1_n| |
| | | | | SF1_1 | +-----------+ +-----+ |
| TIB |---+ | | SF2_1 |-->+-----------+ +-----+ |
| | | +-------+ | SN2 | ... | SNk | |
+-------+ | +-----------+ +-----+ |
| | SF2_2 | |SF2_m| |
| +-----------+ +-----+ |
+----------------------------------------+
physical infrastructure
Figure 1 Core components for SFP establishment
As shown in figure 1, the core components of SFP include PDP, SFP-ME,
SF information base (SIB), and topology information base (TIB). As
Lan, et al Expires April 2, 2024 [Page 5]
INTERNET DRAFT Service Function Path Establishment October 2, 2023
defined in [I.D- boucadair-sfc-framework], the PDP is the central
entity which is responsible for maintaining SFC policy Tables, and
enforcing appropriate policies in SF nodes and SFC Boundary Nodes. In
addition, the PDP in this document is also responsible for creating
SFCs according to the requirements of applications or profits of
vendors. The SIB stores the SF information which includes SF
identity, SF locator, SF type, SF capacity, SF load and SF status. SF
information can be collected from SFC-enabled domain by using IGP or
BGP-LS [I.D-draft-idr-ls-distribution]. The TIB is used to store
underlying physical network infrastructure topology information which
can be collected form network by using IGP or BGP-LS [I.D-draft-idr-
ls-distribution]. The SFP-ME is responsible for establishing,
deleting, and modified SFP according to SFC made by PDP, SF
information, and topology information. The SFP-ME is also responsible
for SFP management.
4.2. SIB structure
The SF information stored by SIB is used to establish or update SFP
by SFP-ME. The SIB structure is defined in Fig.2. The following
entries are defined in the SIB.
+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Index|SF identity|SF locator|SF type|SF capacity|SF load|SF status|
+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 SIB structure
Index: denotes the sequence that a SF entry locates in the SIB. The
index can be used to lookup the SF entry quickly.
SF identity: is used to identify the SF and is unique in SFP-ME
enabled domain. Each SF has an unique identity. The service function
server is responsible for the SF identity management and allocation.
SF locator: represents the SF node where the SF locates. The SF
locator is non-exclusive. Multiple SFs could locate in one SF node or
multiple different SF nodes.
SF type: denotes the type of a SF. SFs can be classified into
different classes which include firewall, DPI (Deep Packet
Inspection), load balancer, etc. The definition of SF can refer to
[I.D- boucadair-sfc-framework]. In this document, the SFs may be
service functions in layer 3 or service functions in layer 4-7.
SF capacity: represents the capacity to process the traffic. The same
service function may have multiple service functions in different
capacities.
Lan, et al Expires April 2, 2024 [Page 6]
INTERNET DRAFT Service Function Path Establishment October 2, 2023
SF load: denotes the current traffic load steering a SF. The SFP-ME
can establish or update SFP according to SF load.
SF status: denotes the current status of a SF. The SF status includes
available, congestion, unavailable, etc. The exact definition of SF
status is application-specific.
4.3. TIB structure
The underlying physical network topology information is used to
deploy SFs for establishing or updating SFP according some optimal
criterions or the profit of vendors. The TIB is used to store network
topology information. The structure of TIB can be defined in
different formats, e.g. routing information table etc. Fig. 3 shows a
definition of the TIB structure. The following entries are defined in
the TIB.
+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+--+ +-+-+-+-+-+--+
| SF node | number | Neighbor 1 | Neighbor 1 |...| Neighbor N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+-+-+-+-+--+ +-+-+-+-+-+--+
Figure 3 TIB structure
SF node: denotes the SF node which reports the information. The
identifier of SF node can be flat identifier or hierarchical
identifier, e.g. IP address.
Number: denotes the number of neighbor nodes.
Neighbor: denotes the neighbor node of the current SF node. A SF node
may have multiple neighbor nodes.
5. SFP management
SFP aims to provide SFC an optimal/near-optimal path on underlying
physical network, ensuring network function represented by the
specific SFC can be implemented with required or even higher
performance. Operations of SPF refer to establishment, deletion and
update and are conducted by SFP-ME.
The SFP-ME in this document includes a service function pre-selection
(SFPS), classifier, service function path calculation (SFPC) and
service chain-path base (SCPB), as shown in Figure 4. The SFPS is
used to select candidate nodes for SFP establishment. The classifier
is used to determine which cost function is taken for SFP
establishment and transfer SFP deletion and update information to
SFPC. The SFPC is used to fulfill SFP establishment, deletion and
Lan, et al Expires April 2, 2024 [Page 7]
INTERNET DRAFT Service Function Path Establishment October 2, 2023
update. The SCPB stores service function chain-path mapping
information and is used for SFP deletion.
A service function path header should be added to encapsulated
packets or frames to represent service function paths. The service
function path header should be independent of the underlying
transport and can be encapsulated inside any transport mechanism.
There are several approaches to encapsulate service function path
header as described in Metadata Considerations [I-D.rijsman-sfc-
metadata-considerations], Service Chain Header [I-D.zhang-sfc-sch],
Network Service Header[I-D.quinn-sfc-nsh] and so on.
To implement SPF establishment, deletion and update, SFP-ME need to
interact with NIB, TIB, PDP by using a variety of protocols, such as
NETCONF [RFC6241],PCEP[I-D.wu-pce-traffic-steering-sfc], etc.
Lan, et al Expires April 2, 2024 [Page 8]
INTERNET DRAFT Service Function Path Establishment October 2, 2023
+------------+
| |
| PDP |
| |
+-----+------+
|
+-----------+ +---------------|------------------------+
| | | | |
| NIB <----+ | +------+--------+ |
| | | | | | |
+-----------| | | +---v---+ +-----v------+ |
| | | | | | |
+---+-+--> SNPS | | CLASSIFIER | |
| | | | | | | |
+-----------+ | | | +---v---+ +-----v------+ |
| | | | | | | |
| TIB <----+ | | | | |
| | | | +------+--------+ |
+---------- + | | | |
| | | |
| | +---V---+ +------+ |
| | | | | | |
| +----- -->| SFPC <-------- > SCPB | |
| | | | | |
| +---+---+ +------+ |
| | |
+---------------+------------------------+
|
V
Figure 4 Framework of SFP-ME
5.1. SFP establishment
SFP establishment refers to determining the optimal/near-optimal
service node for each service function on SFC and finding the
optimal/near-optimal path for the instantiated service nodes of a
given SFC such that the required service functions are executed in
sequence required by SFC with minimal costs.
The term of cost is user-defined and can be end-to-end delay,
resource consumption and so on. There may exist only one cost
definition which can be applied to all SFC in the same domain, or may
co-exist several different cost definitions with each one targeting
at different types of SFC. Cost must be expressed as a function, i.e.
cost function. Trying to minimize the cost, several algorithms can be
applied based on different cases.
Lan, et al Expires April 2, 2024 [Page 9]
INTERNET DRAFT Service Function Path Establishment October 2, 2023
When SFC is generated based on policy in PDP, SFP-ME receives SFC
information and start to execute SFP establishment. The SFP
establishment processes in three steps, as shown in Figure 5.
Firstly, SNPS selects several service nodes as candidates, these
service nodes must include one or more service function Instance of
the given SFC and are currently available. Concurrently, classifier
selects the appropriate cost function according to the type of the
given SFC, this step can be omitted if there is only one cost
function applied to all SFC in the same domain.
Secondly, with the aim to minimize cost, SFPC applies algorithms to
selects one service node for each service function of the given SFC
from the candidates and builds a path making the service functions
strictly executed with the ordered sequence. Thus an optimal/near-
optimal SFP for SFC is established.
Lastly, Information of the established SFP is send to SFC entrance,
meanwhile SCPB is updated.
Lan, et al Expires April 2, 2024 [Page 10]
INTERNET DRAFT Service Function Path Establishment October 2, 2023
+------------+
| |
| PDP |
| |
+------------+
|
+---------------|------------------------+
| | |
| +------+--------+ |
| | 1 | 1 |
| +---v---+ +-----v------+ |
| | | | | |
| | SNPS | | CLASSIFIER | |
| | | | | |
| +-------+ +------------+ |
| | | |
| | | |
| +------+---------+ |
| | 2 |
| | |
| +---V---+ +------+ |
| | | 3 | | |
| | SFPC |-------- > SCPB | |
| | | | | |
| +---+---+ +------+ |
| | |
+--------------+-------------------------+
| 3
V
Figure 5 SFP Establishment Process
5.2. SFP deletion
SFP deletion refers to releasing the overall service function
Instantiations of the established SFP, thus the released service
function Instantiations can be used for other SFP's establishment.
SFP-ME starts to execute SFP deletion once PDP notifies that SFC has
been deleted. Information of the to be deleted SFC is send to SFPC
through classifier and match against the restored SFC in SCPB to find
SFP for the given SFC, then SFPC notify SFC entrance that this
specific SFP is invalid, meanwhile update SCPB. The SFP deletion
process is shown in Figure 6.
Lan, et al Expires April 2, 2024 [Page 11]
INTERNET DRAFT Service Function Path Establishment October 2, 2023
+------------+
| |
| PDP |
| |
+------------+
|
+----------+---------------------+
| | 1 |
| +-----v------+ |
| | | |
| | CLASSIFIER | |
| | | |
| +------------+ |
| | 2 |
| | |
| +---V---+ +------+ |
| | | 3 | | |
| | SFPC <------ > SCPB | |
| | | | | |
| +---+---+ +------+ |
| | |
+----------+---------------------+
| 4
V
Figure 6 SFP deletion process
5.3. SFP update
SFP update refers to changing partial service function Instantiations
or path of the established SFP, due to breakdown of partial service
function nodes or physical links.
Breakdown of service function nodes or physical links can lead the
established SFP to work improperly, re-establishment of SFP can be
executed to guarantee function of the corresponding SFC is still
implemented with optimal/near-optimal performance. SFP update is an
alternative way. The updated SFP may perform worse than the re-
establishment one, however, the update process takes up less time
which can be very attractive to time-sensitive function.
SFP-ME starts to execute SFP update once PDP notifies that SFP need
to be updated. Information of the to be updated SFC is send to SFPC
through classifier, SFPC selects adjacent service nodes or path to
replace the ones which has been breakdown. Thus the given SFP is
undated, Information of the undated SFP is send to SFC entrance. The
SFP update process is shown in Figure 7.
Lan, et al Expires April 2, 2024 [Page 12]
INTERNET DRAFT Service Function Path Establishment October 2, 2023
+------------+
| |
| PDP |
| |
+------------+
|
+----------+-----------+
| | 1 |
| +-----v------+ |
| | | |
| | CLASSIFIER | |
| | | |
| +------------+ |
| | 2 |
| | |
| +---V---+ |
| | | |
| | SFPC | |
| | | |
| +---+---+ |
| | |
+----------+-----------+
| 3
V
Figure 7 SFP update process
Lan, et al Expires April 2, 2024 [Page 13]
INTERNET DRAFT Service Function Path Establishment October 2, 2023
6. Security Considerations
It will be considered in a future revision.
7. IANA Considerations
No IANA action is needed for this document.
8. References
8.1. Normative References
[RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework
for Policy-based Admission Control", RFC 2753, January
2000.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[I-D.quinn-sfc-problem-statement] Quinn, P., "Service Function
Chaining Problem Statement", draft-quinn-sfc-problem-
statement-02 (work in progress), December 2013.
[I-D. boucadair-sfc-framework] M. Boucadair, "Service Function
Chaining: Framework & Architecture",draft-boucadair-sfc-
framework-02 (work in progress),February 2014.
[I-D.rijsman-sfc-metadata-considerations] B. Rijsman, J. Moisand,
"Metadata Considerations", draft-rijsman-sfc-metadata-
considerations-00 (work in progress),February 2014.
[I-D.zhang-sfc-sch] H. Zhang, L. Fourie, R. Parker, M. Zarny,
"Service Chain Header", draft-zhang-sfc-sch-01 (work in
progress), May 2014.
[I-D.quinn-sfc-nsh] P. Quinn, J. Guichard, R. Fernando, S. Kumar, et
al. "Network Service Header",draft-quinn-sfc-nsh-02 (work
in progress), February 2014.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.Bierman,
"Network Configuration Protocol (NETCONF)", RFC 6241, June
Lan, et al Expires April 2, 2024 [Page 14]
INTERNET DRAFT Service Function Path Establishment October 2, 2023
2011.
Authors' Addresses
Julong Lan
National Digital Switching System Engineering and Technological
Research Center
NDSC
Jianxue Ave. No. 7
Zhengzhou 450002
China
EMail: ndscljl@163.com
Yuxiang Hu
National Digital Switching System Engineering and Technological
Research Center
NDSC
Jianxue Ave. No. 7
Zhengzhou 450002
China
EMail: chxachxa@126.com
Guozhen Cheng
National Digital Switching System Engineering and Technological
Research Center
NDSC
Jianxue Ave. No. 7
Zhengzhou 450002
China
EMail: chengguozhen1986@163.com
Peng Wang
National Digital Switching System Engineering and Technological
Research Center
NDSC
Jianxue Ave. No. 7
Zhengzhou 450002
China
EMail: wangpeng.ndsc@gmail.com
Lan, et al Expires April 2, 2024 [Page 15]
INTERNET DRAFT Service Function Path Establishment October 2, 2023
Tong Duan
NDSC
Jianxue Ave. No. 7
Zhengzhou 450002
China
EMail: duantong21@126.com
Lan, et al Expires April 2, 2024 [Page 16]
