draft-ietf-pce-disco-proto-ospf-06.txt   draft-ietf-pce-disco-proto-ospf-07.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
Intended Status: Standard Track Intended Status: Standard Track
Expires: December 2007 J.P. Vasseur (Editor) Expires: March 2008 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
September 2007
OSPF protocol extensions for Path Computation Element (PCE) Discovery OSPF protocol extensions for Path Computation Element (PCE) Discovery
draft-ietf-pce-disco-proto-ospf-06.txt draft-ietf-pce-disco-proto-ospf-07.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 2, line 32 skipping to change at page 2, line 32
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
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 Overload Information....................................6 3.2.1. PCE Overload Information....................................5
3.3. Flooding Scope..............................................6 3.3. Flooding Scope..............................................6
4. OSPF Extensions.............................................6 4. The OSPF PCED TLV...........................................6
4.1. The OSPF PCED TLV...........................................6 4.1. PCE-ADDRESS Sub-TLV.........................................7
4.1.1. PCE-ADDRESS Sub-TLV.........................................8 4.2. PATH-SCOPE Sub-TLV..........................................8
4.1.2. PATH-SCOPE Sub-TLV..........................................8 4.3. PCE-DOMAIN Sub-TLV.........................................10
4.1.3. PCE-DOMAIN Sub-TLV.........................................10 4.4. NEIG-PCE-DOMAIN Sub-TLV....................................11
4.1.4. NEIG-PCE-DOMAIN Sub-TLV....................................11 4.5. PCE-CAP-FLAGS Sub-TLV......................................12
4.1.5. PCE-CAP-FLAGS Sub-TLV......................................12 4.6. The OVERLOAD Sub-TLV.......................................13
4.1.6. The OVERLOAD Sub-TLV.......................................14
5. Elements of Procedure......................................14 5. Elements of Procedure......................................14
5.1. OVERLOAD sub-TLV Specific Procedures.......................15 5.1. OVERLOAD sub-TLV Specific Procedures.......................14
6. Backward Compatibility.....................................16 6. Backward Compatibility.....................................15
7. IANA Considerations........................................16 7. IANA Considerations........................................15
7.1. OSPF TLV...................................................16 7.1. OSPF TLV...................................................15
7.2. PCED Sub-TLVs Registry.....................................16 7.2. PCE Capability Flags registry..............................15
7.3. PCE Capability Flags registry..............................17 8. Security Considerations....................................16
8. Security Considerations....................................17 9. Manageability Considerations...............................16
9. Manageability Considerations...............................18 9.1. Control of Policy and Functions............................16
9.1. Control of Policy and Functions............................18 9.2. Information and Data Model.................................17
9.2. Information and Data Model.................................18 9.3. Liveness Detection and Monitoring..........................17
9.3. Liveness Detection and Monitoring..........................18 9.4. Verify Correct Operations..................................17
9.4. Verify Correct Operations..................................18
9.5. Requirements on Other Protocols and Functional 9.5. Requirements on Other Protocols and Functional
Components...............................................18 Components...............................................17
9.6. Impact on network operations...............................19 9.6. Impact on network operations...............................17
10. Acknowledgments............................................19 10. Acknowledgments............................................18
11. References.................................................19 11. References.................................................18
11.1. Normative references.......................................19 11.1. Normative references.......................................18
11.2. Informative references.....................................20 11.2. Informative references.....................................18
12. Editor's Addresses.........................................20 12. Editor's Addresses.........................................19
13. Contributors' Addresses....................................20 13. Contributors' Addresses....................................19
14. Intellectual Property Statement............................21 14. Intellectual Property Statement............................19
1. Terminology 1. Terminology
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.
skipping to change at page 4, line 53 skipping to change at page 4, line 47
When PCCs are LSRs participating in the IGP (OSPF or IS-IS), and PCEs When PCCs are LSRs participating in the IGP (OSPF or IS-IS), and PCEs
are either LSRs or servers also participating in the IGP, an are either LSRs or servers also participating in the IGP, an
effective mechanism for PCE discovery within an IGP routing domain effective mechanism for PCE discovery within an IGP routing domain
consists of utilizing IGP advertisements. consists of utilizing IGP advertisements.
This document defines OSPF extensions to allow a PCE in an OSPF This document defines OSPF extensions to allow a PCE in an OSPF
routing domain to advertise its location along with some information routing domain to advertise its location along with some information
useful to a PCC for PCE selection so as to satisfy dynamic PCE useful to a PCC for PCE selection so as to satisfy dynamic PCE
discovery requirements set forth in [RFC4674]. This document also discovery requirements set forth in [RFC4674]. This document also
defines extensions allowing a PCE in an OSPF routing domain to defines extensions allowing a PCE in an OSPF routing domain to
advertise its processing congestion state. advertise its overload state.
Generic capability advertisement mechanisms for OSPF are defined in Generic capability advertisement mechanisms for OSPF are defined in
[OSPF-CAP]. These allow a router to advertise its capabilities within [OSPF-CAP]. These allow a router to advertise its capabilities within
an OSPF area or an entire OSPF routing domain. This document an OSPF area or an entire OSPF routing domain. This document
leverages this generic capability advertisement mechanism to fully leverages this generic capability advertisement mechanism to fully
satisfy the aforementioned dynamic PCE discovery requirements. satisfy the aforementioned dynamic PCE discovery requirements.
This document defines a new TLV (named the PCE Discovery (PCED) TLV) This document defines a new TLV (named the PCE Discovery (PCED) TLV)
to be carried within the OSPF Router Information LSA ([OSPF-CAP]). to be carried within the OSPF Router Information LSA ([OSPF-CAP]).
skipping to change at page 5, line 50 skipping to change at page 5, line 41
- The set of one or more PCE-Domain(s) into which the PCE has - The set of one or more PCE-Domain(s) into which the PCE has
visibility and can compute paths; visibility and can compute paths;
- The set of one or more neighbor PCE-Domain(s) towards which a PCE - The set of one or more neighbor PCE-Domain(s) towards which a PCE
can compute paths; can compute paths;
- A set of communication capabilities (e.g. support for request - A set of communication capabilities (e.g. support for request
prioritization) and path computation specific capabilities prioritization) and path computation specific capabilities
(e.g. supported constraints). (e.g. supported constraints).
Optional elements to describe more complex capabilities may also be
advertised.
PCE Discovery information is by nature fairly static and does not PCE Discovery information is by nature fairly static and does not
change with PCE activity. Changes in PCE Discovery information may change with PCE activity. Changes in PCE Discovery information may
occur as a result of PCE configuration updates, PCE occur as a result of PCE configuration updates, PCE
deployment/activation, PCE deactivation/suppression, or PCE failure. deployment/activation, PCE deactivation/suppression, or PCE failure.
Hence, this information is not expected to change frequently. Hence, this information is not expected to change frequently.
3.2.1. PCE Overload Information 3.2.1. PCE Overload Information
The PCE Overload information is optional and can be used to report a The PCE Overload information is optional and can be used to report a
PCE's overload state in order to discourage the PCCs to send new path PCE's overload state in order to discourage the PCCs to send new path
skipping to change at page 6, line 31 skipping to change at page 6, line 19
The flooding scope for PCE information advertised through OSPF can be The flooding scope for PCE information advertised through OSPF can be
limited to one or more OSPF areas the PCE belongs to, or can be limited to one or more OSPF areas the PCE belongs to, or can be
extended across the entire OSPF routing domain. extended across the entire OSPF routing domain.
Note that some PCEs may belong to multiple areas, in which case the Note that some PCEs may belong to multiple areas, in which case the
flooding scope may comprise these areas. This could be the case for flooding scope may comprise these areas. This could be the case for
an ABR for instance advertising its PCE information within the an ABR for instance advertising its PCE information within the
backbone area and/or a subset of its attached IGP area(s). backbone area and/or a subset of its attached IGP area(s).
4. OSPF Extensions 4. The OSPF PCED TLV
4.1. The OSPF PCED TLV
The OSPF PCE Discovery TLV (PCED TLV) is made of a set of non-ordered The OSPF PCE Discovery TLV (PCED TLV) is made of a set of non-ordered
sub-TLVs. sub-TLVs.
The format of the OSPF PCED TLV and its sub-TLVs is identical to the The format of the OSPF PCED TLV and its sub-TLVs is identical to the
TLV format used by the Traffic Engineering Extensions to OSPF TLV format used by the Traffic Engineering Extensions to OSPF
[RFC3630]. That is, the TLV is comprised of 2 octets for the type, 2 [RFC3630]. That is, the TLV is comprised of 2 octets for the type, 2
octets specifying the TLV length, and a value field. The Length field octets specifying the TLV length, and a value field. The Length field
defines the length of the value portion in octets. defines the length of the value portion in octets.
The TLV is padded to four-octet alignment; padding is not included in The TLV is padded to four-octet alignment; padding is not included in
the Length field (so a three octet value would have a length of the Length field (so a three octet value would have a length of
three, but the total size of the TLV would be eight octets). Nested three, but the total size of the TLV would be eight octets). Nested
TLVs are also four-octet aligned. Unrecognized types are ignored. TLVs are also four-octet aligned. Unrecognized types are ignored.
All Type values between 32768 and 65535 are reserved for vendor-
specific extensions. All other undefined Type codes are reserved for
future assignment by IANA.
The OSPF PCED TLV has the following format: The OSPF PCED TLV has the following format:
1 2 3 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 | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// sub-TLVs // // sub-TLVs //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type To be defined by IANA (suggested value=5) Type To be defined by IANA (suggested value=5)
Length Variable Length Variable
Value This comprises one or more sub-TLVs Value This comprises one or more sub-TLVs
Six sub-TLVs are defined:
Sub-TLVs types are under IANA control.
Currently five sub-TLVs are defined (type values to be assigned by
IANA):
Sub-TLV type Length Name Sub-TLV type Length Name
1 variable PCE-ADDRESS sub-TLV 1 variable PCE-ADDRESS sub-TLV
2 4 PATH-SCOPE sub-TLV 2 4 PATH-SCOPE sub-TLV
3 variable PCE-DOMAIN sub-TLV 3 variable PCE-DOMAIN sub-TLV
4 variable NEIG-PCE-DOMAIN sub-TLV 4 variable NEIG-PCE-DOMAIN sub-TLV
5 variable PCE-CAP-FLAGS sub-TLV 5 variable PCE-CAP-FLAGS sub-TLV
6 4 OVERLOAD sub-TLV 6 4 OVERLOAD sub-TLV
The PCE-ADDRESS and PATH-SCOPE sub-TLVs MUST always be present within The PCE-ADDRESS and PATH-SCOPE sub-TLVs MUST always be present within
the PCED TLV. the PCED TLV.
The PCE-DOMAIN and NEIG-PCE-DOMAIN sub-TLVs are optional. They MAY be The PCE-DOMAIN and NEIG-PCE-DOMAIN sub-TLVs are optional. They MAY be
present in the PCED TLV to facilitate selection of inter-domain PCEs. present in the PCED TLV to facilitate selection of inter-domain PCEs.
The PCE-CAP-FLAGS sub-TLV is optional and MAY be present in the PCED The PCE-CAP-FLAGS sub-TLV is optional and MAY be present in the PCED
TLV to facilitate the PCE selection process. TLV to facilitate the PCE selection process.
The OVERLOAD sub-TLV is optional and MAY be present in the PCED TLV, The OVERLOAD sub-TLV is optional and MAY be present in the PCED TLV,
to indicate a PCE's processing congestion state. to indicate a PCE's overload state.
Any non recognized sub-TLV MUST be silently ignored. Any non recognized sub-TLV MUST be silently ignored.
Additional sub-TLVs could be added in the future to advertise
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].
No additional sub-TLVs will be added to the PCED TLV in the future.
If a future application requires advertising additional PCE
information in OSPF, this will not be carried in the Router
Information LSA.
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. 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.
If it appears more than once, only the first occurrence MUST be If it appears more than once, only the first occurrence MUST be
processed and other MUST be ignored. processed and other MUST be ignored.
The format of the PCE-ADDRESS sub-TLV is as follows: The format of the PCE-ADDRESS sub-TLV is as follows:
1 2 3 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 | Length | | Type = 1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| address-type | Reserved | | address-type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// PCE IP Address // // PCE IP Address //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PCE-ADDRESS sub-TLV format PCE-ADDRESS sub-TLV format
Type To be assigned by IANA (suggested value =1) Type 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.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. If it appears more than once, only the TLV within each PCED TLV. If it appears more than once, only the
first occurrence MUST be processed and other MUST be ignored. first occurrence MUST be processed and other MUST be ignored.
The PATH-SCOPE sub-TLV contains a set of bit flags indicating the The PATH-SCOPE sub-TLV contains a set of bit flags indicating the
supported path scopes and four fields indicating PCE preferences. supported path scopes and four fields indicating PCE preferences.
The PATH-SCOPE sub-TLV has the following format: The PATH-SCOPE sub-TLV has the following format:
1 2 3 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 | Length | | Type = 2 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|1|2|3|4|5| Reserved |PrefL|PrefR|PrefS|PrefY| Res | |0|1|2|3|4|5| Reserved |PrefL|PrefR|PrefS|PrefY| Res |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 2
Type To be defined by IANA (suggested value =2)
Length 4 Length 4
Value This comprises a 2-octet flag field where each bit Value This comprises a 2-octet flag field where each bit
represents a supported path scope, as well as four represents a supported path scope, as well as four
preference fields used to specify PCE preferences. preference fields used to specify PCE preferences.
The following bits are defined: The following bits are defined:
Bit Path Scope Bit Path Scope
0 L bit: Can compute intra-area paths 0 L bit: Can compute intra-area paths
skipping to change at page 10, line 34 skipping to change at page 10, line 21
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.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).
A PCED TLV MAY include multiple PCE-DOMAIN sub-TLVs when the PCE has A PCED TLV MAY include multiple PCE-DOMAIN sub-TLVs when the PCE has
visibility in multiple PCE-Domains. visibility in multiple PCE-Domains.
The PCE-DOMAIN sub-TLV has the following format: The PCE-DOMAIN sub-TLV has the following format:
1 2 3 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 | Length | | Type=3 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Domain-type | Reserved | | Domain-type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Domain ID // // Domain ID //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PCE-DOMAIN sub-TLV format PCE-DOMAIN sub-TLV format
Type To be assigned by IANA (suggested value =3) Type 3
Length Variable Length Variable
3 domain-type values are defined: 3 domain-type values are defined:
1 IPv4 Area Address 1 IPv4 Area Address
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 octets (which is the current visibility. When coded in two octets (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
skipping to change at page 11, line 35 skipping to change at page 11, line 15
1 IPv4 Area Address 1 IPv4 Area Address
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 octets (which is the current visibility. When coded in two octets (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 first two octets set to 0. Number field MUST have its first two octets set to 0.
. .
4.1.4. NEIG-PCE-DOMAIN Sub-TLV 4.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
sub-TLV: sub-TLV:
1 2 3 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 | Length | | Type = 4 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Domain-type | Reserved | | Domain-type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Domain ID // // Domain ID //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NEIG-PCE-DOMAIN sub-TLV format NEIG-PCE-DOMAIN sub-TLV format
Type To be assigned by IANA (suggested value =4) Type 4
Length Variable Length Variable
3 domain-type values are defined: 3 domain-type values are defined:
1 IPv4 Area Address 1 IPv4 Area Address
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 Domain ID: With the address type 1/2 this indicates the
IPv4/v6 address of a neighbour area towards which the PCE can IPv4/v6 address of a neighbour area towards which the PCE can
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 octets (which is the current defined format as the coded in two octets (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 first two octets set to 0. its first two octets 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.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. If it appears more than once, only the first present more than once. If it appears more than once, only the first
occurrence MUST be processed and other MUST be ignored. occurrence MUST be processed and other MUST be ignored.
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:
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 | Length | | Type = 5 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// PCE Capability Flags // // PCE Capability Flags //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type To be assigned by IANA (suggested value =5) Type 5
Length Multiple of 4 octets Length Multiple of 4 octets
Value This contains an array of units of 32 bit flags Value This contains an array of units of 32 bit flags
numbered from the most significant as bit zero, where numbered from the most significant as bit zero, where
each bit represents one PCE capability. each bit represents one PCE capability.
IANA is requested to manage the space of the PCE Capability Flags IANA is requested to manage the space of the PCE Capability Flags
The following bits are to be assigned by IANA: The following bits are to be assigned by IANA:
Bit Capabilities Bit Capabilities
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
4 Synchronized paths computation 4 Synchronized paths computation
5 Support for multiple objective functions 5 Support for multiple objective functions
skipping to change at page 14, line 5 skipping to change at page 13, line 26
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. OVERLOAD Sub-TLV 4.6. The OVERLOAD Sub-TLV
The OVERLOAD sub-TLV is used to indicate that a PCE is experiencing The OVERLOAD sub-TLV is used to indicate that a PCE is experiencing
a processing congestion state and may optionally include the expected a processing overload state.
PCE congestion duration.
The OVERLOAD sub-TLV is optional, it MAY be carried within the PCED The OVERLOAD sub-TLV is optional, it MAY be carried within the PCED
TLV. It MUST NOT be present more than once. If it appears more than TLV. It MUST NOT be present more than once. If it appears more than
once, only the first occurrence MUST be processed and other MUST be once, only the first occurrence MUST be processed and other MUST be
ignored. ignored.
The format of the OVERLOAD sub-TLV is as follows: The format of the OVERLOAD sub-TLV is as follows:
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 | Length | | Type = 6 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| Reserved | |C| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type To be assigned by IANA (suggested value =6) Type 6
Length 4 Length 4
Value Value
-C bit: When set this indicates that the PCE is overloaded -C bit: When set this indicates that the PCE is overloaded
and cannot accept any new request. When cleared this and cannot accept any new request. When cleared this
indicates that the PCE is not overloaded and can indicates that the PCE is not overloaded and can
accept new requests. accept new requests.
5. Elements of Procedure 5. Elements of Procedure
The PCED TLV is advertised within OSPFv2 Router Information LSAs The PCED TLV is advertised within OSPFv2 Router Information LSAs
skipping to change at page 15, line 30 skipping to change at page 14, line 53
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. OVERLOAD sub-TLV Specific Procedures 5.1. OVERLOAD sub-TLV Specific Procedures
When a PCE enters into an overload state, the conditions of which are When a PCE enters into an overload state, the conditions of which are
implementation dependent, a Router Information LSA with an OVERLOAD implementation dependent, a Router Information LSA with an OVERLOAD
sub-TLV with the C bit set MAY be generated. sub-TLV with the C bit set MAY be generated.
When a PCE exits from an overload state, the conditions of which When a PCE exits from an overload state, the conditions of which are
are implementation dependent (e.g. CPU utilization, average queue implementation dependent (e.g. CPU utilization, average queue length
length below some pre-defined threshold), a new Router Information below some pre-defined threshold), a new Router Information LSA with
LSA with an OVERLOAD sub-TLV with the C bit cleared SHOULD be an OVERLOAD sub-TLV with the C bit cleared SHOULD be generated, if
generated, if the overload information had been previously the overload information had been previously advertised.
advertised.
A PCE implementation supporting the OSPF extensions defined in this A PCE implementation supporting the OSPF extensions defined in this
document SHOULD support an appropriate dampening algorithm so as to document SHOULD support an appropriate dampening algorithm so as to
dampen OSPF flooding of PCE Overload information in order to not dampen OSPF flooding of PCE Overload information in order to not
impact the OSPF scalability. It is RECOMMENDED to introduce some impact the OSPF scalability. It is RECOMMENDED to introduce some
hysteresis for overload state transition, so as to avoid state hysteresis for overload state transition, so as to avoid state
oscillations that may impact OSPF performance. For instance two oscillations that may impact OSPF performance. For instance two
thresholds MAY be configured: An upper-threshold and a lower- thresholds MAY be configured: An upper-threshold and a lower-
threshold; an LSR enters the overload state when the CPU load reaches threshold; an LSR enters the overload state when the CPU load reaches
the upper threshold and leaves the overload state when the CPU load the upper threshold and leaves the overload state when the CPU load
skipping to change at page 16, line 25 skipping to change at page 15, line 43
7.1. OSPF TLV 7.1. OSPF TLV
Once the OSPF RI TLVs registry defined in [OSPF-CAP] will have been Once the OSPF RI TLVs registry defined in [OSPF-CAP] will have been
assigned, IANA will assign a new TLV code-point for the PCED TLV assigned, IANA will assign a new TLV code-point for the PCED TLV
carried within the Router Information LSA. carried within the Router Information LSA.
Value TLV Name Reference Value TLV Name Reference
----- -------- ---------- ----- -------- ----------
5 PCED (this document) 5 PCED (this document)
7.2. PCED Sub-TLVs Registry 7.2. PCE Capability Flags registry
The PCED TLV referenced above is constructed from sub-TLVs. Each sub-
TLV includes a 16-bit type identifier.
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, and manage sub-TLV type identifiers as follows:
- sub-TLV Type
- sub-TLV Name
- Reference
This document defines five sub-TLVs as follows (suggested values):
Sub-TLV Sub-TLV
Type Name Reference
----- -------- ----------
1 PCE-ADDRESS This document
2 PATH-SCOPE This document
3 PCE-DOMAIN This document
4 NEIG-PCE-DOMAIN This document
5 PCE-CAP-FLAGS This document
6 OVERLOAD This document
New sub-TLV type values may be allocated only by an IETF Consensus
action.
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 top-level OSPF registry, the The IANA is requested to create a new top-level OSPF registry, the
"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.
 End of changes. 40 change blocks. 
112 lines changed or deleted 68 lines changed or added

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