Internet DRAFT - draft-xu-spring-pce-based-sfc-arch
draft-xu-spring-pce-based-sfc-arch
Spring Working Group X. Xu
Internet-Draft J. You
Intended status: Standards Track Huawei
Expires: December 24, 2014 H. Shah
Ciena
L. Contreras
Telefonica I+D
June 22, 2014
PCE-based SFC Architecture in SR Networks
draft-xu-spring-pce-based-sfc-arch-01
Abstract
Service Function Chaining (SFC) provides a flexible way to construct
services. When applying a particular service function chain to the
traffic, the traffic needs to be steered through an ordered set of
service functions in the network. This ordered set of service
functions in the network, referred to as a Service Function Path
(SFP), is an instantiation of the service function chain in the
network. Segment Routing (SR) technique can be leveraged to steer
the traffic through the SFP in SR networks. This document describes
a PCE-based SFC architecture in which the PCE is used to compute a
service function path (i.e., instantiate a service function chain) in
SR networks.
Requirements Language
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].
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."
Xu, et al. Expires December 24, 2014 [Page 1]
Internet-Draft PCE-based SFC Arch June 2014
This Internet-Draft will expire on December 24, 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. PCE-based SFC Architecture in SR Networks . . . . . . . . . . 4
3.1. PCC Requests SFP . . . . . . . . . . . . . . . . . . . . 6
3.2. PCC Requests SR-specific SFP . . . . . . . . . . . . . . 6
3.3. PCEP Extensions Discussion . . . . . . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5. Security considerations . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
Service Function Chaining provides a flexible way to construct
services. When applying a particular service function chain to the
traffic classified by the SFC classifier, the traffic needs to be
steered through an ordered set of service functions in the network.
This ordered set service functions in the network, referred to as a
Service Function Path (SFP), is an instantiation of the service
function chain in the network. For example, as shown in Figure 1, a
SFP corresponding to the SFC of {SF1, SF3} can be expressed as
{Service Node 1, SF1, Service Node 2, SF3}.
Xu, et al. Expires December 24, 2014 [Page 2]
Internet-Draft PCE-based SFC Arch June 2014
+-------------------------------------------------+
| SR Netowrks |
| +-----+ +-----+ |
| | SF1 | | SF2 | |
| +--+--+ +--+--+ |
| | | |
| ^ | | |
| (2)| +---+ +---+ |
| +--+ | | |
| | | | +--------------+ |
| V | | |+-----+ | |
+----------+ (1) +---+-+----+ (3) || SF3 | | |
--> |SFC |----> | Service |---->|+-----+ |---->
----+Classifier+------+ Node 1 +-----+Service Node 2+--------
+----------+ +----------+ +--------------+ |
| |
| |
| |
+-------------------------------------------------+
Figure 1: Service Function Chaining in SR Network
Segment Routing (SR) [I-D.filsfils-spring-segment-routing] technique
leverages the source routing and tunneling paradigms, which can be
used to steer traffic through an ordered set of routers. SR can be
applied to both MPLS data plane [I-D.gredler-spring-mpls],
[I-D.filsfils-spring-segment-routing-mpls] and IPv6 data plane
[I-D.previdi-6man-segment-routing-header].
[I-D.sivabalan-pce-segment-routing] specifies extensions to the Path
Computation Element Protocol (PCEP) [RFC5440] that allow a stateful
PCE to compute and instantiate an SR path.
[I-D.xu-spring-sfc-use-case] describes a use case for SPRING where
the SR mechanism is leveraged to realize the service path layer
functionality of the SFC.
This document describes an architecture for PCEP in which a stateful
PCE is used to compute an SFP in SR networks.
2. Terminology
This section contains definitions for terms used frequently
throughout this document. However, many additional definitions can
be found in [I-D.quinn-sfc-arch].
Service Function (SF): A function that is responsible for specific
treatment of received packets.
Xu, et al. Expires December 24, 2014 [Page 3]
Internet-Draft PCE-based SFC Arch June 2014
Service Function Chain (SFC): A service function chain defines an
ordered set of service functions that must be applied to packets
and/or frames selected as a result of classification.
Service Node (SN): Physical or virtual element that hosts one or
more service functions and has one or more network locators
associated with it for reachability and service delivery.
SF Identifier (SF ID): A unique identifier that represents a
service function within an SFC-enabled domain.
SFC Classifier: An entity that classifies packets for service
function chaining according to classification rules. Packets are
then marked with the corresponding SFC header. SFC classifier is
embedded in a SFC ingress node.
Service Function Path (SFP): The instantiation of an SFC in the
network. Specifically, it is an ordered list of service node
locators and SF IDs.
Compact SFP: An ordered list of service node locators.
SR: Segment Routing.
SR Header: an MPLS label stack or an IPv6 address list.
SID: Segment Identifier.
Service Function SID : A locally unique SID indicating a
particular service function on a service node.
SR-specific SFP: An ordered list of node SIDs (representing
service nodes) and Service Function SIDs.
Compact SR-specific SFP: An ordered list of node SIDs
(representing service nodes).
PCC: Path Computation Client.
PCE: Path Computation Element.
PCEP: Path Computation Element Protocol.
3. PCE-based SFC Architecture in SR Networks
When a packet enters an SFC-enabled domain, the SFC classifier
classifies the packet for service function chaining according to the
local policy rules, and then attaches an SFC header
Xu, et al. Expires December 24, 2014 [Page 4]
Internet-Draft PCE-based SFC Arch June 2014
[I-D.quinn-sfc-nsh] to the packet which should include the SFP
information. As in this document SR technique is leveraged to steer
the packet through the SFP, the SFC classifier therefore needs to
attach a segment list which represents the SFP to the packet.
[RFC5440] describes PCEP for communication between a Path Computation
Client (PCC) and a Path Control Element (PCE). In this document, the
PCE is responsible for computing the SFP or the SR-specific SFP,
while the SFC classifier constructs the SR header according to the
path computation result returned from the PCE (as shown in Figure 2).
+---------+
| |
+---------> PCE |
| | |
| +---------+
|
|
|
|
| +---------------------------------------------------+
| | SR Netowrks |
| | |
| | ------------- |
+--V--------+ ///// \\\\\ |
| +-----+| // +-----+ +-----+ \\ |
| | PCC || | | SF1 | | SF2 | | |
----> |SFC +-----+| | +-----+ +-----+ | ----->
------+Classifier +------ +-----+ ----------------
+-----------+ | | SF3 | - |
| \\ +-----+ // |
| \\\\\ ///// |
| ------------- |
+---------------------------------------------------+
Figure 2: PCE-based SFC Architecture in SR Networks
Two methods will be discussed depending on the requested path type
from the PCC:
(1) The PCC requests an SFP.
(2) The PCC requests an SR-specific SFP.
In the first case, the SFC classifier needs to transform the SFP
information to the SR-specific SFP information and then attach an SR
header containing the SR-specific SFP information to the packets.
For the second case, the SFC classifier can directly attach an SR
Xu, et al. Expires December 24, 2014 [Page 5]
Internet-Draft PCE-based SFC Arch June 2014
header containing the SR-specific SFP information to the packets.
The detailed will be discussed in the following sub-sections.
3.1. PCC Requests SFP
The PCE is responsible for computing the SFP based on the network
information, SF information, service requirements, etc. How PCE
computes the SFP is out of scope of this document. The SFC
classifier is responsible to transform the SFP to the SR-specific
SFP. The detailed procedures are described below:
Step 1: The SFC classifier acting as a PCC sends a PCReq message
to the PCE to request an SFP or a compact SFP. Two new setup
types of the PATH-SETUP-TYPE TLV must be carried, indicating that
an SFP or a compact SFP needs to be setup. The PCReq message also
needs to carry an ordered set of SF Identifiers which indicates
the SFC.
Step 2: The PCE sends a response to the PCC, carrying an SFP or a
compact SFP.
Step 3: If the PCE returns an SFP, the SFC classifier transforms
the SFP information into the SR-specific SFP information. If the
PCE returns a compact SFP, the SFC classifier needs to insert the
corresponding SF identifier after each service node and then
transform it into the SR-specific SFP information .
Step 4: Upon receiving the packets, the SFC classifier classifies
them for service function chain according to classification rules.
Packets are then attacheded with an SR header containing the
corresponding SR-specific SFP information.
3.2. PCC Requests SR-specific SFP
The PCE is responsible to compute the SR-specific SFP based on the
network information, SF information, service requirements, etc. How
PCE computes the SR-specific SFP is out of scope of this document.
The SFC classifier is responsible to attach an SR header containing
the SR-specific SFP information to the selected packets. The
detailed procedures are described below:
Step 1: The SFC classifier sends a PCReq message to the PCE to
request an SR-specific SFP. A new setup type of the PATH-SETUP-
TYPE TLV must be carried, indicating that an SR-specific SFP needs
to be setup. The PCC also needs to carry an ordered set of SF
identifiers.
Xu, et al. Expires December 24, 2014 [Page 6]
Internet-Draft PCE-based SFC Arch June 2014
Step 2: The PCE sends a response to the PCC, carrying an SR-
specific SFP.
Step 3: Upon receiving the packets, the SFC classifier classifies
them for service chaining according to classification rules.
Packets are then attched with an SR header containning the
corresponding SR-specific SFP information.
3.3. PCEP Extensions Discussion
The possible PCEP extensions for supporting the two methods proposed
in this document will be specified in a separate document.
4. IANA Considerations
TBD.
5. Security considerations
This document does not introduce any new security considerations.
6. Acknowledgement
TBD.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element
(PCE) Communication Protocol (PCEP)", RFC 5440, March
2009.
7.2. Informative References
[I-D.filsfils-spring-segment-routing]
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,
Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe,
"Segment Routing Architecture", draft-filsfils-spring-
segment-routing-03 (work in progress), June 2014.
Xu, et al. Expires December 24, 2014 [Page 7]
Internet-Draft PCE-based SFC Arch June 2014
[I-D.filsfils-spring-segment-routing-mpls]
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,
Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe,
"Segment Routing with MPLS data plane", draft-filsfils-
spring-segment-routing-mpls-02 (work in progress), June
2014.
[I-D.gredler-spring-mpls]
Gredler, H., Rekhter, Y., Jalil, L., Kini, S., and X. Xu,
"Supporting Source/Explicitly Routed Tunnels via Stacked
LSPs", draft-gredler-spring-mpls-06 (work in progress),
May 2014.
[I-D.previdi-6man-segment-routing-header]
Previdi, S., Filsfils, C., Field, B., and I. Leung, "IPv6
Segment Routing Header (SRH)", draft-previdi-6man-segment-
routing-header-01 (work in progress), June 2014.
[I-D.quinn-sfc-arch]
Quinn, P. and J. Halpern, "Service Function Chaining (SFC)
Architecture", draft-quinn-sfc-arch-05 (work in progress),
May 2014.
[I-D.quinn-sfc-nsh]
Quinn, P., Guichard, J., Fernando, R., Surendra, S.,
Smith, M., Yadav, N., Agarwal, P., Manur, R., Chauhan, A.,
Elzur, U., McConnell, B., and C. Wright, "Network Service
Header", draft-quinn-sfc-nsh-02 (work in progress),
February 2014.
[I-D.sivabalan-pce-segment-routing]
Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E., and
R. Raszuk, "PCEP Extensions for Segment Routing", draft-
sivabalan-pce-segment-routing-02 (work in progress),
October 2013.
[I-D.xu-spring-sfc-use-case]
Xu, X., Li, Z., and H. Shah, "Service Function Chaining
Use Case for SPRING", draft-xu-spring-sfc-use-case-01
(work in progress), June 2014.
Authors' Addresses
Xiaohu Xu
Huawei
Email: xuxiaohu@huawei.com
Xu, et al. Expires December 24, 2014 [Page 8]
Internet-Draft PCE-based SFC Arch June 2014
Jianjie You
Huawei
101 Software Avenue, Yuhuatai District
Nanjing, 210012
China
Email: youjianjie@huawei.com
Himanshu Shah
Ciena
Email: hshah@ciena.com
Luis M. Contreras
Telefonica I+D
Ronda de la Comunicacion, s/n
Sur-3 building, 3rd floor
Madrid, 28050
Spain
Email: luismiguel.contrerasmurillo@telefonica.com
URI: http://people.tid.es/LuisM.Contreras/
Xu, et al. Expires December 24, 2014 [Page 9]
