Internet DRAFT - draft-xu-pce-sr-sfc
draft-xu-pce-sr-sfc
PCE Working Group X. Xu
Internet-Draft Huawei
Intended status: Standards Track J. You
Expires: January 4, 2018
S. Sivabalan
Cisco
H. Shah
Ciena
L. Contreras
Telefonica I+D
D. Bernier
Bell Canada
S. Ma
Juniper
July 3, 2017
PCEP Extensions for Unifed Source Routing-based SFC
draft-xu-pce-sr-sfc-05
Abstract
MPLS-SPRING (a.k.a., MPLS Segment Routing) could be leveraged to
realize a unified source routing mechanism across MPLS, IPv4 and IPv6
data planes by using a unified source routing instruction set while
preserving backward compatibility with MPLS-SPRING. More
specifically, the source routing instruction set information
contained in a source routed packet could be uniformly encoded as an
MPLS label stack no matter the underlay is IPv4, IPv6 or MPLS. The
unified source routing mechanism could be leveraged to realize a
transport-independent service function chaining by encoding the
service function path information or service function chain
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 unifed
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].
Xu, et al. Expires January 4, 2018 [Page 1]
Internet-Draft July 2017
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 January 4, 2018.
Copyright Notice
Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. PCEP Message Extensions for MPLS Source Routing-based SFC . . 5
3.1. PCReq Message . . . . . . . . . . . . . . . . . . . . . . 5
3.2. PCRep Message . . . . . . . . . . . . . . . . . . . . . . 5
3.3. PCUpd Message . . . . . . . . . . . . . . . . . . . . . . 6
3.4. PCRpt Message . . . . . . . . . . . . . . . . . . . . . . 6
4. Object Formats . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 6
4.1.1. SR-SFC PCE Capability TLV . . . . . . . . . . . . . . 6
4.2. RP/SRP Object . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Include Route Object . . . . . . . . . . . . . . . . . . 7
4.4. SR-SFC-ERO Object . . . . . . . . . . . . . . . . . . . . 8
4.4.1. SR-SFC-ERO Subobject . . . . . . . . . . . . . . . . 8
Xu, et al. Expires January 4, 2018 [Page 2]
Internet-Draft July 2017
4.4.2. NSI Associated with SID . . . . . . . . . . . . . . . 10
4.4.3. SR-SFC-ERO Processing . . . . . . . . . . . . . . . . 10
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6.1. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 10
6.2. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 10
6.3. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 10
6.4. New Path Setup Type . . . . . . . . . . . . . . . . . . . 10
6.5. New IRO Sub-object Type . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
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}.
Xu, et al. Expires January 4, 2018 [Page 3]
Internet-Draft July 2017
+-------+
+--+ 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
MPLS-SPRING (a.k.a., MPLS Segment Routing) could be leveraged to
realize a unified source routing mechanism across MPLS, IPv4 and IPv6
data planes by using a unified source routing instruction set while
preserving backward compatibility with MPLS-SPRING as descried in
[I-D.xu-mpls-unified-source-routing-instruction]. More specifically,
the source routing instruction set information contained in a source
routed packet could be uniformly encoded as an MPLS label stack no
matter the underlay is IPv4, IPv6 or MPLS. The unified source
routing mechanism in turn could be leveraged to realize a transport-
independent service function chaining by encoding the service
function path information or service function chain 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.
Xu, et al. Expires January 4, 2018 [Page 4]
Internet-Draft July 2017
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:
Compact SFP: An ordered list of SFFs.
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:
<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>]
Xu, et al. Expires January 4, 2018 [Page 5]
Internet-Draft July 2017
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>]
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:
Xu, et al. Expires January 4, 2018 [Page 6]
Internet-Draft July 2017
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.
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:
Xu, et al. Expires January 4, 2018 [Page 7]
Internet-Draft July 2017
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.
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
Xu, et al. Expires January 4, 2018 [Page 8]
Internet-Draft July 2017
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
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.// When will the NSI value 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.
Xu, et al. Expires January 4, 2018 [Page 9]
Internet-Draft July 2017
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
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:
Xu, et al. Expires January 4, 2018 [Page 10]
Internet-Draft July 2017
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-21 (work in progress), June 2017.
[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
Xu, et al. Expires January 4, 2018 [Page 11]
Internet-Draft July 2017
[I-D.ietf-pce-lsp-setup-type]
Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J.
Hardwick, "Conveying path setup type in PCEP messages",
draft-ietf-pce-lsp-setup-type-04 (work in progress), April
2017.
[I-D.ietf-pce-segment-routing]
Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
and J. Hardwick, "PCEP Extensions for Segment Routing",
draft-ietf-pce-segment-routing-09 (work in progress),
April 2017.
[I-D.ietf-spring-segment-routing-mpls]
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing with MPLS
data plane", draft-ietf-spring-segment-routing-mpls-10
(work in progress), June 2017.
[I-D.xu-mpls-service-chaining]
Xu, X., Bryant, S., Assarpour, H., Shah, H., Contreras,
L., daniel.bernier@bell.ca, d., jefftant@gmail.com, j.,
Ma, S., and M. Vigoureux, "Service Chaining using Unified
Source Routing Instructions", draft-xu-mpls-service-
chaining-03 (work in progress), June 2017.
[I-D.xu-mpls-unified-source-routing-instruction]
Xu, X., Bryant, S., Raszuk, R., Chunduri, U., Contreras,
L., Jalil, L., Assarpour, H., Velde, G., Tantsura, J., and
S. Ma, "Unified Source Routing Instruction using MPLS
Label Stack", draft-xu-mpls-unified-source-routing-
instruction-02 (work in progress), June 2017.
[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
Xiaohu Xu
Huawei
Email: xuxiaohu@huawei.com
JIanjie You
Email: jianjie.you@gmail.com
Xu, et al. Expires January 4, 2018 [Page 12]
Internet-Draft July 2017
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
Shaowen Ma
Juniper
Email: mashaowen@gmail.com
Xu, et al. Expires January 4, 2018 [Page 13]
