PCE Working Group X. Xu
Internet-Draft Huawei
Intended status: Standards Track J. You
Expires: July 2, 2017
S. Sivabalan
Cisco
H. Shah
Ciena
L. Contreras
Telefonica I+D
D. Bernier
Bell Canada
December 29, 2016
PCEP Extensions for MPLS Source Routing-based SFC
draft-xu-pce-sr-sfc-04
Abstract
Source Packet Routing in Networking (SPRING) WG is developing an MPLS
source routing mechanism. This MPLS source routing mechanism can be
leveraged to realize the service path layer functionality of the
service function chaining (i.e., steering the selected traffic
through a particular service function path) by encoding the service
function path information as an MPLS label stack. This document
describes extensions to the Path Computation Element Protocol (PCEP)
that allow a PCE to compute and instantiate service function paths in
the MPLS source routing based service function chaining context. The
extensions specified in this document are applicable to both the
stateless PCE model and the stateful PCE model.
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 RFC 2119 [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/.
Xu, et al. Expires July 2, 2017 [Page 1]
Internet-Draft December 2016
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 July 2, 2017.
Copyright Notice
Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. PCEP Message Extensions for MPLS Source Routing-based SFC . . 4
3.1. PCReq Message . . . . . . . . . . . . . . . . . . . . . . 4
3.2. PCRep Message . . . . . . . . . . . . . . . . . . . . . . 4
3.3. PCUpd Message . . . . . . . . . . . . . . . . . . . . . . 5
3.4. PCRpt Message . . . . . . . . . . . . . . . . . . . . . . 5
4. Object Formats . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 6
4.1.1. SR-SFC PCE Capability TLV . . . . . . . . . . . . . . 6
4.2. RP/SRP Object . . . . . . . . . . . . . . . . . . . . . . 6
4.3. Include Route Object . . . . . . . . . . . . . . . . . . 7
4.4. SR-SFC-ERO Object . . . . . . . . . . . . . . . . . . . . 7
4.4.1. SR-SFC-ERO Subobject . . . . . . . . . . . . . . . . 7
4.4.2. NSI Associated with SID . . . . . . . . . . . . . . . 9
4.4.3. SR-SFC-ERO Processing . . . . . . . . . . . . . . . . 9
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6.1. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 9
6.2. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 9
6.3. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 10
6.4. New Path Setup Type . . . . . . . . . . . . . . . . . . . 10
6.5. New IRO Sub-object Type . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
Xu, et al. Expires July 2, 2017 [Page 2]
Internet-Draft December 2016
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
Service Function Chaining [RFC7665] provides a flexible way to
construct services. When applying a particular Service Function
Chain (SFC) to the traffic classified by the Classifier, the traffic
needs to be steered through an ordered set of Service Function
Forwarders (SFF) and Service Functions (SF) in the network. This
ordered set of SFFs and SFs in the network, referred to as a Service
Function Path (SFP), is an instantiation of the SFC in the network.
For example, as shown in Figure 1, an SFP corresponding to the SFC of
{SF1, SF3} can be expressed as {SFF1, SF1, SFF2, SF3}.
+-------+
+--+ PCE |
| +-------+
|
|
|
| +-------------------------------------------------+
| | MPLS-SR Netowrks |
| | +-----+ +-----+ |
| | | SF1 | | SF2 | |
| | +--+--+ +--+--+ |
| | | | |
| | ^ | | |
| | (2)| +---+ +---+ |
| | +--+ | | |
++---------+ | | | +--------------+ |
| +----+| V | | | +-----+ | |
| |PCC || (1) +---+-+----+ (3) | | SF3 | | |
--> |SFC +----+|----> | SFF1 |---->| +-----+ |---->
----+Classifier+------+ +-----+ SFF2 +--------
+----------+ +----------+ +--------------+ |
| |
+-------------------------------------------------+
Figure 1: PCE-based Service Function Chaining in MPLS-SR Network
Source Packet Routing in Networking (SPRING) WG is developing an MPLS
source routing mechanism called MPLS Segment Routing (SR). This MPLS
SR mechanism can be leveraged to realize the service path layer
functionality of the service function chaining (i.e., steering the
selected traffic through a particular service function path) by
Xu, et al. Expires July 2, 2017 [Page 3]
Internet-Draft December 2016
encoding the service function path information as an MPLS label
stack, as described in [I-D.xu-mpls-service-chaining].
This document describes extensions to the Path Computation Element
Protocol (PCEP) that allow a PCE to compute and instantiate service
function paths in the MPLS source routing based service function
chaining context. More specifically, the PCC provides an ordered
list of SF IDs to the PCE and indicates to the PCE that what type SFs
and paths are requested (e.g., an SFP, or a compact SFP, or an SR-
specific SFP, or a compact SR-specific SFP) through the path
computation request message, and then the PCE responds with a
corresponding path through the path computation response message.
The extensions specified in this document are applicable to both the
stateless PCE model [RFC5440] and the stateful PCE model
[I-D.ietf-pce-stateful-pce].
2. Terminology
This memo makes use of the terms defined in [RFC5440],
[I-D.ietf-pce-segment-routing] and [I-D.xu-mpls-service-chaining].
In addition, this memo defines the following two additional terms:
SR-specific SFP: An ordered list of node SIDs (representing SFFs)
and Service Function SIDs.
Compact SR-specific SFP: An ordered list of node SIDs
(representing SFFs).
3. PCEP Message Extensions for MPLS Source Routing-based SFC
3.1. PCReq Message
This document does not specify any changes to the PCReq message
format. This document requires the PATH-SETUP-TYPE TLV
[I-D.ietf-pce-lsp-setup-type] to be carried in the RP Object in order
for a PCC to request a particular type of path. Four new Path Setup
Types need to be defined for MPLS source routing-based SFC (see
Section 4.2). This document also requires the Include Route Object
(IRO) to be carried in the PCReq message in order for a PCC to
specify an SFC. A new IRO sub-object type needs to be defined for SF
(see Section 4.3).
3.2. PCRep Message
This document defines the format of the PCRep message carrying an
SFP. The message is sent by a PCE to a PCC in response to a
previously received PCReq message, where the PCC requested an SFP.
The format of the SFC-specific PCRep message is defined as follows:
Xu, et al. Expires July 2, 2017 [Page 4]
Internet-Draft December 2016
<PCRep Message>::=<Common Header>
<response-list>
Where:
<response-list>::=<response>[<response-list>]
<response>::=<RP>
[<NO-PATH>]
[<path-list>]
Where:
<path-list>::=<SR-SFC-ERO>[<path-list>]
The RP and NO-PATH Objects are defined in [RFC5440]. The <SR-SFC-
ERO> object contains an SFP and is defined in Section 4.4.
3.3. PCUpd Message
This document defines the format of the PCUpd message carrying an SFP
update. The message is sent forwardly by a PCE to a PCC to update an
previously computed SFP.
The format of the PCUpd message is defined as follows:
<PCUpd Message>::=<Common Header>
<udpate-request-list>
Where:
<udpate-request-list>::=<udpate-request>[<udpate-request-list>]
<udpate-request>::=<SRP><path-list>
Where:
<path-list>::=<SR-SFC-ERO>[<path-list>]
3.4. PCRpt Message
PCPRpt message sent from a PCC to PCE as a respond to a PCUpd message
or in an unsolicited manner (e.g., during state synchronization).
The format of the PCUpd message is defined as follows:
<PCUpd Message>::=<Common Header>
<state-report-list>
Where:
<state-report-list>::=<state-report>[<state-report-list>]
<state-report>::=[<SRP>]<path-list>
Where:
<path-list>::=<SR-SFC-ERO>[<path-list>]
Xu, et al. Expires July 2, 2017 [Page 5]
Internet-Draft December 2016
4. Object Formats
4.1. OPEN Object
This document defines a new optional TLV for use in the OPEN Object.
4.1.1. SR-SFC PCE Capability TLV
The SR-SFC-PCE-CAPABILITY TLV is an optional TLV for use in the OPEN
Object to negotiate SR-SFC capability on the PCEP session. The
format of the SR-SFC-PCE-CAPABILITY TLV is shown in the following
Figure 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 | MSD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: SR-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 32-bit value is formatted as follows. The
"Maximum SID Depth" (1 octet) field (MSD) specifies the maximum
number of SIDs that a PCC is capable of imposing on a packet. The
"Flags" (1 octet) and "Reserved" (2 octets) fields are currently
unused, and MUST be set to zero and ignored on receipt.
4.1.1.1. Negotiating SR-SFC Capability
The SR-SFC capability TLV is contained in the OPEN object. By
including the TLV in the OPEN message to a PCE, a PCC indicates its
support for SFPs. By including the TLV in the OPEN message to a PCC,
a PCE indicates that it is capable of computing SFPs.
4.2. RP/SRP Object
In order to setup an SFP, the RP or SRP object MUST carry a PATH-
SETUP-TYPE TLV specified in [I-D.ietf-pce-lsp-setup-type]. This
document defines four new Path Setup Types (PST) for SR-SFC as
follows:
PST = 2: The path is an SFP.
PST = 3: The path is a compact SFP.
Xu, et al. Expires July 2, 2017 [Page 6]
Internet-Draft December 2016
PST = 4: The path is an SR-specific SFP.
PST = 5: The path is a compact SR-specific SFP.
4.3. Include Route Object
The IRO (Include Route Object) MUST be carried within PCReq messages
to indicate a particular SFC. Furthermore, the IRO MAY be carried in
PCRep messages. When carried within a PCRep message with the NO-PATH
object, the IRO indicates the set of service functions that cause the
PCE to fail to find a path. This document defines a new sub-object
type for the SR-SFC as follows:
Type Sub-object
5 Service Function ID
4.4. SR-SFC-ERO Object
Generally speaking, an SR-SFC-ERO object consists of one or more ERO
subobjects described in the following sub-sections to represent a
particular type of service function path. In the ERO subobject, each
SID is associated with an identifier that represents either an SFF or
an SF. This identifier is referred to as the 'Node or Service
Identifier' (NSI). As described later, an NSI can be represented in
various formats (e.g., IPv4 address, IPv6 address, SF identifier,
etc). Specifically, in the SFP case, the NSI of every ERO subobject
contained in the SR-SFC-ERO object represents an SFF or an SF while
the SID of each ERO subobject is set to null. In the compact SFP
case, the NSI of every ERO subobject contained in the SR-SFC-ERO
object only represents an SFF meanwhile the SID of every ERO
subobject is set to null. In the SR-specific SFP, the NSI of every
ERO subobject contained in the SR-SFC-ERO object represents an SFF or
an SF while the SID of every ERO subject MUST NOT be null. In the
compact SR-specific SFP, the NSI of every ERO subobject contained in
the SR-SFC-ERO object represents an SFF meanwhile the SID of every
ERO subobject MUST NOT be null.
4.4.1. SR-SFC-ERO Subobject
An SR-SFC-ERO subobject (as shown in Figure 3) consists of a 32-bit
header followed by the SID and the NSI associated with the SID. The
SID is a 32-bit or 128 bit number. The size of the NSI depends on
its respective type, as described in the following sub-sections.
Xu, et al. Expires July 2, 2017 [Page 7]
Internet-Draft December 2016
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | NSIT | Flags |P|F|S|C|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// SID (variable:4 or 16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// NSI (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: SR-SFC-ERO Subobject Format
'L' Flag: indicates whether the subobject represents a loose-hop
in the explicit route [RFC3209]. If this flag is unset, a PCC
MUST not overwrite the SID value present in the SR-SFC-ERO
subobject. Otherwise, a PCC MAY expand or replace one or more SID
value(s) in the received SR-SFC-ERO based on its local policy.
Type: is the type of the SR-SFC-ERO Subobject. This document
defines the SR-SFC-ERO Subobject type. A new code point will be
requested for the SR-SFC-ERO Subobject from IANA.
Length: contains the total length of the subobject in octets,
including the L, Type and Length fields. Length MUST be at least
4, and MUST be a multiple of 4.
NSI Type (NSIT): indicates the type of NSI associated with the
SID. The NSI-Type values are described later in this document.
Flags: is used to carry any additional information pertaining to
SID. Currently, the following flag bits are defined:
M: When this bit is set, the SID value represents an MPLS label
stack entry as specified in [RFC5462], where only the label
value is specified by the PCE. Other fields (TC, S, and TTL)
fields MUST be considered invalid, and PCC MUST set these
fields according to its local policy and MPLS forwarding rules.
C: When this bit as well as the M bit are set, then the SID
value represents an MPLS label stack entry as specified in
[RFC5462], where all the entry's fields (Label, TC, S, and TTL)
are specified by the PCE. However, a PCC MAY choose to
override TC, S, and TTL values according its local policy and
MPLS forwarding rules.
S: When this bit is set, the SID value in the subobject body is
null. In this case, the PCC is responsible for choosing the
Xu, et al. Expires July 2, 2017 [Page 8]
Internet-Draft December 2016
SID value, e.g., by looking up its Traffic Engineering Database
(TED) using node/service identifier in the subobject body.
F: When this bit is set, the NSI value in the subobject body is
null.
P: When this bit is set, the SID value represents an IPv6
address.
SID: is the 4-octect or 16-octect Segment Identifier
NSI: contains the NSI associated with the SID. Depending on the
value of NSIT, the NSI can have different format as described in
the following sub-section.
4.4.2. NSI Associated with SID
This document defines the following NSIs:
'IPv4 Node ID': is specified as an IPv4 address. In this case,
NSIT and Length are 1 and 12 respectively.
'IPv6 Node ID': is specified as an IPv6 address. In this case,
NSIT and Length are 2 and 24 respectively.
'Service Function ID': is specified as an SF ID. In this case,
NSIT and Length are TBD.
4.4.3. SR-SFC-ERO Processing
TBD
5. Acknowledgements
TBD.
6. IANA Considerations
6.1. PCEP Objects
IANA is requested to allocate an ERO subobject type (recommended
value= 6) for the SR-SFC-ERO subobject.
6.2. PCEP-Error Object
TBD
Xu, et al. Expires July 2, 2017 [Page 9]
Internet-Draft December 2016
6.3. PCEP TLV Type Indicators
This document defines the following new PCEP TLV:
Value Meaning Reference
27 SR-SFC-PCE-CAPABILITY This document
6.4. New Path Setup Type
This document defines the following four new setup types for the
PATH-SETUP-TYPE TLV:
Value Description Reference
2 The path is an SFP. This document
3 The path is a compact SFP. This document
4 The path is an SR-specific SFP. This document
5 The path is a compact SR-specific SFP. This document
6.5. New IRO Sub-object Type
This document defines a new IRO sub-object type for SFC as follows:
Type Sub-object
5 Service Function ID
7. Security Considerations
This document does not introduce any new security considerations.
8. References
8.1. Normative References
[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-18 (work in progress), December 2016.
Xu, et al. Expires July 2, 2017 [Page 10]
Internet-Draft December 2016
[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>.
[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>.
8.2. Informative References
[I-D.ietf-pce-lsp-setup-type]
Sivabalan, S., Medved, J., Minei, I., Crabbe, E., Varga,
R., Tantsura, J., and J. Hardwick, "Conveying path setup
type in PCEP messages", draft-ietf-pce-lsp-setup-type-03
(work in progress), June 2015.
[I-D.ietf-pce-segment-routing]
Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E.,
Raszuk, R., Lopez, V., Tantsura, J., Henderickx, W., and
J. Hardwick, "PCEP Extensions for Segment Routing", draft-
ietf-pce-segment-routing-08 (work in progress), October
2016.
[I-D.ietf-spring-segment-routing-mpls]
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
Litkowski, S., Horneffer, M., Shakir, R.,
jefftant@gmail.com, j., and E. Crabbe, "Segment Routing
with MPLS data plane", draft-ietf-spring-segment-routing-
mpls-05 (work in progress), July 2016.
[I-D.xu-mpls-service-chaining]
Xu, X., Bryant, S., Assarpour, H., Shah, H., Contreras,
L., and d. daniel.bernier@bell.ca, "Service Chaining using
MPLS Source Routing", draft-xu-mpls-service-chaining-00
(work in progress), October 2016.
[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>.
Authors' Addresses
Xu, et al. Expires July 2, 2017 [Page 11]
Internet-Draft December 2016
Xiaohu Xu
Huawei
Email: xuxiaohu@huawei.com
JIanjie You
Email: jianjie.you@gmail.com
Siva Sivabalan
Cisco
Email: msiva@cisco.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/
Daniel Bernier
Bell Canada
Email: daniel.bernier@bell.ca
Xu, et al. Expires July 2, 2017 [Page 12]