draft-ietf-pce-stateful-pce-09.txt   draft-ietf-pce-stateful-pce-10.txt 
PCE Working Group E. Crabbe PCE Working Group E. Crabbe
Internet-Draft I. Minei Internet-Draft
Intended status: Standards Track Google, Inc. Intended status: Standards Track I. Minei
Expires: December 24, 2014 J. Medved Expires: April 29, 2015 Google, Inc.
J. Medved
Cisco Systems, Inc. Cisco Systems, Inc.
R. Varga R. Varga
Pantheon Technologies SRO Pantheon Technologies SRO
June 22, 2014 October 26, 2014
PCEP Extensions for Stateful PCE PCEP Extensions for Stateful PCE
draft-ietf-pce-stateful-pce-09 draft-ietf-pce-stateful-pce-10
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
PCEP sessions. This document describes a set of extensions to PCEP PCEP sessions. This document describes a set of extensions to PCEP
to enable stateful control of MPLS-TE and GMPLS LSPs via PCEP. to enable stateful control of MPLS-TE and GMPLS LSPs via PCEP.
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 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 24, 2014. This Internet-Draft will expire on April 29, 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
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
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
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Motivation and Objectives for Stateful PCE . . . . . . . . . 5 3. Motivation and Objectives for Stateful PCE . . . . . . . . . 5
3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.1. Background . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . . . . . . 9
5.1. LSP State Ownership . . . . . . . . . . . . . . . . . . . 9 5.1. LSP State Ownership . . . . . . . . . . . . . . . . . . . 9
skipping to change at page 4, line 9 skipping to change at page 4, line 5
for support of Generalized MPLS (GMPLS) in PCEP are defined in for support of Generalized MPLS (GMPLS) in PCEP are defined in
[I-D.ietf-pce-gmpls-pcep-extensions] [I-D.ietf-pce-gmpls-pcep-extensions]
This document specifies a set of extensions to PCEP to enable This document specifies a set of extensions to PCEP to enable
stateful control of LSPs within and across PCEP sessions in stateful control of LSPs within and across PCEP sessions in
compliance with [RFC4657]. It includes mechanisms to effect LSP compliance with [RFC4657]. It includes mechanisms to effect LSP
state synchronization between PCCs and PCEs, delegation of control state synchronization between PCCs and PCEs, delegation of control
over LSPs to PCEs, and PCE control of timing and sequence of path over LSPs to PCEs, and PCE control of timing and sequence of path
computations within and across PCEP sessions. computations within and across PCEP sessions.
1.1. 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].
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.
The following terms are defined in this document: The following terms are defined in this document:
Stateful PCE: has access to not only the network state, but also to Stateful PCE: has access to not only the network state, but also to
skipping to change at page 8, line 17 skipping to change at page 8, line 17
The objectives for the protocol extensions to support stateful PCE The objectives for the protocol extensions to support stateful PCE
described in this document are as follows: described in this document are as follows:
o Allow a single PCC to interact with a mix of stateless and o Allow a single PCC to interact with a mix of stateless and
stateful PCEs simultaneously using the same PCEP. stateful PCEs simultaneously using the same PCEP.
o Support efficient LSP state synchronization between the PCC and o Support efficient LSP state synchronization between the PCC and
one or more active or passive stateful PCEs. one or more active or passive stateful PCEs.
o Allow a PCC to delegate control of its LSPs to an active stateful o Allow a PCC to delegate control of its LSPs to an active stateful
PCE such that a single LSP is under the control a single PCE at PCE such that a given LSP is under the control of a single PCE at
any given time. A PCC may revoke this delegation at any time any given time. A PCC may revoke this delegation at any time
during the lifetime of the LSP. If LSP delegation is revoked during the lifetime of the LSP. If LSP delegation is revoked
while the PCEP session is up, the PCC MUST notify the PCE about while the PCEP session is up, the PCC MUST notify the PCE about
the revocation. A PCE may return an LSP delegation at any point the revocation. A PCE may return an LSP delegation at any point
during the lifetime of the PCEP session. during the lifetime of the PCEP session.
o Allow a PCE to control computation timing and update timing across o Allow a PCE to control computation timing and update timing across
all LSPs that have been delegated to it. all LSPs that have been delegated to it.
o Enable uninterrupted operation of PCC's LSPs in the event of a PCE o Enable uninterrupted operation of PCC's LSPs in the event of a PCE
skipping to change at page 11, line 11 skipping to change at page 11, line 11
The presence of the Stateful PCE Capability TLV in PCE's OPEN message The presence of the Stateful PCE Capability TLV in PCE's OPEN message
indicates that the PCE is interested in receiving LSP State Reports indicates that the PCE is interested in receiving LSP State Reports
whenever LSP parameters or operational status changes. whenever LSP parameters or operational status changes.
The PCEP protocol extensions for stateful PCEs MUST NOT be used if The PCEP protocol extensions for stateful PCEs MUST NOT be used if
one or both PCEP Speakers have not included the Stateful PCE one or both PCEP Speakers have not included the Stateful PCE
Capability TLV in their respective OPEN message. If the PCEP Speaker Capability TLV in their respective OPEN message. If the PCEP Speaker
on the PCC supports the extensions of this draft but did not on the PCC supports the extensions of this draft but did not
advertise this capability, then upon receipt of PCUpd message from advertise this capability, then upon receipt of PCUpd message from
the PCE, it SHOULD generate a PCErr with error-type 19 (Invalid the PCE, it SHOULD generate a PCErr with error-type 19 (Invalid
Operation), error-value 2 (Attempted LSP Update Request if active Operation), error-value 2 (Attempted LSP Update Request if the
stateful PCE capability was not advertised)(see Section 8.4) and it stateful PCE capability was not advertised)(see Section 8.4) and it
will terminate the PCEP session. If the PCEP Speaker on the PCE will terminate the PCEP session. If the PCEP Speaker on the PCE
supports the extensions of this draft but did not advertise this supports the extensions of this draft but did not advertise this
capability, then upon receipt of a PCRpt message from the PCC, it capability, then upon receipt of a PCRpt message from the PCC, it
SHOULD generate a PCErr with error-type 19 (Invalid Operation), SHOULD generate a PCErr with error-type 19 (Invalid Operation),
error-value 5 (Attempted LSP State Report if active stateful PCE error-value 5 (Attempted LSP State Report if active stateful PCE
capability was not advertised) (see Section 8.4) and it will capability was not advertised) (see Section 8.4) and it will
terminate the PCEP session. terminate the PCEP session.
LSP delegation and LSP update operations defined in this document MAY LSP delegation and LSP update operations defined in this document MAY
skipping to change at page 13, line 43 skipping to change at page 13, line 43
| | | |
|-----PCRpt, SYNC=1----->| |-----PCRpt, SYNC=1----->|
| | | |
|-----PCRpt, SYNC=1----->| |-----PCRpt, SYNC=1----->|
| . | | . |
| . | | . |
| . | | . |
|-----PCRpt, SYNC=1----->| |-----PCRpt, SYNC=1----->|
| | | |
|-PCRpt, SYNC=1 | |-PCRpt, SYNC=1 |
| \ ,-PCErr=?-| | \ ,-PCErr |
| \ / | | \ / |
| \/ | | \/ |
| /\ | | /\ |
| / `-------->| (Ignored) | / `-------->| (Ignored)
|<--------` | |<--------` |
Figure 2: Failed state synchronization (PCE failure) Figure 2: Failed state synchronization (PCE failure)
The sequence where the PCC fails during the State Synchronization The sequence where the PCC fails during the State Synchronization
phase is shown in Figure 3. phase is shown in Figure 3.
skipping to change at page 14, line 26 skipping to change at page 14, line 26
| . | | . |
| . | | . |
|-------- PCErr=? ------>| |-------- PCErr=? ------>|
| | | |
Figure 3: Failed state synchronization (PCC failure) Figure 3: Failed state synchronization (PCC failure)
Optimizations to the synchronization procedures and alternate Optimizations to the synchronization procedures and alternate
mechanisms of providing the synchronization function are outside the mechanisms of providing the synchronization function are outside the
scope of this document and are discussed elsewhere (see scope of this document and are discussed elsewhere (see
[I-D.minei-pce-stateful-sync-optimizations]). [I-D.ietf-pce-stateful-sync-optimizations]).
5.5. LSP Delegation 5.5. LSP Delegation
If during Capability advertisement both the PCE and the PCC have If during Capability advertisement both the PCE and the PCC have
indicated that they support LSP Update, then the PCC may choose to indicated that they support LSP Update, then the PCC may choose to
grant the PCE a temporary right to update (a subset of) LSP grant the PCE a temporary right to update (a subset of) LSP
attributes on one or more LSPs. This is called "LSP Delegation", and attributes on one or more LSPs. This is called "LSP Delegation", and
it MAY be performed at any time after the Initialization phase, it MAY be performed at any time after the Initialization phase,
including during the State Synchronization phase. including during the State Synchronization phase.
skipping to change at page 19, line 46 skipping to change at page 19, line 46
Upon receiving a path computation request from a PCC, the PCE Upon receiving a path computation request from a PCC, the PCE
triggers a path computation and returns either a positive or a triggers a path computation and returns either a positive or a
negative reply to the PCC ([RFC5440], Section 4.2.4). negative reply to the PCC ([RFC5440], Section 4.2.4).
Upon receiving a positive path computation reply, the PCC receives a Upon receiving a positive path computation reply, the PCC receives a
set of computed paths and starts to setup the LSPs. For each LSP, it set of computed paths and starts to setup the LSPs. For each LSP, it
sends an LSP State Report carried on a PCRpt message to the PCE, sends an LSP State Report carried on a PCRpt message to the PCE,
indicating that the LSP's status is "Going-up". indicating that the LSP's status is "Going-up".
Once an LSP is up, the PCC sends an LSP State Report carried on a Once an LSP is up or active, the PCC sends an LSP State Report
PCRpt message to the PCE, indicating that the LSP's status is 'Up'. carried on a PCRpt message to the PCE, indicating that the LSP's
If the LSP could not be set up, the PCC sends an LSP State Report status is 'Up' or 'Active' respectively. If the LSP could not be set
indicating that the LSP is "Down' and stating the cause of the up, the PCC sends an LSP State Report indicating that the LSP is
failure. Note that due to timing constraints, the LSP status may "Down' and stating the cause of the failure. Note that due to timing
change from 'Going-up' to 'Up' (or 'Down') before the PCC has had a constraints, the LSP status may change from 'Going-up' to 'Up' (or
chance to send an LSP State Report indicating that the status is 'Down') before the PCC has had a chance to send an LSP State Report
'Going-up'. In such cases, the PCC may choose to only send the PCRpt indicating that the status is 'Going-up'. In such cases, the PCC may
indicating the latest status ('Up' or 'Down'). choose to only send the PCRpt indicating the latest status ('Active',
'Up' or 'Down').
Upon receiving a negative reply from a PCE, a PCC may decide to Upon receiving a negative reply from a PCE, a PCC may decide to
resend a modified request or take any other appropriate action. For resend a modified request or take any other appropriate action. For
each requested LSP, it also sends an LSP State Report carried on a each requested LSP, it also sends an LSP State Report carried on a
PCRpt message to the PCE, indicating that the LSP's status is 'Down'. PCRpt message to the PCE, indicating that the LSP's status is 'Down'.
There is no direct correlation between PCRep and PCRpt messages. For There is no direct correlation between PCRep and PCRpt messages. For
a given LSP, multiple LSP State Reports will follow a single PCRep a given LSP, multiple LSP State Reports will follow a single PCRep
message, as a PCC notifies a PCE of the LSP's state changes. message, as a PCC notifies a PCE of the LSP's state changes.
skipping to change at page 22, line 41 skipping to change at page 22, line 41
ordering specified in this document. ordering specified in this document.
6.1. The PCRpt Message 6.1. The PCRpt Message
A Path Computation LSP State Report message (also referred to as A Path Computation LSP State Report message (also referred to as
PCRpt message) is a PCEP message sent by a PCC to a PCE to report the PCRpt message) is a PCEP message sent by a PCC to a PCE to report the
current state of an LSP. A PCRpt message can carry more than one LSP current state of an LSP. A PCRpt message can carry more than one LSP
State Reports. A PCC can send an LSP State Report either in response State Reports. A PCC can send an LSP State Report either in response
to an LSP Update Request from a PCE, or asynchronously when the state to an LSP Update Request from a PCE, or asynchronously when the state
of an LSP changes. The Message-Type field of the PCEP common header of an LSP changes. The Message-Type field of the PCEP common header
for the PCRpt message is set to [TBD]. for the PCRpt message is to be assigned by IANA.
The format of the PCRpt message is as follows: The format of the PCRpt message is as follows:
<PCRpt Message> ::= <Common Header> <PCRpt Message> ::= <Common Header>
<state-report-list> <state-report-list>
Where: Where:
<state-report-list> ::= <state-report>[<state-report-list>] <state-report-list> ::= <state-report>[<state-report-list>]
<state-report> ::= [<SRP>] <state-report> ::= [<SRP>]
skipping to change at page 23, line 42 skipping to change at page 23, line 42
then it should use the SRP-ID-number of that request. No state then it should use the SRP-ID-number of that request. No state
compression is allowed for state reporting, e.g. PCRpt messages MUST compression is allowed for state reporting, e.g. PCRpt messages MUST
NOT be pruned from the PCC's egress queue even if subsequent NOT be pruned from the PCC's egress queue even if subsequent
operations on the same LSP have been completed before the PCRpt operations on the same LSP have been completed before the PCRpt
message has been sent to the TCP stack. The PCC MUST explicitly message has been sent to the TCP stack. The PCC MUST explicitly
report state changes (including removal) for paths it manages. report state changes (including removal) for paths it manages.
The LSP object (see Section 7.3) is mandatory, and it MUST be The LSP object (see Section 7.3) is mandatory, and it MUST be
included in each LSP State Report on the PCRpt message. If the LSP included in each LSP State Report on the PCRpt message. If the LSP
object is missing, the receiving PCE MUST send a PCErr message with object is missing, the receiving PCE MUST send a PCErr message with
Error-type=6 (Mandatory Object missing) and Error-value=[TBD] (LSP Error-type=6 (Mandatory Object missing) and Error-value to be
object missing). assigned by IANA (LSP object missing).
If the LSP transitioned to non-operational state, the PCC SHOULD If the LSP transitioned to non-operational state, the PCC SHOULD
include the LSP-ERROR-TLV (Section 7.3.3) with the relevant LSP Error include the LSP-ERROR-TLV (Section 7.3.3) with the relevant LSP Error
Code to report the error to the PCE. Code to report the error to the PCE.
The RRO SHOULD be included by the PCC when the path is up, but MAY be The RRO SHOULD be included by the PCC when the path is up or active,
omitted if the path is down due to a signaling error or another but MAY be omitted if the path is down due to a signaling error or
failure. another failure.
A PCE may choose to implement a limit on the resources a single PCC A PCE may choose to implement a limit on the resources a single PCC
can occupy. If a PCRpt is received that causes the PCE to exceed can occupy. If a PCRpt is received that causes the PCE to exceed
this limit, it MUST send a PCErr message with error-type 19 (invalid this limit, it MUST send a PCErr message with error-type 19 (invalid
operation) and error-value 4 (indicating resource limit exceeded) in operation) and error-value 4 (indicating resource limit exceeded) in
response to the PCRpt message triggering this condition and MAY response to the PCRpt message triggering this condition and MAY
terminate the session. terminate the session.
6.2. The PCUpd Message 6.2. The PCUpd Message
A Path Computation LSP Update Request message (also referred to as A Path Computation LSP Update Request message (also referred to as
PCUpd message) is a PCEP message sent by a PCE to a PCC to update PCUpd message) is a PCEP message sent by a PCE to a PCC to update
attributes of an LSP. A PCUpd message can carry more than one LSP attributes of an LSP. A PCUpd message can carry more than one LSP
Update Request. The Message-Type field of the PCEP common header for Update Request. The Message-Type field of the PCEP common header for
the PCUpd message is set to [TBD]. the PCUpd message is to be assigned by IANA.
The format of a PCUpd message is as follows: The format of a PCUpd message is as follows:
<PCUpd Message> ::= <Common Header> <PCUpd Message> ::= <Common Header>
<update-request-list> <update-request-list>
Where: Where:
<update-request-list> ::= <update-request>[<update-request-list>] <update-request-list> ::= <update-request>[<update-request-list>]
<update-request> ::= <SRP> <update-request> ::= <SRP>
skipping to change at page 26, line 31 skipping to change at page 26, line 31
If the stateful PCE capability has been advertised on the PCEP If the stateful PCE capability has been advertised on the PCEP
session, the PCErr message MAY include the SRP object. If the error session, the PCErr message MAY include the SRP object. If the error
reported is the result of an LSP update request, then the SRP-ID- reported is the result of an LSP update request, then the SRP-ID-
number MUST be the one from the PCUpd that triggered the error. If number MUST be the one from the PCUpd that triggered the error. If
the error is unsolicited, the SRP object MAY be omitted. This is the error is unsolicited, the SRP object MAY be omitted. This is
equivalent to including an SRP object with SRP-ID-number equal to the equivalent to including an SRP object with SRP-ID-number equal to the
reserved value 0x00000000. reserved value 0x00000000.
The format of a PCErr message from [RFC5440] is extended as follows: The format of a PCErr message from [RFC5440] is extended as follows:
<PCErr Message> ::= <Common Header> <PCErr Message> ::= <Common Header>
( <error-obj-list> [<Open>] ) | <error> ( <error-obj-list> [<Open>] ) | <error>
[<error-list>] [<error-list>]
<error-obj-list>::=<PCEP-ERROR>[<error-obj-list>] <error-obj-list>::=<PCEP-ERROR>[<error-obj-list>]
<error>::=[<request-id-list> | <stateful-request-id-list>] <<<< new <error>::=[<request-id-list> | <stateful-request-id-list>]
<error-obj-list> <error-obj-list>
<request-id-list>::=<RP>[<request-id-list>] <request-id-list>::=<RP>[<request-id-list>]
<stateful-request-id-list>::=<SRP>[<stateful-request-id-list>] <<< new <stateful-request-id-list>::=<SRP>[<stateful-request-id-list>]
<error-list>::=<error>[<error-list>] <error-list>::=<error>[<error-list>]
6.4. The PCReq Message 6.4. The PCReq Message
A PCC MAY include the LSP object in the PCReq message (see A PCC MAY include the LSP object in the PCReq message (see
Section 7.3) if the stateful PCE capability has been negotiated on a Section 7.3) if the stateful PCE capability has been negotiated on a
PCEP session between the PCC and a PCE. PCEP session between the PCC and a PCE.
The definition of the PCReq message from [RFC5440] is extended to The definition of the PCReq message from [RFC5440] is extended to
optionally include the LSP object after the END-POINTS object. The optionally include the LSP object after the END-POINTS object. The
encoding from [RFC5440] will become: encoding from [RFC5440] will become:
skipping to change at page 27, line 20 skipping to change at page 27, line 20
[<svec-list>] [<svec-list>]
<request-list> <request-list>
Where: Where:
<svec-list>::=<SVEC>[<svec-list>] <svec-list>::=<SVEC>[<svec-list>]
<request-list>::=<request>[<request-list>] <request-list>::=<request>[<request-list>]
<request>::= <RP> <request>::= <RP>
<END-POINTS> <END-POINTS>
[<LSP>] <--- New Object [<LSP>]
[<LSPA>] [<LSPA>]
[<BANDWIDTH>] [<BANDWIDTH>]
[<metric-list>] [<metric-list>]
[<RRO>[<BANDWIDTH>]] [<RRO>[<BANDWIDTH>]]
[<IRO>] [<IRO>]
[<LOAD-BALANCING>] [<LOAD-BALANCING>]
6.5. The PCRep Message 6.5. The PCRep Message
A PCE MAY include the LSP object in the PCRep message (see A PCE MAY include the LSP object in the PCRep message (see
skipping to change at page 27, line 47 skipping to change at page 27, line 47
from [RFC5440] will become: from [RFC5440] will become:
<PCRep Message> ::= <Common Header> <PCRep Message> ::= <Common Header>
<response-list> <response-list>
Where: Where:
<response-list>::=<response>[<response-list>] <response-list>::=<response>[<response-list>]
<response>::=<RP> <response>::=<RP>
[<LSP>] <--- New Object [<LSP>]
[<NO-PATH>] [<NO-PATH>]
[<attribute-list>] [<attribute-list>]
[<path-list>] [<path-list>]
7. Object Formats 7. Object Formats
The PCEP objects defined in this document are compliant with the PCEP The PCEP objects defined in this document are compliant with the PCEP
object format defined in [RFC5440]. The P flag and the I flag of the object format defined in [RFC5440]. The P flag and the I flag of the
PCEP objects defined in this document MUST always be set to 0 on PCEP objects defined in this document SHOULD always be set to 0 on
transmission and MUST be ignored on receipt since these flags are transmission and SHOULD be ignored on receipt since these flags are
exclusively related to path computation requests. exclusively related to path computation requests.
7.1. OPEN Object 7.1. OPEN Object
This document defines two new optional TLVs for use in the OPEN This document defines one new optional TLVs for use in the OPEN
Object. Object.
7.1.1. Stateful PCE Capability TLV 7.1.1. Stateful PCE Capability TLV
The STATEFUL-PCE-CAPABILITY TLV is an optional TLV for use in the The STATEFUL-PCE-CAPABILITY TLV is an optional TLV for use in the
OPEN Object for stateful PCE capability advertisement. Its format is OPEN Object for stateful PCE capability advertisement. Its format is
shown in the following figure: shown in the following figure:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |U| | Flags |U|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: STATEFUL-PCE-CAPABILITY TLV format Figure 9: STATEFUL-PCE-CAPABILITY TLV format
The type of the TLV is [TBD] and it has a fixed length of 4 octets. The type of the TLV is to be assigned by IANA and it has a fixed
length of 4 octets.
The value comprises a single field - Flags (32 bits): The value comprises a single field - Flags (32 bits):
U (LSP-UPDATE-CAPABILITY - 1 bit): if set to 1 by a PCC, the U Flag U (LSP-UPDATE-CAPABILITY - 1 bit): if set to 1 by a PCC, the U Flag
indicates that the PCC allows modification of LSP parameters; if indicates that the PCC allows modification of LSP parameters; if
set to 1 by a PCE, the U Flag indicates that the PCE is capable of set to 1 by a PCE, the U Flag indicates that the PCE is capable of
updating LSP parameters. The LSP-UPDATE-CAPABILITY Flag must be updating LSP parameters. The LSP-UPDATE-CAPABILITY Flag must be
advertised by both a PCC and a PCE for PCUpd messages to be advertised by both a PCC and a PCE for PCUpd messages to be
allowed on a PCEP session. allowed on a PCEP session.
skipping to change at page 29, line 13 skipping to change at page 29, line 13
procedures defined in this document. procedures defined in this document.
7.2. SRP Object 7.2. SRP Object
The SRP (Stateful PCE Request Parameters) object MUST be carried The SRP (Stateful PCE Request Parameters) object MUST be carried
within PCUpd messages and MAY be carried within PCRpt and PCErr within PCUpd messages and MAY be carried within PCRpt and PCErr
messages. The SRP object is used to correlate between update messages. The SRP object is used to correlate between update
requests sent by the PCE and the error reports and state reports sent requests sent by the PCE and the error reports and state reports sent
by the PCC. by the PCC.
SRP Object-Class is [TBD]. SRP Object-Class is to be assigned by IANA.
SRP Object-Type is 1. SRP Object-Type is 1.
The format of the SRP object body is shown in Figure 10: The format of the SRP object body is shown in Figure 10:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRP-ID-number | | SRP-ID-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Optional TLVs // // Optional TLVs //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 30, line 29 skipping to change at page 30, line 29
The LSP object MUST be present within PCRpt and PCUpd messages. The The LSP object MUST be present within PCRpt and PCUpd messages. The
LSP object MAY be carried within PCReq and PCRep messages if the LSP object MAY be carried within PCReq and PCRep messages if the
stateful PCE capability has been negotiated on the session. The LSP stateful PCE capability has been negotiated on the session. The LSP
object contains a set of fields used to specify the target LSP, the object contains a set of fields used to specify the target LSP, the
operation to be performed on the LSP, and LSP Delegation. It also operation to be performed on the LSP, and LSP Delegation. It also
contains a flag indicating to a PCE that the LSP state contains a flag indicating to a PCE that the LSP state
synchronization is in progress. This document focuses on LSPs that synchronization is in progress. This document focuses on LSPs that
are signaled with RSVP, many of the TLVs used with the LSP object are signaled with RSVP, many of the TLVs used with the LSP object
mirror RSVP state. mirror RSVP state.
LSP Object-Class is [TBD]. LSP Object-Class is to be assigned by IANA.
LSP Object-Type is 1. LSP Object-Type is 1.
The format of the LSP object body is shown in Figure 11: The format of the LSP object body is shown in Figure 11:
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 | Flag | O|A|R|S|D| | PLSP-ID | Flag | O|A|R|S|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 31, line 32 skipping to change at page 31, line 32
S (SYNC - 1 bit): the S Flag MUST be set to 1 on each PCRpt sent S (SYNC - 1 bit): the S Flag MUST be set to 1 on each PCRpt sent
from a PCC during State Synchronization. The S Flag MUST be set from a PCC during State Synchronization. The S Flag MUST be set
to 0 in other PCRpt messages sent from the PCC. to 0 in other PCRpt messages sent from the PCC.
R(Remove - 1 bit): On PCRpt messages the R Flag indicates that the R(Remove - 1 bit): On PCRpt messages the R Flag indicates that the
LSP has been removed from the PCC and the PCE SHOULD remove all LSP has been removed from the PCC and the PCE SHOULD remove all
state from its database. Upon receiving an LSP State Report with state from its database. Upon receiving an LSP State Report with
the R Flag set to 1 for an RSVP-signaled LSP, the PCE SHOULD the R Flag set to 1 for an RSVP-signaled LSP, the PCE SHOULD
remove all state for the path identified by the LSP Identifiers remove all state for the path identified by the LSP Identifiers
TLV from its database. When the all-zeros LSP-IDENTIFIERS-TLV is TLV from its database. When the all-zeros LSP-IDENTIFIERS TLV is
used, the PCE SHOULD remove all state for the PLSP-ID from its used, the PCE SHOULD remove all state for the PLSP-ID from its
database. database.
A(Administrative - 1 bit): On PCRpt messages, the A Flag indicates A(Administrative - 1 bit): On PCRpt messages, the A Flag indicates
the PCC's target operational status for this LSP. On PCUpd the PCC's target operational status for this LSP. On PCUpd
messages, the A Flag indicates the LSP status that the PCE desires messages, the A Flag indicates the LSP status that the PCE desires
for this LSP. In both cases, a value of '1' means that the for this LSP. In both cases, a value of '1' means that the
desired operational state is active, and a value of '0' means that desired operational state is active, and a value of '0' means that
the desired operational state is inactive. A PCC ignores the A the desired operational state is inactive. A PCC ignores the A
flag on a PCUpd message unless the operator's policy allows the flag on a PCUpd message unless the operator's policy allows the
skipping to change at page 33, line 21 skipping to change at page 33, line 21
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP ID | Tunnel ID | | LSP ID | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID | | Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Tunnel Endpoint Address | | IPv4 Tunnel Endpoint Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: IPV4-LSP-IDENTIFIERS TLV format Figure 12: IPV4-LSP-IDENTIFIERS TLV format
The type of the TLV is [TBD] and it has a fixed length of 12 octets. The type of the TLV is to be assigned by IANA and it has a fixed
The value contains the following fields: length of 16 octets. The value contains the following fields:
IPv4 Tunnel Sender Address: contains the sender node's IPv4 address, IPv4 Tunnel Sender Address: contains the sender node's IPv4 address,
as defined in [RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4 as defined in [RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4
Sender Template Object. Sender Template Object.
LSP ID: contains the 16-bit 'LSP ID' identifier defined in LSP ID: contains the 16-bit 'LSP ID' identifier defined in
[RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4 Sender Template [RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4 Sender Template
Object. Object. A value of 0 MUST be used if the LSP is not yet signaled.
Tunnel ID: contains the 16-bit 'Tunnel ID' identifier defined in Tunnel ID: contains the 16-bit 'Tunnel ID' identifier defined in
[RFC3209], Section 4.6.1.1 for the LSP_TUNNEL_IPv4 Session Object. [RFC3209], Section 4.6.1.1 for the LSP_TUNNEL_IPv4 Session Object.
Tunnel ID remains constant over the life time of a tunnel. Tunnel ID remains constant over the life time of a tunnel.
Extended Tunnel ID: contains the 32-bit 'Extended Tunnel ID' Extended Tunnel ID: contains the 32-bit 'Extended Tunnel ID'
identifier defined in [RFC3209], Section 4.6.1.1 for the identifier defined in [RFC3209], Section 4.6.1.1 for the
LSP_TUNNEL_IPv4 Session Object. LSP_TUNNEL_IPv4 Session Object.
IPv4 Tunnel Endpoint Address: contains the egress node's IPv4 IPv4 Tunnel Endpoint Address: contains the egress node's IPv4
skipping to change at page 34, line 39 skipping to change at page 34, line 39
+ + + +
| IPv6 tunnel endpoint address | | IPv6 tunnel endpoint address |
+ (16 octets) + + (16 octets) +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: IPV6-LSP-IDENTIFIERS TLV format Figure 13: IPV6-LSP-IDENTIFIERS TLV format
The type of the TLV is [TBD] and it has a fixed length of 36 octets. The type of the TLV is to be assigned by IANA and it has a fixed
The value contains the following fields: length of 52 octets. The value contains the following fields:
IPv6 Tunnel Sender Address: contains the sender node's IPv6 address, IPv6 Tunnel Sender Address: contains the sender node's IPv6 address,
as defined in [RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6 as defined in [RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6
Sender Template Object. Sender Template Object.
LSP ID: contains the 16-bit 'LSP ID' identifier defined in LSP ID: contains the 16-bit 'LSP ID' identifier defined in
[RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6 Sender Template [RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6 Sender Template
Object. Object. A value of 0 MUST be used if the LSP is not yet signaled.
Tunnel ID: contains the 16-bit 'Tunnel ID' identifier defined in Tunnel ID: contains the 16-bit 'Tunnel ID' identifier defined in
[RFC3209], Section 4.6.1.2 for the LSP_TUNNEL_IPv6 Session Object. [RFC3209], Section 4.6.1.2 for the LSP_TUNNEL_IPv6 Session Object.
Tunnel ID remains constant over the life time of a tunnel. Tunnel ID remains constant over the life time of a tunnel.
However, when Global Path Protection or Global Default Restoration However, when Global Path Protection or Global Default Restoration
is used, both the primary and secondary LSPs have their own Tunnel is used, both the primary and secondary LSPs have their own Tunnel
IDs. A PCC will report a change in Tunnel ID when traffic IDs. A PCC will report a change in Tunnel ID when traffic
switches over from primary LSP to secondary LSP (or vice versa). switches over from primary LSP to secondary LSP (or vice versa).
skipping to change at page 36, line 5 skipping to change at page 36, line 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=[TBD] | Length (variable) | | Type=[TBD] | Length (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Symbolic Path Name // // Symbolic Path Name //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: SYMBOLIC-PATH-NAME TLV format Figure 14: SYMBOLIC-PATH-NAME TLV format
The type of the TLV is [TBD] and it has a variable length, which MUST The type of the TLV is to be assigned by IANA and it has a variable
be greater than 0. length, which MUST be greater than 0.
7.3.3. LSP Error Code TLV 7.3.3. LSP Error Code TLV
The LSP Error code TLV is an optional TLV for use in the LSP object The LSP Error code TLV is an optional TLV for use in the LSP object
to convey error information. When an LSP Update Request fails, an to convey error information. When an LSP Update Request fails, an
LSP State Report MUST be sent to report the current state of the LSP, LSP State Report MUST be sent to report the current state of the LSP,
and SHOULD contain the LSP-ERROR-CODE TLV indicating the reason for and SHOULD contain the LSP-ERROR-CODE TLV indicating the reason for
the failure. Similarly, when a PCRpt is sent as a result of an LSP the failure. Similarly, when a PCRpt is sent as a result of an LSP
transitioning to non-operational state, the LSP-ERROR-CODE TLV SHOULD transitioning to non-operational state, the LSP-ERROR-CODE TLV SHOULD
be included to indicate the reason for the transition. be included to indicate the reason for the transition.
skipping to change at page 36, line 31 skipping to change at page 36, line 31
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Error Code | | LSP Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: LSP-ERROR-CODE TLV format Figure 15: LSP-ERROR-CODE TLV format
The type of the TLV is [TBD] and it has a fixed length of 4 octets. The type of the TLV is to be assigned by IANA and it has a fixed
The value contains an error code that indicates the cause of the length of 4 octets. The value contains an error code that indicates
failure. the cause of the failure.
The following LSP Error Codes are defined: The following LSP Error Codes are currently defined:
Value Meaning Value Meaning
1 Unknown reason 1 Unknown reason
2 Limit reached for PCE-controlled LSPs 2 Limit reached for PCE-controlled LSPs
3 Too many pending LSP update requests 3 Too many pending LSP update requests
4 Unacceptable parameters 4 Unacceptable parameters
5 Internal error 5 Internal error
6 LSP administratively brought down 6 LSP administratively brought down
7 LSP preempted 7 LSP preempted
8 RSVP signaling error 8 RSVP signaling error
skipping to change at page 37, line 24 skipping to change at page 37, line 24
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=[TBD] | Length (variable) | | Type=[TBD] | Length (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ RSVP ERROR_SPEC or USER_ERROR_SPEC Object + + RSVP ERROR_SPEC or USER_ERROR_SPEC Object +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: RSVP-ERROR-SPEC TLV format Figure 16: RSVP-ERROR-SPEC TLV format
The type of the TLV is [TBD] and it has a variable length. The value The type of the TLV is to be assigned by IANA and it has a variable
contains the RSVP ERROR_SPEC or USER_ERROR_SPEC object, including the length. The value contains the RSVP ERROR_SPEC or USER_ERROR_SPEC
object header. object, including the object header.
8. IANA Considerations 8. IANA Considerations
This document requests IANA actions to allocate code points for the This document requests IANA actions to allocate code points for the
protocol elements defined in this document. Values shown here are protocol elements defined in this document. Values shown here are
suggested for use by IANA. suggested for use by IANA.
8.1. PCEP Messages 8.1. PCEP Messages
This document defines the following new PCEP messages: This document defines the following new PCEP messages:
skipping to change at page 39, line 8 skipping to change at page 39, line 8
Error-value=8: LSP Object missing Error-value=8: LSP Object missing
Error-value=9: ERO Object missing Error-value=9: ERO Object missing
Error-value=10: SRP Object missing Error-value=10: SRP Object missing
Error-value=11: LSP-IDENTIFIERS TLV missing Error-value=11: LSP-IDENTIFIERS TLV missing
19 Invalid Operation 19 Invalid Operation
Error-value=1: Attempted LSP Update Request for a non- Error-value=1: Attempted LSP Update Request for a non-
delegated LSP. The PCEP-ERROR Object delegated LSP. The PCEP-ERROR Object
is followed by the LSP Object that is followed by the LSP Object that
identifies the LSP. identifies the LSP.
Error-value=2: Attempted LSP Update Request if active Error-value=2: Attempted LSP Update Request if the
stateful PCE capability was not stateful PCE capability was not
advertised. advertised.
Error-value=3: Attempted LSP Update Request for an LSP Error-value=3: Attempted LSP Update Request for an LSP
identified by an unknown PLSP-ID. identified by an unknown PLSP-ID.
Error-value=4: A PCE indicates to a PCC that it has Error-value=4: A PCE indicates to a PCC that it has
exceeded the resource limit allocated exceeded the resource limit allocated
for its state, and thus it cannot for its state, and thus it cannot
accept and process its LSP State Report accept and process its LSP State Report
message. message.
Error-value=5: Attempted LSP State Report if active Error-value=5: Attempted LSP State Report if active
skipping to change at page 42, line 37 skipping to change at page 42, line 37
PCEP protocol extensions defined in this document do not put new PCEP protocol extensions defined in this document do not put new
requirements on other protocols. requirements on other protocols.
9.6. Impact on Network Operation 9.6. Impact on Network Operation
Mechanisms defined in [RFC5440], Section 8.6 also apply to PCEP Mechanisms defined in [RFC5440], Section 8.6 also apply to PCEP
protocol extensions defined in this document. protocol extensions defined in this document.
Additionally, a PCEP implementation SHOULD allow a limit to be placed Additionally, a PCEP implementation SHOULD allow a limit to be placed
on the number of LSPs delegated to the PcE and on the rate of PCUpd on the number of LSPs delegated to the PCE and on the rate of PCUpd
and PCRpt messages sent by a PCEP speaker and processed from a peer. and PCRpt messages sent by a PCEP speaker and processed from a peer.
It SHOULD also allow sending a notification when a rate threshold is It SHOULD also allow sending a notification when a rate threshold is
reached. reached.
A PCC implementation SHOULD allow a limit to be placed on the rate of A PCC implementation SHOULD allow a limit to be placed on the rate of
LSP Updates to the same LSP to avoid signaling overload discussed in LSP Updates to the same LSP to avoid signaling overload discussed in
Section 10.3. Section 10.3.
10. Security Considerations 10. Security Considerations
skipping to change at page 44, line 48 skipping to change at page 44, line 48
Thanks also to Cyril Margaria, Jon Hardwick, Dhruv Dhoddy, Ramon Thanks also to Cyril Margaria, Jon Hardwick, Dhruv Dhoddy, Ramon
Casellas, Oscar Gonzales de Dios, Tomas Janciga, Stefan Kobza, Kexin Casellas, Oscar Gonzales de Dios, Tomas Janciga, Stefan Kobza, Kexin
Tang, Matej Spanik, Jon Parker, Marek Zavodsky, Ambrose Kwong, Ashwin Tang, Matej Spanik, Jon Parker, Marek Zavodsky, Ambrose Kwong, Ashwin
Sampath, Calvin Ying and Xian Zhang for helpful comments and Sampath, Calvin Ying and Xian Zhang for helpful comments and
discussions. discussions.
12. References 12. References
12.1. Normative References 12.1. Normative References
[I-D.ietf-pce-gmpls-pcep-extensions]
Margaria, C., Dios, O., and F. Zhang, "PCEP extensions for
GMPLS", draft-ietf-pce-gmpls-pcep-extensions-09 (work in
progress), February 2014.
[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.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997. Functional Specification", RFC 2205, September 1997.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,
"OSPF Protocol Extensions for Path Computation Element "OSPF Protocol Extensions for Path Computation Element
(PCE) Discovery", RFC 5088, January 2008. (PCE) Discovery", RFC 5088, January 2008.
[RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang,
"IS-IS Protocol Extensions for Path Computation Element "IS-IS Protocol Extensions for Path Computation Element
(PCE) Discovery", RFC 5089, January 2008. (PCE) Discovery", RFC 5089, January 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
skipping to change at page 45, line 45 skipping to change at page 45, line 38
[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.
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
Used to Form Encoding Rules in Various Routing Protocol Used to Form Encoding Rules in Various Routing Protocol
Specifications", RFC 5511, April 2009. Specifications", RFC 5511, April 2009.
12.2. Informative References 12.2. Informative References
[I-D.ietf-pce-gmpls-pcep-extensions]
Margaria, C., Dios, O., and F. Zhang, "PCEP extensions for
GMPLS", draft-ietf-pce-gmpls-pcep-extensions-10 (work in
progress), October 2014.
[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-02 (work in progress), June 2014. app-03 (work in progress), October 2014.
[I-D.minei-pce-stateful-sync-optimizations] [I-D.ietf-pce-stateful-sync-optimizations]
Crabbe, E., Medved, J., Minei, I., 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-
minei-pce-stateful-sync-optimizations-02 (work in ietf-pce-stateful-sync-optimizations-01 (work in
progress), March 2014. progress), June 2014.
[I-D.sivabalan-pce-disco-stateful] [I-D.sivabalan-pce-disco-stateful]
Sivabalan, S., Medved, J., and X. Zhang, "IGP Extensions Sivabalan, S., Medved, J., and X. Zhang, "IGP Extensions
for Stateful PCE Discovery", draft-sivabalan-pce-disco- for Stateful PCE Discovery", draft-sivabalan-pce-disco-
stateful-03 (work in progress), January 2014. stateful-03 (work in progress), January 2014.
[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 Information LSP Path Computation using Preemption", Global Information
Infrastructure Symposium, July 2007. 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.
[NET-REC] Vasseur, JP., Pickavet, M., and P. Demeester, "Network
Recovery: Protection and Restoration of Optical, SONET-
SDH, IP, and MPLS", The Morgan Kaufmann Series in
Networking, June 2004.
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
McManus, "Requirements for Traffic Engineering Over MPLS", McManus, "Requirements for Traffic Engineering Over MPLS",
RFC 2702, September 1999. RFC 2702, September 1999.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001. Label Switching Architecture", RFC 3031, January 2001.
[RFC3346] Boyle, J., Gill, V., Hannan, A., Cooper, D., Awduche, D., [RFC3346] Boyle, J., Gill, V., Hannan, A., Cooper, D., Awduche, D.,
Christian, B., and W. Lai, "Applicability Statement for Christian, B., and W. Lai, "Applicability Statement for
Traffic Engineering with MPLS", RFC 3346, August 2002. Traffic Engineering with MPLS", RFC 3346, August 2002.
skipping to change at page 47, line 12 skipping to change at page 47, line 9
Communication Protocol Generic Requirements", RFC 4657, Communication Protocol Generic Requirements", RFC 4657,
September 2006. September 2006.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, October 2008. Engineering", RFC 5305, October 2008.
[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.
[RFC5557] Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path
Computation Element Communication Protocol (PCEP)
Requirements and Protocol Extensions in Support of Global
Concurrent Optimization", RFC 5557, July 2009.
Authors' Addresses Authors' Addresses
Edward Crabbe Edward Crabbe
Google, Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043
US
Email: edc@google.com Email: edward.crabbe@gmail.com
Ina Minei Ina Minei
Google, Inc. Google, Inc.
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
Mountain View, CA 94043 Mountain View, CA 94043
US US
Email: inaminei@google.com Email: inaminei@google.com
Jan Medved Jan Medved
 End of changes. 51 change blocks. 
97 lines changed or deleted 83 lines changed or added

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