PCEP Extensions for SFC in SR Networks
draft-xu-pce-sr-sfc-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Xiaohu Xu , Jianjie You , Himanshu Shah , Luis M. Contreras | ||
| Last updated | 2014-06-22 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-xu-pce-sr-sfc-01
Pce 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
PCEP Extensions for SFC in SR Networks
draft-xu-pce-sr-sfc-01
Abstract
[I-D.xu-spring-pce-based-sfc-arch] describes a PCE-based SFC
architecture in which the PCE is used to compute service function
paths in SR networks. Based on the above architecture, this document
describes extensions to the Path Computation Element Protocol (PCEP)
that allow a PCE to compute and instantiate service function paths 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."
This Internet-Draft will expire on December 24, 2014.
Xu, et al. Expires December 24, 2014 [Page 1]
Internet-Draft PCEP Extensions for SR-based SFC June 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of PCEP Extensions for SFC in SR Networks . . . . . 4
4. PCEP Message Extensions for SR-based SFC . . . . . . . . . . 5
4.1. PCReq Message . . . . . . . . . . . . . . . . . . . . . . 5
4.2. PCRep Message . . . . . . . . . . . . . . . . . . . . . . 5
5. Object Formats . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 5
5.1.1. SR-SFC PCE Capability TLV . . . . . . . . . . . . . . 6
5.2. RP Object . . . . . . . . . . . . . . . . . . . . . . . . 6
5.3. Include Route Object . . . . . . . . . . . . . . . . . . 7
5.4. SR-SFC-ERO Object . . . . . . . . . . . . . . . . . . . . 7
5.4.1. SR-SFC-ERO Subobject . . . . . . . . . . . . . . . . 7
5.4.2. NSI Associated with SID . . . . . . . . . . . . . . . 9
5.4.3. SR-SFC-ERO Processing . . . . . . . . . . . . . . . . 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
8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
Xu, et al. Expires December 24, 2014 [Page 2]
Internet-Draft PCEP Extensions for SR-based SFC June 2014
1. Introduction
Service Function Chaining (SFC) 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, an
SFP corresponding to the SFC of {SF1, SF3} can be expressed as
{Service Node 1, SF1, Service Node 2, SF3}.
+-------+
+--+ PCE |
| +-------+
|
|
|
| +-------------------------------------------------+
| | SR Netowrks |
| | +-----+ +-----+ |
| | | SF1 | | SF2 | |
| | +--+--+ +--+--+ |
| | | | |
| | ^ | | |
| | (2)| +---+ +---+ |
| | +--+ | | |
++---------+ | | | +--------------+ |
| +----+| V | | |+-----+ | |
| |PCC || (1) +---+-+----+ (3) || SF3 | | |
--> |SFC +----+|----> | Service |---->|+-----+ |---->
----+Classifier+------+ Node 1 +-----+Service Node 2+--------
+----------+ +----------+ +--------------+ |
| |
+-------------------------------------------------+
Figure 1: PCE-based Service Function Chaining in SR Network
[I-D.xu-spring-pce-based-sfc-arch] 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.
This document describes extensions to the PCEP based on that
architecture.
Xu, et al. Expires December 24, 2014 [Page 3]
Internet-Draft PCEP Extensions for SR-based SFC June 2014
2. Terminology
This section contains definitions for terms used frequently
throughout this document. However, many additional definitions can
be found in [RFC5440], [I-D.sivabalan-pce-segment-routing] and
[I-D.xu-spring-pce-based-sfc-arch].
PCC: Path Computation Client
PCE: Path Computation Element
PCEP: Path Computation Element Protocol
ERO: Explicit Route Object
SF Identifier (SF ID): A unique identifier that represents a
service function within an SFC-enabled domain.
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.
SID: Segment Identifier
Service Function SID : A locally unique SID indicating a
particular service function on a service node.
SR: Segment Routing
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).
3. Overview of PCEP Extensions for SFC in SR Networks
As discussed in [I-D.xu-spring-pce-based-sfc-arch], the PCC provides
an ordered list of SF IDs to the PCE and indicates to the PCE that
what type of path is requested (e.g., an SFP, or a compact SFP, or an
SR-specific SFP, or a compact SR-specific SFP), and then the PCE
responds with a correponding path.
Xu, et al. Expires December 24, 2014 [Page 4]
Internet-Draft PCEP Extensions for SR-based SFC June 2014
4. PCEP Message Extensions for SR-based SFC
4.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.sivabalan-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 SR-based SFC, or SR-SFC in short
(Section 5.2). This document also requires the Include Route Object
(IRO) to be carried in the PCReq message in order for a PCC to
specify that the computed SFP must traverse a set of specified
service functions. A new IRO sub-object type needs to be defined for
SFC (Section 5.3).
4.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 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>]
The RP and NO-PATH Objects are defined in [RFC5440]. The <SR-SFC-
ERO> object contains the SFP and is defined in Section 5.4.
5. Object Formats
5.1. OPEN Object
This document defines a new optional TLV for use in the OPEN Object.
Xu, et al. Expires December 24, 2014 [Page 5]
Internet-Draft PCEP Extensions for SR-based SFC June 2014
5.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.
5.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.
5.2. RP Object
In order to setup an SFP, the RP object MUST carry a PATH-SETUP-TYPE
TLV specified in [I-D.sivabalan-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.
Xu, et al. Expires December 24, 2014 [Page 6]
Internet-Draft PCEP Extensions for SR-based SFC June 2014
5.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
5.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 a service
node or a service function. 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 a service
node or a service function 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 a service node
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 a service node or a service function 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 a service node meanwhile the SID of every ERO
subobject MUST NOT be null.
5.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 December 24, 2014 [Page 7]
Internet-Draft PCEP Extensions for SR-based SFC June 2014
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
The fields in the ERO Subobject are as follows:
'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.
Xu, et al. Expires December 24, 2014 [Page 8]
Internet-Draft PCEP Extensions for SR-based SFC June 2014
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.
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.
5.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 ID': is specified as an SF ID. In this case, NSIT and
Length are TBD.
5.4.3. SR-SFC-ERO Processing
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 December 24, 2014 [Page 9]
Internet-Draft PCEP Extensions for SR-based SFC June 2014
6.3. PCEP TLV Type Indicators
This document defines the following new PCEP TLVs:
Value Meaning Reference
27 SR-SFC-PCE-CAPABILITY This document
6.4. New Path Setup Type
This document defines a new setup type for the PATH-SETUP-TYPE TLV as
follows:
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 the SFC as
follows:
Type Sub-object
5 Service Function ID
7. Security considerations
This document does not introduce any new security considerations.
8. Acknowledgement
TBD.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Xu, et al. Expires December 24, 2014 [Page 10]
Internet-Draft PCEP Extensions for SR-based SFC June 2014
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element
(PCE) Communication Protocol (PCEP)", RFC 5440, March
2009.
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching
(MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
Class" Field", RFC 5462, February 2009.
9.2. Informative References
[I-D.sivabalan-pce-lsp-setup-type]
Sivabalan, S., Medved, J., Minei, I., Varga, R., and E.
Crabbe, "Conveying path setup type in PCEP messages",
draft-sivabalan-pce-lsp-setup-type-01 (work in progress),
October 2013.
[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-pce-based-sfc-arch]
Xu, X., "PCE-based SFC Architecture in SR Networks",
draft-xu-spring-pce-based-sfc-arch-00 (work in progress),
April 2014.
Authors' Addresses
Xiaohu Xu
Huawei
Email: xuxiaohu@huawei.com
Jianjie You
Huawei
101 Software Avenue, Yuhuatai District
Nanjing, 210012
China
Email: youjianjie@huawei.com
Xu, et al. Expires December 24, 2014 [Page 11]
Internet-Draft PCEP Extensions for SR-based SFC June 2014
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 12]