draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt   draft-ietf-ccamp-gmpls-ason-routing-ospf-09.txt 
Network Working Group Dimitri Papadimitriou Network Working Group Dimitri Papadimitriou
Internet Draft (Alcatel-Lucent) Internet Draft (Alcatel-Lucent)
Category: Experimental Category: Experimental
Created: April 7, 2009 Created: August 16, 2009
Expires: October 7, 2009 Expires: February 16, 2010
OSPFv2 Routing Protocols Extensions for ASON Routing OSPFv2 Routing Protocols Extensions for ASON Routing
draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt draft-ietf-ccamp-gmpls-ason-routing-ospf-09.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 47 skipping to change at page 1, line 46
an Automatically Switched Optical Network (ASON). an Automatically Switched Optical Network (ASON).
The Generalized Multiprotocol Label Switching (GMPLS) protocol suite The Generalized Multiprotocol Label Switching (GMPLS) protocol suite
is designed to provide a control plane for a range of network is designed to provide a control plane for a range of network
technologies including optical networks such as time division technologies including optical networks such as time division
multiplexing (TDM) networks including SONET/SDH and Optical Transport multiplexing (TDM) networks including SONET/SDH and Optical Transport
Networks (OTNs), and lambda switching optical networks. Networks (OTNs), and lambda switching optical networks.
The requirements for GMPLS routing to satisfy the requirements of The requirements for GMPLS routing to satisfy the requirements of
ASON routing, and an evaluation of existing GMPLS routing protocols ASON routing, and an evaluation of existing GMPLS routing protocols
are provided in other documents. This document defines to the OSPFv2 are provided in other documents. This document defines extensions to
Link State Routing Protocol to meet the routing requirements for the OSPFv2 Link State Routing Protocol to meet the requirements for
routing in an ASON. routing in an ASON.
Note that this work is scoped to the requirements and evaluation Note that this work is scoped to the requirements and evaluation
expressed in RFC 4258 and RFC 4652 and the ITU-T Recommendations expressed in RFC 4258 and RFC 4652 and the ITU-T Recommendations
current when those documents were written. Future extensions of current when those documents were written. Future extensions of
revisions of this work may be necessary if the ITU-T Recommendations revisions of this work may be necessary if the ITU-T Recommendations
are revised or if new requirements are introduced into a revision of are revised or if new requirements are introduced into a revision of
RFC 4258. RFC 4258.
Table of Contents Table of Contents
1. Introduction................................................. 3 1. Introduction................................................. 3
1.1. Conventions Used In This Document.......................... 4 1.1. Conventions Used In This Document.......................... 4
2. Routing Areas, OSPF Areas, and Protocol Instances............ 4 2. Routing Areas, OSPF Areas, and Protocol Instances............ 4
3. Reachability................................................. 4 3. Reachability................................................. 5
3.1 Node IPv4 Local Prefix Sub-TLV.............................. 5 3.1 Node IPv4 Local Prefix Sub-TLV.............................. 5
3.2 Node IPv6 Local Prefix Sub-TLV.............................. 6 3.2 Node IPv6 Local Prefix Sub-TLV.............................. 6
4. Link Attribute............................................... 7 4. Link Attribute............................................... 7
4.1 Local Adaptation............................................ 7 4.1 Local Adaptation............................................ 7
4.2 Bandwidth Accounting........................................ 8 4.2 Bandwidth Accounting........................................ 8
5. Routing Information Scope.................................... 8 5. Routing Information Scope.................................... 8
5.1 Terminology and Identification.............................. 8 5.1 Terminology and Identification.............................. 8
5.2 Link Advertisement (Local and Remote TE Router ID Sub-TLV).. 9 5.2 Link Advertisement (Local and Remote TE Router ID Sub-TLV).. 9
5.3 Reachability Advertisement (Local TE Router ID Sub-TLV).... 10 5.3 Reachability Advertisement (Local TE Router ID Sub-TLV).... 10
6. Routing Information Dissemination........................... 10 6. Routing Information Dissemination........................... 11
6.1 Import/Export Rules........................................ 11 6.1 Import/Export Rules........................................ 11
6.2 Discovery and Selection.................................... 12 6.2 Discovery and Selection.................................... 12
6.2.1 Upward Discovery and Selection........................... 12 6.2.1 Upward Discovery and Selection........................... 12
6.2.2 Downward Discovery and Selection......................... 12 6.2.2 Downward Discovery and Selection......................... 13
6.3 Loop Prevention............................................ 14 6.2.3. Router Information Experimental Capabilities TLV........ 15
6.3.1 Associated RA ID......................................... 15 6.3 Loop Prevention............................................ 15
6.3.2 Processing............................................... 15 6.3.1 Associated RA ID......................................... 16
6.4 Resiliency................................................. 16 6.3.2 Processing............................................... 17
6.5 Neighbor Relationship and Routing Adjacency................ 17 6.4 Resiliency................................................. 18
6.6 Reconfiguration............................................ 17 6.5 Neighbor Relationship and Routing Adjacency................ 19
7. OSPFv2 Extensions........................................... 18 6.6 Reconfiguration............................................ 19
7.1 Compatibility.............................................. 18 7. OSPFv2 Scalability.......................................... 20
7.2 Scalability................................................ 19 8. Security Considerations..................................... 20
8. Security Considerations..................................... 19
9. IANA Considerations......................................... 20 9. IANA Considerations......................................... 20
9.1 Sub-TLVs for the OSPF Opaque TE LSA........................ 20 10. Experimental Code Points................................... 21
9.2 OSPF RI LSA................................................ 20 10.1. Sub-TLVs of the Link TLV................................. 21
9.2.1 RI Capability Bits....................................... 20 10.2. Sub-TLVs of the Node Attribute TLV....................... 21
9.2.2 RI LSA TLVs.............................................. 21 10.3. Sub-TLVs of the Router Address TLV....................... 22
10. References................................................. 21 10.4. TLVs of the Router Information LSA....................... 22
10.1 Normative References...................................... 21 11. References................................................. 23
10.2 Informative References.................................... 22 11.1 Normative References...................................... 23
11. Author's Address........................................... 23 11.2 Informative References.................................... 24
Appendix 1: ASON Terminology................................... 24 12. Author's Address........................................... 25
Appendix 2: ASON Routing Terminology........................... 26 Appendix 1: ASON Terminology................................... 26
Appendix 2: ASON Routing Terminology........................... 28
1. Introduction 1. Introduction
The Generalized Multiprotocol Label Switching (GMPLS) [RFC3945] The Generalized Multiprotocol Label Switching (GMPLS) [RFC3945]
protocol suite is designed to provide a control plane for a range of protocol suite is designed to provide a control plane for a range of
network technologies including optical networks such as time division network technologies including optical networks such as time division
multiplexing (TDM) networks including SONET/SDH and Optical Transport multiplexing (TDM) networks including SONET/SDH and Optical Transport
Networks (OTNs), and lambda switching optical networks. Networks (OTNs), and lambda switching optical networks.
The ITU-T defines the architecture of the Automatically Switched The ITU-T defines the architecture of the Automatically Switched
skipping to change at page 4, line 5 skipping to change at page 4, line 5
attributes (and their processing) may be defined in other documents attributes (and their processing) may be defined in other documents
that complement this document. that complement this document.
Note that this work is scoped to the requirements and evaluation Note that this work is scoped to the requirements and evaluation
expressed in [RFC4258] and [RFC4652] and the ITU-T Recommendations expressed in [RFC4258] and [RFC4652] and the ITU-T Recommendations
current when those documents were written. Future extensions of current when those documents were written. Future extensions of
revisions of this work may be necessary if the ITU-T Recommendations revisions of this work may be necessary if the ITU-T Recommendations
are revised or if new requirements are introduced into a revision of are revised or if new requirements are introduced into a revision of
[RFC4258]. [RFC4258].
This document is classified as Experimental. Significant changes to
routing protocols are of concern to the stability of the Internet.
The extensions described in this document are intended for cautious
use in self-contained environments. The objective is to determine
whether these extensions are stable and functional, whether there is
a demand for implementation and deployment, and whether the
extensions have any impact on existing routing protocol deployments.
1.1. Conventions Used in This Document 1.1. 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 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
The reader is assumed to be familiar with the terminology and The reader is assumed to be familiar with the terminology and
requirements developed in [RFC4258] and the evaluation outcomes requirements developed in [RFC4258] and the evaluation outcomes
detailed in [RFC4652]. detailed in [RFC4652].
skipping to change at page 5, line 11 skipping to change at page 5, line 21
This extension takes the form of a network mask (a 32-bit number This extension takes the form of a network mask (a 32-bit number
indicating the range of IP addresses residing on a single IP indicating the range of IP addresses residing on a single IP
network/subnet). The set of local addresses are carried in an OSPFv2 network/subnet). The set of local addresses are carried in an OSPFv2
TE LSA node attribute TLV (a specific sub-TLV is defined per address TE LSA node attribute TLV (a specific sub-TLV is defined per address
family, i.e., IPv4 and IPv6, used as network-unique identifiers). family, i.e., IPv4 and IPv6, used as network-unique identifiers).
The proposed solution is to advertise the local address prefixes of The proposed solution is to advertise the local address prefixes of
a router as new sub-TLVs of the (OSPFv2 TE LSA) Node Attribute top a router as new sub-TLVs of the (OSPFv2 TE LSA) Node Attribute top
level TLV. This document defines the following sub-TLVs: level TLV. This document defines the following sub-TLVs:
- Node IPv4 Local Prefix sub-TLV: Type 3 (TBD) - Length: variable - Node IPv4 Local Prefix sub-TLV: Length: variable
- Node IPv6 Local Prefix sub-TLV: Type 4 (TBD) - Length: variable - Node IPv6 Local Prefix sub-TLV: Length: variable
3.1 Node IPv4 Local Prefix Sub-TLV 3.1 Node IPv4 Local Prefix Sub-TLV
The Type of the Node IPv4 Local Prefix sub-TLV is 3 (TBD). The Value The Type field of the Node IPv4 Local Prefix sub-TLV is assigned a
field of this sub-TLV contains one or more local IPv4 prefixes. The value in the range 32768-32777 agreed by all participants in the
Length is set to 8 x n, where n is the number of local IPv4 prefixes experiment. The Value field of this sub-TLV contains one or more
included in the sub-TLV. local IPv4 prefixes. The Length is measured in bytes and, as defined
in [RFC3630] reports the length in bytes of the Value part of the
sub-TLV. It is set to 8 x n, where n is the number of local IPv4
prefixes included in the sub-TLV.
The Node IPv4 Local Prefix sub-TLV has the following format: The Node IPv4 Local Prefix sub-TLV has the following format:
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 (3 - TBD) | Length (8 x n) | | Type | Length (8 x n) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Mask 1 | | Network Mask 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address 1 | | IPv4 Address 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// ... // // ... //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Mask n | | Network Mask n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address n | | IPv4 Address n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Network mask i: A 32-bit number indicating the IPv4 address mask
Network mask "i": A 32-bit number indicating the IPv4 address mask for the ith advertised destination prefix.
for the advertised destination prefix "i".
Each <Network mask, IPv4 Address> pair listed as part of this sub- Each <Network mask, IPv4 Address> pair listed as part of this sub-
TLV represents a reachable destination prefix hosted by the TLV represents a reachable destination prefix hosted by the
advertising Router ID. advertising Router ID.
The local addresses that can be learned from Opaque TE LSAs (that is, The local addresses that can be learned from Opaque TE LSAs (that is,
the router address and TE interface addresses) SHOULD NOT be the router address and TE interface addresses) SHOULD NOT be
advertised in the node IPv4 local prefix sub-TLV. advertised in the node IPv4 local prefix sub-TLV.
3.2 Node IPv6 Local Prefix Sub-TLV 3.2 Node IPv6 Local Prefix Sub-TLV
The Type of the Node IPv6 Local Prefix sub-TLV is 4 (TBD). The Value The Type field of the Node IPv6 Local Prefix sub-TLV is assigned a
field of this sub-TLV contains one or more local IPv6 prefixes. IPv6 value in the range 32768-32777 agreed by all participants in the
Prefix representation uses [RFC5340] Section A.4.1. experiment. The Value field of this sub-TLV contains one or more
local IPv6 prefixes. IPv6 Prefix representation uses [RFC5340]
Section A.4.1.
The Node IPv6 Local Prefix sub-TLV has the following format: The Node IPv6 Local Prefix sub-TLV has the following format:
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 (4 - TBD) | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | (0) | | PrefixLength | PrefixOptions | (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| IPv6 Address Prefix 1 | | IPv6 Address Prefix 1 |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// ... // // ... //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | (0) | | PrefixLength | PrefixOptions | (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| IPv6 Address Prefix n | | IPv6 Address Prefix n |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length reports the length of the Value part of the sub-TLV in
Length is set to the sum over all of the local prefixes included in bytes. It is set to the sum over all of the local prefixes
the sub-TLV of (4 + (number of 32-bit words in the prefix)/4 ). included in the sub-TLV of
(4 + (number of 32-bit words in the prefix) * 4).
The encoding of each prefix potentially using fewer than four The encoding of each prefix potentially using fewer than four
32-bit words is described below. 32-bit words is described below.
PrefixLength: length in bits of the prefix. PrefixLength: Length in bits of the prefix.
PrefixOptions: 8-bit field describing various capabilities PrefixOptions: 8-bit field describing various capabilities
associated with the prefix (see [RFC5340] Section A.4.2). associated with the prefix (see [RFC5340] Section A.4.2).
IPv6 Address Prefix "i": encoding of the prefix "i" itself as an IPv6 Address Prefix i: The ith IPv6 address prefix in the list.
even multiple of 32-bit words, padding with zero bits as Each prefix is encoded in an even multiple of 32-bit words using
necessary. the fewest pairs of 32-bit words necessary to include the entire
prefix. Thus, each prefix is encoded in either 64 or 128 bits
with trailing zero bit padding as necessary.
The local addresses that can be learned from TE LSAs, i.e., router The local addresses that can be learned from TE LSAs, i.e., router
address and TE interface addresses, SHOULD NOT be advertised in the address and TE interface addresses, SHOULD NOT be advertised in the
node IPv6 local prefix sub-TLV. node IPv6 local prefix sub-TLV.
4. Link Attribute 4. Link Attribute
[RFC4652] provides a map between link attributes and characteristics [RFC4652] provides a map between link attributes and characteristics
and their representation in sub-TLVs of the top level Link TLV of the and their representation in sub-TLVs of the top level Link TLV of the
Opaque TE LSA [RFC3630] and [RFC4203], with the exception of the Opaque TE LSA [RFC3630] and [RFC4203], with the exception of the
skipping to change at page 9, line 33 skipping to change at page 9, line 51
brief, as unnumbered links have their ID defined on per Li bases, brief, as unnumbered links have their ID defined on per Li bases,
the remote Lj needs to be identified to scope the link remote ID to the remote Lj needs to be identified to scope the link remote ID to
the local Li. Therefore, the routing protocol MUST be able to the local Li. Therefore, the routing protocol MUST be able to
disambiguate the advertised TE links so that they can be associated disambiguate the advertised TE links so that they can be associated
with the correct TE Router-ID. with the correct TE Router-ID.
For this purpose, a new sub-TLV of the (OSPFv2 TE LSA) top level For this purpose, a new sub-TLV of the (OSPFv2 TE LSA) top level
Link TLV is introduced that defines the local and the remote Link TLV is introduced that defines the local and the remote
TE Router-ID. TE Router-ID.
The Type of the Local and Remote TE Router-ID sub-TLV is 25 (TBD), The Type field of the Local and Remote TE Router-ID sub-TLV is
and its length is 8 octets. The Value field of this sub-TLV contains assigned a value in the range 32768-32777 agreed by all participants
4 octets of Local TE Router Identifier followed by 4 octets of Remote in the experiment. The Length field takes the value 8. The Value
TE Router Identifier. The value of the Local and the Remote TE field of this sub-TLV contains 4 octets of Local TE Router Identifier
Router Identifier SHOULD NOT be set to 0. followed by 4 octets of Remote TE Router Identifier. The value of the
Local and the Remote TE Router Identifier SHOULD NOT be set to 0.
The format of the Local and Remote TE Router-ID sub-TLV is: The format of the Local and Remote TE Router-ID sub-TLV is:
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 (25 - TBD) | Length (8) | | Type | Length (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local TE Router Identifier | | Local TE Router Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote TE Router Identifier | | Remote TE Router Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This sub-TLV is only required to be included as part of the top This sub-TLV is only required to be included as part of the top
level Link TLV if the Router-ID is advertising on behalf of more level Link TLV if the Router-ID is advertising on behalf of more
than one TE Router-ID. In any other case, this sub-TLV SHOULD be than one TE Router-ID. In any other case, this sub-TLV SHOULD be
omitted except if operator plans to start of with 1 Li and omitted except if operator plans to start of with 1 Li and
skipping to change at page 10, line 23 skipping to change at page 10, line 42
defined in [RFC3630]. defined in [RFC3630].
5.3 Reachability Advertisement (Local TE Router ID sub-TLV) 5.3 Reachability Advertisement (Local TE Router ID sub-TLV)
When the Router-ID is advertised on behalf of multiple TE Router-IDs When the Router-ID is advertised on behalf of multiple TE Router-IDs
(Lis), the routing protocol MUST be able to associate the advertised (Lis), the routing protocol MUST be able to associate the advertised
reachability information with the correct TE Router-ID. reachability information with the correct TE Router-ID.
For this purpose, a new sub-TLV of the (OSPFv2 TE LSA) top level For this purpose, a new sub-TLV of the (OSPFv2 TE LSA) top level
Node Attribute TLV is introduced. This TLV associates the local Node Attribute TLV is introduced. This TLV associates the local
prefixes (sub-TLV 3 and 4, TBD see above) to a given TE Router-ID. prefixes (see above) to a given TE Router-ID.
The Type of the Local TE Router-ID sub-TLV is 5 (TBD), and its Length The Type field of the Local TE Router-ID sub-TLV is assigned a value
is 4 octets. The value field of this sub-TLV contains the Local TE in the range 32768-32777 agreed by all participants in the
Router Identifier [RFC3630] encoded over 4 octets. experiment. The Length field takes the value 4. The Value field of
this sub-TLV contains the Local TE Router Identifier [RFC3630]
encoded over 4 octets.
The format of the Local TE Router-ID sub-TLV is: The format of the Local TE Router-ID sub-TLV is:
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 (5 - TBD) | Length (4) | | Type | Length (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local TE Router Identifier | | Local TE Router Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This sub-TLV is only required to be included be included as part of This sub-TLV is only required to be included be included as part of
the Node Attribute TLV if the Router-ID is advertising on behalf of the Node Attribute TLV if the Router-ID is advertising on behalf of
more than one TE Router-ID. In any other case, this sub-TLV SHOULD more than one TE Router-ID. In any other case, this sub-TLV SHOULD
be omitted. be omitted.
6. Routing Information Dissemination 6. Routing Information Dissemination
skipping to change at page 12, line 15 skipping to change at page 12, line 40
In practice, and in order to avoid scalability and processing In practice, and in order to avoid scalability and processing
overhead, routing information imported/exported downward/upward in overhead, routing information imported/exported downward/upward in
the hierarchy is expected to include reachability information (see the hierarchy is expected to include reachability information (see
Section 3) and, upon strict policy control, link topology Section 3) and, upon strict policy control, link topology
information. information.
6.2 Discovery and Selection 6.2 Discovery and Selection
6.2.1 Upward Discovery and Selection 6.2.1 Upward Discovery and Selection
In order to discover RCs that are capable to disseminate routing In order to discover RCs that are capable of disseminating routing
information up the routing hierarchy, the following Capability information up the routing hierarchy, the following capability
Descriptor bit [RFC4970] is defined: descriptor bit is set in the OSPF Router Information Experimental
Capabilities TLV (see Section 6.2.3) carried in the Router
Information LSA ([RFC4970]).
- U bit: When set, this flag indicates that the RC is capable of - U bit: When set, this flag indicates that the RC is capable of
disseminating routing information upward to the adjacent level. disseminating routing information upward to the adjacent level.
In the case that multiple RCs are advertized from the same RA with In the case that multiple RCs are advertized from the same RA with
their U bit set, the RC with the highest Router-ID, among those RCs their U bit set, the RC with the highest Router-ID, among those RCs
with the U bit set, SHOULD be selected as the RC for upward with the U bit set, SHOULD be selected as the RC for upward
dissemination of routing information. The other RCs MUST NOT dissemination of routing information. The other RCs MUST NOT
participate in the upward dissemination of routing information as participate in the upward dissemination of routing information as
long as the opaque LSA information corresponding to the highest long as the opaque LSA information corresponding to the highest
skipping to change at page 12, line 40 skipping to change at page 13, line 18
hierarchy from the same RA. hierarchy from the same RA.
Note that if the information to allow the selection of the RC that Note that if the information to allow the selection of the RC that
will be used to disseminate routing information up the hierarchy from will be used to disseminate routing information up the hierarchy from
a specific RA cannot be discovered automatically, it MUST be manually a specific RA cannot be discovered automatically, it MUST be manually
configured. configured.
Once an RC has been selected, it remains unmodified even if an RC Once an RC has been selected, it remains unmodified even if an RC
with a higher Router-ID is introduced and advertizes its capability with a higher Router-ID is introduced and advertizes its capability
to disseminate routing information upward the adjacent level (i.e., to disseminate routing information upward the adjacent level (i.e.,
U-bit set). This hysteresis mechanism prevents from disturbing the U bit set). This hysteresis mechanism prevents from disturbing the
upward routing information dissemination process in case, e.g., of upward routing information dissemination process in case, e.g., of
flapping. flapping.
6.2.2 Downward Discovery and Selection 6.2.2 Downward Discovery and Selection
The same discovery mechanism is used for selecting the RC responsible The same discovery mechanism is used for selecting the RC responsible
for dissemination of routing information downward in the hierarchy. for dissemination of routing information downward in the hierarchy.
However, an additional restriction MUST be applied such that the RC However, an additional restriction MUST be applied such that the RC
selection process takes into account that an upper level may be selection process takes into account that an upper level may be
adjacent to one or more lower (RA) levels. For this purpose a adjacent to one or more lower (RA) levels. For this purpose a
specific TLV indexing the (lower) RA ID to which the RC's are capable specific TLV indexing the (lower) RA ID to which the RC's are capable
of disseminating routing information is needed. of disseminating routing information is needed.
The Downstream Associated RA ID TLV is carried in the OSPF router The Downstream Associated RA ID TLV is carried in the OSPF Router
information LSA [RFC4970]. The Length of this TLV is n x 4 octets. Information LSA [RFC4970]. The Type field of the Downstream
The Value field of this sub-TLV contains the list of Associated RA Associated RA ID TLV is assigned a value in the range 32768-32777
IDs. Each Associated RA ID value is encoded following the OSPF area agreed by all participants in the experiment. The Length of this TLV
ID (32 bits) encoding rules defined in [RFC2328]. is n x 4 octets. The Value field of this sub-TLV contains the list of
Associated RA IDs. Each Associated RA ID value is encoded following
the OSPF area ID (32 bits) encoding rules defined in [RFC2328].
The format of the Downstream Associated RA ID TLV is: The format of the Downstream Associated RA ID TLV is:
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 (7 - TBD) | Length (4 x n) | | Type | Length (4 x n) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Associated RA ID 1 | | Associated RA ID 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// ... // // ... //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Associated RA ID n | | Associated RA ID n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note that this information MUST be present when the D bit is set. To To discover RCs that are capable to disseminate routing information
discover RCs that are capable to disseminate routing information downward the routing hierarchy, the following capability descriptor
downward the routing hierarchy, the following Capability Descriptor bit is set in the OSPF Router Information Experimental Capabilities
bit [RFC4970] is defined, that MUST be advertised together with the TLV (see Section 6.2.3) carried in the Router Information LSA
Downstream Associated RA ID TLV: ([RFC4970]).
Note that the Downstream Associated RA ID TLV MUST be present when
the D bit is set.
- D bit: when set, this flag indicates that the RC is capable to - D bit: when set, this flag indicates that the RC is capable to
disseminate routing information downward the adjacent levels. disseminate routing information downward the adjacent levels.
If multiple RCs are advertised for the same Associated RA ID, the RC If multiple RCs are advertised for the same Associated RA ID, the RC
with the highest Router ID, among the RCs with the D bit set, MUST be with the highest Router ID, among the RCs with the D bit set, MUST be
selected as the RC for downward dissemination of routing information. selected as the RC for downward dissemination of routing information.
The other RCs for the same Associated RA ID MUST NOT participate in The other RCs for the same Associated RA ID MUST NOT participate in
the downward dissemination of routing information as long as the the downward dissemination of routing information as long as the
opaque LSA information corresponding to the highest Router ID RC does opaque LSA information corresponding to the highest Router ID RC does
skipping to change at page 14, line 6 skipping to change at page 15, line 5
Note that if the information to allow the selection of the RC that Note that if the information to allow the selection of the RC that
will be used to disseminate routing information down the hierarchy to will be used to disseminate routing information down the hierarchy to
a specific RA cannot be discovered automatically, it MUST be manually a specific RA cannot be discovered automatically, it MUST be manually
configured. configured.
The OSPF Router information Opaque LSA (Opaque type of 4, Opaque ID The OSPF Router information Opaque LSA (Opaque type of 4, Opaque ID
of 0) and its content, in particular the Router Informational of 0) and its content, in particular the Router Informational
Capabilities TLV [RFC4970] and TE Node Capability Descriptor TLV Capabilities TLV [RFC4970] and TE Node Capability Descriptor TLV
[RFC5073], MUST NOT be re-originated. [RFC5073], MUST NOT be re-originated.
6.2.3. Router Information Experimental Capabilities TLV
A new TLV is defined for inclusion in the Router Information LSA to
carry experimental capabilities because the assignment policy for
bits in the Router Informational Capabilities TLV is "Standards
Action" [RFC5226] prohibiting its use from Experimental documents.
The format of the Router Information Experimental Capabilities TLV is
as follows:
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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Experimental Capabilities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type A value in the range 32768-32777 agreed by all
participants in the experiment.
Length A 16-bit field that indicates the length of the value
portion in octets and will be a multiple of 4 octets
dependent on the number of capabilities advertised.
Initially, the length will be 4, denoting 4 octets of
informational capability bits.
Value A variable length sequence of capability bits rounded
to a multiple of 4 octets padded with undefined bits.
The following experimental capability bits are assigned:
Bit Capabilities
0 The U bit (see Section 6.2.1)
1 The D bit (see Section 6.2.2)
6.3 Loop Prevention 6.3 Loop Prevention
When more than one RC is bound to an adjacent level of the hierarchy, When more than one RC is bound to an adjacent level of the hierarchy,
and is configured or selected to redistribute routing information and is configured or selected to redistribute routing information
upward and downward, a specific mechanism is required to avoid upward and downward, a specific mechanism is required to avoid
looping of routing information. Looping is the re-introduction of looping of routing information. Looping is the re-introduction of
routing information that has been advertized from the upper level routing information that has been advertized from the upper level
back to the upper level. This specific case occurs, for example, when back to the upper level. This specific case occurs, for example, when
the RC advertizing routing information downward in the hierarchy is the RC advertizing routing information downward in the hierarchy is
not the same one that advertizes routing upward in the hierarchy. not the same one that advertizes routing upward in the hierarchy.
skipping to change at page 15, line 15 skipping to change at page 16, line 48
6.3.1 Associated RA ID 6.3.1 Associated RA ID
We need some way of filtering the downward/upward re-originated We need some way of filtering the downward/upward re-originated
Opaque TE LSA. Per [RFC5250], the information contained in Opaque Opaque TE LSA. Per [RFC5250], the information contained in Opaque
LSAs may be used directly by OSPF. By adding the RA ID associated LSAs may be used directly by OSPF. By adding the RA ID associated
with the incoming routing information the loop prevention problem can with the incoming routing information the loop prevention problem can
be solved. be solved.
This additional information, referred to as the Associated RA ID, MAY This additional information, referred to as the Associated RA ID, MAY
be carried in opaque LSAs that including any of the following top be carried in opaque LSAs that including any of the following top
level LSAs: level TLVs:
- the Router Address top level TLV - the Router Address top level TLV
- the Link top level TLV - the Link top level TLV
- the Node Attribute top level TLV. - the Node Attribute top level TLV.
The Associated RA ID reflects the identifier of the area from which The Associated RA ID reflects the identifier of the area from which
the routing information is received. For example, for a multi-level the routing information is received. For example, for a multi-level
hierarchy, this identifier does not reflect the originating RA ID, it hierarchy, this identifier does not reflect the originating RA ID, it
will reflect the RA from which the routing information is imported. will reflect the RA from which the routing information is imported.
The Type field of the Associated RA ID sub-TLV is assigned a value in
the range 32768-32777 agreed by all participants in the experiment.
The same value MUST be used for the Type regardless of which TLV the
sub-TLV appears in.
The Length of the Associated RA ID TLV is 4 octets. The Value field The Length of the Associated RA ID TLV is 4 octets. The Value field
of this sub-TLV contains the Associated RA ID. The Associated RA ID of this sub-TLV contains the Associated RA ID. The Associated RA ID
value is encoded following the OSPF area ID (32 bits) encoding rules value is encoded following the OSPF area ID (32 bits) encoding rules
defined in [RFC2328]. defined in [RFC2328].
The format of the Associated RA ID TLV is defined as follows: The format of the Associated RA ID TLV is defined 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 (26 - TBD) | Length (4) | | Type | Length (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Associated RA ID | | Associated RA ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.3.2 Processing 6.3.2 Processing
When fulfilling the rules detailed in Section 6.1 a given Opaque LSA When fulfilling the rules detailed in Section 6.1 a given Opaque LSA
is imported/exported downward or upward the routing hierarchy, the is imported/exported downward or upward the routing hierarchy, the
Associated RA ID TLV is added to the received opaque LSA list of TLVs Associated RA ID TLV is added to the received opaque LSA list of TLVs
such as to identify the area from which this routing information has such as to identify the area from which this routing information has
skipping to change at page 18, line 16 skipping to change at page 20, line 5
the downstream level with the newly reconfigured RA ID (as part of the downstream level with the newly reconfigured RA ID (as part of
the re-advertised Opaque TE LSA). the re-advertised Opaque TE LSA).
- Enable export of routing information upstream such as to re-sync - Enable export of routing information upstream such as to re-sync
the upstream level with the newly reconfigured RA ID (as part of the upstream level with the newly reconfigured RA ID (as part of
the re-advertised Opaque TE LSA). the re-advertised Opaque TE LSA).
Note that the re-sync operation needs to be carried out only between Note that the re-sync operation needs to be carried out only between
the directly adjacent upper and lower routing level. the directly adjacent upper and lower routing level.
7. OSPFv2 Extensions 7. OSPFv2 Scalability
7.1 Compatibility
Extensions specified in this document are associated to the:
1. Opaque Traffic Engineering LSA (Type 1) defined in [RFC3630]:
- Router Address top level TLV (Type 1):
- Associated RA ID sub-TLV (Type 26 TBD by IANA): optional
sub-TLV for loop avoidance.
- Link top level TLV (Type 2):
- Local and Remote TE Router-ID sub-TLV (Type 25 TBD by IANA):
optional sub-TLV for scoping link attributes per TE Router-ID.
- Associated RA ID sub-TLV (Type 26 TBD by IANA): optional sub-
TLV for loop avoidance.
2. Node Attribute top level TLV (TBD by IANA [OSPF-NODE]):
- Node IPv4 Local Prefix sub-TLV (Type 3 TBD by IANA): optional
sub-TLV for IPv4 reachability advertisement.
- Node IPv6 Local Prefix sub-TLV (Type 4 TBD by IANA): optional
sub-TLV for IPv6 reachability advertisement.
- Local TE Router-ID sub-TLV (Type 5 TBD by IANA): optional sub-
TLV for scoping reachability per TE Router-ID.
- Associated RA ID sub-TLV (Type 26 by IANA): optional sub-TLV
for loop avoidance.
3. Opaque Router Information LSA (Type 4) defined in [RFC4970]:
- Router Information Capability Descriptor TLV (Type 1).
- U bit in Capability Descriptor TLV (bit position 7 TBD by
IANA).
- D bit in Capability Descriptor TLV (bit position 8 TBD by
IANA).
- Downstream Associated RA ID TLV (Type 7 TBD by IANA).
7.2 Scalability
- Routing information exchange upward/downward in the hierarchy - Routing information exchange upward/downward in the hierarchy
between adjacent RAs SHOULD by default be limited to reachability between adjacent RAs SHOULD by default be limited to reachability
information. In addition, several transformations such as prefix information. In addition, several transformations such as prefix
aggregation are RECOMMENDED when allowing decreasing the amount of aggregation are RECOMMENDED when allowing decreasing the amount of
information imported/exported by a given RC without impacting information imported/exported by a given RC without impacting
consistency. consistency.
- Routing information exchange upward/downward in the hierarchy - Routing information exchange upward/downward in the hierarchy
involving TE attributes MUST be under strict policy control. Pacing involving TE attributes MUST be under strict policy control. Pacing
skipping to change at page 19, line 44 skipping to change at page 20, line 32
8. Security Considerations 8. Security Considerations
This document specifies the contents and processing of Opaque LSAs This document specifies the contents and processing of Opaque LSAs
in OSPFv2 [RFC2328]. Opaque TE and RI LSAs defined in this document in OSPFv2 [RFC2328]. Opaque TE and RI LSAs defined in this document
are not used for SPF computation, and so have no direct effect on IP are not used for SPF computation, and so have no direct effect on IP
routing. Additionally, ASON routing domains are delimited by the routing. Additionally, ASON routing domains are delimited by the
usual administrative domain boundaries. usual administrative domain boundaries.
Any mechanisms used for securing the exchange of normal OSPF LSAs Any mechanisms used for securing the exchange of normal OSPF LSAs
can be applied equally to all Opaque TE and RI LSAs used in the ASON can be applied equally to all Opaque TE and RI LSAs used in the ASON
context. In order to be secured against passive attacks and provide context. Authentication of OSPFv2 LSA exchanges (such as OSPF
significant protection against active attacks, mechanisms to cryptographic authentication [RFC2328] and [OSPF-CA]) can be used to
authenticate OSPFv2 LSA exchanges shall be used for Opaque LSAs such secure against passive attacks and provide significant protection
as OSPF cryptographic authentication [RFC2328] and [OSPF-CA]. The against active attacks. [OSPF-CA] defines a mechanism for
latter defines a mechanism for authenticating OSPF packets by making authenticating OSPF packets by making use of the HMAC algorithm in
use of the HMAC algorithm in conjunction with the SHA family of conjunction with the SHA family of cryptographic hash functions.
cryptographic hash functions.
[RFC2154] adds i) digital signatures to authenticate OSPF LSA data, [RFC2154] adds i) digital signatures to authenticate OSPF LSA data,
ii) certification mechanism for distribution of routing information, ii) certification mechanism for distribution of routing information,
and iii) use a neighbor-to-neighbor authentication algorithm to and iii) use a neighbor-to-neighbor authentication algorithm to
protect local OSPFv2 protocol exchanges. protect local OSPFv2 protocol exchanges.
9. IANA Considerations 9. IANA Considerations
9.1 TLVs for the OSPF Opaque TE LSA This document makes no requests for IANA action.
IANA manages a registry of Top Level TLVs carried in the Opaque TE 10. Experimental Code Points
LSA. This is found as the "Open Shortest Path First (OSPF) Traffic
Engineering TLVs" registry.
9.1.1. Sub-TLVs of the TE Link Top Level TLV This document is classified as Experimental. It defines new TLVs and
sub-TLVs for inclusion in OSPF LSAs. According to the assignment
policies for the registries of codepoints for these TLVs and sub-
TLVs, values must be assigned from the experimental ranges and must
not be recorded by IANA or mentioned in this document.
IANA manages a subregistry for sub-TLVs carried in the TE Link top The following sections summarise the TLVs and sub-TLVs concerned.
level TLV. This is found as the "Types for sub-TLVs of TE Link TLV
(Value 2)" subregistry.
IANA is requested to make allocations from this subregistry for the 10.1. Sub-TLVs of the Link TLV
following new sub-TLVs. (Recommended values.)
Value Sub-TLV Reference This document defines the following sub-TLVs of the Link TLV carried
------- ----------------------------- --------- in the OSPF TE LSA:
25 Local and Remote TE Router ID [This.ID]
26 Associated RA ID [This.ID]
The value for the Associated RA ID sub-TLV is requested to be - Local and Remote TE Router ID sub-TLV
consistent with the values for the same sub-TLV carried in other top - Associated RA ID sub-TLV
level TLVs (see Sections 9.1.2 and 9.1.3).
9.1.2. Sub-TLVs of Router Address Top Level TLV The defining text for code point assignment for sub-TLVs of the OSPF
TE Link TLV says ([RFC3630]):
IANA is requested to create a subregistry to track sub-TLVs of the o Types in the range 10-32767 are to be assigned via Standards
Router Address Top Level TLV (type 1). The "Types for sub-TLVs of Action.
Router Address TLV (Value 1)" subregistry should have the following o Types in the range 32768-32777 are for experimental use; these
format and entries. (Recommended values.) will not be registered with IANA, and MUST NOT be mentioned by
RFCs.
o Types in the range 32778-65535 are not to be assigned at this
time.
Range Registration Procedures Notes That means that the new sub-TLVs must be assigned type values from
----------- ----------------------- -------------------- the range 32768-32777. It is a matter for experimental
0-32767 Standards Action implementations to assign their own code points, and to agree with
32768-32777 Experimental Use IANA does not assign cooperating implementations participating in the same experiments
32778-65535 Standards Track RFC what values to use.
Value Sub-TLV Reference Note that the same value for the Associated RA ID sub-TLV MUST be
------- ----------------------- --------- used when it appears in the Link TLV, the Node Attribute TLV, and the
26 Associated RA ID [This.ID] Router Address TLV.
The value for the Associated RA ID sub-TLV is requested to be 10.2. Sub-TLVs of the Node Attribute TLV
consistent with the values for the same sub-TLV carried in other top
level TLVs (see Sections 9.1.1 and 9.1.3).
9.1.3. Node Attribute Top Level TLV and its Sub-TLVs This document defines the following sub-TLVs of the Node Attribute
TLV carried in the OSPF TE LSA.
[OSPF-NODE] requests the allocaiton of a codepoint for the Node - Node IPv4 Local Prefix sub-TLV
Attribute TLV from the "Open Shortest Path First (OSPF) Traffic - Node IPv6 Local Prefix sub-TLV
Engineering TLVs" registry. - Local TE Router ID sub-TLV
- Associated RA ID sub-TLV
The defining text for code point assignment for sub-TLVs of the OSPF
Node Attribute TLV says ([OSPF-NODE]):
[OSPF-NODE] also requests the creation of a subregistry to track the o Types in the range 3-32767 are to be assigned via Standards
sub-TLVs of the Node Attribute TLV, and requests the allocation of Action.
codepoints for sub-TLVs 1 and 2. o Types in the range 32768-32777 are for experimental use; these
will not be registered with IANA, and MUST NOT be mentioned by
RFCs.
o Types in the range 32778-65535 are not to be assigned at this
time. Before any assignments can be made in this range, there
MUST be a Standards Track RFC that specifies IANA
Considerations that covers the range being assigned.
IANA is requested to make four further allocations from this That means that the new sub-TLVs must be assigned type values from
subregistry as follows. (Recommended values.) the range 32768-32777. It is a matter for experimental
implementations to assign their own code points, and to agree with
cooperating implementations participating in the same experiments
what values to use.
Value Sub-TLV Reference Note that the same value for the Associated RA ID sub-TLV MUST be
------- ---------------------- --------- used when it appears in the Link TLV, the Node Attribute TLV, and the
3 Node IPv4 Local Prefix [This.ID] Router Address TLV.
4 Node IPv6 Local Prefix [This.ID]
5 Local TE Router ID [This.ID]
26 Associated RA ID [This.ID]
The value for the Associated RA ID sub-TLV is requested to be 10.3. Sub-TLVs of the Router Address TLV
consistent with the values for the same sub-TLV carried in other top
level TLVs (see Sections 9.1.1 and 9.1.2).
9.2 OSPF RI LSA The OSPF Router Address TLV is defined in [RFC3630]. No sub-TLVs are
defined in that document and there is no registry or allocation
policy for sub-TLVs of the Router Address TLV.
9.2.1 RI Capability Bits This document defines the following new sub-TLVs for inclusion in the
OSPF Router Address TLV:
IANA maintains the "Open Shortest Path First v2 (OSPFv2) Parameters" - Associated RA ID sub-TLV
registry with a subregistry called "OSPF Router Informational
Capability Bits".
IANA is requested to allocate two new bits as follows. (Recommended Note that the same value for the Associated RA ID sub-TLV MUST be
values.) used when it appears in the Link TLV, the Node Attribute TLV, and the
Router Address TLV. This is consistent with potential for a future
definition of a registry with policies that match the other existing
registries.
Bit Capabilities Reference 10.4. TLVs of the Router Information LSA
-------- -------------------------------------- ---------
7 Upward routing dissemination capable [This.ID]
8 Downward routing dissemination capable [This.ID]
9.2.2 RI LSA TLVs This document defines two new TLVs to be carried in the Router
Information LSA.
IANA maintains the "Open Shortest Path First v2 (OSPFv2) Parameters" - Downstream Associated RA ID TLV
registry with a subregistry called "OSPF Router Information (RI) - Router Information Experimental Capabilities TLV
TLVs". IANA is requested make an allocation from this subregistry as The defining text for code point assignment for TLVs of the OSPF
follows. (Recommended values.) Router Information LSA says ([RFC4970]):
Value Sub-TLV Reference
------- ---------------------- ---------
7 Downstream Associated RA ID [This.ID]
10. References o 1-32767 Standards Action.
10.1 Normative References o Types in the range 32768-32777 are for experimental use; these
will not be registered with IANA and MUST NOT be mentioned by
RFCs.
o Types in the range 32778-65535 are reserved and are not to be
assigned at this time. Before any assignments can be made in
this range, there MUST be a Standards Track RFC that specifies
IANA Considerations that covers the range being assigned.
That means that the new TLVs must be assigned type values from the
range 32768-32777. It is a matter for experimental implementations to
assign their own code points, and to agree with cooperating
implementations participating in the same experiments what values to
use.
11. References
11.1 Normative References
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[RFC2328] J. Moy, "OSPF Version 2", RFC 2328, STD 54, April 1998. [RFC2328] J. Moy, "OSPF Version 2", RFC 2328, STD 54, April 1998.
[RFC3630] D. Katz et al. "Traffic Engineering (TE) Extensions to [RFC3630] D. Katz et al. "Traffic Engineering (TE) Extensions to
skipping to change at page 22, line 36 skipping to change at page 24, line 5
[RFC4202] K. Kompella (Editor) et al., "Routing Extensions in [RFC4202] K. Kompella (Editor) et al., "Routing Extensions in
Support of Generalized MPLS," RFC 4202, October 2005. Support of Generalized MPLS," RFC 4202, October 2005.
[RFC4203] K. Kompella (Editor) et al., "OSPF Extensions in [RFC4203] K. Kompella (Editor) et al., "OSPF Extensions in
Support of Generalized Multi-Protocol Label Switching Support of Generalized Multi-Protocol Label Switching
(GMPLS)," RFC 4203, October 2005. (GMPLS)," RFC 4203, October 2005.
[RFC4970] A. Lindem et al., "Extensions to OSPF for Advertising [RFC4970] A. Lindem et al., "Extensions to OSPF for Advertising
Optional Router Capabilities", RFC 4970, July 2007. Optional Router Capabilities", RFC 4970, July 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The
OSPF Opaque LSA Option", RFC 5250, July 2008. OSPF Opaque LSA Option", RFC 5250, July 2008.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, July 2008. for IPv6", RFC 5340, July 2008.
[OSPF-NODE] R. Aggarwal and K. Kompella, "Advertising a Router's [OSPF-NODE] R. Aggarwal and K. Kompella, "Advertising a Router's
Local Addresses in OSPF TE Extensions", draft-ietf-ospf- Local Addresses in OSPF TE Extensions", draft-ietf-ospf-
te-node-addr, work in progress. te-node-addr, work in progress.
10.2 Informative References 11.2 Informative References
[RFC4258] D.Brungard (Ed.) et al. "Requirements for Generalized [RFC4258] D.Brungard (Ed.) et al. "Requirements for Generalized
MPLS (GMPLS) Routing for Automatically Switched Optical MPLS (GMPLS) Routing for Automatically Switched Optical
Network (ASON)," RFC 4258, November 2005. Network (ASON)," RFC 4258, November 2005.
[RFC4652] D.Papadimitriou (Ed.) et al. "Evaluation of existing [RFC4652] D.Papadimitriou (Ed.) et al. "Evaluation of existing
Routing Protocols against ASON Routing Requirements", Routing Protocols against ASON Routing Requirements",
RFC 4652, October 2006. RFC 4652, October 2006.
[RFC5073] J.P.Vasseur et al., "Routing extensions for discovery of [RFC5073] J.P.Vasseur et al., "Routing extensions for discovery of
skipping to change at page 23, line 32 skipping to change at page 25, line 5
Network (ASON)," June 2002. Network (ASON)," June 2002.
[G.7715.1] ITU-T Draft Rec. G.7715.1/Y.1706.1, "ASON Routing [G.7715.1] ITU-T Draft Rec. G.7715.1/Y.1706.1, "ASON Routing
Architecture and Requirements for Link State Protocols," Architecture and Requirements for Link State Protocols,"
November 2003. November 2003.
[G.8080] ITU-T Rec. G.8080/Y.1304, "Architecture for the [G.8080] ITU-T Rec. G.8080/Y.1304, "Architecture for the
Automatically Switched Optical Network (ASON)," Automatically Switched Optical Network (ASON),"
November 2001 (and Revision, January 2003). November 2001 (and Revision, January 2003).
11. Author's Address 12. Author's Address
Dimitri Papadimitriou Dimitri Papadimitriou
Alcatel-Lucent Bell Alcatel-Lucent Bell
Copernicuslaan 50 Copernicuslaan 50
B-2018 Antwerpen B-2018 Antwerpen
Belgium Belgium
Phone: +32 3 2408491 Phone: +32 3 2408491
EMail: dimitri.papadimitriou@alcatel-lucent.be EMail: dimitri.papadimitriou@alcatel-lucent.be
Acknowledgements Acknowledgements
The authors would like to thank Dean Cheng, Acee Lindem, Pandian The authors would like to thank Dean Cheng, Acee Lindem, Pandian
Vijay, Alan Davey, Adrian Farrel, Deborah Brungard, and Ben Campbell Vijay, Alan Davey, Adrian Farrel, Deborah Brungard, and Ben Campbell
for their useful comments and suggestions. for their useful comments and suggestions.
Lisa Dusseault and Jari Arkko provided useful comments during IESG
review.
Question 14 of Study Group 15 of the ITU-T provided useful and Question 14 of Study Group 15 of the ITU-T provided useful and
constructive input. constructive input.
Appendix 1: ASON Terminology Appendix 1: ASON Terminology
This document makes use of the following terms: This document makes use of the following terms:
Administrative domain: (see Recommendation G.805) for the purposes of Administrative domain: (see Recommendation G.805) for the purposes of
[G7715.1] an administrative domain represents the extent of resources [G7715.1] an administrative domain represents the extent of resources
which belong to a single player such as a network operator, a service which belong to a single player such as a network operator, a service
 End of changes. 65 change blocks. 
207 lines changed or deleted 254 lines changed or added

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