draft-ietf-pce-stateful-pce-07.txt   draft-ietf-pce-stateful-pce-08.txt 
PCE Working Group E. Crabbe PCE Working Group E. Crabbe
Internet-Draft Google, Inc. Internet-Draft Google, Inc.
Intended status: Standards Track J. Medved Intended status: Standards Track J. Medved
Expires: April 11, 2014 Cisco Systems, Inc. Expires: August 16, 2014 Cisco Systems, Inc.
I. Minei I. Minei
Juniper Networks, Inc. Google, Inc.
R. Varga R. Varga
Pantheon Technologies SRO Pantheon Technologies SRO
October 8, 2013 February 12, 2014
PCEP Extensions for Stateful PCE PCEP Extensions for Stateful PCE
draft-ietf-pce-stateful-pce-07 draft-ietf-pce-stateful-pce-08
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 information available to the PCE, it also makes no provisions for PCE
synchronization or PCE control of timing and sequence of path control of timing and sequence of path computations within and across
computations within and across PCEP sessions. This document PCEP sessions. This document describes a set of extensions to PCEP
describes a set of extensions to PCEP to enable stateful control of to enable stateful control of MPLS-TE and GMPLS LSPs via PCEP.
MPLS-TE and GMPLS LSPs via PCEP.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. 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
skipping to change at page 2, line 4 skipping to change at page 1, line 48
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 April 11, 2014.
This Internet-Draft will expire on August 16, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Motivation and Objectives for Stateful PCE . . . . . . . . . . 7 3. Motivation and Objectives for Stateful PCE . . . . . . . . . . 5
3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.1. Background . . . . . . . . . . . . . . . . . . . . . . 7 3.1.1. Background . . . . . . . . . . . . . . . . . . . . . . 6
3.1.2. Why a Stateful PCE? . . . . . . . . . . . . . . . . . 7 3.1.2. Why a Stateful PCE? . . . . . . . . . . . . . . . . . 6
3.1.3. Protocol vs. Configuration . . . . . . . . . . . . . . 8 3.1.3. Protocol vs. Configuration . . . . . . . . . . . . . . 7
3.2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . 8
4. New Functions to Support Stateful PCEs . . . . . . . . . . . . 9 4. New Functions to Support Stateful PCEs . . . . . . . . . . . . 8
5. Architectural Overview of Protocol Extensions . . . . . . . . 10 5. Architectural Overview of Protocol Extensions . . . . . . . . 9
5.1. LSP State Ownership . . . . . . . . . . . . . . . . . . . 10 5.1. LSP State Ownership . . . . . . . . . . . . . . . . . . . 9
5.2. New Messages . . . . . . . . . . . . . . . . . . . . . . . 11 5.2. New Messages . . . . . . . . . . . . . . . . . . . . . . . 10
5.3. Capability Advertisement . . . . . . . . . . . . . . . . . 12 5.3. Capability Advertisement . . . . . . . . . . . . . . . . . 10
5.4. State Synchronization . . . . . . . . . . . . . . . . . . 12 5.4. State Synchronization . . . . . . . . . . . . . . . . . . 11
5.5. LSP Delegation . . . . . . . . . . . . . . . . . . . . . . 15 5.5. LSP Delegation . . . . . . . . . . . . . . . . . . . . . . 14
5.5.1. Delegating an LSP . . . . . . . . . . . . . . . . . . 16 5.5.1. Delegating an LSP . . . . . . . . . . . . . . . . . . 15
5.5.2. Revoking a Delegation . . . . . . . . . . . . . . . . 16 5.5.2. Revoking a Delegation . . . . . . . . . . . . . . . . 15
5.5.3. Returning a Delegation . . . . . . . . . . . . . . . . 18 5.5.3. Returning a Delegation . . . . . . . . . . . . . . . . 17
5.5.4. Redundant Stateful PCEs . . . . . . . . . . . . . . . 18 5.5.4. Redundant Stateful PCEs . . . . . . . . . . . . . . . 17
5.5.5. Redelegation on PCE Failure . . . . . . . . . . . . . 19 5.5.5. Redelegation on PCE Failure . . . . . . . . . . . . . 18
5.6. LSP Operations . . . . . . . . . . . . . . . . . . . . . . 19 5.6. LSP Operations . . . . . . . . . . . . . . . . . . . . . . 18
5.6.1. Passive Stateful PCE Path Computation 5.6.1. Passive Stateful PCE Path Computation
Request/Response . . . . . . . . . . . . . . . . . . . 20 Request/Response . . . . . . . . . . . . . . . . . . . 19
5.6.2. Active Stateful PCE LSP Update . . . . . . . . . . . . 21 5.6.2. Active Stateful PCE LSP Update . . . . . . . . . . . . 20
5.7. LSP Protection . . . . . . . . . . . . . . . . . . . . . . 23 5.7. LSP Protection . . . . . . . . . . . . . . . . . . . . . . 22
5.8. Transport . . . . . . . . . . . . . . . . . . . . . . . . 23 5.8. Transport . . . . . . . . . . . . . . . . . . . . . . . . 22
6. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 23 6. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 22
6.1. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 23 6.1. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 22
6.2. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 25 6.2. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 24
6.3. The PCErr Message . . . . . . . . . . . . . . . . . . . . 27 6.3. The PCErr Message . . . . . . . . . . . . . . . . . . . . 26
7. Object Formats . . . . . . . . . . . . . . . . . . . . . . . . 27
7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 28 7. Object Formats . . . . . . . . . . . . . . . . . . . . . . . . 26
7.1.1. Stateful PCE Capability TLV . . . . . . . . . . . . . 28 7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 27
7.2. SRP Object . . . . . . . . . . . . . . . . . . . . . . . . 28 7.1.1. Stateful PCE Capability TLV . . . . . . . . . . . . . 27
7.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . . 30 7.2. SRP Object . . . . . . . . . . . . . . . . . . . . . . . . 27
7.3.1. LSP Identifiers TLVs . . . . . . . . . . . . . . . . . 32 7.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . . 29
7.3.1. LSP Identifiers TLVs . . . . . . . . . . . . . . . . . 31
7.3.2. Symbolic Path Name TLV . . . . . . . . . . . . . . . . 34 7.3.2. Symbolic Path Name TLV . . . . . . . . . . . . . . . . 34
7.3.3. LSP Error Code TLV . . . . . . . . . . . . . . . . . . 35 7.3.3. LSP Error Code TLV . . . . . . . . . . . . . . . . . . 35
7.3.4. RSVP Error Spec TLV . . . . . . . . . . . . . . . . . 36 7.3.4. RSVP Error Spec TLV . . . . . . . . . . . . . . . . . 35
7.4. Optional TLVs for the LSPA Object . . . . . . . . . . . . 36 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
7.4.1. Symbolic Path Name TLV . . . . . . . . . . . . . . . . 37 8.1. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 36
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 8.2. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . 36
8.1. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 37
8.2. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . 37
8.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . . 37 8.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . . 37
8.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 38 8.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 37
8.5. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 38 8.5. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 38
8.6. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 39 8.6. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 38
8.7. LSP-ERROR-CODE TLV . . . . . . . . . . . . . . . . . . . . 39 8.7. LSP-ERROR-CODE TLV . . . . . . . . . . . . . . . . . . . . 39
9. Manageability Considerations . . . . . . . . . . . . . . . . . 39 9. Manageability Considerations . . . . . . . . . . . . . . . . . 39
9.1. Control Function and Policy . . . . . . . . . . . . . . . 40 9.1. Control Function and Policy . . . . . . . . . . . . . . . 39
9.2. Information and Data Models . . . . . . . . . . . . . . . 41 9.2. Information and Data Models . . . . . . . . . . . . . . . 40
9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 41 9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 40
9.4. Verifying Correct Operation . . . . . . . . . . . . . . . 41 9.4. Verifying Correct Operation . . . . . . . . . . . . . . . 41
9.5. Requirements on Other Protocols and Functional 9.5. Requirements on Other Protocols and Functional
Components . . . . . . . . . . . . . . . . . . . . . . . . 41 Components . . . . . . . . . . . . . . . . . . . . . . . . 41
9.6. Impact on Network Operation . . . . . . . . . . . . . . . 41 9.6. Impact on Network Operation . . . . . . . . . . . . . . . 41
10. Security Considerations . . . . . . . . . . . . . . . . . . . 42 10. Security Considerations . . . . . . . . . . . . . . . . . . . 41
10.1. Vulnerability . . . . . . . . . . . . . . . . . . . . . . 42 10.1. Vulnerability . . . . . . . . . . . . . . . . . . . . . . 41
10.2. LSP State Snooping . . . . . . . . . . . . . . . . . . . . 42 10.2. LSP State Snooping . . . . . . . . . . . . . . . . . . . . 42
10.3. Malicious PCE . . . . . . . . . . . . . . . . . . . . . . 43 10.3. Malicious PCE . . . . . . . . . . . . . . . . . . . . . . 42
10.4. Malicious PCC . . . . . . . . . . . . . . . . . . . . . . 43 10.4. Malicious PCC . . . . . . . . . . . . . . . . . . . . . . 43
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43
12.1. Normative References . . . . . . . . . . . . . . . . . . . 44 12.1. Normative References . . . . . . . . . . . . . . . . . . . 43
12.2. Informative References . . . . . . . . . . . . . . . . . . 45 12.2. Informative References . . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46
1. Introduction 1. Introduction
[RFC5440] describes the Path Computation Element Protocol (PCEP). [RFC5440] describes the Path Computation Element Protocol (PCEP).
PCEP defines the communication between a Path Computation Client PCEP defines the communication between a Path Computation Client
(PCC) and a Path Computation Element (PCE), or between PCEs, enabling (PCC) and a Path Computation Element (PCE), or between PCEs, enabling
computation of Multiprotocol Label Switching (MPLS) for Traffic computation of Multiprotocol Label Switching (MPLS) for Traffic
Engineering Label Switched Path (TE LSP) characteristics. Extensions Engineering Label Switched Path (TE LSP) characteristics. Extensions
for support of Generalized MPLS (GMPLS) in PCEP are defined in for support of Generalized MPLS (GMPLS) in PCEP are defined in
skipping to change at page 5, line 29 skipping to change at page 4, line 29
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.
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 [RFC4090]: MPLS TE
Fast Reroute (FRR), FRR One-to-One Backup, FRR Facility Backup.
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
the set of active paths and their reserved resources for its the set of active paths and their reserved resources for its
computations. A stateful PCE might also retain information computations. A stateful PCE might also retain information
regarding LSPs under construction in order to reduce churn and regarding LSPs under construction in order to reduce churn and
resource contention. The additional state allows the PCE to resource contention. The additional state allows the PCE to
compute constrained paths while considering individual LSPs and compute constrained paths while considering individual LSPs and
their interactions. Note that this requires reliable state their interactions. Note that this requires reliable state
synchronization mechanisms between the PCE and the network, PCE synchronization mechanisms between the PCE and the network, PCE
skipping to change at page 6, line 11 skipping to change at page 5, line 10
which the PCE may issue recommendations to the network. For which the PCE may issue recommendations to the network. For
example, an active stateful PCE may utilize the Delegation example, an active stateful PCE may utilize the Delegation
mechanism to update LSP parameters in those PCCs that delegated mechanism to update LSP parameters in those PCCs that delegated
control over their LSPs to the PCE. control over their LSPs to the PCE.
Delegation: An operation to grant a PCE temporary rights to modify a Delegation: An operation to grant a PCE temporary rights to modify a
subset of LSP parameters on one or more PCC's LSPs. LSPs are 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 delegated from a PCC to a PCE, and are referred to as delegated
LSPs. The PCC who owns the PCE state for the LSP has the right to LSPs. The PCC who 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 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 PCC of the in time. For intra-domain LSPs, this PCC SHOULD be the LSP head
LSP head end. 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: when a PCEP session is terminated, a Redelegation Timeout Interval: when a PCEP session is terminated, a
PCC waits for this time period before revoking LSP delegation to a PCC waits for this time period before revoking LSP delegation to a
PCE and attempting to redelegate LSPs associated with the 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-
configured or dynamically computed by the PCC based on local configured or dynamically computed by the PCC based on local
policy. policy.
State Timeout Interval: when a PCEP session is terminated, a PCC State Timeout Interval: when a PCEP session is terminated, a PCC
waits for this time period before flushing LSP state associated waits for this time period before flushing LSP state associated
with that PCEP session and reverting to operator-defined default with that PCEP session and reverting to operator-defined default
parameters. The State Timeout Interval is a PCC-local value that parameters or behaviors. The State Timeout Interval is a PCC-
can be either operator-configured or dynamically computed by the local value that can be either operator-configured or dynamically
PCC based on local policy. computed by the PCC based on local policy.
LSP State Report: an operation to send LSP state (Operational / LSP State Report: an operation to send LSP state (Operational /
Admin Status, LSP attributes configured and set by a PCE, etc.) Admin Status, LSP attributes configured at the PCC and set by a
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.
LSP State Database: information about all LSPs and their attributes. LSP State Database: information about all LSPs and their attributes.
Within this document, PCE-PCE communications are described by having Within this document, PCE-PCE communications are described by having
the requesting PCE fill the role of a PCC. This provides a saving in the requesting PCE fill the role of a PCC. This provides a saving in
documentation without loss of function. documentation without loss of function.
skipping to change at page 8, line 51 skipping to change at page 7, line 48
o Scale & Performance: configuration operations often require o Scale & Performance: configuration operations often require
processing of additional configuration portions beyond the state processing of additional configuration portions beyond the state
being directly acted upon, with corresponding cost in CPU cycles, being directly acted upon, with corresponding cost in CPU cycles,
negatively impacting both PCC stability LSP update rate capacity. negatively impacting both PCC stability LSP update rate capacity.
o Scale & Performance: configuration operations often have o Scale & Performance: configuration operations often have
transactional semantics which are typically heavyweight and transactional semantics which are typically heavyweight and
require additional CPU cycles, negatively impacting PCC update require additional CPU cycles, negatively impacting PCC update
rate capacity. rate capacity.
o Security: opening up a configuration channel to a PCE would allow o Security: when a PCC opens a configuration channel allowing a PCE
a malicious PCE to take over a PCC. The PCEP extensions described to send configuration, a malicious PCE may take advantage of this
in this document only allow a PCE control over a very limited set ability to take over the PCC. In contrast, the PCEP extensions
of LSP attributes. described in this document only allow a PCE control over a very
limited set of LSP attributes.
o Interoperability: each vendor has a proprietary information model o Interoperability: each vendor has a proprietary information model
for configuring LSP state, which prevents interoperability of a for configuring LSP state, which prevents interoperability of a
PCE with PCCs from different vendors. The PCEP extensions PCE with PCCs from different vendors. The PCEP extensions
described in this document allow for a common information model described in this document allow for a common information model
for LSP state for all vendors. for LSP state for all vendors.
o Efficient State Synchronization: configuration channels may be o Efficient State Synchronization: configuration channels may be
heavyweight and unidirectional, therefore efficient state heavyweight and unidirectional, therefore efficient state
synchronization between a PCE and a PCE may be a problem. synchronization between a PCC and a PCE may be a problem.
3.2. Objectives 3.2. Objectives
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
skipping to change at page 10, line 40 skipping to change at page 9, line 36
5. Architectural Overview of Protocol Extensions 5. Architectural Overview of Protocol Extensions
5.1. LSP State Ownership 5.1. LSP State Ownership
In the PCEP protocol (defined in [RFC5440]), LSP state and operation In the PCEP protocol (defined in [RFC5440]), LSP state and operation
are under the control of a PCC (a PCC may be an LSR or a management are under the control of a PCC (a PCC may be an LSR or a management
station). Attributes received from a PCE are subject to PCC's local station). Attributes received from a PCE are subject to PCC's local
policy. The PCEP protocol extensions described in this document do policy. The PCEP protocol extensions described in this document do
not change this behavior. not change this behavior.
An active stateful PCE may have control of a PCC's LSPs be delegated An active stateful PCE may have control of a PCC's LSPs that were
to it, but the LSP state ownership is retained by the PCC. In delegated to it, but the LSP state ownership is retained by the PCC.
particular, in addition to specifying values for LSP's attributes, an In particular, in addition to specifying values for LSP's attributes,
active stateful PCE also decides when to make LSP modifications. an active stateful PCE also decides when to make LSP modifications.
Retaining LSP state ownership on the PCC allows for: Retaining LSP state ownership on the PCC allows for:
o a PCC to interact with both stateless and stateful PCEs at the o a PCC to interact with both stateless and stateful PCEs at the
same time same time
o a stateful PCE to only modify a small subset of LSP parameters, o a stateful PCE to only modify a small subset of LSP parameters,
i.e. to set only a small subset of the overall LSP state; other i.e. to set only a small subset of the overall LSP state; other
parameters may be set by the operator through command line parameters may be set by the operator through command line
interface (CLI) commands interface (CLI) commands
skipping to change at page 12, line 25 skipping to change at page 11, line 19
The presence of the Stateful PCE Capability TLV in PCC's OPEN Object The presence of the Stateful PCE Capability TLV in PCC's OPEN Object
indicates that the PCC is willing to send LSP State Reports whenever indicates that the PCC is willing to send LSP State Reports whenever
LSP parameters or operational status changes. LSP parameters or operational status changes.
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 Capability TLV in their respective OPEN message. If the PCEP Speaker
Speakers support the extensions of this draft but did not advertise on the PCC supports the extensions of this draft but did not
this capability, then a PCErr with error-type 19 (Invalid Operation), advertise this capability, then upon receipt of PCUpd message from
error-value 2 (Attempted LSP Update Request if active stateful PCE the PCE, it SHOULD generate a PCErr with error-type 19 (Invalid
capability was not advertised)(see Section 8.4) will be generated and Operation), error-value 2 (Attempted LSP Update Request if active
the PCEP session will be terminated. stateful PCE capability was not advertised)(see Section 8.4) and it
will terminate the PCEP session. If the PCEP Speaker on the PCE
supports the extensions of this draft but did not advertise this
capability, then upon receipt of a PCRpt message from the PCC, it
SHOULD generate a PCErr with error-type 19 (Invalid Operation),
error-value 5 (Attempted LSP State Report if active stateful PCE
capability was not advertised) (see Section 8.4) and it will
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
only be used if both PCEP Speakers set the LSP-UPDATE Flag in the only be used if both PCEP Speakers set the LSP-UPDATE Flag in the
"Stateful Capability" TLV to 'Updates Allowed (U Flag = 1)'. If this "Stateful Capability" TLV to 'Updates Allowed (U Flag = 1)'. If this
is not the case and LSP delegation or LSP update operations are is not the case and LSP delegation or LSP update operations are
attempted, then a PCErr with error-type 19 (Invalid Operation) and attempted, then a PCErr with error-type 19 (Invalid Operation) and
error-value 1 (Attempted LSP Update Request for a non-delegated error-value 1 (Attempted LSP Update Request for a non-delegated
LSP).(see Section 8.4) SHOULD be generated. Note that even if the LSP).(see Section 8.4) SHOULD be generated. Note that even if the
update capability has not been advertised, a PCE can still receive update capability has not been advertised, a PCE can still receive
LSP Status Reports from a PCC and build and maintain an up to date LSP Status Reports from a PCC and build and maintain an up to date
skipping to change at page 17, line 48 skipping to change at page 16, line 48
Interval timer expires, LSP delegations to the PCE remain intact. Interval timer expires, LSP delegations to the PCE remain intact.
Likewise, when a PCC's PCEP session with a PCE terminates Likewise, when a PCC's PCEP session with a PCE terminates
unexpectedly, the PCC MUST wait for the State Timeout Interval before unexpectedly, the PCC MUST wait for the State Timeout Interval before
flushing any LSP state associated with that PCE. Note that the State flushing any LSP state associated with that PCE. Note that the State
Timeout Interval timer may expire before the PCC has redelegated the Timeout Interval timer may expire before the PCC has redelegated the
LSPs to another PCE, for example if a PCC is not connected to any LSPs to another PCE, for example if a PCC is not connected to any
active stateful PCE or if no connected active stateful PCE accepts active stateful PCE or if no connected active stateful PCE accepts
the delegation. In this case, the PCC SHALL flush any LSP state set the delegation. In this case, the PCC SHALL flush any LSP state set
by the PCE upon expiration of the State Timeout Interval and revert by the PCE upon expiration of the State Timeout Interval and revert
to operator-defined default parameters. This operation SHOULD be to operator-defined default parameters or behaviors. This operation
done in a make-before-break fashion. SHOULD be done in a make-before-break fashion.
The State Timeout Interval SHOULD be greater than or equal to the The State Timeout Interval SHOULD be greater than or equal to the
Redelegation Timeout Interval and MAY be set to infinity (meaning Redelegation Timeout Interval and MAY be set to infinity (meaning
that until the PCC specifically takes action to change the parameters that until the PCC specifically takes action to change the parameters
set by the PCE, they will remain intact). set by the PCE, they will remain intact).
5.5.3. Returning a Delegation 5.5.3. Returning a Delegation
A PCE that no longer wishes to update an LSP's parameters SHOULD A PCE that no longer wishes to update an LSP's parameters SHOULD
return the LSP delegation back to the PCC by sending an empty LSP return the LSP delegation back to the PCC by sending an empty LSP
skipping to change at page 28, line 47 skipping to change at page 27, line 47
Unassigned bits are considered reserved. They MUST be set to 0 on Unassigned bits are considered reserved. They MUST be set to 0 on
transmission and MUST be ignored on receipt. transmission and MUST be ignored on receipt.
Advertisement of the stateful PCE capability implies support of LSPs Advertisement of the stateful PCE capability implies support of LSPs
that are signaled via RSVP, as well as the objects, TLVs and that are signaled via RSVP, as well as the objects, TLVs and
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, PCNtf and within PCUpd messages and MAY be carried within PCRpt and PCErr
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 [TBD].
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
skipping to change at page 29, line 24 skipping to change at page 28, line 24
| SRP-ID-number | | SRP-ID-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Optional TLVs // // Optional TLVs //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: The SRP Object format Figure 10: The SRP Object format
The SRP object body has a variable length and may contain additional The SRP object body has a variable length and may contain additional
TLVs. The SYMBOLIC-PATH-NAME TLV MAY be included as one of the TLVs.
optional TLVs.
Flags (32 bits): None defined yet. Flags (32 bits): None defined yet.
SRP-ID-number (32 bits): The SRP-ID-number value in the scope of the SRP-ID-number (32 bits): The SRP-ID-number value in the scope of the
current PCEP session uniquely identify the operation that the PCE has current PCEP session uniquely identify the operation that the PCE has
requested the PCC to perform on a given LSP. The SRP-ID-number is requested the PCC to perform on a given LSP. The SRP-ID-number is
incremented each time a new request is sent to the PCC, and may wrap incremented each time a new request is sent to the PCC, and may wrap
around. around.
The values 0x00000000 and 0xFFFFFFFF are reserved. The values 0x00000000 and 0xFFFFFFFF are reserved.
skipping to change at page 30, line 24 skipping to change at page 29, line 24
LSP Object-Class is [TBD]. LSP Object-Class is [TBD].
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 | Flags | O|A|R|S|D| | PLSP-ID | Flag | O|A|R|S|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// TLVs // // TLVs //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: The LSP Object format Figure 11: The LSP Object format
PLSP-ID (20 bits): A PCEP-specific identifier for the LSP. A PCC PLSP-ID (20 bits): A PCEP-specific identifier for the LSP. A PCC
creates a unique PLSP-ID for each LSP that is constant for the life creates a unique PLSP-ID for each LSP that is constant for the
time of a PCEP session. The mapping of the Symbolic Path Name to lifetime of a PCEP session. The PCC will advertise the same PLSP-ID
PLSP-ID is communicated to the PCE by sending a PCRpt message on all PCEP sessions it maintains at a given times. The mapping of
containing the SYMBOLIC-PATH-NAME TLV. All subsequent PCEP messages the Symbolic Path Name to PLSP-ID is communicated to the PCE by
then address the LSP by the PLSP-ID. The values of 0 and 0xFFFFF are sending a PCRpt message containing the SYMBOLIC-PATH-NAME TLV. All
reserved. Note that the PLSP-ID is a value that is constant for the subsequent PCEP messages then address the LSP by the PLSP-ID. The
life time of the PCEP session, during which time for an RSVP-signaled values of 0 and 0xFFFFF are reserved. Note that the PLSP-ID is a
LSP there might be a different RSVP identifiers (LSP-id, tunnel-id) value that is constant for the lifetime of the PCEP session, during
allocated it. which time for an RSVP-signaled LSP there might be a different RSVP
identifiers (LSP-id, tunnel-id) allocated it.
Flags (12 bits): Flags (12 bits):
D (Delegate - 1 bit): on a PCRpt message, the D Flag set to 1 D (Delegate - 1 bit): on a PCRpt message, the D Flag set to 1
indicates that the PCC is delegating the LSP to the PCE. On a indicates that the PCC is delegating the LSP to the PCE. On a
PCUpd message, the D flag set to 1 indicates that the PCE is PCUpd message, the D flag set to 1 indicates that the PCE is
confirming the LSP Delegation. To keep an LSP delegated to the confirming the LSP Delegation. To keep an LSP delegated to the
PCE, the PCC must set the D flag to 1 on each PCRpt message for PCE, the PCC must set the D flag to 1 on each PCRpt message for
the duration of the delegation - the first PCRpt with the D flag the duration of the delegation - the first PCRpt with the D flag
set to 0 revokes the delegation. To keep the delegation, the PCE set to 0 revokes the delegation. To keep the delegation, the PCE
skipping to change at page 34, line 48 skipping to change at page 34, line 37
operator in a PCC's configuration. If the operator does not specify operator in a PCC's configuration. If the operator does not specify
a unique symbolic name for a path, the PCC MUST auto-generate one. a unique symbolic name for a path, the PCC MUST auto-generate one.
The SYMBOLIC-PATH-NAME TLV MUST be included in the LSP State Report The SYMBOLIC-PATH-NAME TLV MUST be included in the LSP State Report
when during a given PCEP session an LSP is first reported to a PCE. when during a given PCEP session an LSP is first reported to a PCE.
A PCC sends to a PCE the first LSP State Report either during State A PCC sends to a PCE the first LSP State Report either during State
Synchronization, or when a new LSP is configured at the PCC. The Synchronization, or when a new LSP is configured at the PCC. The
symbolic path name MAY be included in subsequent LSP State Reports symbolic path name MAY be included in subsequent LSP State Reports
for the LSP. for the LSP.
The SYMBOLIC-PATH-NAME TLV MAY appear as a TLV in both the LSP Object The SYMBOLIC-PATH-NAME TLV MAY appear as a TLV in the LSP Object
and the LSPA Object.
The format of the SYMBOLIC-PATH-NAME TLV is shown in the following The format of the SYMBOLIC-PATH-NAME TLV is shown in the following
figure: 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 (variable) | | Type=[TBD] | Length (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
skipping to change at page 36, line 45 skipping to change at page 36, line 28
+ 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 [TBD] and it has a variable length. The value
contains the RSVP ERROR_SPEC or USER_ERROR_SPEC object, including the contains the RSVP ERROR_SPEC or USER_ERROR_SPEC object, including the
object header. object header.
7.4. Optional TLVs for the LSPA Object
TLVs that may be included in the LSPA Object are described in the
following sections and in separate technology-specific documents.
7.4.1. Symbolic Path Name TLV
See section Section 7.3.2.
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 38, line 39 skipping to change at page 38, line 18
Error-value=2: Attempted LSP Update Request if active Error-value=2: Attempted LSP Update Request if active
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
stateful PCE capability was not
advertised.
20 LSP State synchronization error. 20 LSP State synchronization error.
Error-value=1: A PCE indicates to a PCC that it can Error-value=1: A PCE indicates to a PCC that it can
not process (an otherwise valid) LSP not process (an otherwise valid) LSP
State Report. The PCEP-ERROR Object is State Report. The PCEP-ERROR Object is
followed by the LSP Object that followed by the LSP Object that
identifies the LSP. identifies the LSP.
Error-value=5: A PCC indicates to a PCE that it can Error-value=5: A PCC indicates to a PCE that it can
not complete the state synchronization, not complete the state synchronization,
8.5. PCEP TLV Type Indicators 8.5. PCEP TLV Type Indicators
skipping to change at page 44, line 19 skipping to change at page 44, line 4
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] [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-08 (work in GMPLS", draft-ietf-pce-gmpls-pcep-extensions-09 (work in
progress), July 2013. 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 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic (GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
May 2005.
[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 26 skipping to change at page 45, line 7
12.2. Informative References 12.2. Informative References
[I-D.ietf-pce-stateful-pce-app] [I-D.ietf-pce-stateful-pce-app]
Zhang, X. and I. Minei, "Applicability of Stateful Path Zhang, X. and I. Minei, "Applicability of Stateful Path
Computation Element (PCE)", Computation Element (PCE)",
draft-ietf-pce-stateful-pce-app-01 (work in progress), draft-ietf-pce-stateful-pce-app-01 (work in progress),
September 2013. September 2013.
[I-D.minei-pce-stateful-sync-optimizations] [I-D.minei-pce-stateful-sync-optimizations]
Crabbe, E., Medved, J., Minei, I., Varga, R., Zhang, X., Crabbe, E., Medved, J., Minei, I., Varga, R., Zhang, X.,
and D. Dhody, "Optimizations of State Synchronization and D. Dhody, "Optimizations of Label Switched Path State
Procedures for Stateful PCE", Synchronization Procedures for a Stateful PCE",
draft-minei-pce-stateful-sync-optimizations-00 (work in draft-minei-pce-stateful-sync-optimizations-01 (work in
progress), October 2013. progress), December 2013.
[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", for Stateful PCE Discovery",
draft-sivabalan-pce-disco-stateful-02 (work in progress), draft-sivabalan-pce-disco-stateful-03 (work in progress),
July 2013. 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 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", pre- and throughput objectives in traffic engineering",
print, 2011. INFOCOM, 2012 Proceedings IEEE Page(s): 846-854, 2012.
[NET-REC] Vasseur, JP., Pickavet, M., and P. Demeester, "Network [NET-REC] Vasseur, JP., Pickavet, M., and P. Demeester, "Network
Recovery: Protection and Restoration of Optical, SONET- Recovery: Protection and Restoration of Optical, SONET-
SDH, IP, and MPLS", The Morgan Kaufmann Series in SDH, IP, and MPLS", The Morgan Kaufmann Series in
Networking, June 2004. 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.
skipping to change at page 47, line 4 skipping to change at page 46, line 26
Authors' Addresses Authors' Addresses
Edward Crabbe Edward Crabbe
Google, Inc. Google, Inc.
1600 Amphitheatre Parkway 1600 Amphitheatre Parkway
Mountain View, CA 94043 Mountain View, CA 94043
US US
Email: edc@google.com Email: edc@google.com
Jan Medved Jan Medved
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Dr. 170 West Tasman Dr.
San Jose, CA 95134 San Jose, CA 95134
US US
Email: jmedved@cisco.com Email: jmedved@cisco.com
Ina Minei Ina Minei
Juniper Networks, Inc. Google, Inc.
1194 N. Mathilda Ave. 1600 Amphitheatre Parkway
Sunnyvale, CA 94089 Mountain View, CA 94043
US US
Email: ina@juniper.net Email: inaminei@google.com
Robert Varga Robert Varga
Pantheon Technologies SRO Pantheon Technologies SRO
Mlynske Nivy 56 Mlynske Nivy 56
Bratislava 821 05 Bratislava 821 05
Slovakia Slovakia
Email: robert.varga@pantheon.sk Email: robert.varga@pantheon.sk
 End of changes. 40 change blocks. 
134 lines changed or deleted 127 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/