Internet DRAFT - draft-wu-pce-traffic-steering-sfc
draft-wu-pce-traffic-steering-sfc
PCE Working Group Q. Wu
Internet-Draft D. Dhody
Intended status: Standards Track Huawei
Expires: December 29, 2017 M. Boucadair
C. Jacquenet
Orange
J. Tantsura
June 27, 2017
PCEP Extensions for Service Function Chaining (SFC)
draft-wu-pce-traffic-steering-sfc-12
Abstract
This document provides an overview of the usage of Path Computation
Element (PCE) to dynamically structure service function chains.
Service Function Chaining (SFC) is a technique that is meant to
facilitate the dynamic enforcement of differentiated traffic
forwarding policies within a domain. Service function chains are
composed of an ordered set of elementary Service Functions (such as
firewalls, load balancers) that need to be invoked according to the
design of a given service. Corresponding traffic is thus forwarded
along a Service Function Path (SFP) that can be computed by means of
PCE.
This document specifies extensions to the Path Computation Element
Protocol (PCEP) that allow a stateful PCE to compute and instantiate
Service Function Paths.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on December 29, 2017.
Wu, et al. Expires December 29, 2017 [Page 1]
Internet-Draft PCEP for SFC June 2017
Copyright Notice
Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . 3
3. Service Function Paths and PCE . . . . . . . . . . . . . . . 4
4. Overview of PCEP Operation in SFC-Enabled Networks . . . . . 6
4.1. SFP Instantiation . . . . . . . . . . . . . . . . . . . . 6
4.2. SFP Withdrawal . . . . . . . . . . . . . . . . . . . . . 6
4.3. SFP Delegation and Cleanup . . . . . . . . . . . . . . . 7
4.4. SFP State Synchronization . . . . . . . . . . . . . . . . 7
4.5. SFP Update and Report . . . . . . . . . . . . . . . . . . 7
5. Object Formats . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. The OPEN Object . . . . . . . . . . . . . . . . . . . . . 7
5.2. The LSP Object . . . . . . . . . . . . . . . . . . . . . 8
5.2.1. SFP Identifiers TLV . . . . . . . . . . . . . . . . . 8
6. Backward Compatibility . . . . . . . . . . . . . . . . . . . 9
7. SFP Instantiation Signaling and Forwarding Considerations . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
11.1. Normative References . . . . . . . . . . . . . . . . . . 10
11.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
Service Function Chaining (SFC) enables the creation of composite
services that consist of an ordered set of Service Functions (SF)
that must be applied to packets and/or frames and/or flows selected
as a result of service-inferred traffic classification as described
in [RFC7665]. A Service Function Path (SFP) is a path along which
traffic that is bound to a specific service function chain will be
Wu, et al. Expires December 29, 2017 [Page 2]
Internet-Draft PCEP for SFC June 2017
forwarded. Packets typically follow a Service Function Path from a
classifier through the Service Functions (SF) that need to be invoked
according to the SFC instructions. Forwarding decisions are made by
Service Function Forwarders (SFF) according to such instructions.
[RFC5440] describes the Path Computation Element Protocol (PCEP) as
the protocol used by a Path Computation Client (PCC) and a Path
Control Element (PCE) to exchange information, thereby enabling the
computation of Multiprotocol Label Switching (MPLS) for Traffic
Engineering Label Switched Path (TE LSP), in particular.
[I-D.ietf-pce-stateful-pce] specifies extensions to PCEP to enable a
stateful control of MPLS TE LSPs. [I-D.ietf-pce-pce-initiated-lsp]
provides the extensions needed for stateful PCE-initiated LSP
instantiation.
This document specifies PCEP extensions that allow a stateful PCE to
compute and instantiate traffic-engineered Service Function Paths
(SFP).
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 RFC2119 [RFC2119].
This document makes use of these acronyms:
PCC: Path Computation Client.
PCE: Path Computation Element.
PCEP: Path Computation Element Protocol.
PDP: Policy Decision Point.
SF: Service Function.
SFC: Service Function Chain.
SFP: Service Function Path.
RSP: Rendered Service Path.
SFF: Service Function Forwarder.
UNI: User-Network Interface.
Wu, et al. Expires December 29, 2017 [Page 3]
Internet-Draft PCEP for SFC June 2017
3. Service Function Paths and PCE
Service function chains are constructed as a sequence of SFs, where a
SF can be virtualized or embedded in a physical network element. One
or several SFs may be supported by the same physical network element.
A SFC creates an abstracted view of a service and specifies the set
of required SFs as well as the order in which they must be executed.
When an SFC is created, it is necessary to select the specific
instances of SFs that will be used. A service function path for that
SFC will then be established (notion of rendered service path) or can
be precomputed, based upon the sequence of SFs that need to be
invoked by the corresponding traffic, i.e., the traffic that is bound
to the corresponding SFC. Note that a SF instance can be serviced by
one or multiple SFFs. One or multiple SF instances can be serviced
by one SFF. Thus, the instantiation of an SFC results in the
establishment of a Service Function Path, either in a hop-by-hop
fashion, or by means of traffic-engineering capabilities. In the
latter case, the SFP is precomputed, i.e., an SFP is an instantiation
of the defined SFC as described in [RFC7665].
The computation, the selection, and the establishment of a traffic-
engineered SFP can rely upon a set of (service-specific) policies
(forwarding and routing, QoS, security, etc., or a combination
thereof). Stateful PCE with appropriate SFC-aware PCEP extensions
can be used to compute traffic-engineered SFPs.
Wu, et al. Expires December 29, 2017 [Page 4]
Internet-Draft PCEP for SFC June 2017
SFC Control Plane
+------------------------+
|PCE based Controller |
I2 | +-------++-------+ |
+------------- |Policy || TE-DB | |
| I1 | +-------++-------+ <----+
| +----------| +-------------+ | |
| |SFP | |LSP-DB/SFP-DB| | |I2
| |Instan- | +-------------+ | |
| |tiation +-----------^------------+ |policy-provisioning
| |PCEP | |information/
| |Signaling I2 | |Carried by NETCONF,
| | | |BGP, for example
| | | |
| | | |
| | +------V+ +----+--+
V V | | | |
+-----+ Forwarding| | Forwarding| | Forwarding
| SFC |----------->| SFF-1 | --------->| SFF-2 |----------->
Classifier | | | |
| | | | | |
+-----+ ++-----++ +-----+-+
| | |
+--+--+ ++----+ +--+--+
|SF-1 | |SF-2 | |SF-3 |
| | | | | |
+--+--+ +---+-+ +--+--+
|I2 |I2 |I2
V V V
Figure 1: PCE-based SFP instantiation
In Figure 1, the PCE-based Controller [I-D.ietf-teas-pce-central-
control] in the SFC Control plane is responsible for computing the
path for a given service function chain. This PCE-based controller
can operate as a stateful PCE ([I-D.draft_ietf-stateful-pce]) that
will provide a classifier (a headend from a PCE standpoint) with the
PCEP-formatted information to instantiate a given SFP. As a
consequence, the PCE-based controller derives the set of policy-
provisioning information (namely SFP configuration information and
traffic classification rules) that will be provided to the various
elements (Classifier, SFF) involved in the establishment of the SFP.
By doing so, SFC Classifier can bind a flow to a service function
chain and forward such flow along the corresponding SFP. The SFC
Control Plane [I-D.ietf-sfc-control-plane] is also responsible for
defining the appropriate policies (traffic classification, forwarding
and routing, etc.) that will be enforced by SFC Classifiers,SFF Nodes
Wu, et al. Expires December 29, 2017 [Page 5]
Internet-Draft PCEP for SFC June 2017
and SF Nodes, as described in [RFC7665]. From that standpoint, the
SFC Control Plane embeds a Policy Decision Point that is responsible
for defining the SFC policies. SFC policies will be provided by the
PDP and enforced by SFC components like classifiers and SFFs by means
of policy-provision information. A protocol like NETCONF, BGP can be
used to carry such policy-provisioning information.
4. Overview of PCEP Operation in SFC-Enabled Networks
A PCEP speaker indicates its ability to support PCE-computed SFP
paths during the PCEP Initialization phase via a mechanism described
in Section 5.1. A PCE may initiate SFPs only for PCCs that
advertised this capability; a PCC follows the procedures described in
this document only for sessions where the PCE advertised this
capability.
As per Section 5.1 of [I-D.ietf-pce-pce-initiated-lsp], the PCE sends
a Path Computation LSP Initiate Request (PCInitiate) message to the
PCC to instantiate or delete a LSP. The Explicit Route Object (ERO)
is used to encode either a full sequence of SF instances or a
specific sequence of SFFs and SFs to establish an SFP. If the said
SFFs and SFs are identified with an IP address, the IP sub-object can
be used as a SF/SFF identification means. This document makes no
change to the PCInitiate message format but extends LSP objects
described in Section 5.2.
Editor's note: In case a PCE-Initiated signaling mechanism is used to
set up the service function path, does the classifier / PCE-Initiated
signaling protocol need to understand whether an IP address is
assigned to a SFF or a SF, or the signaling protocol is only used to
signal IP addresses for SFs?
To prevent multiple classifiers assign the same SFP ID to one Service
Function Path(SFP ID assignment conflict),in this document, we assume
SFP ID can be predetermined and assigned by stateful PCE when
stateful PCE can be used to compute traffic-engineered SFPs.
4.1. SFP Instantiation
The instantiation of a SFP is the same as defined in Section 5.3 of
[I-D.ietf-pce-pce-initiated-lsp]. Rules for processing and error
codes remain unchanged.
4.2. SFP Withdrawal
The withdrawal of an SFP is the same as defined in Section 5.4 of
[I-D.ietf-pce-pce-initiated-lsp]: the PCE sends an LSP Initiate
Message with an LSP object carrying the PLSP-ID of the SFP and the
Wu, et al. Expires December 29, 2017 [Page 6]
Internet-Draft PCEP for SFC June 2017
SFP Identifier to be removed, as well as an SRP object with the R
flag set (LSP-REMOVE as per Section 5.2 of
[I-D.ietf-pce-pce-initiated-lsp]). Rules for processing and error
codes remain unchanged.
4.3. SFP Delegation and Cleanup
SFP delegation and cleanup operations are similar to those defined in
Section 6 of [I-D.ietf-pce-pce-initiated-lsp]. Rules for processing
and error codes remain unchanged.
4.4. SFP State Synchronization
State Synchronization operations described in Section 5.4 of
[I-D.ietf-pce-stateful-pce] can be applied to SFP state maintenance
as well.
4.5. SFP Update and Report
A PCE can send an SFP Update request to a PCC to update one or more
attributes of an SFP and to re-signal the SFP with the updated
attributes. A PCC can send an SFP state report to a PCE, and which
contains the SFP State information. The mechanism is described in
[I-D.ietf-pce-stateful-pce] and can be applied to SFPs as well.
5. Object Formats
5.1. The OPEN Object
The optional TLV shown in Figure 2 is defined for use in the OPEN
Object to indicate the PCEP speaker's Service Function Chaining
capability.
The SFC-PCE-CAPABILITY TLV is an optional TLV to be carried in the
OPEN Object to advertise the SFC capability during the PCEP session.
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=TBD | length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SFC-PCE-CAPABILITY TLV Format
The code point for the TLV type is to be defined by IANA (see
Section 9). The TLV length is 4 octets.
Wu, et al. Expires December 29, 2017 [Page 7]
Internet-Draft PCEP for SFC June 2017
As per [I-D.ietf-pce-stateful-pce], a PCEP speaker advertises the
capability of instantiating PCE-initiated LSPs via the Stateful PCE
Capability TLV (LSP-INSTANTIATION-CAPABILITY bit) carried in an Open
message. The inclusion of the SFC-PCE-CAPABILITY TLV in an OPEN
object indicates that the sender is SFC-capable. Both mechanisms
indicate the SFP instantiation capability of the PCEP speaker.
5.2. The LSP Object
The LSP object is defined in [I-D.ietf-pce-pce-initiated-lsp] and
included here for reference (Figure 3).
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PLSP-ID | Flags |F|C| O|A|R|S|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LSP Object Format
A new flag, called the SFC flag (F-bit), is introduced. The F-bit
set to "1" indicates that this LSP is actually an SFP. The C flag
will also be set to indicate it was created via a PCInitiate message.
5.2.1. SFP Identifiers TLV
As described in section 4, SFP ID is predetermined and assigned by
stateful PCE. The SFP Identifiers TLV MUST be included in the LSP
object for SFPs. The SFP Identifier TLV is used by the classifier to
select the SFP along which some traffic will be forwarded, according
to the traffic classification rules applied by the classifier
[RFC7665]. The SFP Identifier is part of the SFC metadata carried in
packets and is used by the SFF to invoke service functions and
identify the next SFF.
The format of the SFP Identifier TLV is shown in Figure 4.
Wu, et al. Expires December 29, 2017 [Page 8]
Internet-Draft PCEP for SFC June 2017
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Path ID | Service Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Service Path ID (SPI): 24 bits
Service Index (SI): 8 bits
Figure 4
SPI: identifies a service path. The same ID is used by the
participating nodes for path setup/selection. An administrator can
use the SPI for reporting and troubleshooting packets along a
specific path. SPI along with PLSP-ID is used by PCEP to identify
the Service Path.
SI: provides location within the service path.
6. Backward Compatibility
The SFP instantiation capability defined as a PCEP extension and
documented in this draft MUST NOT be used if PCCs or the PCE did not
advertise their stateful SFP instantiation capability,Section 5.1.
If this is not the case and stateful operations on SFPs are
attempted, then a PCErr message with error-type 19 (Invalid
Operation) and error-value TBD needs to be generated.
[Editor's note: more information on exact error value is needed]
7. SFP Instantiation Signaling and Forwarding Considerations
The PCE-initiated SFP instantiation signaling described in this
document is exchanged between PCE server and SFC Classifier and does
not assume any specific mechanism to exchange SFP
information(e.g.,path identification information,metadata
[I-D.ietf-sfc-nsh]) between SFFs or between SFF and SF, or between
the controller and SFF and establish SFP in the data plane throughout
a SFC domain. For example, such mechanism can rely upon the use of
the SFC Encapsulation defined in [I-D.ietf-sfc-nsh] to exchange SFP
information between SFFs or rely upon the use of BGP Control plane
defined in [I-D.ietf-bess-nsh-bgp-control-plane] to exchange SFP
information between the Controller and SFF.
Likewise, [I-D.ietf-teas-pce-central-control] can use the signaling
mechanism described in this draft to enforce SFC-inferred traffic
engineering policies and provide load balancing between service
function nodes. The approach that relies upon the Segment Routing
technique [I-D.ietf-pce-segment-routing] can also take advantage of
Wu, et al. Expires December 29, 2017 [Page 9]
Internet-Draft PCEP for SFC June 2017
the signaling mechanism described in this document to support Service
Path instantiation, which does not require any additional specific
extension to the Segment Routing machinery.
8. Security Considerations
The security considerations described in [RFC5440] and
[I-D.ietf-pce-pce-initiated-lsp] are applicable to this
specification. This document does not raise any additional security
issue.
9. IANA Considerations
IANA is requested to allocate a new code point in the PCEP TLV Type
Indicators registry, as follows:
Value Meaning Reference
------- ---------------------------- --------------
TBD SFC-PCE-CAPABILITY This document
10. Acknowledgements
Many thanks to Ron Parker, Hao Wang, Dave Dolson, Jing Huang, and
Joel M. Halpern for the discussion about the content for the
document.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[I-D.ietf-pce-stateful-pce]
Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP
Extensions for Stateful PCE", draft-ietf-pce-stateful-
pce-21 (work in progress), June 2017.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<http://www.rfc-editor.org/info/rfc5440>.
Wu, et al. Expires December 29, 2017 [Page 10]
Internet-Draft PCEP for SFC June 2017
[I-D.ietf-pce-pce-initiated-lsp]
Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP
Extensions for PCE-initiated LSP Setup in a Stateful PCE
Model", draft-ietf-pce-pce-initiated-lsp-10 (work in
progress), June 2017.
[I-D.ietf-teas-pce-central-control]
Farrel, A., Zhao, Q., Li, Z., and C. Zhou, "An
Architecture for Use of PCE and PCEP in a Network with
Central Control", draft-ietf-teas-pce-central-control-03
(work in progress), June 2017.
11.2. Informative References
[RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework
for Policy-based Admission Control", RFC 2753,
DOI 10.17487/RFC2753, January 2000,
<http://www.rfc-editor.org/info/rfc2753>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015,
<http://www.rfc-editor.org/info/rfc7665>.
[RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash,
"Policy-Enabled Path Computation Framework", RFC 5394,
DOI 10.17487/RFC5394, December 2008,
<http://www.rfc-editor.org/info/rfc5394>.
[I-D.ietf-sfc-control-plane]
Boucadair, M., "Service Function Chaining (SFC) Control
Plane Components & Requirements", draft-ietf-sfc-control-
plane-08 (work in progress), October 2016.
[I-D.ietf-pce-segment-routing]
Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
and J. Hardwick, "PCEP Extensions for Segment Routing",
draft-ietf-pce-segment-routing-09 (work in progress),
April 2017.
[I-D.ietf-sfc-nsh]
Quinn, P. and U. Elzur, "Network Service Header", draft-
ietf-sfc-nsh-12 (work in progress), February 2017.
[I-D.ietf-bess-nsh-bgp-control-plane]
Farrel, A., Drake, J., Rosen, E., Uttaro, J., and L.
Jalil, "BGP Control Plane for NSH SFC", draft-ietf-bess-
nsh-bgp-control-plane-00 (work in progress), March 2017.
Wu, et al. Expires December 29, 2017 [Page 11]
Internet-Draft PCEP for SFC June 2017
Authors' Addresses
Qin Wu
Huawei
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012
China
EMail: bill.wu@huawei.com
Dhruv Dhody
Huawei
Leela Palace
Bangalore, Karnataka 560008
INDIA
EMail: dhruv.ietf@gmail.com
Mohamed Boucadair
Orange
Rennes 35000
France
EMail: mohamed.boucadair@orange.com
Christian Jacquenet
Orange
Rennes
France
EMail: christian.jacquenet@orange.com
Jeff Tantsura
2330 Central Expressway
Santa Clara, CA 95050
US
EMail: jefftant.ietf@gmail.com
Wu, et al. Expires December 29, 2017 [Page 12]
