PCE Working Group Q. Wu
Internet-Draft D. Dhody
Intended status: Standards Track Huawei
Expires: December 28, 2014 M. Boucadair
C. Jacquenet
France Telecom
J. Tantsura
Ericsson
June 26, 2014

PCEP Extensions for traffic steering support in Service Function Chaining
draft-wu-pce-traffic-steering-sfc-04

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 December 28, 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 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

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.boucadair-sfc-framework][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.
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.boucadair-sfc-framework][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.

           +---------------------------------+
           |+------+ +------+            PDP |
           ||      | |      |                |
           ||      | |      |                |
           ||PCE   | |Policy|                |
           |*------+ +------+                |
           *---------------------------------+
          /
         /
        / SFP
       /  Instan-
      /   tiation
     /             SF Node1            SF Node2
    /              +-------+           +-------+
   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.

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:

 
 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.

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. Relationship to SR

Segment Routing (SR) technology leverages the source routing and tunneling paradigms where a source node can choose a path without relying on hop-by-hop signaling. A stateful PCE can be used for computing one or more SR-TE paths taking into account various constraints and objective functions. Once a path is chosen, the stateful PCE can instantiate an SR-TE path on a PCC using PCEP extensions specified in [I-D.sivabalan-pce-segment-routing].

The SFP instantiation mechanism described in this document is not tightly coupled to any SFP signaling mechanism. Thus SR based SFP can also utilize the mechanism described here and do not need another set of protocol extensions.

8. 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.

9. IANA Considerations

TBD

10. References

10.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., Minei, I., Medved, J. and R. Varga, "PCEP Extensions for Stateful PCE", Internet-Draft draft-ietf-pce-stateful-pce-09, June 2014.
[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-01, June 2014.

10.2. Informative References

[RFC2753] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for Policy-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 J. Halpern, "Service Function Chaining (SFC) Architecture", Internet-Draft draft-quinn-sfc-arch-05, May 2014.
[I-D.boucadair-sfc-framework] Boucadair, M., Jacquenet, C., Parker, R., Lopez, D., Guichard, J. and C. Pignataro, "Service Function Chaining: Framework & Architecture", Internet-Draft draft-boucadair-sfc-framework-02, February 2014.
[I-D.sivabalan-pce-segment-routing] Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E. and R. Raszuk, "PCEP Extensions for Segment Routing", Internet-Draft draft-sivabalan-pce-segment-routing-02, October 2013.

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
Mohamed Boucadair France Telecom Rennes 35000 France EMail: mohamed.boucadair@orange.com
Christian Jacquenet France Telecom Rennes 35000 France EMail: christian.jacquenet@orange.com
Jeff Tantsura Ericsson 300 Holger Way San Jose, CA 95134 US EMail: Jeff.Tantsura@ericsson.com