< draft-wu-pce-traffic-steering-sfc-04.txt   draft-wu-pce-traffic-steering-sfc-05.txt >
PCE Working Group Q. Wu PCE Working Group Q. Wu
Internet-Draft D. Dhody Internet-Draft D. Dhody
Intended status: Standards Track Huawei Intended status: Standards Track Huawei
Expires: December 28, 2014 M. Boucadair Expires: March 18, 2015 M. Boucadair
C. Jacquenet C. Jacquenet
France Telecom France Telecom
J. Tantsura J. Tantsura
Ericsson Ericsson
June 26, 2014 September 14, 2014
PCEP Extensions for traffic steering support in Service Function PCEP Extensions for traffic steering support in Service Function
Chaining Chaining
draft-wu-pce-traffic-steering-sfc-04 draft-wu-pce-traffic-steering-sfc-05
Abstract Abstract
This document provides an overview of the usage of Path Computation This document provides an overview of the usage of Path Computation
Element (PCE) with Service Function Chaining (SFC); which is Element (PCE) with Service Function Chaining (SFC); which is
described as the definition and instantiation of an ordered set of described as the definition and instantiation of an ordered set of
such service functions (such as firewalls, load balancers), and the such service functions (such as firewalls, load balancers), and the
subsequent "steering" of traffic flows through those service subsequent "steering" of traffic flows through those service
functions. functions.
Further this document specifies extensions to the Path Computation This document specifies extensions to the Path Computation Element
Element Protocol (PCEP) that allow a stateful PCE to compute and Protocol (PCEP) that allow a stateful PCE to compute and instantiate
instantiate Service Function Paths (SFP). Service Function Paths (SFP).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 28, 2014. This Internet-Draft will expire on March 18, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 25 skipping to change at page 2, line 25
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 3
3. Service Function Paths and PCE . . . . . . . . . . . . . . . 3 3. Service Function Paths and PCE . . . . . . . . . . . . . . . 3
4. Overview of PCEP Operation in SFC enabled Networks . . . . . 5 4. Overview of PCEP Operation in SFC-enabled Networks . . . . . 5
4.1. SFP Instantiation . . . . . . . . . . . . . . . . . . . . 5 4.1. SFP Instantiation . . . . . . . . . . . . . . . . . . . . 5
4.2. SFP Deletion . . . . . . . . . . . . . . . . . . . . . . 5 4.2. SFP Withdrawal . . . . . . . . . . . . . . . . . . . . . 5
4.3. SFP Delegation and Cleanup . . . . . . . . . . . . . . . 5 4.3. SFP Delegation and Cleanup . . . . . . . . . . . . . . . 5
4.4. SFP State Synchronization . . . . . . . . . . . . . . . . 5 4.4. SFP State Synchronization . . . . . . . . . . . . . . . . 5
4.5. SFP Update and Report . . . . . . . . . . . . . . . . . . 5 4.5. SFP Update and Report . . . . . . . . . . . . . . . . . . 6
5. Object Formats . . . . . . . . . . . . . . . . . . . . . . . 6 5. Object Formats . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. The OPEN Object . . . . . . . . . . . . . . . . . . . . . 6 5.1. The OPEN Object . . . . . . . . . . . . . . . . . . . . . 6
5.2. The LSP Object . . . . . . . . . . . . . . . . . . . . . 6 5.2. The LSP Object . . . . . . . . . . . . . . . . . . . . . 6
5.2.1. SFP Identifiers TLV . . . . . . . . . . . . . . . . . 7 5.2.1. SFP Identifiers TLV . . . . . . . . . . . . . . . . . 7
6. Backward Compatibility . . . . . . . . . . . . . . . . . . . 7 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . 7
7. Relationship to SR . . . . . . . . . . . . . . . . . . . . . 7 7. Relationship to SR . . . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
Service chaining enables creation of composite services that consist Service chaining enables the creation of composite services that
of an ordered set of Service Functions (SF) that must be applied to consist of an ordered set of Service Functions (SF) that must be
packets and/or frames selected as a result of classification as applied to packets and/or frames selected as a result of
described in [I-D.boucadair-sfc-framework][I-D.quinn-sfc-arch] and classification as described in [I-D.ietf-sfc-architecture] and
referred to as Service Function Chain (SFC). Service Function Path referred to as Service Function Chain (SFC). A Service Function Path
(SFP) is the instantiation of a SFC in the network. Packets follow a (SFP) is the instantiation of a SFC in the network. Packets follow a
Service Function Path from a classifier through the requisite Service Service Function Path from a classifier through the requisite Service
Functions (SF). Functions (SF).
[RFC5440] describes the Path Computation Element Protocol (PCEP) as [RFC5440] describes the Path Computation Element Protocol (PCEP) as
the communication between a Path Computation Client (PCC) and a Path the communication between a Path Computation Client (PCC) and a Path
Control Element (PCE), or between PCE and PCE, enabling computation Control Element (PCE), or between PCE and PCE, enabling computation
of Multiprotocol Label Switching (MPLS) for Traffic Engineering Label of Multiprotocol Label Switching (MPLS) for Traffic Engineering Label
Switched Path (TE LSP). Switched Path (TE LSP).
skipping to change at page 3, line 41 skipping to change at page 3, line 41
PCEP: Path Computation Element Protocol. PCEP: Path Computation Element Protocol.
PDP: Policy Decision Point. PDP: Policy Decision Point.
SF: Service Function. SF: Service Function.
SFC: Service Function Chain. SFC: Service Function Chain.
SFP: Service Function Path. SFP: Service Function Path.
SFF: Service Forwarder Function.
UNI: User-Network Interface. UNI: User-Network Interface.
3. Service Function Paths and PCE 3. Service Function Paths and PCE
Services are constructed as a sequence of SFs that represent an SFC, 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 where a 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 network element, and one or more SFs may be supported by the same
physical network element. SFC creates an abstracted view of a physical network element. A SFC creates an abstracted view of a
service and specifies the set of required SFs as well as the order in service and specifies the set of required SFs as well as the order in
which they must be executed. which they must be executed.
When an SFC is instantiated into the network it is necessary to 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 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, the service topology for that SFC using SF network locators. Thus,
instantiation of the SFC results in the creation of a Service instantiation of the SFC results in the creation of a Service
Function Path (SFP) and is used for forwarding packets through the Function Path (SFP) and is used for forwarding packets through the
SFC. In other words, an SFP is the instantiation of the defined SFC SFC. In other words, an SFP is the instantiation of the defined SFC
as described in details in as described in [I-D.ietf-sfc-architecture].
[I-D.boucadair-sfc-framework][I-D.quinn-sfc-arch].
The selection of SFP can be based on a range of policy attributes, The selection of SFP can be based on a set of policy attributes
ranging from simple to more elaborate criteria and stateful PCE with (forwarding and routing, QoS, security, etc., or a combination
extensions to PCEP are one such way to achieve this. thereof), ranging from simple to more elaborate selection criteria
and the use of 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 Stateful pce [I-D.ietf-pce-stateful-pce] specifies a set of
extensions to PCEP to enable stateful control of TE LSPs. extensions to PCEP to enable stateful control of TE LSPs.
[I-D.ietf-pce-pce-initiated-lsp] provides the fundamental motivations [I-D.ietf-pce-pce-initiated-lsp] provides the fundamental motivations
and extensions needed for stateful PCE-initiated LSP instantiation. and extensions needed for stateful PCE-initiated LSP instantiation.
This document specifies extensions that allow a stateful PCE to This document specifies extensions that allow a stateful PCE to
compute and instantiate Service Function Paths (SFP) via PCEP. compute and instantiate Service Function Paths (SFP) via PCEP.
+---------------------------------+ +------------------------+
|+------+ +------+ PDP | | stateful PCE |
|| | | | | | +-------+ +-------+ |
|| | | | | | |Policy | | TE-DB | | +-------+
||PCE | |Policy| | | +-------+ +-------+ | | SFC |
|*------+ +------+ | +----------| +-------------+ |<---|control|
*---------------------------------+ |SFP | |LSP-DB/SFP-DB| | | plane |
/ |Instan- | +-------------+ | +-------+
/ |tiation +------------------------+
/ SFP | +-----+ +-----+ +-----+
/ Instan- | |SF-1 | |SF-2 | |SF-3 |
/ tiation | | | | | | |
/ SF Node1 SF Node2 | +---+-+ +-+---+ +--+--+
/ +-------+ +-------+ | | | |
| ++-----++ +----+--+
V | | | | V | | | |
+-----+ Signaling |+-----+| Signaling |+-----+| Signaling +-----+ +-----+ Signaling | | Signaling | | Signaling
|SF-In|----------->||SF-1 || --------->||SF-2 ||----------->|SF-E | | SF |----------->| SFF-1 | --------->| SFF-2 |----------->
|gress| || || || || |gress| Classifier | | | |
+-----+ |+-----+| |+-----+| +-----+ |Node | | | | |
+-------+ +-------+ +-----+ +-------+ +-------+
Figure 1: SFP instantiation vis PCE Figure 1: PCE based SFP instantiation
A Policy Decision Point (PDP) [RFC2753] is the central entity which SFC Control plane components are responsible for maintaining SFC
is responsible for maintaining SFC Policy Tables and enforcing Policy Tables and enforcing appropriate policies in SF Classifier and
appropriate policies in SF Nodes described in detail in SFF Nodes as described 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 [I-D.ietf-sfc-architecture][I-D.ww-sfc-control-plane]. The SFC
Control plane component can be seen as a policy Decision point
(PDP,[RFC5394]). Such PDP can then operates a stateful PCE and its
instantiation mechanism to compute and instantiate Service Function
Paths (SFP). The PCE maybe co-located with the SFC Control plane
component or an external entity.
A PCEP speaker indicates its ability to support PCE initiated dynamic 4. Overview of PCEP Operation in SFC-enabled Networks
SFP during the PCEP Initialization Phase via mechanism described in
Section 5.1. A PCEP speaker indicates its ability to support PCE provisioned
dynamic SFP paths during the PCEP Initialization phase via a
mechanism described in Section 5.1. A PCE can initiate SFPs only for
PCCs that advertised this capability and a PCC will follow the
procedures described in this document only on sessions where the PCE
advertised this capability. .
As per section 5.1 of [I-D.ietf-pce-pce-initiated-lsp], the PCE sends 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 a Path Computation LSP Initiate Request (PCInitiate) message to the
PCC to instantiate or delete a LSP. This document makes no change to PCC to instantiate or delete a LSP. This document makes no change to
the PCInitiate message format but extends LSP objects described in the PCInitiate message format but extends LSP objects described in
Section 5.2. Section 5.2.
4.1. SFP Instantiation 4.1. SFP Instantiation
The Instantiation operation of SFP is same as defined in section 5.3 The Instantiation operation of a SFP is the same as defined in
of [I-D.ietf-pce-pce-initiated-lsp]. Rules of processing and error section 5.3[I-D.ietf-pce-pce-initiated-lsp]. Rules of processing and
codes remains unchanged. error codes remain unchanged.
4.2. SFP Deletion 4.2. SFP Withdrawal
The deletion operation of SFP is same as defined in section 5.4 of The withdrawal operation of a SFP is the same as defined in section
[I-D.ietf-pce-pce-initiated-lsp] by sending an LSP Initiate Message 5.4 of [I-D.ietf-pce-pce-initiated-lsp] : the PCE sends an LSP
with an LSP object carrying the PLSP-ID of the SFP to be removed and Initiate Message with an LSP object carrying the PLSP-ID of the SFP
an SRP object with the R flag set (LSP-REMOVE as per section 5.2 of to be removed and an SRP object with the R flag set (LSP-REMOVE as
[I-D.ietf-pce-pce-initiated-lsp]). Rules of processing and error per section 5.2 of [I-D.ietf-pce-pce-initiated-lsp]). Rules of
codes remains unchanged. processing and error codes remain unchanged.
4.3. SFP Delegation and Cleanup 4.3. SFP Delegation and Cleanup
SFP delegation and cleanup operations are same as defined in section SFP delegation and cleanup operations are similar to those defined in
6 of [I-D.ietf-pce-pce-initiated-lsp]. Rules of processing and error section 6 of [I-D.ietf-pce-pce-initiated-lsp]. Rules of processing
codes remains unchanged. and error codes remains unchanged.
4.4. SFP State Synchronization 4.4. SFP State Synchronization
State Synchronization operations described in Section 5.4 of State Synchronization operations described in Section 5.4 of
[I-D.ietf-pce-stateful-pce] and can be applied for SFPs as well. [I-D.ietf-pce-stateful-pce]can be applied for SFP state maintenance
as well.
4.5. SFP Update and Report 4.5. SFP Update and Report
PCE can make an SFP Update requests to a PCC to update one or more A PCE can send an SFP Update request to a PCC to update one or more
attributes of an SFP and to re-signal the SFP with updated attributes of an SFP and to re-signal the SFP with the updated
attributes. PCC can make an SFP state report to a PCE to send SFP attributes. A PCC can send an SFP state report to a PCE, and which
state. The mechanism are described in [I-D.ietf-pce-stateful-pce] contains the SFP State information. The mechanism is described in
and can be applied for SFPs as well. [I-D.ietf-pce-stateful-pce] and can be applied for SFPs as well.
5. Object Formats 5. Object Formats
5.1. The OPEN Object 5.1. The OPEN Object
This document defines a new optional TLV for use in 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 to indicate the PCEP speaker's Service function Chaining capability.
Chaining.
The SFC-PCE-CAPABILITY TLV is an optional TLV for use in the OPEN 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 Object to advertise the SFC capability during the PCEP session. The
format of the SFC-PCE-CAPABILITY TLV is shown in the following format of the SFC-PCE-CAPABILITY TLV is shown in the
figure: followingFigure 2 :
0 1 2 3 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 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 | | Type=TBD | length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags | | Reserved | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SFC-PCE-CAPABILITY TLV Format
The code point for the TLV type is to be defined by IANA. The TLV The code point for the TLV type is to be defined by IANA. The TLV
length is 4 octets. length is 4 octets.
The value is TBD. The value is TBD.
As per [I-D.ietf-pce-stateful-pce], PCEP speaker advertises As per [I-D.ietf-pce-stateful-pce], a PCEP speaker advertises the
capability for instantiation of PCE-initiated LSPs via Stateful PCE capability of instantiating PCE-initiated LSPs via the Stateful PCE
Capability TLV (LSP-INSTANTIATION-CAPABILITY bit) in open message. Capability TLV (LSP-INSTANTIATION-CAPABILITY bit) conveyed in an Open
The inclusion of SFC-PCE-CAPABILITY TLV in an OPEN object indicates message. The inclusion of the SFC-PCE-CAPABILITY TLV in an OPEN
that the sender is SFC capable. These mechanism when used together object indicates that the sender is SFC-capable. Both mechanisms
indicates the instantiation capability for SFP by the PCEP speaker. indicate the SFP instantiation capability of the PCEP speaker.
5.2. The LSP Object 5.2. The LSP Object
The LSP object is defined in [I-D.ietf-pce-pce-initiated-lsp] and The LSP object is defined in [I-D.ietf-pce-pce-initiated-lsp] and
included here for easy reference. included here for reference (Figure 3).
0 1 2 3 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 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| | PLSP-ID | Flags |F|C| O|A|R|S|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// TLVs // // 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 LSP Object Format
it was created via a PCInitiate message.
A new flag, called the SFC (F) flag, is introduced. The F Flag set
to 1 indicates that this LSP is actually an SFP. The C flag will
also be set to indicate it was created via a PCInitiate message.
5.2.1. SFP Identifiers TLV 5.2.1. SFP Identifiers TLV
The SFP Identifiers TLV MUST be included in the LSP object for The SFP Identifiers TLV MUST be included in the LSP object for
Service Function Paths (SFP). Service Function Paths (SFP).
The format and operations are TBD. The format and operations are TBD.
6. Backward Compatibility 6. Backward Compatibility
The PCEP protocol extensions described in this document for PCEP The SFP instantiation capability PCEP protocol extensions described
speaker with instantiation capability for SFPs MUST NOT be used if in this document MUST NOT be used if PCCs or the PCE did not
PCC or PCE has not advertised its stateful capability with advertise its SFP instantiation stateful capability, as per
Instantiation and SFC capability as per Section 5.1. If this is not Section 5.1. If this is not the case and stateful operations on SFPs
the case and Stateful operations on SFPs are attempted, then a PCErr are attempted, then a PCErr with error-type 19 (Invalid Operation)
with error-type 19 (Invalid Operation) and error-value TBD needs to and error-value TBD needs to be generated.
be generated.
[Editor Note: more information on exact error value is needed] [Editor Note: more information on exact error value is needed]
7. Relationship to SR 7. Relationship to SR
Segment Routing (SR) technology leverages the source routing and Segment Routing (SR) technology leverages the source routing and
tunneling paradigms where a source node can choose a path without tunneling paradigms where a source node can choose a path without
relying on hop-by-hop signaling. A stateful PCE can be used for relying on hop-by-hop signaling. A stateful PCE can be used for
computing one or more SR-TE paths taking into account various computing one or more SR-TE paths taking into account various
constraints and objective functions. Once a path is chosen, the constraints and objective functions. Once a path is chosen, the
stateful PCE can instantiate an SR-TE path on a PCC using PCEP stateful PCE can instantiate an SR-TE path on a PCC using PCEP
extensions specified in [I-D.sivabalan-pce-segment-routing]. extensions specified in [I-D.sivabalan-pce-segment-routing].
The SFP instantiation mechanism described in this document is not The SFP instantiation mechanism described in this document is not
tightly coupled to any SFP signaling mechanism. Thus SR based SFP tightly coupled to any SFP signaling mechanism. Thus, SR-based SFP
can also utilize the mechanism described here and do not need another can also utilize the mechanism described here and does not need any
set of protocol extensions. other specific protocol extensions.
8. Security Considerations 8. Security Considerations
The security considerations described in [RFC5440] and The security considerations described in [RFC5440] and
[I-D.ietf-pce-pce-initiated-lsp] are applicable to this [I-D.ietf-pce-pce-initiated-lsp] are applicable to this
specification. No additional security measure is required. specification. No additional security measure is required.
9. IANA Considerations 9. IANA Considerations
TBD TBD
skipping to change at page 8, line 33 skipping to change at page 8, line 39
Extensions for PCE-initiated LSP Setup in a Stateful PCE Extensions for PCE-initiated LSP Setup in a Stateful PCE
Model", draft-ietf-pce-pce-initiated-lsp-01 (work in Model", draft-ietf-pce-pce-initiated-lsp-01 (work in
progress), June 2014. progress), June 2014.
10.2. Informative References 10.2. Informative References
[RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework
for Policy-based Admission Control", RFC 2753, January for Policy-based Admission Control", RFC 2753, January
2000. 2000.
[RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash,
"Policy-Enabled Path Computation Framework", RFC 5394,
December 2008.
[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element
(PCE) Communication Protocol (PCEP)", RFC 5440, March (PCE) Communication Protocol (PCEP)", RFC 5440, March
2009. 2009.
[I-D.quinn-sfc-arch] [I-D.ietf-sfc-architecture]
Quinn, P. and J. Halpern, "Service Function Chaining (SFC) Halpern, J. and C. Pignataro, "Service Function Chaining
Architecture", draft-quinn-sfc-arch-05 (work in progress), (SFC) Architecture", draft-ietf-sfc-architecture-01 (work
May 2014. in progress), September 2014.
[I-D.boucadair-sfc-framework] [I-D.ww-sfc-control-plane]
Boucadair, M., Jacquenet, C., Parker, R., Lopez, D., Li, H., Wu, Q., Huang, O., Boucadair, M., Jacquenet, C.,
Guichard, J., and C. Pignataro, "Service Function and W. Haeffner, "Service Function Chain Control Plane
Chaining: Framework & Architecture", draft-boucadair-sfc- Framework", draft-ww-sfc-control-plane-02 (work in
framework-02 (work in progress), February 2014. progress), July 2014.
[I-D.sivabalan-pce-segment-routing] [I-D.sivabalan-pce-segment-routing]
Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E., and Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E.,
R. Raszuk, "PCEP Extensions for Segment Routing", draft- Raszuk, R., Lopez, V., and J. Tantsura, "PCEP Extensions
sivabalan-pce-segment-routing-02 (work in progress), for Segment Routing", draft-sivabalan-pce-segment-
October 2013. routing-03 (work in progress), July 2014.
Authors' Addresses Authors' Addresses
Qin Wu Qin Wu
Huawei Huawei
101 Software Avenue, Yuhua District 101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012 Nanjing, Jiangsu 210012
China China
EMail: sunseawq@huawei.com EMail: sunseawq@huawei.com
 End of changes. 39 change blocks. 
113 lines changed or deleted 131 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/