< draft-wu-pce-traffic-steering-sfc-05.txt   draft-wu-pce-traffic-steering-sfc-06.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: March 18, 2015 M. Boucadair Expires: September 5, 2015 M. Boucadair
C. Jacquenet C. Jacquenet
France Telecom France Telecom
J. Tantsura J. Tantsura
Ericsson Ericsson
September 14, 2014 March 4, 2015
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-05 draft-wu-pce-traffic-steering-sfc-06
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.
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 March 18, 2015. This Internet-Draft will expire on September 5, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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
skipping to change at page 2, line 29 skipping to change at page 2, line 29
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 Withdrawal . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . 6
4.5. SFP Update and Report . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . 7
5.2.1. SFP Identifiers TLV . . . . . . . . . . . . . . . . . 7 5.2.1. SFP Identifiers TLV . . . . . . . . . . . . . . . . . 7
6. Backward Compatibility . . . . . . . . . . . . . . . . . . . 7 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . 8
7. Relationship to SR . . . . . . . . . . . . . . . . . . . . . 7 7. SFP signaling and forwarding consideration . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
Service chaining enables the creation of composite services that Service chaining enables the creation of composite services that
consist of an ordered set of Service Functions (SF) that must be consist of an ordered set of Service Functions (SF) that must be
applied to packets and/or frames selected as a result of applied to packets and/or frames selected as a result of
classification as described in [I-D.ietf-sfc-architecture] and classification as described in [I-D.ietf-sfc-architecture] and
referred to as Service Function Chain (SFC). A 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
skipping to change at page 7, line 23 skipping to change at page 7, line 28
LSP Object Format LSP Object Format
A new flag, called the SFC (F) flag, is introduced. The F Flag set 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 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. 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 SFP Identifier TLV is used by the
classifier to enable SFP selection for the traffic,i.e.,direct
traffic to specific SFP[I-D.ietf-sfc-architecture]. The SFP
Identifier carried in the SFC encapsulation can be further used by
SFF to select service functions and next SFF,e.g., enable a packet
that repeatedly arrives at the same SFF to get the correct services
provided each time it arrives, and to go to the correct next SFF each
time it arrives.
The format and operations are TBD. The format of SFP Identifier TLV is shown in the following figure.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Path ID | Service Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Service path ID (SPI): 24 bits
Service index (SI): 8 bits
SPI: identifies a service path. The same ID is used by the
participating nodes for path setup/selection. An administrator can
use the SPI for reporting and troubleshooting packets along a
specific path. SPI along with PLSP-ID is used in PCEP to identify
the Service Path.
SI: provides location within the service path.
6. Backward Compatibility 6. Backward Compatibility
The SFP instantiation capability PCEP protocol extensions described The SFP instantiation capability PCEP protocol extensions described
in this document MUST NOT be used if PCCs or the PCE did not in this document MUST NOT be used if PCCs or the PCE did not
advertise its SFP instantiation stateful capability, as per advertise its SFP instantiation stateful capability, as per
Section 5.1. If this is not the case and stateful operations on SFPs Section 5.1. If this is not the case and stateful operations on SFPs
are attempted, then a PCErr with error-type 19 (Invalid Operation) are attempted, then a PCErr with error-type 19 (Invalid Operation)
and error-value TBD needs to be generated. and error-value TBD needs to 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. SFP signaling and forwarding consideration
Segment Routing (SR) technology leverages the source routing and
tunneling paradigms where a source node can choose a path without
relying on hop-by-hop signaling. A stateful PCE can be used for
computing one or more SR-TE paths taking into account various
constraints and objective functions. Once a path is chosen, the
stateful PCE can instantiate an SR-TE path on a PCC using PCEP
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. For example,SR-based
can also utilize the mechanism described here and does not need any approach [I-D.ietf-pce-segment-routing] can utilize the mechanism
other specific protocol extensions. described here and does not need any other specific protocol
extensions. Generic SFC Encapsulation [I-D.quinn-sfc-nsh] can also
be used together with the mechanism described here to enable SFP
forwarding.
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 25 skipping to change at page 8, line 48
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[I-D.ietf-pce-stateful-pce] [I-D.ietf-pce-stateful-pce]
Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP
Extensions for Stateful PCE", draft-ietf-pce-stateful- Extensions for Stateful PCE", draft-ietf-pce-stateful-
pce-09 (work in progress), June 2014. pce-10 (work in progress), October 2014.
[I-D.ietf-pce-pce-initiated-lsp] [I-D.ietf-pce-pce-initiated-lsp]
Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP
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-02 (work in
progress), June 2014. progress), October 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, [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash,
"Policy-Enabled Path Computation Framework", RFC 5394, "Policy-Enabled Path Computation Framework", RFC 5394,
December 2008. 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.ietf-sfc-architecture] [I-D.ietf-sfc-architecture]
Halpern, J. and C. Pignataro, "Service Function Chaining Halpern, J. and C. Pignataro, "Service Function Chaining
(SFC) Architecture", draft-ietf-sfc-architecture-01 (work (SFC) Architecture", draft-ietf-sfc-architecture-05 (work
in progress), September 2014. in progress), February 2015.
[I-D.ww-sfc-control-plane] [I-D.ww-sfc-control-plane]
Li, H., Wu, Q., Huang, O., Boucadair, M., Jacquenet, C., Li, H., Wu, Q., Boucadair, M., Jacquenet, C., and W.
and W. Haeffner, "Service Function Chain Control Plane Haeffner, "Service Function Chaining (SFC) Control Plane
Framework", draft-ww-sfc-control-plane-02 (work in Achitecture", draft-ww-sfc-control-plane-03 (work in
progress), July 2014. progress), September 2014.
[I-D.sivabalan-pce-segment-routing] [I-D.ietf-pce-segment-routing]
Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E., Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E.,
Raszuk, R., Lopez, V., and J. Tantsura, "PCEP Extensions Raszuk, R., Lopez, V., and J. Tantsura, "PCEP Extensions
for Segment Routing", draft-sivabalan-pce-segment- for Segment Routing", draft-ietf-pce-segment-routing-00
routing-03 (work in progress), July 2014. (work in progress), October 2014.
[I-D.quinn-sfc-nsh]
Quinn, P., Guichard, J., Surendra, S., Smith, M.,
Henderickx, W., Nadeau, T., Agarwal, P., Manur, R.,
Chauhan, A., Halpern, J., Majee, S., Elzur, U., Melman,
D., Garg, P., McConnell, B., Wright, C., and K. Kevin,
"Network Service Header", draft-quinn-sfc-nsh-07 (work in
progress), February 2015.
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. 19 change blocks. 
36 lines changed or deleted 63 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/