draft-ietf-pce-disco-proto-ospf-04.txt   draft-ietf-pce-disco-proto-ospf-05.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 Intended Status: Standards Track
Expires: November 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-04.txt draft-ietf-pce-disco-proto-ospf-05.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 Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 Notice
Copyright (C) The IETF Trust (2007). All rights reserved. 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
skipping to change at page 3, line 11 skipping to change at page 3, line 11
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
10. Acknowledgments............................................19 10. Acknowledgments............................................19
11. References.................................................19 11. References.................................................19
11.1. Normative references.......................................19 11.1. Normative references.......................................19
11.2. Informative references.....................................20 11.2. Informative references.....................................20
12. Editor's Addresses:........................................20 12. Editors' Addresses.........................................20
13. Contributors' Addresses:...................................21 13. Contributors' Addresses:...................................21
14. Intellectual Property Statement............................21 14. Intellectual Property Statement............................21
1. Terminology 1. Terminology
Terminology used in this document Terminology used in this document:
ABR: OSPF Area Border Router. ABR: OSPF Area Border Router.
AS: Autonomous System. AS: Autonomous System.
IGP: Interior Gateway Protocol. Either of the two routing IGP: Interior Gateway Protocol. Either of the two routing
protocols Open Shortest Path First (OSPF) or Intermediate System protocols Open Shortest Path First (OSPF) or Intermediate System
to Intermediate System (ISIS). to Intermediate System (ISIS).
Intra-area TE LSP: A TE LSP whose path does not cross IGP area Intra-area TE LSP: A TE LSP whose path does not cross IGP area
boundaries. boundaries.
Intra-AS TE LSP: A TE LSP whose path does not cross AS boundaries. Intra-AS TE LSP: A TE LSP whose path does not cross AS boundaries.
Inter-area TE LSP: A TE LSP whose path transits two or more IGP Inter-area TE LSP: A TE LSP whose path transits two or more IGP
areas. That is a TE-LSP that crosses at least one IGP area areas. That is a TE-LSP that crosses at least one IGP area boundary.
boundary.
Inter-AS TE LSP: A TE LSP whose path transits two or more Inter-AS TE LSP: A TE LSP whose path transits two or more
ASes or sub-ASes (BGP confederations). That is a TE-LSP that ASes or sub-ASes (BGP confederations). That is a TE-LSP that
crosses at least one AS boundary. crosses at least one AS boundary.
LSA: Link State Advertisement LSA: Link State Advertisement
LSR: Label Switching Router. LSR: Label Switching Router.
PCC: Path Computation Client: Any client application requesting a PCC: Path Computation Client: Any client application requesting a
path computation to be performed by a Path Computation Element. path computation to be performed by a Path Computation Element.
PCE: Path Computation Element: An entity (component, application, PCE: Path Computation Element: An entity (component, application,
or network node) that is capable of computing a network path or or network node) that is capable of computing a network path or
route based on a network graph, and applying computational route based on a network graph, and applying computational
constraints. constraints.
PCE-Domain: In a PCE context this refers to any collection of PCE-Domain: In a PCE context this refers to any collection of
network elements within a common sphere of address management or network elements within a common sphere of address management or
path computational responsibility (referred to as "domain" in path computational responsibility (referred to as "domain" in
[RFC4655]). Examples of PCE-Domains include IGP areas and [RFC4655]). Examples of PCE-Domains include IGP areas and ASes.
Autonomous Systems. This should be distinguished from an OSPF This should be distinguished from an OSPF routing domain.
routing domain.
PCEP: Path Computation Element Protocol. PCEP: Path Computation Element Protocol.
TE LSP: Traffic Engineered Label Switched Path. TE LSP: Traffic Engineered Label Switched Path.
2. Introduction 2. Introduction
[RFC4655] describes the motivations and architecture for a PCE-based [RFC4655] describes the motivations and architecture for a PCE-based
path computation model for Multi Protocol Label Switching (MPLS) and path computation model for Multi Protocol Label Switching (MPLS) and
Generalized MPLS (GMPLS) Traffic Engineered Label Switched Paths (TE- Generalized MPLS (GMPLS) Traffic Engineered Label Switched Paths (TE-
skipping to change at page 11, line 36 skipping to change at page 11, line 36
2 IPv6 Area Address 2 IPv6 Area Address
3 AS Number 3 AS Number
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.
skipping to change at page 16, line 53 skipping to change at page 17, line 5
The IANA is requested to create a sub-registry of the OSPF RI TLVs The IANA is requested to create a sub-registry of the OSPF RI TLVs
registry defined in [OSPF-CAP], named the "OSPF PCED sub-TLV" registry defined in [OSPF-CAP], named the "OSPF PCED sub-TLV"
registry, and manage sub-TLV type identifiers as follows: 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 sub-TLVs as follows (suggested values): This document defines five sub-TLVs as follows (suggested values):
Value TLV name References Sub-TLV Sub-TLV
Type 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.
skipping to change at page 17, line 31 skipping to change at page 17, line 34
"PCE Capability Flags" registry, and to manage the space of PCE "PCE Capability Flags" registry, and to manage the space of PCE
capability bit flags numbering them in the usual IETF notation capability bit flags numbering them in the usual IETF notation
starting at zero and continuing at least through 31, with the most starting at zero and continuing at least through 31, with the most
significant bit as bit zero. significant bit as bit zero.
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
- Capability Description - Capability Description
- Defining RFC
Several bits are defined in this document. Here are the suggested Several bits are defined in this document. Here are the suggested
values: values:
Bit Capability Description Bit Capability Description
0 Path computation with GMPLS link constraints 0 Path computation with GMPLS link constraints
1 Bidirectional path computation 1 Bidirectional path computation
2 Diverse path computation 2 Diverse path computation
3 Load-balanced path computation 3 Load-balanced path computation
skipping to change at page 20, line 9 skipping to change at page 20, line 12
[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 11.2. Informative references
Element (PCE)-based Architecture", RFC4655, August 2006.
[RFC4674] Le Roux, J.L., et al. "Requirements for PCE discovery",
RFC4674, October 2006.
[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 [RFC4655] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation
Element (PCE)-based Architecture", RFC4655, August 2006.
[RFC4657] Ash, J., Le Roux, J.L., "PCE Communication Protocol Generic [RFC4657] Ash, J., Le Roux, J.L., "PCE Communication Protocol Generic
Requirements", RFC4657, September 2006. Requirements", RFC4657, September 2006.
[RFC4674] Le Roux, J.L., et al. "Requirements for PCE discovery",
RFC4674, October 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-
in progress. pcep, work 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, work in Computation Element Discovery", draft-ietf-pce-disc-mib,
progress. work in progress.
[PCED-ISIS] Le Roux, Vasseur, et al. "IS-IS protocol extensions for
Path Computation Element (PCE) Discovery", draft-ietf-pce-disco-
proto-isis, work in progress.
12. Editor's Addresses: 12. Editors' Addresses
Jean-Louis Le Roux (Editor) Jean-Louis Le Roux (Editor)
France Telecom France Telecom
2, avenue Pierre-Marzin 2, avenue Pierre-Marzin
22307 Lannion Cedex 22307 Lannion Cedex
FRANCE FRANCE
Email: jeanlouis.leroux@orange-ftgroup.com Email: jeanlouis.leroux@orange-ftgroup.com
Jean-Philippe Vasseur (Editor) Jean-Philippe Vasseur (Editor)
Cisco Systems, Inc. Cisco Systems, Inc.
 End of changes. 17 change blocks. 
30 lines changed or deleted 21 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/