draft-ietf-pce-stateful-pce-00.txt   draft-ietf-pce-stateful-pce-01.txt 
Network Working Group E. Crabbe Network 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: August 31, 2012 Cisco Systems, Inc. Expires: January 16, 2013 Cisco Systems, Inc.
R. Varga R. Varga
Pantheon Technologies LLC Pantheon Technologies SRO
I. Minei I. Minei
Juniper Networks, Inc. Juniper Networks, Inc.
February 28, 2012 July 15, 2012
PCEP Extensions for Stateful PCE PCEP Extensions for Stateful PCE
draft-ietf-pce-stateful-pce-00 draft-ietf-pce-stateful-pce-01
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
synchronization or PCE control of timing and sequence of path synchronization or PCE control of timing and sequence of path
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 August 31, 2012. This Internet-Draft will expire on January 16, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 11 skipping to change at page 3, line 11
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 . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Motivation and Objectives . . . . . . . . . . . . . . . . . . 6 3. Motivation and Objectives . . . . . . . . . . . . . . . . . . 6
3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.1. Background . . . . . . . . . . . . . . . . . . . . . . 6 3.1.1. Background . . . . . . . . . . . . . . . . . . . . . . 7
3.1.2. Why a Stateful PCE? . . . . . . . . . . . . . . . . . 7 3.1.2. Why a Stateful PCE? . . . . . . . . . . . . . . . . . 7
3.1.3. Protocol vs. Configuration . . . . . . . . . . . . . . 14 3.1.3. Protocol vs. Configuration . . . . . . . . . . . . . . 14
3.2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . 14 3.2. Objectives . . . . . . . . . . . . . . . . . . . . . . . . 15
4. New Functions to Support Stateful PCEs . . . . . . . . . . . . 15 4. New Functions to Support Stateful PCEs . . . . . . . . . . . . 16
5. Architectural Overview of Protocol Extensions . . . . . . . . 16 5. Architectural Overview of Protocol Extensions . . . . . . . . 16
5.1. LSP State Ownership . . . . . . . . . . . . . . . . . . . 16 5.1. LSP State Ownership . . . . . . . . . . . . . . . . . . . 16
5.2. New Messages . . . . . . . . . . . . . . . . . . . . . . . 16 5.2. New Messages . . . . . . . . . . . . . . . . . . . . . . . 17
5.3. Capability Negotiation . . . . . . . . . . . . . . . . . . 17 5.3. Capability Negotiation . . . . . . . . . . . . . . . . . . 18
5.4. State Synchronization . . . . . . . . . . . . . . . . . . 18 5.4. State Synchronization . . . . . . . . . . . . . . . . . . 18
5.4.1. State Synchronization Avoidance . . . . . . . . . . . 20 5.4.1. State Synchronization Avoidance . . . . . . . . . . . 20
5.5. LSP Delegation . . . . . . . . . . . . . . . . . . . . . . 23 5.5. LSP Delegation . . . . . . . . . . . . . . . . . . . . . . 24
5.5.1. Delegating an LSP . . . . . . . . . . . . . . . . . . 24 5.5.1. Delegating an LSP . . . . . . . . . . . . . . . . . . 25
5.5.2. Revoking a Delegation . . . . . . . . . . . . . . . . 24 5.5.2. Revoking a Delegation . . . . . . . . . . . . . . . . 25
5.5.3. Returning a Delegation . . . . . . . . . . . . . . . . 25 5.5.3. Returning a Delegation . . . . . . . . . . . . . . . . 26
5.5.4. Redundant Stateful PCEs . . . . . . . . . . . . . . . 26 5.5.4. Redundant Stateful PCEs . . . . . . . . . . . . . . . 27
5.6. LSP Operations . . . . . . . . . . . . . . . . . . . . . . 26 5.6. LSP Operations . . . . . . . . . . . . . . . . . . . . . . 27
5.6.1. Passive Stateful PCE Path Computation 5.6.1. Passive Stateful PCE Path Computation
Request/Response . . . . . . . . . . . . . . . . . . . 26 Request/Response . . . . . . . . . . . . . . . . . . . 28
5.6.2. Active Stateful PCE LSP Update . . . . . . . . . . . . 28 5.6.2. Active Stateful PCE LSP Update . . . . . . . . . . . . 29
5.7. LSP Protection . . . . . . . . . . . . . . . . . . . . . . 29 5.7. LSP Protection . . . . . . . . . . . . . . . . . . . . . . 30
5.8. Transport . . . . . . . . . . . . . . . . . . . . . . . . 29 5.8. Transport . . . . . . . . . . . . . . . . . . . . . . . . 31
6. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 29 6. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 31
6.1. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 30 6.1. The PCRpt Message . . . . . . . . . . . . . . . . . . . . 31
6.2. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 31 6.2. The PCUpd Message . . . . . . . . . . . . . . . . . . . . 32
7. Object Formats . . . . . . . . . . . . . . . . . . . . . . . . 32 6.3. The PCReq Message . . . . . . . . . . . . . . . . . . . . 34
7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 32 6.4. The PCRep Message . . . . . . . . . . . . . . . . . . . . 35
7.1.1. Stateful PCE Capability TLV . . . . . . . . . . . . . 32 7. Object Formats . . . . . . . . . . . . . . . . . . . . . . . . 35
7.1.2. LSP State Database Version TLV . . . . . . . . . . . . 33 7.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 35
7.2. LSP Object . . . . . . . . . . . . . . . . . . . . . . . . 34 7.1.1. Stateful PCE Capability TLV . . . . . . . . . . . . . 36
7.2.1. The LSP Symbolic Name TLV . . . . . . . . . . . . . . 35 7.1.2. LSP State Database Version TLV . . . . . . . . . . . . 36
7.2.2. LSP Identifiers TLVs . . . . . . . . . . . . . . . . . 36 7.1.3. Node Identifier TLV . . . . . . . . . . . . . . . . . 37
7.2.3. LSP Update Error Code TLV . . . . . . . . . . . . . . 39 7.2. LSP Object . . . . . . . . . . . . . . . . . . . . . . . . 38
7.2.4. RSVP ERROR_SPEC TLVs . . . . . . . . . . . . . . . . . 39 7.2.1. The LSP Symbolic Name TLV . . . . . . . . . . . . . . 39
7.2.5. LSP State Database Version TLV . . . . . . . . . . . . 40 7.2.2. LSP Identifiers TLVs . . . . . . . . . . . . . . . . . 40
7.2.6. Delegation Parameters TLVs . . . . . . . . . . . . . . 41 7.2.3. LSP Update Error Code TLV . . . . . . . . . . . . . . 42
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 7.2.4. RSVP ERROR_SPEC TLVs . . . . . . . . . . . . . . . . . 42
8.1. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 41 7.2.5. LSP State Database Version TLV . . . . . . . . . . . . 43
8.2. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . 41 7.2.6. Delegation Parameters TLVs . . . . . . . . . . . . . . 44
8.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . . 42 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
8.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 42 8.1. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 44
8.5. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 43 8.2. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . 44
8.6. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 43 8.3. LSP Object . . . . . . . . . . . . . . . . . . . . . . . . 45
8.7. LSP-UPDATE-ERROR-CODE TLV . . . . . . . . . . . . . . . . 44 8.4. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 45
9. Manageability Considerations . . . . . . . . . . . . . . . . . 44 8.5. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . . 46
9.1. Control Function and Policy . . . . . . . . . . . . . . . 44 8.6. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 46
9.2. Information and Data Models . . . . . . . . . . . . . . . 45 8.7. LSP-UPDATE-ERROR-CODE TLV . . . . . . . . . . . . . . . . 47
9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 45 9. Manageability Considerations . . . . . . . . . . . . . . . . . 47
9.4. Verifying Correct Operation . . . . . . . . . . . . . . . 45 9.1. Control Function and Policy . . . . . . . . . . . . . . . 47
9.2. Information and Data Models . . . . . . . . . . . . . . . 48
9.3. Liveness Detection and Monitoring . . . . . . . . . . . . 48
9.4. Verifying Correct Operation . . . . . . . . . . . . . . . 48
9.5. Requirements on Other Protocols and Functional 9.5. Requirements on Other Protocols and Functional
Components . . . . . . . . . . . . . . . . . . . . . . . . 46 Components . . . . . . . . . . . . . . . . . . . . . . . . 49
9.6. Impact on Network Operation . . . . . . . . . . . . . . . 46 9.6. Impact on Network Operation . . . . . . . . . . . . . . . 49
10. Security Considerations . . . . . . . . . . . . . . . . . . . 46 10. Security Considerations . . . . . . . . . . . . . . . . . . . 49
10.1. Vulnerability . . . . . . . . . . . . . . . . . . . . . . 46 10.1. Vulnerability . . . . . . . . . . . . . . . . . . . . . . 49
10.2. LSP State Snooping . . . . . . . . . . . . . . . . . . . . 47 10.2. LSP State Snooping . . . . . . . . . . . . . . . . . . . . 50
10.3. Malicious PCE . . . . . . . . . . . . . . . . . . . . . . 47 10.3. Malicious PCE . . . . . . . . . . . . . . . . . . . . . . 50
10.4. Malicious PCC . . . . . . . . . . . . . . . . . . . . . . 48 10.4. Malicious PCC . . . . . . . . . . . . . . . . . . . . . . 51
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 48 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 51
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51
12.1. Normative References . . . . . . . . . . . . . . . . . . . 48 12.1. Normative References . . . . . . . . . . . . . . . . . . . 51
12.2. Informative References . . . . . . . . . . . . . . . . . . 49 12.2. Informative References . . . . . . . . . . . . . . . . . . 52
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 53
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 Control Element (PCE), or between PCE and PCE, (PCC) and a Path Control Element (PCE), or between PCE and PCE,
enabling computation of Multiprotocol Label Switching (MPLS) for enabling computation of Multiprotocol Label Switching (MPLS) for
Traffic Engineering Label Switched Path (TE LSP) characteristics Traffic Engineering Label Switched Path (TE LSP) characteristics
This document specifies a set of extensions to PCEP to enable This document specifies a set of extensions to PCEP to enable
skipping to change at page 6, line 33 skipping to change at page 6, line 33
by some downstream mode, the head-end LSP is notified by means of by some downstream mode, the head-end LSP is notified by means of
RSVP. Upon receiving the notification, the headend Label RSVP. Upon receiving the notification, the headend Label
Switching Router (LSR) recomputes the path and signals the LSP Switching Router (LSR) recomputes the path and signals the LSP
along an alternate path. [NET-REC] along an alternate path. [NET-REC]
MPLS TE Global Path Protection: once an LSP failure is detected by MPLS TE Global Path Protection: once an LSP failure is detected by
some downstream mode, the head-end LSP is notified by means of some downstream mode, the head-end LSP is notified by means of
RSVP. Upon receiving the notification, the headend LSR reroutes RSVP. Upon receiving the notification, the headend LSR reroutes
traffic using a pre-signaled backup (secondary) LSP. [NET-REC]. traffic using a pre-signaled backup (secondary) LSP. [NET-REC].
Revocation: an operation performed by a PCC on a previously
delegated LSP. Revocation clears the LSP's PCE specific state on
the PCC and, if a PCEP session with the PCE the LSP was delegated
to exists in the UP state, also generates a revocation message to
the PCE.
Within this document, when describing PCE-PCE communications, the Within this document, when describing PCE-PCE communications, the
requesting PCE fills the role of a PCC. This provides a saving in requesting PCE fills the role of a PCC. This provides a saving in
documentation without loss of function. documentation without loss of function.
The message formats in this document are specified using Routing The message formats in this document are specified using Routing
Backus-Naur Format (RBNF) encoding as specified in [RFC5511]. Backus-Naur Format (RBNF) encoding as specified in [RFC5511].
3. Motivation and Objectives 3. Motivation and Objectives
3.1. Motivation 3.1. Motivation
skipping to change at page 7, line 43 skipping to change at page 7, line 51
o Any reliable synchronization mechanism would result in significant o Any reliable synchronization mechanism would result in significant
control plane overhead control plane overhead
o Out-of-band ted synchronization would be complex and prone to race o Out-of-band ted synchronization would be complex and prone to race
conditions conditions
o Path calculations incorporating total network state would be o Path calculations incorporating total network state would be
highly complex highly complex
In general, stress on the MPLS TE control plane will be directly In general, stress on the MPLS TE control plane will be directly
proportional to the size of the system being controlled and the and proportional to the size of the system being controlled and the
the tightness of the control loop, and indirectly proportional to the tightness of the control loop, and indirectly proportional to the
amount of over-provisioning in terms of both network capacity and amount of over-provisioning in terms of both network capacity and
reservation overhead. reservation overhead.
Despite these concerns in terms of implementation complexity and Despite these concerns in terms of implementation complexity and
scalability, several TE algorithms exist today that have been scalability, several TE algorithms exist today that have been
demonstrated to be extremely effective in large TE systems, providing demonstrated to be extremely effective in large TE systems, providing
both rapid convergence and significant benefits in terms of both rapid convergence and significant benefits in terms of
optimality of resource usage [MXMN-TE]. All of these systems share optimality of resource usage [MXMN-TE]. All of these systems share
at least two common characteristics: the requirement for both global at least two common characteristics: the requirement for both global
visibility of a flow (or in this case, a TE LSP) state and for visibility of a flow (or in this case, a TE LSP) state and for
skipping to change at page 15, line 10 skipping to change at page 15, line 38
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 single LSP is under the control a single PCE at
any given time. A PCC may revoke this delegation at any point any given time. A PCC may revoke this delegation at any time
during the lifetime of the PCEP session. A PCE may return this during the lifetime of the LSP. If LSP delegation is revoked
delegation at any point during the lifetime of the PCEP session. 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
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 Allow a PCE to specify protection / restoration settings for all o Allow a PCE to specify protection / restoration settings for all
LSPs that have been delegated to it. LSPs that have been delegated to it.
o Enable uninterrupted operation of PCC's LSPs in the event PCE o Enable uninterrupted operation of PCC's LSPs in the event PCE
failure or while control of LSPs is being transferred between failure or while control of LSPs is being transferred between
PCEs. PCEs.
skipping to change at page 16, line 45 skipping to change at page 17, line 26
5.2. New Messages 5.2. New Messages
In this document, we define the following new PCEP messages: In this document, we define the following new PCEP messages:
Path Computation State Report (PCRpt): a PCEP message sent by a PCC Path Computation State Report (PCRpt): a PCEP message sent by a PCC
to a PCE to report the status of one or more LSPs. Each LSP to a PCE to report the status of one or more LSPs. Each LSP
Status Report in a PCRpt message can contain the actual LSP's Status Report in a PCRpt message can contain the actual LSP's
path,bandwidth, operational and administrative status, etc. An path,bandwidth, operational and administrative status, etc. An
LSP Status Report carried on a PCRpt message is also used in LSP Status Report carried on a PCRpt message is also used in
delegation or revocation of control of an LSP to/from a PCE. The delegation or revocation of control of an LSP to/from a PCE. The
PCRep message is described in Section 6.1. PCRpt message is described in Section 6.1.
Path Computation Update Request (PCUpd): a PCEP message sent by a Path Computation Update Request (PCUpd): a PCEP message sent by a
PCE to a PCC to update LSP parameters, on one or more LSPs. Each PCE to a PCC to update LSP parameters, on one or more LSPs. Each
LSP Update Request on a PCUpd message MUST contain all LSP LSP Update Request on a PCUpd message MUST contain all LSP
parameters that a PCE wishes to set for a given LSP. An LSP parameters that a PCE wishes to set for a given LSP. An LSP
Update Request carried on a PCUpd message is also used to return Update Request carried on a PCUpd message is also used to return
LSP delegations if at any point PCE no longer desires control of LSP delegations if at any point PCE no longer desires control of
an LSP. The PCUpd message is described in Section 6.2. an LSP. The PCUpd message is described in Section 6.2.
The new functions defined in Section 4 are mapped onto the new The new functions defined in Section 4 are mapped onto the new
skipping to change at page 17, line 45 skipping to change at page 18, line 24
parameter updates. parameter updates.
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 MAY only be used if The PCEP protocol extensions for stateful PCEs MUST not be used if
both sides have included the Stateful PCE Capability TLV in their one or both PCEP Speakers have not included the Stateful PCE
respective OPEN messages, otherwise a PCErr with code "Stateful PCE Capability TLV in their respective OPEN message, otherwise a PCErr
capability not negotiated" (see Section 8.4) will be generated and with code "Stateful PCE capability not negotiated" (see Section 8.4)
the PCEP session will be terminated. will be generated and the PCEP session will be terminated.
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)', "Stateful Capability" TLV to 'Updates Allowed (U Flag = 1)',
otherwise a PCErr with code "Delegation not negotiated" (see otherwise a PCErr with code "Delegation not negotiated" (see
Section 8.4) will be generated. Note that even if the update Section 8.4) will be generated. Note that even if the update
capability has not been negotiated, a PCE can still receive LSP capability has not been negotiated, a PCE can still receive LSP
Status Reports from a PCC and build and maintain an up to date view Status Reports from a PCC and build and maintain an up to date view
of the state of the PCC's LSPs. of the state of the PCC's LSPs.
skipping to change at page 18, line 39 skipping to change at page 19, line 18
a PCE before State Synchronization is complete. This is to allow the a PCE before State Synchronization is complete. This is to allow the
PCE to get the best possible view of the network before it starts PCE to get the best possible view of the network before it starts
computing new paths. computing new paths.
If the PCC encounters a problem which prevents it from completing the If the PCC encounters a problem which prevents it from completing the
state transfer, it MUST send a PCErr message to the PCE and terminate state transfer, it MUST send a PCErr message to the PCE and terminate
the session using the PCEP session termination procedure. the session using the PCEP session termination procedure.
The PCE does not send positive acknowledgements for properly received The PCE does not send positive acknowledgements for properly received
synchronization messages. It MUST respond with a PCErr message synchronization messages. It MUST respond with a PCErr message
indicating "PCRpt error" (see ) if it encounters a problem with the indicating "PCRpt error" (see Section 8.4) if it encounters a problem
LSP State Report it received from the PCC. Either the PCE or the PCC with the LSP State Report it received from the PCC. Either the PCE
MAY terminate the session if the PCE encounters a problem during the or the PCC MAY terminate the session if the PCE encounters a problem
synchronization. during the synchronization.
The successful State Synchronization sequence is shown in Figure 3. The successful State Synchronization sequence is shown in Figure 3.
+-+-+ +-+-+ +-+-+ +-+-+
|PCC| |PCE| |PCC| |PCE|
+-+-+ +-+-+ +-+-+ +-+-+
| | | |
|-----PCRpt, SYNC=1----->| (Sync start) |-----PCRpt, SYNC=1----->| (Sync start)
| | | |
|-----PCRpt, SYNC=1----->| |-----PCRpt, SYNC=1----->|
skipping to change at page 20, line 39 skipping to change at page 21, line 15
VERSION TLV as an optional TLV in the LSP Object on each LSP State VERSION TLV as an optional TLV in the LSP Object on each LSP State
Report. The LSP-DB-VERSION TLV contains a PCC's LSP State Database Report. The LSP-DB-VERSION TLV contains a PCC's LSP State Database
version, which is incremented each time a change is made to the PCC's version, which is incremented each time a change is made to the PCC's
local LSP State Database. The LSP State Database version is an local LSP State Database. The LSP State Database version is an
unsigned 64-bit value that MUST be incremented by 1 for each unsigned 64-bit value that MUST be incremented by 1 for each
successive change in the LSP state database. The LSP State Database successive change in the LSP state database. The LSP State Database
version MUST start at 1 and may wrap around. Values 0 and version MUST start at 1 and may wrap around. Values 0 and
0xFFFFFFFFFFFFFFF are reserved. 0xFFFFFFFFFFFFFFF are reserved.
State Synchronization Avoidance is negotiated on a PCEP session State Synchronization Avoidance is negotiated on a PCEP session
during session startup. during session startup. To make sure that a PCEP peer can recognize
a previously connected peer even if its IP address changed, each PCEP
peer includes the NODE_IDENTIFIER TLV in the OPEN message.
If both PCEP speakers set the INCLUDE-DB-VERSION Flag in the OPEN If both PCEP speakers set the INCLUDE-DB-VERSION Flag in the OPEN
object's STATEFUL-PCE-CAPABILITY TLV to 1, the PCC will include the object's STATEFUL-PCE-CAPABILITY TLV to 1, the PCC will include the
LSP-DB-VERSION TLV in each LSP Object. The TLV will contain the LSP-DB-VERSION TLV in each LSP Object. The TLV will contain the
PCC's latest LSP State Database version. PCC's latest LSP State Database version.
If a PCE's LSP State Database survived the restart of a PCEP session, If a PCE's LSP State Database survived the restart of a PCEP session,
the PCE will include the LSP-DB-VERSION TLV in its OPEN object, and the PCE will include the LSP-DB-VERSION TLV in its OPEN object, and
the TLV will contain the last LSP State Database version received on the TLV will contain the last LSP State Database version received on
an LSP State Update from the PCC in a previous PCEP session. If a an LSP State Update from the PCC in a previous PCEP session. If a
skipping to change at page 21, line 27 skipping to change at page 22, line 9
Note that a PCE MAY force State Synchronization by not including the Note that a PCE MAY force State Synchronization by not including the
LSP-DB-VERSION TLV in its OPEN object. LSP-DB-VERSION TLV in its OPEN object.
Figure 6 shows an example sequence where State Synchronization is Figure 6 shows an example sequence where State Synchronization is
skipped. skipped.
+-+-+ +-+-+ +-+-+ +-+-+
|PCC| |PCE| |PCC| |PCE|
+-+-+ +-+-+ +-+-+ +-+-+
| | | |
|-PCOpen-, | |--Open--, |
| DBv=42 \ ,--PCOpen-| | DBv=42 \ ,---Open--|
| IDB=1 \ / DBv=42 | | IDB=1 \ / DBv=42 |
| \/ IDB=1 | | \/ IDB=1 |
| /\ | | /\ |
| / `-------->| (OK to skip sync) | / `-------->| (OK to skip sync)
(Skip sync) |<--------` | (Skip sync) |<--------` |
| . | | . |
| . | | . |
| . | | . |
| | | |
|--PCRpt,DBv=43,SYNC=0-->| (Regular |--PCRpt,DBv=43,SYNC=0-->| (Regular
skipping to change at page 22, line 9 skipping to change at page 23, line 9
Figure 7 shows an example sequence where State Synchronization is Figure 7 shows an example sequence where State Synchronization is
performed due to LSP State Database version mismatch during the PCEP performed due to LSP State Database version mismatch during the PCEP
session setup. Note that the same State Synchronization sequence session setup. Note that the same State Synchronization sequence
would happen if either the PCE or the PCE would not include the LSP- would happen if either the PCE or the PCE would not include the LSP-
DB-VERSION TLV in their respective Open messages. DB-VERSION TLV in their respective Open messages.
+-+-+ +-+-+ +-+-+ +-+-+
|PCC| |PCE| |PCC| |PCE|
+-+-+ +-+-+ +-+-+ +-+-+
| | | |
|-PCOpen-, | |--Open--, |
| DBv=46 \ ,--PCOpen-| | DBv=46 \ ,---Open--|
| IDB=1 \ / DBv=42 | | IDB=1 \ / DBv=42 |
| \/ IDB=1 | | \/ IDB=1 |
| /\ | | /\ |
| / `-------->| (Expect sync) | / `-------->| (Expect sync)
(Do sync) |<--------` | (Purge LSP State) (Do sync) |<--------` | (Purge LSP State)
| | | |
|--PCRpt,DBv=46,SYNC=1-->| (Sync start) |--PCRpt,DBv=46,SYNC=1-->| (Sync start)
| . | | . |
| . | | . |
| . | | . |
skipping to change at page 23, line 9 skipping to change at page 24, line 9
skipped, but because one or both PCEP Speakers set the INCLUDE-DB- skipped, but because one or both PCEP Speakers set the INCLUDE-DB-
VERSION Flag to 0, the PCC does not send LSP-DB-VERSION TLVs to the VERSION Flag to 0, the PCC does not send LSP-DB-VERSION TLVs to the
PCE. If the current PCEP session restarts, the PCEP Speakers will PCE. If the current PCEP session restarts, the PCEP Speakers will
have to perform State Synchronization, since the PCE will not know have to perform State Synchronization, since the PCE will not know
the PCC's latest LSP State Database version. the PCC's latest LSP State Database version.
+-+-+ +-+-+ +-+-+ +-+-+
|PCC| |PCE| |PCC| |PCE|
+-+-+ +-+-+ +-+-+ +-+-+
| | | |
|-PCOpen-, | |--Open--, |
| DBv=42 \ ,--PCOpen-| | DBv=42 \ ,---Open--|
| IDB=0 \ / DBv=42 | | IDB=0 \ / DBv=42 |
| \/ IDB=0 | | \/ IDB=0 |
| /\ | | /\ |
| / `-------->| (OK to skip sync) | / `-------->| (OK to skip sync)
(Skip sync) |<--------` | (Skip sync) |<--------` |
| . | | . |
| . | | . |
| . | | . |
|------PCRpt,SYNC=0----->| (Regular |------PCRpt,SYNC=0----->| (Regular
| | LSP State Update) | | LSP State Update)
skipping to change at page 24, line 41 skipping to change at page 25, line 41
|---PCRpt, Delegate=1--->| |---PCRpt, Delegate=1--->|
| | | |
Figure 9: Delegating an LSP Figure 9: Delegating an LSP
Note that for an LSP to remain delegated to a PCE, the PCC MUST set Note that for an LSP to remain delegated to a PCE, the PCC MUST set
the Delegate flag to 1 on each LSP Status Report sent to the PCE. the Delegate flag to 1 on each LSP Status Report sent to the PCE.
5.5.2. Revoking a Delegation 5.5.2. Revoking a Delegation
A PCC revokes an LSP delegation by sending an LSP State Report with When a PCC decides that a PCE is no longer permitted to modify an
the Delegate flag set to 0. A PCC MAY revoke an LSP delegation at LSP, it revokes that LSP's delegation to the PCE. A PCC may revoke
any time during the PCEP session life time. When a PCC's PCEP an LSP delegation at any time during the LSP's life time. A PCC
session with the PCE terminates, the PCC SHALL wait a time interval revoking a LSP MAY immediately clear the LSP state provided by the
specified in 'Delegation Timeout Interval' and then revoke all LSP PCE, and MUST ignore any further PCUpd messages received regarding
delegations to the PCE . the revoked LSP from the previous PCE delegate.
After an LSP delegation has been revoked, a PCE can no longer update
LSP's parameters; an attempt to update parameters of a non-delegated
LSP will result in the PCC sending a PCErr message indicating "LSP is
not delegated" (see Section 8.4).
The revocation sequence is shown in Figure 10. If a PCEP session with the PCE to which the LSP is delegated exists
in the UP state during the revocation, the PCC MUST notify that PCE
by sending an LSP State Report with the Delegate flag set to 0, as
shown in Figure 10.
+-+-+ +-+-+ +-+-+ +-+-+
|PCC| |PCE| |PCC| |PCE|
+-+-+ +-+-+ +-+-+ +-+-+
| | | |
|---PCRpt, Delegate=1--->| |---PCRpt, Delegate=1--->|
| | | |
|<--(PCUpd,Delegate=1)---| Delegation confirmed |<--(PCUpd,Delegate=1)---| Delegation confirmed
| . | | . |
| . | | . |
| . | | . |
|---PCRpt, Delegate=0--->| Delegation revoked |---PCRpt, Delegate=0--->| PCC revokes delegation
| | | |
Figure 10: Revoking a Delegation Figure 10: Revoking a Delegation
If a PCC can not delegate an LSP to a PCE (for example, if a PCC is After an LSP delegation has been revoked, a PCE can no longer update
not connected to any active stateful PCE or if no connected active LSP's parameters; an attempt to update parameters of a non-delegated
stateful PCE accepts the delegation), the LSP delegation on the PCC LSP will result in the PCC sending a PCErr message indicating "LSP is
will time out within a configurable Delegation Timeout Interval and not delegated" (see Section 8.4).
the PCC SHALL flush any LSP state set by a PCE.
When a PCC's PCEP session with a PCE terminates, the PCC SHALL wait a
time interval specified in 'Delegation Timeout Interval' before
revoking LSP delegations to the PCE. If a new PCEP session with the
PCE can be established before the 'Delegation Timeout' timer expires,
LSP delegations to the PCE remain intact. If, after expiry of the
'Delegation Timeout' timer, a PCC can not delegate an LSP to another
PCE (for example, if a PCC is not connected to any active stateful
PCE or if no connected active stateful PCE accepts the delegation),
the PCC SHALL flush any LSP state set by the PCE.
If State Synchronization Avoidance is enabled, a PCC MUST increment
its LSP State Database version when the 'Delegation Timeout' timer
expires.
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
Update Request which has the Delegate flag set to 0. Note that in Update Request which has the Delegate flag set to 0. Note that in
order to keep a delegation, the PCE MUST set the Delegate flag to 1 order to keep a delegation, the PCE MUST set the Delegate flag to 1
on each LSP Update Request sent to the PCC. on each LSP Update Request sent to the PCC.
+-+-+ +-+-+ +-+-+ +-+-+
skipping to change at page 31, line 38 skipping to change at page 33, line 25
<path-list>::=<path>[<path-list>] <path-list>::=<path>[<path-list>]
<path>::=<ERO><attribute-list> <path>::=<ERO><attribute-list>
Where: Where:
<attribute-list> ::= [<LSPA>] <attribute-list> ::= [<LSPA>]
[<BANDWIDTH>] [<BANDWIDTH>]
[<metric-list>] [<metric-list>]
[<IRO>]
<metric-list> ::= <METRIC>[<metric-list>] <metric-list> ::= <METRIC>[<metric-list>]
There is one mandatory object that MUST be included within each LSP There is one mandatory object that MUST be included within each LSP
Update Request in the PCUpd message: the LSP object (see Update Request in the PCUpd message: the LSP object (see
Section 7.2). If the LSP object is missing, the receiving PCE MUST Section 7.2). If the LSP object is missing, the receiving PCE MUST
send a PCErr message with Error-type=6 (Mandatory Object missing) and send a PCErr message with Error-type=6 (Mandatory Object missing) and
Error-value=[TBD] (LSP object missing). Error-value=[TBD] (LSP object missing).
The LSP Update Request MUST contain a path descriptor for the primary The LSP Update Request MUST contain a path descriptor for the primary
skipping to change at page 32, line 33 skipping to change at page 34, line 18
Note that a PCC MUST process all LSP Update Requests - for example, Note that a PCC MUST process all LSP Update Requests - for example,
an LSP Update Request is sent when a PCE returns delegation or puts an LSP Update Request is sent when a PCE returns delegation or puts
an LSP into non-operational state. The protocol relies on TCP for an LSP into non-operational state. The protocol relies on TCP for
message-level flow control. message-level flow control.
Note also that it's up to the PCE to handle inter-LSP dependencies; Note also that it's up to the PCE to handle inter-LSP dependencies;
for example, if ordering of LSP set-ups is required, the PCE has to for example, if ordering of LSP set-ups is required, the PCE has to
wait for an LSP State Report for a previous LSP before triggering the wait for an LSP State Report for a previous LSP before triggering the
LSP setup of a next LSP. LSP setup of a next LSP.
6.3. The PCReq Message
A PCC MAY include the LSP object in the PCReq message (see
Section 7.2) if stateful PCE capability has been negotiated on a PCEP
session between the PCC and a PCE. The definition of the PCReq
message (see [RFC5440], Section 6.4) is then extended as follows:
<PCReq Message>::= <Common Header>
[<svec-list>]
<request-list>
Where:
<svec-list>::=<SVEC>[<svec-list>]
<request-list>::=<request>[<request-list>]
<request>::= <RP>
<END-POINTS>
[<LSP>] <--- New Object
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<RRO>[<BANDWIDTH>]]
[<IRO>]
[<LOAD-BALANCING>]
Where:
<metric-list>::=<METRIC>[<metric-list>]
6.4. The PCRep Message
A PCE MAY include the LSP object in the PCRep message (see
(Section 7.2) if stateful PCE capability has been negotiated on a
PCEP session between the PCC and the PCE and the LSP object was
included in the corresponding PCReq message from the PCC. The
definition of the PCRep message (see [RFC5440], Section 6.5) is then
extended as follows
<PCRep Message> ::= <Common Header>
<response-list>
Where:
<response-list>::=<response>[<response-list>]
<response>::=<RP>
[<LSP>] <--- New Object
[<NO-PATH>]
[<attribute-list>]
[<path-list>]
<path-list>::=<path>[<path-list>]
<path>::= <ERO><attribute-list>
Where:
<attribute-list>::=[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]
<metric-list>::=<METRIC>[<metric-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 MUST always be set to 0 on
transmission and MUST be ignored on receipt since these flags are transmission and MUST 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
skipping to change at page 33, line 8 skipping to change at page 36, line 13
support stateful PCE capability negotiation. support stateful PCE capability negotiation.
7.1.1. Stateful PCE Capability TLV 7.1.1. Stateful PCE Capability TLV
The format of the STATEFUL-PCE-CAPABILITY TLV is shown in the The format of the STATEFUL-PCE-CAPABILITY TLV is shown in the
following figure: 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=2 | | Type=[TBD] | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |S|U|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |S|U|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: STATEFUL-PCE-CAPABILITY TLV format Figure 14: STATEFUL-PCE-CAPABILITY TLV format
The type of the TLV is [TBD] and it has a fixed length of 2 octets. The type of the TLV is [TBD] and it has a fixed length of 4 octets.
The value comprises a single field - Flags (16 bits): The value comprises a single field - Flags (16 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 wishes to set to 1 by a PCE, the U Flag indicates that the PCE wishes to
update LSP parameters. The LSP-UPDATE-CAPABILITY Flag must be update 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 34, line 19 skipping to change at page 37, line 19
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP State DB Version | | LSP State DB Version |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: LSP-DB-VERSION TLV format Figure 15: LSP-DB-VERSION TLV format
The type of the TLV is [TBD] and it has a fixed length of 8 octets. The type of the TLV is [TBD] and it has a fixed length of 8 octets.
The value contains a 64-bit unsigned integer. The value contains a 64-bit unsigned integer.
7.1.3. Node Identifier TLV
NODE-IDENTIFIER is an optional TLV that MAY be included in the OPEN
Object when a PCEP Speaker wishes to determine if State
Synchronization can be skipped when a PCEP session is restarted. It
contains a unique identifier for the node that does not change during
the life time of the PCEP Speaker. It identifies the PCEP Speaker to
its peers if the Speaker's IP address changed.
The format of the NODE-IDENTIFIER TLV is shown in the following
figure:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=[TBD] | Length (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// PCEP Speaker Node Identifier //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: NODE-IDENTIFIER TLV format
The type of the TLV is [TBD] and it has a a variable length, which
MUST be greater than 0. The value contains a node identifier that
MUST be unique in the network. The node identifier MAY be configured
by an operator. If the node identifier is not configured by the
operator, it can be derived from a PCC's MAC address or serial
number.
7.2. LSP Object 7.2. LSP Object
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 is also operation to be performed on the LSP, and LSP Delegation. It also
contains a flag to indicate to a PCE that the initial LSP state contains a flag indicating to a PCE that the LSP state
synchronization has been done. synchronization is in progress.
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 16: The format of the LSP object body is shown in Figure 17:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session-internal LSP-ID | Flags |R|O|S|D| | LSP-ID | Flags |R|O|S|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Optional TLVs // // Optional TLVs //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: The LSP Object format Figure 17: The LSP Object format
The LSP object body has a variable length and may contain additional The LSP object body has a variable length and may contain additional
TLVs. TLVs.
Session-internal LSP-ID (20 bits): Per-PCEP session identifier for an LSP-ID (20 bits): An identifier for the LSP. A PCC creates a unique
LSP. In each PCEP session the PCC creates a unique LSP-ID for each LSP-ID for each LSP that is constant for the life time of a PCEP
LSP that will remain constant for the duration of the session. The session. The mapping of the LSP Symbolic Name to LSP-ID is
mapping of the LSP Symbolic Name to LSP-ID is communicated to the PCE communicated to the PCE by sending a PCRpt message containing the
by sending a PCRpt message containing the 'LSP Symbolic Name' TLV. 'LSP Symbolic Name' TLV. All subsequent PCEP messages then address
All subsequent PCEP messages then address the LSP by its Session- the LSP by the LSP-ID.
internal LSP-ID.
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 the PCE. On a PCUpd indicates that the PCC is delegating the LSP to the PCE. On a
message, the D flag set to 1 indicates that the PCE is confirming PCUpd message, the D flag set to 1 indicates that the PCE is
the LSP Delegation. To keep an LSP delegated to the PCE, the PCC confirming the LSP Delegation. To keep an LSP delegated to the
must set the D flag to 1 on each PCRpt message for the duration of PCE, the PCC must set the D flag to 1 on each PCRpt message for
the delegation - the first PCRpt with the D flag set to 0 revokes the duration of the delegation - the first PCRpt with the D flag
the delegation. To keep the delegation, the PCE must set the D set to 0 revokes the delegation. To keep the delegation, the PCE
flag to 1 on each PCUpd message for the duration of the delegation must set the D flag to 1 on each PCUpd message for the duration of
- the first PCUpd with the D flag set to 0 returns the delegation. the delegation - the first PCUpd with the D flag set to 0 returns
the delegation.
S (SYNC - 1 bit): the S Flag MUST be set to 1 on each LSP State S (SYNC - 1 bit): the S Flag MUST be set to 1 on each LSP State
Report sent from a PCC during State Synchronization. The S Flag Report sent from a PCC during State Synchronization. The S Flag
MUST be set to 0 otherwise. MUST be set to 0 otherwise.
O (Operational - 1 bit): On PCRpt messages the O Flag indicates the O (Operational - 1 bit): On PCRpt messages the O Flag indicates the
LSP status. Value of '1' means that the LSP is operational, i.e. LSP status. Value of '1' means that the LSP is operational, i.e.
it is either being signaled or it is active. Value of '0' means it is either being signaled or it is active. Value of '0' means
that the LSP is not operational, i.e it is de-routed and the PCC that the LSP is not operational, i.e it is de-routed and the PCC
is not attempting to set it up. On PCUpd messages the flag is not attempting to set it up. On PCUpd messages the flag
skipping to change at page 36, line 29 skipping to change at page 40, line 15
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Symbolic LSP Name // // Symbolic LSP Name //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: LSP-SYMBOLIC-NAME TLV format Figure 18: LSP-SYMBOLIC-NAME TLV format
The type of the TLV is [TBD] and it has a variable length, which MUST The type of the TLV is [TBD] and it has a variable length, which MUST
be greater than 0. be greater than 0.
7.2.2. LSP Identifiers TLVs 7.2.2. LSP Identifiers TLVs
Whenever the value of an LSP identifier changes, a PCC MUST send out Whenever the value of an LSP identifier changes, a PCC MUST send out
an LSP State Report, where the LSP Object carries the LSP Identifiers an LSP State Report, where the LSP Object carries the LSP Identifiers
TLV that contains the new value. The LSP Identifiers TLV MUST also TLV that contains the new value. The LSP Identifiers TLV MUST also
be included in the LSP object during state synchronization. There be included in the LSP object during state synchronization. There
skipping to change at page 37, line 17 skipping to change at page 40, line 43
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=[TBD] | Length=12 | | Type=[TBD] | Length=12 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Tunnel Sender Address | | IPv4 Tunnel Sender Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP ID | Tunnel ID | | LSP ID | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID | | Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: IPV4-LSP-IDENTIFIERS TLV format Figure 19: IPV4-LSP-IDENTIFIERS TLV format
The type of the TLV is [TBD] and it has a fixed length of 8 octets. The type of the TLV is [TBD] and it has a fixed length of 12 octets.
The value contains two fields: 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.
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.
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).
Extended Tunnel ID: contains the 128-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.
The format of the IPV6-LSP-IDENTIFIERS TLV is shown in the following The format of the IPV6-LSP-IDENTIFIERS 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=36 | | Type=[TBD] | Length=36 |
skipping to change at page 38, line 29 skipping to change at page 41, line 48
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| Extended Tunnel ID | | Extended Tunnel ID |
+ (16 octets) + + (16 octets) +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: IPV6-LSP-IDENTIFIERS TLV format Figure 20: IPV6-LSP-IDENTIFIERS TLV format
The type of the TLV is [TBD] and it has a fixed length of 20 octets. The type of the TLV is [TBD] and it has a fixed length of 36 octets.
The value contains two fields: 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.
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).
Extended Tunnel ID: contains the 32-bit 'Extended Tunnel ID' Extended Tunnel ID: contains the 128-bit 'Extended Tunnel ID'
identifier defined in [RFC3209], Section 4.6.1.2 for the identifier defined in [RFC3209], Section 4.6.1.2 for the
LSP_TUNNEL_IPv6 Session Object. LSP_TUNNEL_IPv6 Session Object.
7.2.3. LSP Update Error Code TLV 7.2.3. LSP Update Error Code TLV
If an LSP Update Request failed, an LSP State Report MUST be sent to If an LSP Update Request failed, an LSP State Report MUST be sent to
all connected stateful PCEs. LSP State Report MUST contain the LSP all connected stateful PCEs. LSP State Report MUST contain the LSP
Update Error Code TLV, indicating the cause of the failure. Update Error Code TLV, indicating the cause of the failure.
The format of the LSP-UPDATE-ERROR-CODE TLV is shown in the following The format of the LSP-UPDATE-ERROR-CODE 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=4 | | Type=[TBD] | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | | Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: LSP-UPDATE-ERROR-CODE TLV format Figure 21: LSP-UPDATE-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 [TBD] and it has a fixed length of 4 octets.
The value contains the error code that indicates the cause of the LSP The value contains the error code that indicates the cause of the LSP
setup failure. Error codes will be defined in a later revision of setup failure. Error codes will be defined in a later revision of
this document. this document.
7.2.4. RSVP ERROR_SPEC TLVs 7.2.4. RSVP ERROR_SPEC TLVs
If the set up of an LSP failed at a downstream node which returned an If the set up of an LSP failed at a downstream node which returned an
ERROR_SPEC to the PCC, the ERROR_SPEC MUST be included in the LSP ERROR_SPEC to the PCC, the ERROR_SPEC MUST be included in the LSP
skipping to change at page 40, line 15 skipping to change at page 43, line 21
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=8 | | Type=[TBD] | Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ IPv4 ERROR_SPEC object (rfc2205) + + IPv4 ERROR_SPEC object (rfc2205) +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: IPV4-RSVP-ERROR-SPEC TLV format Figure 22: IPV4-RSVP-ERROR-SPEC TLV format
The type of the TLV is [TBD] and it has a fixed length of 8 octets. The type of the TLV is [TBD] and it has a fixed length of 8 octets.
The value contains the RSVP IPv4 ERROR_SPEC object defined in The value contains the RSVP IPv4 ERROR_SPEC object defined in
[RFC2205]. Error codes allowed in the ERROR_SPEC object are defined [RFC2205]. Error codes allowed in the ERROR_SPEC object are defined
in [RFC2205] and [RFC3209]. in [RFC2205] and [RFC3209].
The format of the IPV6-RSVP-ERROR-SPEC TLV is shown in the following The format of the IPV6-RSVP-ERROR-SPEC 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=20 | | Type=[TBD] | Length=20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// IPv6 ERROR_SPEC object (rfc2205) // // IPv6 ERROR_SPEC object (rfc2205) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 22: IPV6-RSVP-ERROR-SPEC TLV format Figure 23: IPV6-RSVP-ERROR-SPEC TLV format
The type of the TLV is [TBD] and it has a fixed length of 20 octets. The type of the TLV is [TBD] and it has a fixed length of 20 octets.
The value contains the RSVP IPv6 ERROR_SPEC object defined in The value contains the RSVP IPv6 ERROR_SPEC object defined in
[RFC2205]. Error codes allowed in the ERROR_SPEC object are defined [RFC2205]. Error codes allowed in the ERROR_SPEC object are defined
in [RFC2205] and [RFC3209]. in [RFC2205] and [RFC3209].
7.2.5. LSP State Database Version TLV 7.2.5. LSP State Database Version TLV
The LSP-DB-VERSION TLV can be included as an optional TLV in the LSP The LSP-DB-VERSION TLV can be included as an optional TLV in the LSP
object. The LSP-DB-VERSION TLV is discussed in Section 5.4.1 which object. The LSP-DB-VERSION TLV is discussed in Section 5.4.1 which
skipping to change at page 44, line 45 skipping to change at page 47, line 45
In addition to configuring specific PCEP session parameters, as In addition to configuring specific PCEP session parameters, as
specified in [RFC5440], Section 8.1, a PCE or PCC implementation MUST specified in [RFC5440], Section 8.1, a PCE or PCC implementation MUST
allow configuring the stateful PCEP capability and the LSP Update allow configuring the stateful PCEP capability and the LSP Update
capability. A PCC implementation SHOULD allow the operator to capability. A PCC implementation SHOULD allow the operator to
specify multiple candidate PCEs for and a delegation preference for specify multiple candidate PCEs for and a delegation preference for
each candidate PCE. A PCC SHOULD allow the operator to specify an each candidate PCE. A PCC SHOULD allow the operator to specify an
LSP delegation policy where LSPs are delegated to the most-preferred LSP delegation policy where LSPs are delegated to the most-preferred
online PCE. A PCC MAY allow the operator to specify different LSP online PCE. A PCC MAY allow the operator to specify different LSP
delegation policies. delegation policies.
A PCE or PCC implementation SHOULD allow the operator to configure a
Node Identifier (Section 7.1.3).
A PCC implementation which allows concurrent connections to multiple A PCC implementation which allows concurrent connections to multiple
PCEs SHOULD allow the operator to group the PCEs by administrative PCEs SHOULD allow the operator to group the PCEs by administrative
domains and it MUST NOT advertise LSP existence and state to a PCE if domains and it MUST NOT advertise LSP existence and state to a PCE if
the LSP is delegated to a PCE in a different group. the LSP is delegated to a PCE in a different group.
A PCC implementation SHOULD allow the operator to specify whether the A PCC implementation SHOULD allow the operator to specify whether the
PCC will advertise LSP existence and state for LSPs that are not PCC will advertise LSP existence and state for LSPs that are not
controlled by any PCE (for example, LSPs that are statically controlled by any PCE (for example, LSPs that are statically
configured at the PCC). configured at the PCC).
skipping to change at page 48, line 22 skipping to change at page 51, line 22
Delegation of LSPs can create further strain on PCE resources and a Delegation of LSPs can create further strain on PCE resources and a
PCE implementation MAY preemptively give back delegations if it finds PCE implementation MAY preemptively give back delegations if it finds
itself lacking the resources needed to effectively manage the itself lacking the resources needed to effectively manage the
delegation. Since the delegation state is ultimately controlled by delegation. Since the delegation state is ultimately controlled by
the PCC, PCE implementations SHOULD provide throttling mechanisms to the PCC, PCE implementations SHOULD provide throttling mechanisms to
prevent strain created by flaps of either a PCEP session or an LSP prevent strain created by flaps of either a PCEP session or an LSP
delegation. delegation.
11. Acknowledgements 11. Acknowledgements
We would like to thank Adrian Farrel and Cyril Margaria for their We would like to thank Adrian Farrel, Cyril Margaria and Ramon
contributions to this document. Casellas for their contributions to this document.
We would like to thank Shane Amante, Julien Meuric, Kohei Shiomoto, We would like to thank Shane Amante,Julien Meuric, Kohei Shiomoto,
Paul Schultz and Raveendra Torvi for their comments and suggestions. Paul Schultz and Raveendra Torvi for their comments and suggestions.
Thanks also to Dhruv Dhoddy, Oscar Gonzales de Dios, Tomas Janciga, Thanks also to Dhruv Dhoddy, Oscar Gonzales de Dios, Tomas Janciga,
Stefan Kobza and Kexin Tang for helpful discussions. Stefan Kobza and Kexin Tang for helpful discussions.
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 50, line 43 skipping to change at page 53, line 43
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
Robert Varga Robert Varga
Pantheon Technologies LLC 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
Ina Minei Ina Minei
Juniper Networks, Inc. Juniper Networks, Inc.
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
US US
 End of changes. 51 change blocks. 
141 lines changed or deleted 263 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/