PCE Working Group Q. Wu
Internet-Draft D. Dhody
Intended status: Standards Track Huawei
Expires: August 17, 2014 J. Tantsura
Ericsson
February 13, 2014
PCEP Extensions for traffic steering support in Service Function
Chaining
draft-wu-pce-traffic-steering-sfc-01
Abstract
This document provides an overview of the usage of Path Computation
Element (PCE) with Service Function Chaining (SFC); which is
described as the definition and instantiation of an ordered set of
such service functions (such as firewalls, load balancers), and the
subsequent "steering" of traffic flows through those service
functions.
Further this document specifies extensions to the Path Computation
Element Protocol (PCEP) that allow a stateful PCE to compute and
instantiate Service Function Paths (SFP).
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 August 17, 2014.
Copyright 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
Wu, et al. Expires August 17, 2014 [Page 1]
Internet-Draft PCEP for SFC February 2014
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. Service Function Paths and PCE . . . . . . . . . . . . . . . . 4
4. Overview of PCEP Operation in SFC enabled Networks . . . . . . 5
4.1. SFP Instantiation . . . . . . . . . . . . . . . . . . . . . 5
4.2. SFP Deletion . . . . . . . . . . . . . . . . . . . . . . . 6
4.3. SFP Delegation and Cleanup . . . . . . . . . . . . . . . . 6
4.4. SFP State Synchronization . . . . . . . . . . . . . . . . . 6
4.5. SFP Update and Report . . . . . . . . . . . . . . . . . . . 6
5. Object Formats . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. The OPEN Object . . . . . . . . . . . . . . . . . . . . . . 6
5.2. The LSP Object . . . . . . . . . . . . . . . . . . . . . . 7
5.2.1. SFP Identifiers TLV . . . . . . . . . . . . . . . . . . 7
6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . . 8
Wu, et al. Expires August 17, 2014 [Page 2]
Internet-Draft PCEP for SFC February 2014
1. Introduction
Service chaining enables creation of composite services that consist
of an ordered set of Service Functions (SF) that must be applied to
packets and/or frames selected as a result of classification as
described in [I-D.quinn-sfc-arch] and referred to as Service Function
Chain (SFC). Service Function Path (SFP) is the instantiation of a
SFC in the network. Packets follow a Service Function Path from a
classifier through the requisite Service Functions (SF).
[RFC5440] describes the Path Computation Element Protocol (PCEP) as
the communication between a Path Computation Client (PCC) and a Path
Control Element (PCE), or between PCE and PCE, enabling computation
of Multiprotocol Label Switching (MPLS) for Traffic Engineering Label
Switched Path (TE LSP).
[I-D.ietf-pce-stateful-pce] specifies extensions to PCEP to enable
stateful control of MPLS TE LSPs. [I-D.ietf-pce-pce-initiated-lsp]
provides the fundamental extensions needed for stateful PCE-initiated
LSP instantiation.
This document specifies extensions to the PCEP that allow a stateful
PCE to compute and instantiate 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].
The following terminologies are used in this document:
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.
Wu, et al. Expires August 17, 2014 [Page 3]
Internet-Draft PCEP for SFC February 2014
UNI: User-Network Interface.
3. Service Function Paths and PCE
Services are constructed as a sequence of SFs that represent an SFC,
where SF can be a virtual instance or be embedded in a physical
network element, and one or more SFs may be deployed within the same
physical network element. 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 instantiated into the network it is necessary to
select the specific instances of SFs that will be used, and to create
the service topology for that SFC using SF's network locator. Thus,
instantiation of the SFC results in the creation of a Service
Function Path (SFP) and is used for forwarding packets through the
SFC. In other words, an SFP is the instantiation of the defined SFC
as described in details in [I-D.quinn-sfc-arch].
The selection of SFP can be based on a range of policy attributes,
ranging from simple to more elaborate criteria and stateful PCE with
extensions to PCEP are one such way to achieve this.
Stateful pce [I-D.ietf-pce-stateful-pce] specifies a set of
extensions to PCEP to enable stateful control of TE LSPs.
[I-D.ietf-pce-pce-initiated-lsp] provides the fundamental motivations
and extensions needed for stateful PCE-initiated LSP instantiation.
This document specifies extensions that allow a stateful PCE to
compute and instantiate Service Function Paths (SFP) via PCEP.
Wu, et al. Expires August 17, 2014 [Page 4]
Internet-Draft PCEP for SFC February 2014
+---------------------------------+
|+------+ +------+ PDP |
|| | | | |
|| | | | |
||PCE | |Policy| |
|*------+ +------+ |
*---------------------------------+
/
/
/ SFP
/ Instan-
/ tiation
/
/
V
+-----+ Signaling +-----+ Signaling +-----+ Signaling +-----+
|SF-In|------------>|SF-1 |------------>|SF-2 |------------>|SF-E |
|gress| | | | | |gress|
+-----+ +-----+ +-----+ +-----+
Figure 1: SFP instantiation vis PCE
A Policy Decision Point (PDP) [RFC2753] is the central entity which
is responsible for maintaining SFC Policy Tables and enforcing
appropriate policies in SF Nodes described in detail in
[I-D.boucadair-sfc-framework]. A PDP may further use stateful PCE
and its instantiation mechanism to compute and instantiate Service
Function Paths (SFP). The PCE maybe co-located with the PDP or an
external entity.
4. Overview of PCEP Operation in SFC enabled Networks
A PCEP speaker indicates its ability to support PCE initiated dynamic
SFP during the PCEP Initialization Phase via mechanism described in
Section 5.1.
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. This document makes no change to
the PCInitiate message format but extends LSP objects described in
Section 5.2.
4.1. SFP Instantiation
The Instantiation operation of SFP is same as defined in section 5.3
of [I-D.ietf-pce-pce-initiated-lsp]. Rules of processing and error
codes remains unchanged.
Wu, et al. Expires August 17, 2014 [Page 5]
Internet-Draft PCEP for SFC February 2014
4.2. SFP Deletion
The deletion operation of SFP is same as defined in section 5.4 of
[I-D.ietf-pce-pce-initiated-lsp] by sending an LSP Initiate Message
with an LSP object carrying the PLSP-ID of the SFP to be removed and
an SRP object with the R flag set (LSP-REMOVE as per section 5.2 of
[I-D.ietf-pce-pce-initiated-lsp]). Rules of processing and error
codes remains unchanged.
4.3. SFP Delegation and Cleanup
SFP delegation and cleanup operations are same as defined in section
6 of [I-D.ietf-pce-pce-initiated-lsp]. Rules of processing and error
codes remains unchanged.
4.4. SFP State Synchronization
State Synchronization operations described in Section 5.4 of
[I-D.ietf-pce-stateful-pce] and can be applied for SFPs as well.
4.5. SFP Update and Report
PCE can make an SFP Update requests to a PCC to update one or more
attributes of an SFP and to re-signal the SFP with updated
attributes. PCC can make an SFP state report to a PCE to send SFP
state. The mechanism are described in [I-D.ietf-pce-stateful-pce]
and can be applied for SFPs as well.
5. Object Formats
5.1. The OPEN Object
This document defines a new optional TLV for use in the OPEN Object
to indicate the PCEP speaker's capability for Service function
Chaining.
The SFC-PCE-CAPABILITY TLV is an optional TLV for use in the OPEN
Object to advertise the SFC capability on the PCEP session. The
format of the SFC-PCE-CAPABILITY TLV is shown in the following
figure:
Wu, et al. Expires August 17, 2014 [Page 6]
Internet-Draft PCEP for SFC February 2014
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The code point for the TLV type is to be defined by IANA. The TLV
length is 4 octets.
The value is TBD.
As per [I-D.ietf-pce-stateful-pce], PCEP speaker advertises
capability for instantiation of PCE-initiated LSPs via Stateful PCE
Capability TLV (LSP-INSTANTIATION-CAPABILITY bit) in open message.
The inclusion of SFC-PCE-CAPABILITY TLV in an OPEN object indicates
that the sender is SFC capable. These mechanism when used together
indicates the instantiation capability for SFP by 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 easy reference.
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 //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A new flag, the SFC (F) flag is introduced. The F Flag set to 1 to
indicate that this an SFP. The C flag will also be set to indicate
it was created via a PCInitiate message.
5.2.1. SFP Identifiers TLV
The SFP Identifiers TLV MUST be included in the LSP object for
Service Function Paths (SFP).
The format and operations are TBD.
Wu, et al. Expires August 17, 2014 [Page 7]
Internet-Draft PCEP for SFC February 2014
6. Backward Compatibility
The PCEP protocol extensions described in this document for PCEP
speaker with instantiation capability for SFPs MUST NOT be used if
PCC or PCE has not advertised its stateful capability with
Instantiation and SFC capability as per Section 5.1. If this is not
the case and Stateful operations on SFPs are attempted, then a PCErr
with error-type 19 (Invalid Operation) and error-value TBD needs to
be generated.
[Editor Note: more information on exact error value is needed]
7. Security Considerations
The security considerations described in [RFC5440] and
[I-D.ietf-pce-pce-initiated-lsp] are applicable to this
specification. No additional security measure is required.
8. IANA Considerations
TBD
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in
RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119,
March 1997.
[I-D.ietf-pce-stateful-pce] Crabbe, E., Medved, J., Minei, I.,
and R. Varga, "PCEP Extensions for
Stateful PCE",
draft-ietf-pce-stateful-pce-07
(work in progress), October 2013.
[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-00
(work in progress), December 2013.
9.2. Informative References
[RFC2753] Yavatkar, R., Pendarakis, D., and
R. Guerin, "A Framework for Policy-
Wu, et al. Expires August 17, 2014 [Page 8]
Internet-Draft PCEP for SFC February 2014
based Admission Control", RFC 2753,
January 2000.
[RFC5440] Vasseur, JP. and JL. Le Roux, "Path
Computation Element (PCE)
Communication Protocol (PCEP)",
RFC 5440, March 2009.
[I-D.quinn-sfc-arch] Quinn, P. and A. Beliveau, "Service
Function Chaining (SFC)
Architecture",
draft-quinn-sfc-arch-04 (work in
progress), January 2014.
[I-D.boucadair-sfc-framework] Boucadair, M., Jacquenet, C.,
Parker, R., Lopez, D., Guichard,
J., and C. Pignataro, "Service
Function Chaining: Framework &
Architecture",
draft-boucadair-sfc-framework-02
(work in progress), February 2014.
Authors' Addresses
Qin Wu
Huawei
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012
China
EMail: sunseawq@huawei.com
Dhruv Dhody
Huawei
Leela Palace
Bangalore, Karnataka 560008
INDIA
EMail: dhruv.ietf@gmail.com
Wu, et al. Expires August 17, 2014 [Page 9]
Internet-Draft PCEP for SFC February 2014
Jeff Tantsura
Ericsson
300 Holger Way
San Jose, CA 95134
US
EMail: Jeff.Tantsura@ericsson.com
Wu, et al. Expires August 17, 2014 [Page 10]