| PCE Working Group | Q. Wu |
| Internet-Draft | D. Dhody |
| Intended status: Standards Track | Huawei |
| Expires: January 1, 2016 | M. Boucadair |
| C. Jacquenet | |
| France Telecom | |
| J. Tantsura | |
| Ericsson | |
| June 30, 2015 |
PCEP Extensions for traffic steering support in Service Function Chaining
draft-wu-pce-traffic-steering-sfc-07
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.
This document specifies extensions to the Path Computation Element Protocol (PCEP) that allow a stateful PCE to compute and instantiate Service Function Paths (SFP).
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 January 1, 2016.
Copyright (c) 2015 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.
Service chaining 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 selected as a result of classification as described in [I-D.ietf-sfc-architecture] and referred to as Service Function Chain (SFC). A 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) and Service Function Forwarders (SFF).
[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).
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:
Services are constructed as a sequence of SFs that represent an SFC, where a SF can be a virtual instance or be embedded in a physical network element, and one or more 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 instantiated into the network it is necessary to select the specific instances of SFs that will be used, and to create the service function path for that SFC using SF network locators. Thus, the instantiation of a SFC results in the establishment of a Service Function Path, either a la hop-by-hop through the ordered sequence of SF functions, or in a pre-computed, traffic-engineered fashion. In other words, an SFP is the instantiation of the defined SFC as described in [I-D.ietf-sfc-architecture].
The selection of SFP can be based on a set of policy attributes (forwarding and routing, QoS, security, etc., or a combination thereof), ranging from simple to more elaborate selection criteria and the use of 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.
+------------------------+
| stateful PCE |
| +-------+ +-------+ |
| |Policy | | TE-DB | | +-------+
| +-------+ +-------+ | | SFC |
+----------| +-------------+ |<---|control|
|SFP | |LSP-DB/SFP-DB| | | plane |
|Instan- | +-------------+ | +-------+
|tiation +------------------------+
| +-----+ +-----+ +-----+
| |SF-1 | |SF-2 | |SF-3 |
| | | | | | |
| +---+-+ +-+---+ +--+--+
| | | |
| ++-----++ +----+--+
V | | | |
+-----+ Signaling | | Signaling | | Signaling
| SF |----------->| SFF-1 | --------->| SFF-2 |----------->
Classifier | | | |
|Node | | | | |
+-----+ +-------+ +-------+
Figure 1: PCE based SFP instantiation
SFC Control plane components are responsible for maintaining SFC Policy Tables and enforcing appropriate policies in SF Classifier and SFF Nodes as described in [I-D.ietf-sfc-architecture][I-D.ww-sfc-control-plane]. The SFC Control plane component can be seen as a policy Decision point (PDP,[RFC5394]). Such PDP can then operates a stateful PCE and its instantiation mechanism to compute and instantiate Service Function Paths (SFP). The PCE maybe co-located with the SFC Control plane component or an external entity.
A PCEP speaker indicates its ability to support PCE provisioned dynamic SFP paths during the PCEP Initialization phase via a mechanism described in Section 5.1. A PCE can initiate SFPs only for PCCs that advertised this capability and a PCC will follow the procedures described in this document only on 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) can be used to encode either a sequence of SF functions or a combination of SFs and SFFs to establish a SFP. If the said SFFs and SFs can be 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-Note: In case a PCE-Initiated Signaling mechanism is used to setup the service function path, then does the classifier / PCE-Initiated signaling protocol needs to understand if the IP address is for SFF or SF or the signaling protocol is only used to signal IP address for SFs?
The Instantiation operation of a SFP is the same as defined in section 5.3[I-D.ietf-pce-pce-initiated-lsp]. Rules of processing and error codes remain unchanged.
The withdrawal operation of a 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 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 remain unchanged.
SFP delegation and cleanup operations are similar to those defined in section 6 of [I-D.ietf-pce-pce-initiated-lsp]. Rules of processing and error codes remains unchanged.
State Synchronization operations described in Section 5.4 of [I-D.ietf-pce-stateful-pce]can be applied for SFP state maintenance as well.
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 for SFPs as well.
This document defines a new optional TLV 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 for use in the OPEN Object to advertise the SFC capability during the PCEP session. The format of the SFC-PCE-CAPABILITY TLV is shown in the followingFigure 2 :
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. The TLV length is 4 octets.
The value is TBD.
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) conveyed 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.
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 (F) flag, is introduced. The F Flag 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.
The SFP Identifiers TLV MUST be included in the LSP object for Service Function Paths (SFP). The SFP Identifier TLV is used by the classifier to enable SFP selection for the traffic,i.e.,direct traffic to specific SFP[I-D.ietf-sfc-architecture]. The SFP Identifier carried in the SFC encapsulation can be further used by SFF to select service functions and next SFF,e.g., enable a packet that repeatedly arrives at the same SFF to get the correct services provided each time it arrives, and to go to the correct next SFF each time it arrives.
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
The format of SFP Identifier TLV is shown in the following figure.
SI: provides location within the service path.
The SFP instantiation capability PCEP protocol extensions described in this document MUST NOT be used if PCCs or the PCE did not advertise its SFP instantiation stateful 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]
The SFP instantiation mechanism described in this document is not tightly coupled to any SFP signaling mechanism. For example,SR-based approach [I-D.ietf-pce-segment-routing] can utilize the mechanism described here and does not need any other specific protocol extensions. Generic SFC Encapsulation [I-D.quinn-sfc-nsh] can also be used together with the mechanism described here to enable SFP forwarding.
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.
TBD
Many thanks to Ron Parker, Hao Wang,Dave Dolson,Jing Huang,Joel M. Halpern for the discussion in formulating the content for the draft.
| [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., Minei, I., Medved, J. and R. Varga, "PCEP Extensions for Stateful PCE", Internet-Draft draft-ietf-pce-stateful-pce-11, April 2015. |
| [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", Internet-Draft draft-ietf-pce-pce-initiated-lsp-04, April 2015. |