draft-ietf-pce-stateful-pce-16.txt   draft-ietf-pce-stateful-pce-17.txt 
PCE Working Group E. Crabbe PCE Working Group E. Crabbe
Internet-Draft Oracle Internet-Draft Oracle
Intended status: Standards Track I. Minei Intended status: Standards Track I. Minei
Expires: March 5, 2017 Google, Inc. Expires: May 20, 2017 Google, Inc.
J. Medved J. Medved
Cisco Systems, Inc. Cisco Systems, Inc.
R. Varga R. Varga
Pantheon Technologies SRO Pantheon Technologies SRO
September 1, 2016 November 16, 2016
PCEP Extensions for Stateful PCE PCEP Extensions for Stateful PCE
draft-ietf-pce-stateful-pce-16 draft-ietf-pce-stateful-pce-17
Abstract Abstract
The Path Computation Element Communication Protocol (PCEP) provides The Path Computation Element Communication Protocol (PCEP) provides
mechanisms for Path Computation Elements (PCEs) to perform path mechanisms for Path Computation Elements (PCEs) to perform path
computations in response to Path Computation Clients (PCCs) requests. computations in response to Path Computation Clients (PCCs) requests.
Although PCEP explicitly makes no assumptions regarding the Although PCEP explicitly makes no assumptions regarding the
information available to the PCE, it also makes no provisions for PCE information available to the PCE, it also makes no provisions for PCE
control of timing and sequence of path computations within and across control of timing and sequence of path computations within and across
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 5, 2017. This Internet-Draft will expire on May 20, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 20 skipping to change at page 2, line 20
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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Motivation and Objectives for Stateful PCE . . . . . . . . . 6 3. Motivation and Objectives for Stateful PCE . . . . . . . . . 5
3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.1. Background . . . . . . . . . . . . . . . . . . . . . 6 3.1.1. Background . . . . . . . . . . . . . . . . . . . . . 5
3.1.2. Why a Stateful PCE? . . . . . . . . . . . . . . . . . 6 3.1.2. Why a Stateful PCE? . . . . . . . . . . . . . . . . . 6
3.1.3. Protocol vs. Configuration . . . . . . . . . . . . . 7 3.1.3. Protocol vs. Configuration . . . . . . . . . . . . . 7
3.2. Objectives . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Objectives . . . . . . . . . . . . . . . . . . . . . . . 7
4. New Functions to Support Stateful PCEs . . . . . . . . . . . 8 4. New Functions to Support Stateful PCEs . . . . . . . . . . . 8
5. Overview of Protocol Extensions . . . . . . . . . . . . . . . 9 5. Overview of Protocol Extensions . . . . . . . . . . . . . . . 8
5.1. LSP State Ownership . . . . . . . . . . . . . . . . . . . 9 5.1. LSP State Ownership . . . . . . . . . . . . . . . . . . . 9
5.2. New Messages . . . . . . . . . . . . . . . . . . . . . . 10 5.2. New Messages . . . . . . . . . . . . . . . . . . . . . . 9
5.3. Error Reporting . . . . . . . . . . . . . . . . . . . . . 10 5.3. Error Reporting . . . . . . . . . . . . . . . . . . . . . 10
5.4. Capability Advertisement . . . . . . . . . . . . . . . . 10 5.4. Capability Advertisement . . . . . . . . . . . . . . . . 10
5.5. IGP Extensions for Stateful PCE Capabilities 5.5. IGP Extensions for Stateful PCE Capabilities
Advertisement . . . . . . . . . . . . . . . . . . . . . . 11 Advertisement . . . . . . . . . . . . . . . . . . . . . . 11
5.6. State Synchronization . . . . . . . . . . . . . . . . . . 12 5.6. State Synchronization . . . . . . . . . . . . . . . . . . 12
5.7. LSP Delegation . . . . . . . . . . . . . . . . . . . . . 15 5.7. LSP Delegation . . . . . . . . . . . . . . . . . . . . . 15
5.7.1. Delegating an LSP . . . . . . . . . . . . . . . . . . 15 5.7.1. Delegating an LSP . . . . . . . . . . . . . . . . . . 15
5.7.2. Revoking a Delegation . . . . . . . . . . . . . . . . 16 5.7.2. Revoking a Delegation . . . . . . . . . . . . . . . . 16
5.7.3. Returning a Delegation . . . . . . . . . . . . . . . 18 5.7.3. Returning a Delegation . . . . . . . . . . . . . . . 18
5.7.4. Redundant Stateful PCEs . . . . . . . . . . . . . . . 18 5.7.4. Redundant Stateful PCEs . . . . . . . . . . . . . . . 18
skipping to change at page 4, line 26 skipping to change at page 4, line 26
2. Terminology 2. Terminology
This document uses the following terms defined in [RFC5440]: PCC, This document uses the following terms defined in [RFC5440]: PCC,
PCE, PCEP Peer, PCEP Speaker. PCE, PCEP Peer, PCEP Speaker.
This document uses the following terms defined in [RFC4655]: TED. This document uses the following terms defined in [RFC4655]: TED.
This document uses the following terms defined in [RFC3031]: LSP. This document uses the following terms defined in [RFC3031]: LSP.
The following terms are defined in this document: This document uses the following terms defined in
[I-D.ietf-pce-stateful-pce-app]: Stateful PCE, Passive Stateful PCE,
Stateful PCE: a PCE that has access to not only the network state, Active Stateful PCE, Delegation, LSP State Database.
but also to the set of active paths and their reserved resources
for its computations. A stateful PCE might also retain
information regarding LSPs under construction in order to reduce
churn and resource contention. The additional state allows the
PCE to compute constrained paths while considering individual LSPs
and their interactions. Note that this requires reliable state
synchronization mechanisms between the PCE and the network, PCE
and PCC, and between cooperating PCEs.
Passive Stateful PCE: a PCE that uses LSP state information learned
from PCCs to optimize path computations. It does not actively
update LSP state. A PCC maintains synchronization with the PCE.
Active Stateful PCE: a PCE that may issue recommendations to the
network.For example, an Active Stateful PCE may utilize the
Delegation mechanism to update LSP parameters in those PCCs that
delegated control over their LSPs to the PCE.
Delegation: an operation to grant a PCE temporary rights to modify a The following terms are defined in this document:
subset of LSP parameters on one or more PCC's LSPs. LSPs are
delegated from a PCC to a PCE, and are referred to as delegated
LSPs. The PCC that owns the PCE state for the LSP has the right
to delegate it. An LSP is owned by a single PCC at any given
point in time. For intra-domain LSPs, this PCC should be the LSP
head end.
Revocation: an operation performed by a PCC on a previously Revocation: an operation performed by a PCC on a previously
delegated LSP. Revocation revokes the rights granted to the PCE delegated LSP. Revocation revokes the rights granted to the PCE
in the delegation operation. in the delegation operation.
Redelegation Timeout Interval: the period of time a PCC waits for, Redelegation Timeout Interval: the period of time a PCC waits for,
when a PCEP session is terminated, before revoking LSP delegation when a PCEP session is terminated, before revoking LSP delegation
to a PCE and attempting to redelegate LSPs associated with the to a PCE and attempting to redelegate LSPs associated with the
terminated PCEP session to an alternate PCE. The Redelegation terminated PCEP session to an alternate PCE. The Redelegation
Timeout Interval is a PCC-local value that can be either operator- Timeout Interval is a PCC-local value that can be either operator-
skipping to change at page 5, line 38 skipping to change at page 5, line 17
PCE, etc.) from a PCC to a PCE. PCE, etc.) from a PCC to a PCE.
LSP Update Request: an operation where an Active Stateful PCE LSP Update Request: an operation where an Active Stateful PCE
requests a PCC to update one or more attributes of an LSP and to requests a PCC to update one or more attributes of an LSP and to
re-signal the LSP with updated attributes. re-signal the LSP with updated attributes.
SRP-ID-number: a number used to correlate errors and LSP State SRP-ID-number: a number used to correlate errors and LSP State
Reports to LSP Update Requests. It is carried in the SRP Reports to LSP Update Requests. It is carried in the SRP
(Stateful PCE Request Parameters) Object described in Section 7.2. (Stateful PCE Request Parameters) Object described in Section 7.2.
LSP State Database: information about all LSPs and their attributes.
Within this document, PCEP communications are described through PCC- Within this document, PCEP communications are described through PCC-
PCE relationship. The PCE architecture also supports the PCE-PCE PCE relationship. The PCE architecture also supports the PCE-PCE
communication, by having the requesting PCE fill the role of a PCC, communication, by having the requesting PCE fill the role of a PCC,
as usual. as usual.
The message formats in this document are specified using Routing The message formats in this document are specified using Routing
Backus-Naur Format (RBNF) encoding as specified in [RFC5511]. Backus-Naur Format (RBNF) encoding as specified in [RFC5511].
3. Motivation and Objectives for Stateful PCE 3. Motivation and Objectives for Stateful PCE
skipping to change at page 27, line 11 skipping to change at page 27, line 11
defined in [RFC5440], which represents the intended path. If the SRP defined in [RFC5440], which represents the intended path. If the SRP
object is missing, the receiving PCC MUST send a PCErr message with object is missing, the receiving PCC MUST send a PCErr message with
Error-type=6 (Mandatory Object missing) and Error-value=10 (SRP Error-type=6 (Mandatory Object missing) and Error-value=10 (SRP
object missing). If the LSP object is missing, the receiving PCC object missing). If the LSP object is missing, the receiving PCC
MUST send a PCErr message with Error-type=6 (Mandatory Object MUST send a PCErr message with Error-type=6 (Mandatory Object
missing) and Error-value=8 (LSP object missing). If the ERO object missing) and Error-value=8 (LSP object missing). If the ERO object
is missing, the receiving PCC MUST send a PCErr message with Error- is missing, the receiving PCC MUST send a PCErr message with Error-
type=6 (Mandatory Object missing) and Error-value=9 (ERO object type=6 (Mandatory Object missing) and Error-value=9 (ERO object
missing). missing).
The ERO in the PCUpd may be empty if the PCE cannot find a valid path
for a delegated LSP. One typical situation resulting in this empty
ERO carried in the PCUpd message is that a PCE can no longer find a
strict SRLG-disjoint path for a delegated LSP after a link failure.
The PCC SHOULD implement a local policy to decide the appropriate
action to be taken: either tear down the LSP, or revoke the
delegation and use a locally computed path, or keep the existing LSP.
A PCC only acts on an LSP Update Request if permitted by the local A PCC only acts on an LSP Update Request if permitted by the local
policy configured by the network manager. Each LSP Update Request policy configured by the network manager. Each LSP Update Request
that the PCC acts on results in an LSP setup operation. An LSP that the PCC acts on results in an LSP setup operation. An LSP
Update Request MUST contain all LSP parameters that a PCE wishes to Update Request MUST contain all LSP parameters that a PCE wishes to
be set for the LSP. A PCC MAY set missing parameters from locally be set for the LSP. A PCC MAY set missing parameters from locally
configured defaults. If the LSP specified in the Update Request is configured defaults. If the LSP specified in the Update Request is
already up, it will be re-signaled. already up, it will be re-signaled.
The PCC SHOULD minimize the traffic interruption, and MAY use the The PCC SHOULD minimize the traffic interruption, and MAY use the
make-before-break procedures described in [RFC3209] in order to make-before-break procedures described in [RFC3209] in order to
skipping to change at page 50, line 25 skipping to change at page 50, line 25
13.2. Informative References 13.2. Informative References
[I-D.ietf-pce-gmpls-pcep-extensions] [I-D.ietf-pce-gmpls-pcep-extensions]
Margaria, C., Dios, O., and F. Zhang, "PCEP extensions for Margaria, C., Dios, O., and F. Zhang, "PCEP extensions for
GMPLS", draft-ietf-pce-gmpls-pcep-extensions-11 (work in GMPLS", draft-ietf-pce-gmpls-pcep-extensions-11 (work in
progress), October 2015. progress), October 2015.
[I-D.ietf-pce-stateful-pce-app] [I-D.ietf-pce-stateful-pce-app]
Zhang, X. and I. Minei, "Applicability of a Stateful Path Zhang, X. and I. Minei, "Applicability of a Stateful Path
Computation Element (PCE)", draft-ietf-pce-stateful-pce- Computation Element (PCE)", draft-ietf-pce-stateful-pce-
app-06 (work in progress), July 2016. app-08 (work in progress), October 2016.
[I-D.ietf-pce-stateful-sync-optimizations] [I-D.ietf-pce-stateful-sync-optimizations]
Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X.,
and D. Dhody, "Optimizations of Label Switched Path State and D. Dhody, "Optimizations of Label Switched Path State
Synchronization Procedures for a Stateful PCE", draft- Synchronization Procedures for a Stateful PCE", draft-
ietf-pce-stateful-sync-optimizations-05 (work in ietf-pce-stateful-sync-optimizations-06 (work in
progress), April 2016. progress), October 2016.
[MPLS-PC] Chaieb, I., Le Roux, JL., and B. Cousin, "Improved MPLS-TE [MPLS-PC] Chaieb, I., Le Roux, JL., and B. Cousin, "Improved MPLS-TE
LSP Path Computation using Preemption", Global LSP Path Computation using Preemption", Global
Information Infrastructure Symposium, July 2007. Information Infrastructure Symposium, July 2007.
[MXMN-TE] Danna, E., Mandal, S., and A. Singh, "Practical linear [MXMN-TE] Danna, E., Mandal, S., and A. Singh, "Practical linear
programming algorithm for balancing the max-min fairness programming algorithm for balancing the max-min fairness
and throughput objectives in traffic engineering", and throughput objectives in traffic engineering",
INFOCOM, 2012 Proceedings IEEE Page(s): 846-854, 2012. INFOCOM, 2012 Proceedings IEEE Page(s): 846-854, 2012.
 End of changes. 14 change blocks. 
42 lines changed or deleted 25 lines changed or added

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