draft-ietf-pce-disco-proto-ospf-03.txt   draft-ietf-pce-disco-proto-ospf-04.txt 
Network Working Group J.L. Le Roux (Editor) Network Working Group J.L. Le Roux (Editor)
Internet Draft France Telecom Internet Draft France Telecom
Category: Standard Track Category: Standard Track
Expires: October 2007 J.P. Vasseur (Editor) Expires: November 2007 J.P. Vasseur (Editor)
Cisco System Inc. Cisco System Inc.
Yuichi Ikejiri Yuichi Ikejiri
NTT Communications NTT Communications
Raymond Zhang Raymond Zhang
BT Infonet BT Infonet
OSPF protocol extensions for Path Computation Element (PCE) Discovery OSPF protocol extensions for Path Computation Element (PCE) Discovery
draft-ietf-pce-disco-proto-ospf-03.txt draft-ietf-pce-disco-proto-ospf-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 3, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007). All rights reserved.
Abstract Abstract
There are various circumstances where it is highly desirable for a There are various circumstances where it is highly desirable for a
Path Computation Client (PCC) to be able to dynamically and Path Computation Client (PCC) to be able to dynamically and
automatically discover a set of Path Computation Elements (PCE), automatically discover a set of Path Computation Elements (PCE),
along with some information that can be used for PCE selection. When along with some information that can be used for PCE selection. When
the PCE is a Label Switching Router (LSR) participating in the the PCE is a Label Switching Router (LSR) participating in the
Interior Gateway Protocol (IGP), or even a server participating Interior Gateway Protocol (IGP), or even a server participating
passively in the IGP, a simple and efficient way to discover PCEs passively in the IGP, a simple and efficient way to discover PCEs
consists of using IGP flooding. For that purpose, this document consists of using IGP flooding. For that purpose, this document
defines extensions to the Open Shortest Path First (OSPF) routing defines extensions to the Open Shortest Path First (OSPF) routing
protocol for the advertisement of PCE Discovery information within an protocol for the advertisement of PCE Discovery information within an
OSPF area or within the entire OSPF routing domain. OSPF area or within the entire OSPF routing domain.
Conventions used in this document Conventions used in this document
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 RFC-2119. document are to be interpreted as described in [RFC2119].
Table of Contents Table of Contents
1. Terminology.................................................3 1. Terminology.................................................3
2. Introduction................................................4 2. Introduction................................................4
3. Overview....................................................5 3. Overview....................................................5
3.1. PCE Information.............................................5 3.1. PCE Information.............................................5
3.2. PCE Discovery Information...................................5 3.2. PCE Discovery Information...................................5
3.2.1. PCE Congestion Information..................................6 3.2.1. PCE Congestion Information..................................6
3.3. Flooding scope..............................................6 3.3. Flooding Scope..............................................6
4. OSPF extensions.............................................6 4. OSPF Extensions.............................................6
4.1. The OSPF PCED TLV...........................................6 4.1. The OSPF PCED TLV...........................................6
4.1.1. PCE-ADDRESS sub-TLV.........................................8 4.1.1. PCE-ADDRESS Sub-TLV.........................................8
4.1.2. PATH-SCOPE sub-TLV..........................................8 4.1.2. PATH-SCOPE Sub-TLV..........................................8
4.1.3. PCE-DOMAIN sub-TLV.........................................10 4.1.3. PCE-DOMAIN Sub-TLV.........................................10
4.1.4. NEIG-PCE-DOMAIN sub-TLV....................................11 4.1.4. NEIG-PCE-DOMAIN Sub-TLV....................................11
4.1.5. PCE-CAP-FLAGS sub-TLV......................................12 4.1.5. PCE-CAP-FLAGS Sub-TLV......................................12
4.1.6. The CONGESTION sub-TLV.....................................14 4.1.6. The CONGESTION Sub-TLV.....................................14
5. Elements of Procedure......................................14 5. Elements of Procedure......................................14
5.1. CONGESTION sub-TLV specific procedures.....................15 5.1. CONGESTION sub-TLV Specific Procedures.....................15
6. Backward compatibility.....................................16 6. Backward Compatibility.....................................16
7. IANA Considerations........................................16 7. IANA Considerations........................................16
7.1. OSPF TLV...................................................16 7.1. OSPF TLV...................................................16
7.2. PCED sub-TLVs registry.....................................16 7.2. PCED Sub-TLVs Registry.....................................16
7.3. PCE Capability Flags registry..............................17 7.3. PCE Capability Flags registry..............................17
8. Security Considerations....................................18 8. Security Considerations....................................18
9. Manageability Considerations...............................18 9. Manageability Considerations...............................18
9.1. Control of Policy and Functions............................18 9.1. Control of Policy and Functions............................18
9.2. Information and Data Model.................................18 9.2. Information and Data Model.................................18
9.3. Liveness Detection and Monitoring..........................18 9.3. Liveness Detection and Monitoring..........................18
9.4. Verify Correct Operations..................................18 9.4. Verify Correct Operations..................................18
9.5. Requirements on Other Protocols and Functional 9.5. Requirements on Other Protocols and Functional
Components...............................................19 Components...............................................19
9.6. Impact on network operations...............................19 9.6. Impact on network operations...............................19
skipping to change at page 8, line 5 skipping to change at page 8, line 8
Additional sub-TLVs could be added in the future to advertise Additional sub-TLVs could be added in the future to advertise
additional information. additional information.
The PCED TLV is carried within an OSPF Router Information LSA The PCED TLV is carried within an OSPF Router Information LSA
defined in [OSPF-CAP]. defined in [OSPF-CAP].
The following sub-sections describe the sub-TLVs which may be carried The following sub-sections describe the sub-TLVs which may be carried
within the PCED sub-TLV. within the PCED sub-TLV.
4.1.1. PCE-ADDRESS sub-TLV 4.1.1. PCE-ADDRESS Sub-TLV
The PCE-ADDRESS sub-TLV specifies the IP address(es) that can be The PCE-ADDRESS sub-TLV specifies the IP address(es) that can be
used to reach the PCE. It is RECOMMENDED to make use of an address used to reach the PCE. It is RECOMMENDED to make use of an address
that is always reachable, provided that the PCE is alive. that is always reachable, provided that the PCE is alive.
The PCE-ADDRESS sub-TLV is mandatory; it MUST be present within the The PCE-ADDRESS sub-TLV is mandatory; it MUST be present within the
PCED TLV. It MAY appear twice, when the PCE has both an IPv4 and IPv6 PCED TLV. It MAY appear twice, when the PCE has both an IPv4 and IPv6
address. It MUST NOT appear more than once for the same address type. address. It MUST NOT appear more than once for the same address type.
The format of the PCE-ADDRESS sub-TLV is as follows: The format of the PCE-ADDRESS sub-TLV is as follows:
skipping to change at page 8, line 40 skipping to change at page 8, line 43
Type To be assigned by IANA (suggested value =1) Type To be assigned by IANA (suggested value =1)
Length 8 (IPv4) or 20 (IPv6) Length 8 (IPv4) or 20 (IPv6)
Address-type: Address-type:
1 IPv4 1 IPv4
2 IPv6 2 IPv6
PCE IP Address: The IP address to be used to reach the PCE. PCE IP Address: The IP address to be used to reach the PCE.
4.1.2. PATH-SCOPE sub-TLV 4.1.2. PATH-SCOPE Sub-TLV
The PATH-SCOPE sub-TLV indicates the PCE path computation scope, The PATH-SCOPE sub-TLV indicates the PCE path computation scope,
which refers to the PCE's ability to compute or take part in the which refers to the PCE's ability to compute or take part in the
computation of intra-area, inter-area, inter-AS, or inter-layer_TE computation of intra-area, inter-area, inter-AS, or inter-layer_TE
LSP(s). LSP(s).
The PATH-SCOPE sub-TLV is mandatory; it MUST be present within the The PATH-SCOPE sub-TLV is mandatory; it MUST be present within the
PCED TLV. There MUST be exactly one instance of the PATH-SCOPE sub- PCED TLV. There MUST be exactly one instance of the PATH-SCOPE sub-
TLV within each PCED TLV. TLV within each PCED TLV.
skipping to change at page 10, line 32 skipping to change at page 10, line 34
used preferably for inter-AS computation may configure a PrefS higher used preferably for inter-AS computation may configure a PrefS higher
than the PrefR. than the PrefR.
When the L bit, R bit, S bit or Y bit are cleared, the PrefL, PrefR, When the L bit, R bit, S bit or Y bit are cleared, the PrefL, PrefR,
PrefS, PrefY fields SHOULD respectively be set to 0 and MUST be PrefS, PrefY fields SHOULD respectively be set to 0 and MUST be
ignored. ignored.
Both reserved fields SHOULD be set to zero on transmission and MUST Both reserved fields SHOULD be set to zero on transmission and MUST
be ignored on receipt. be ignored on receipt.
4.1.3. PCE-DOMAIN sub-TLV 4.1.3. PCE-DOMAIN Sub-TLV
The PCE-DOMAIN sub-TLV specifies a PCE-Domain (areas and/or ASes) The PCE-DOMAIN sub-TLV specifies a PCE-Domain (areas and/or ASes)
where the PCE has topology visibility and through which the PCE can where the PCE has topology visibility and through which the PCE can
compute paths. compute paths.
The PCE-DOMAIN sub-TLV MAY be present when PCE-Domains cannot be The PCE-DOMAIN sub-TLV MAY be present when PCE-Domains cannot be
inferred by other IGP information, for instance when the PCE is inferred by other IGP information, for instance when the PCE is
inter-domain capable (i.e. when the R bit or S bit is set) and the inter-domain capable (i.e. when the R bit or S bit is set) and the
flooding scope is the entire routing domain (see section 5 for a flooding scope is the entire routing domain (see section 5 for a
discussion of how the flooding scope is set and interpreted). discussion of how the flooding scope is set and interpreted).
skipping to change at page 11, line 38 skipping to change at page 11, line 38
Domain ID: With the address type 1/2 this indicates the IPv4/v6 Domain ID: With the address type 1/2 this indicates the IPv4/v6
address of an area where the PCE has visibility. With address- address of an area where the PCE has visibility. With address-
type 3 this indicates an AS number where the PCE has type 3 this indicates an AS number where the PCE has
visibility. When coded in two bytes (which is the current visibility. When coded in two bytes (which is the current
defined format as the time of writing this document), the AS defined format as the time of writing this document), the AS
Number field MUST have its left two bytes set to 0. Number field MUST have its left two bytes set to 0.
. .
4.1.4. NEIG-PCE-DOMAIN sub-TLV 4.1.4. NEIG-PCE-DOMAIN Sub-TLV
The NEIG-PCE-DOMAIN sub-TLV specifies a neighbour PCE-domain (area, The NEIG-PCE-DOMAIN sub-TLV specifies a neighbour PCE-domain (area,
AS) toward which a PCE can compute paths. It means that the PCE can AS) toward which a PCE can compute paths. It means that the PCE can
take part in the computation of inter-domain TE LSPs whose path take part in the computation of inter-domain TE LSPs whose path
transits this neighbour PCE-domain. transits this neighbour PCE-domain.
A PCED sub-TLV MAY include several NEIG-PCE-DOMAIN sub-TLVs when the A PCED sub-TLV MAY include several NEIG-PCE-DOMAIN sub-TLVs when the
PCE can compute paths towards several neighbour PCE-domains. PCE can compute paths towards several neighbour PCE-domains.
The NEIG-PCE-DOMAIN sub-TLV has the same format as the PCE-DOMAIN The NEIG-PCE-DOMAIN sub-TLV has the same format as the PCE-DOMAIN
skipping to change at page 12, line 39 skipping to change at page 12, line 39
compute paths. With address-type 3 this indicates the AS number compute paths. With address-type 3 this indicates the AS number
of a neighbour AS towards which the PCE can compute paths. When of a neighbour AS towards which the PCE can compute paths. When
coded in two bytes (which is the current defined format as the coded in two bytes (which is the current defined format as the
time of writing this document), the AS Number field MUST have time of writing this document), the AS Number field MUST have
its left two bytes set to 0. its left two bytes set to 0.
The NEIG-PCE-DOMAIN sub-TLV MUST be present if the R bit is set and The NEIG-PCE-DOMAIN sub-TLV MUST be present if the R bit is set and
the Rd bit is cleared, and/or, if the S bit is set and the Sd bit is the Rd bit is cleared, and/or, if the S bit is set and the Sd bit is
cleared. cleared.
4.1.5. PCE-CAP-FLAGS sub-TLV 4.1.5. PCE-CAP-FLAGS Sub-TLV
The PCE-CAP-FLAGS sub-TLV is an optional sub-TLV used to indicate PCE The PCE-CAP-FLAGS sub-TLV is an optional sub-TLV used to indicate PCE
capabilities. It MAY be present within the PCED TLV. It MUST NOT be capabilities. It MAY be present within the PCED TLV. It MUST NOT be
present more than once. present more than once.
The value field of the PCE-CAP-FLAGS sub-TLV is made up of an array The value field of the PCE-CAP-FLAGS sub-TLV is made up of an array
of units of 32 flags numbered from the most significant as bit zero, of units of 32 flags numbered from the most significant as bit zero,
where each bit represents one PCE capability. where each bit represents one PCE capability.
The format of the PCE-CAP-FLAGS sub-TLV is as follows: The format of the PCE-CAP-FLAGS sub-TLV is as follows:
skipping to change at page 14, line 5 skipping to change at page 14, line 5
7 Support for request prioritization 7 Support for request prioritization
8 Support for multiple requests per message 8 Support for multiple requests per message
9-31 Reserved for future assignments by IANA. 9-31 Reserved for future assignments by IANA.
These capabilities are defined in [RFC4657]. These capabilities are defined in [RFC4657].
Reserved bits SHOULD be set to zero on transmission and MUST be Reserved bits SHOULD be set to zero on transmission and MUST be
ignored on receipt. ignored on receipt.
4.1.6. The CONGESTION sub-TLV 4.1.6. The CONGESTION Sub-TLV
The CONGESTION sub-TLV is used to indicate that a PCE is experiencing The CONGESTION sub-TLV is used to indicate that a PCE is experiencing
a processing congestion state and may optionally include the expected a processing congestion state and may optionally include the expected
PCE congestion duration. PCE congestion duration.
The CONGESTION sub-TLV is optional, it MAY be carried within the PCED The CONGESTION sub-TLV is optional, it MAY be carried within the PCED
TLV. It MUST NOT be present more than once. TLV. It MUST NOT be present more than once.
The format of the CONGESTION sub-TLV is as follows: The format of the CONGESTION sub-TLV is as follows:
0 1 2 3 0 1 2 3
skipping to change at page 15, line 33 skipping to change at page 15, line 32
TLV, this means that the PCE information of that node is unknown. TLV, this means that the PCE information of that node is unknown.
A change in PCED information MUST NOT trigger any SPF computation at A change in PCED information MUST NOT trigger any SPF computation at
a receiving router. a receiving router.
The way PCEs determine the information they advertise is out of the The way PCEs determine the information they advertise is out of the
scope of this document. Some information may be configured on the PCE scope of this document. Some information may be configured on the PCE
(e.g., address, preferences, scope) and other information may be (e.g., address, preferences, scope) and other information may be
automatically determined by the PCE (e.g., areas of visibility). automatically determined by the PCE (e.g., areas of visibility).
5.1. CONGESTION sub-TLV specific procedures 5.1. CONGESTION sub-TLV Specific Procedures
When a PCE enters into a processing congestion state, the conditions When a PCE enters into a processing congestion state, the conditions
of which are implementation dependent, a Router Information LSA with of which are implementation dependent, a Router Information LSA with
a CONGESTION sub-TLV with the C bit set, and optionally a non-null a CONGESTION sub-TLV with the C bit set, and optionally a non-null
expected congestion duration MAY be generated. expected congestion duration MAY be generated.
When a PCE exits from the processing congestion state, the conditions When a PCE exits from the processing congestion state, the conditions
of which are implementation dependent, two cases are considered: of which are implementation dependent, two cases are considered:
- If the congestion duration in the previously originated - If the congestion duration in the previously originated
CONGESITON sub-TLV was null, a CONGESTION sub-TLV with the C bit CONGESITON sub-TLV was null, a CONGESTION sub-TLV with the C bit
skipping to change at page 16, line 21 skipping to change at page 16, line 18
upper-threshold and a resource congestion lower-threshold. An LSR upper-threshold and a resource congestion lower-threshold. An LSR
enters the congested state when the CPU load reaches the upper enters the congested state when the CPU load reaches the upper
threshold and leaves the congested state when the CPU load goes under threshold and leaves the congested state when the CPU load goes under
the lower threshold. the lower threshold.
Upon receipt of an updated CONGESTION sub-TLV a PCC SHOULD take Upon receipt of an updated CONGESTION sub-TLV a PCC SHOULD take
appropriate actions. In particular, the PCC SHOULD stop sending appropriate actions. In particular, the PCC SHOULD stop sending
requests to a congested PCE, and SHOULD gradually start sending requests to a congested PCE, and SHOULD gradually start sending
again requests to a PCE that is no longer congested. again requests to a PCE that is no longer congested.
6. Backward compatibility 6. Backward Compatibility
The PCED TLV defined in this document does not introduce any The PCED TLV defined in this document does not introduce any
interoperability issues. interoperability issues.
A router not supporting the PCED TLV will just silently ignore the A router not supporting the PCED TLV will just silently ignore the
TLV as specified in [OSPF-CAP]. TLV as specified in [OSPF-CAP].
7. IANA Considerations 7. IANA Considerations
7.1. OSPF TLV 7.1. OSPF TLV
Once a registry for the Router Information LSA defined in Once the OSPF RI TLVs registry defined in [OSPF-CAP] will have been
[OSPF-CAP] will have been assigned, IANA will assign a new assigned, IANA will assign a new TLV code-point for the PCED TLV
OSPF TLV code-point for the PCED TLV carried within the Router carried within the Router Information LSA.
Information LSA.
Value Sub-TLV References Value TLV Name Reference
----- -------- ---------- ----- -------- ----------
5 PCED TLV (this document) 5 PCED (this document)
7.2. PCED sub-TLVs registry 7.2. PCED Sub-TLVs Registry
The PCED TLV referenced above is constructed from sub-TLVs. Each sub- The PCED TLV referenced above is constructed from sub-TLVs. Each sub-
TLV includes a 16-bit type identifier. TLV includes a 16-bit type identifier.
The IANA is requested to create a new registry and manage sub-TLV The IANA is requested to create a sub-registry of the OSPF RI TLVs
type identifiers as follows: registry defined in [OSPF-CAP], named the "OSPF PCED sub-TLV"
registry, and manage sub-TLV type identifiers as follows:
- sub-TLV Type - sub-TLV Type
- sub-TLV Name - sub-TLV Name
- Reference - Reference
This document defines five TLVs as follows (suggested values):
This document defines five sub-TLVs as follows (suggested values):
Value TLV name References Value TLV name References
----- -------- ---------- ----- -------- ----------
1 PCE-ADDRESS This document 1 PCE-ADDRESS This document
2 PATH-SCOPE This document 2 PATH-SCOPE This document
3 PCE-DOMAIN This document 3 PCE-DOMAIN This document
4 NEIG-PCE-DOMAIN This document 4 NEIG-PCE-DOMAIN This document
5 PCE-CAP-FLAGS This document 5 PCE-CAP-FLAGS This document
6 CONGESTION This document 6 CONGESTION This document
New sub-TLV type values may be allocated only by an IETF Consensus New sub-TLV type values may be allocated only by an IETF Consensus
action. action.
7.3. PCE Capability Flags registry 7.3. PCE Capability Flags Registry
This document provides new capability bit flags, which are present This document provides new capability bit flags, which are present
in the PCE-CAP-FLAGS TLV referenced in section 4.1.5. in the PCE-CAP-FLAGS TLV referenced in section 4.1.5.
The IANA is requested to create a new registry and to manage the The IANA is requested to create a new top-level OSPF registry, the
space of PCE capability bit flags numbering them in the usual IETF "PCE Capability Flags" registry, and to manage the space of PCE
notation starting at zero and continuing at least through 31, with capability bit flags numbering them in the usual IETF notation
the most significant bit as bit zero. starting at zero and continuing at least through 31, with the most
significant bit as bit zero.
The same registry is defined for IS-IS based PCE discovery [PCED-
ISIS]. A single registry must be defined for both protocols.
New bit numbers may be allocated only by an IETF Consensus action. New bit numbers may be allocated only by an IETF Consensus action.
Each bit should be tracked with the following qualities: Each bit should be tracked with the following qualities:
- Bit number - Bit number
- Defining RFC - Defining RFC
- Capability Description - Capability Description
Several bits are defined in this document. Here are the suggested Several bits are defined in this document. Here are the suggested
skipping to change at page 19, line 49 skipping to change at page 19, line 49
11. References 11. References
11.1. Normative references 11.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.
[RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6",
RFC 2740, December 1999. RFC 2740, December 1999.
[RFC2370] Coltun, R., “The OSPF Opaque LSA Option”, RFC 2370, July [RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July
1998. 1998.
[RFC3630] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering [RFC3630] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering
Extensions to OSPF Version 2", RFC 3630, September 2003. Extensions to OSPF Version 2", RFC 3630, September 2003.
[OSPF-CAP] Lindem, A., Shen, N., Aggarwal, R., Shaffer, S., Vasseur, [OSPF-CAP] Lindem, A., Shen, N., Aggarwal, R., Shaffer, S., Vasseur,
J.P., "Extensions to OSPF for advertising Optional Router J.P., "Extensions to OSPF for advertising Optional Router
Capabilities", draft-ietf-ospf-cap, work in progress. Capabilities", draft-ietf-ospf-cap, work in progress.
[RFC4655] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation [RFC4655] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation
Element (PCE)-based Architecture", RFC4655, August 2006. Element (PCE)-based Architecture", RFC4655, August 2006.
[RFC4674] Le Roux, J.L., et al. "Requirements for PCE discovery", [RFC4674] Le Roux, J.L., et al. "Requirements for PCE discovery",
RFC4674, October 2006. RFC4674, October 2006.
[RFC4203] Kompella, Rekhter, " OSPF Extensions in Support of
Generalized Multi-Protocol Label Switching (GMPLS)", RFC4203, October
2005.
[RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with [RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with
Digital Signatures", RFC 2154, June 1997. Digital Signatures", RFC 2154, June 1997.
11.2. Informative references 11.2. Informative references
[RFC4657] Ash, J., Le Roux, J.L., " PCE Communication Protocol [RFC4657] Ash, J., Le Roux, J.L., "PCE Communication Protocol Generic
Generic Requirements", RFC4657, September 2006. Requirements", RFC4657, September 2006.
[PCEP] Vasseur, Le Roux, et al., "Path Computation Element (PCE) [PCEP] Vasseur, Le Roux, et al., "Path Computation Element (PCE)
communication Protocol (PCEP) - Version 1", draft-ietf-pce-pcep, work communication Protocol (PCEP) - Version 1", draft-ietf-pce-pcep, work
in progress. in progress.
[PCED-MIB] Stephan, E., "Definitions of Managed Objects for Path [PCED-MIB] Stephan, E., "Definitions of Managed Objects for Path
Computation Element Discovery", draft-ietf-pce-disc-mib-00, work in Computation Element Discovery", draft-ietf-pce-disc-mib, work in
progress. progress.
[PCED-ISIS] Le Roux, Vasseur, et al. "IS-IS protocol extensions for [PCED-ISIS] Le Roux, Vasseur, et al. "IS-IS protocol extensions for
Path Computation Element (PCE) Discovery", draft-ietf-pce-disco- Path Computation Element (PCE) Discovery", draft-ietf-pce-disco-
proto-isis, work in progress. proto-isis, work in progress.
12. Editor's Addresses: 12. Editor's Addresses:
Jean-Louis Le Roux (Editor) Jean-Louis Le Roux (Editor)
France Telecom France Telecom
 End of changes. 29 change blocks. 
50 lines changed or deleted 52 lines changed or added

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