RFC 4973
OSPF-xTE: Experimental Extension to OSPF for Traffic Engineering
RFC 4973: OSPF-xTE: Experimental Extension to OSPF for Traffic Engineering 🦋
Okay bestie, the title block first ✨ This RFC is titled OSPF-xTE: Experimental Extension to OSPF for Traffic Engineering. P. Srisuresh (Kazeon Systems) and P. Joseph (Consultant) wrote it, it's in the Experimental category, and it's dated July 2007. It doesn't list anything it obsoletes or updates, so nothing to untangle there 💅
Status of This Memo 🌸
This memo defines an Experimental Protocol for the Internet community, so it's not an Internet standard of any kind. Discussion and suggestions for improvement are requested, and distribution of this memo is unlimited 🫶
Copyright Notice 🎀
Copyright (C) The IETF Trust (2007).
Abstract 💜
OK so this doc defines OSPF-xTE, an experimental traffic engineering (TE) extension to the link-state routing protocol OSPF 🧚 It adds new TE Link State Advertisements (LSAs) to spread TE metrics around an autonomous system (AS), which can be made of several areas. When an AS has a mix of TE and non-TE nodes, OSPF-xTE makes sure the non-TE nodes aren't affected by the TE LSAs, which is honestly so considerate 🥹 It builds a separate TE Link State Database (TE-LSDB), apart from the native OSPF LSDB, so it can work out TE circuit paths. And it's versatile enough to be extended to non-packet networks like Synchronous Optical Network (SONET) / Time Division Multiplexing (TDM) and optical networks 🔥
IESG Note 🙈
The content of this RFC was at one time considered by the IETF, so it may look a lot like a current IETF work in progress or a published IETF work. This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose, and it specifically notes that the decision to publish was not based on IETF review for things like security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor chose to publish this document at its discretion, so readers should be careful about judging its value for implementation and deployment. See RFC 3932 for more information.
Also, see RFC 3630 for the IETF consensus protocol for OSPF Traffic Engineering 💖 The OSPF WG's position at the time of publication was that, although this proposal has some useful properties, the protocol in RFC 3630 is sufficient for the traffic engineering needs identified so far, and the cost of migrating to this proposal exceeds its benefits 😭
Table of Contents 📚
1. Introduction ....................................................3
2. Principles of Traffic Engineering ...............................3
3. Terminology .....................................................5
3.1. Native OSPF Terms ..........................................5
3.2. OSPF-xTE Terms .............................................6
4. Motivations behind the Design of OSPF-xTE .......................9
4.1. Scalable Design ............................................9
4.2. Operable in Mixed and Peer Networks ........................9
4.3. Efficient in Flooding Reach ................................9
4.4. Ability to Reserve TE-Exclusive Links .....................10
4.5. Extensible Design .........................................11
4.6. Unified for Packet and Non-Packet Networks ................11
4.7. Networks Benefiting from the OSPF-xTE Design ..............11
5. OSPF-xTE Solution Overview .....................................12
5.1. OSPF-xTE Solution .........................................12
5.2. Assumptions ...............................................13
6. Strategy for Transition of Opaque LSAs to OSPF-xTE .............14
7. OSPF-xTE Router Adjacency -- TE Topology Discovery .............14
7.1. The OSPF-xTE Router Adjacency .............................14
7.2. The Hello Protocol ........................................15
7.3. The Designated Router .....................................15
7.4. The Backup Designated Router ..............................15
7.5. Flooding and the Synchronization of Databases .............16
7.6. The Graph of Adjacencies ..................................16
8. TE LSAs for Packet Network .....................................18
8.1. TE-Router LSA (0x81) ......................................18
8.1.1. Router-TE Flags: TE Capabilities of the Router .....19
8.1.2. Router-TE TLVs .....................................20
8.1.3. Link-TE Flags: TE Capabilities of a Link ...........22
8.1.4. Link-TE TLVs .......................................23
8.2. TE-Incremental-Link-Update LSA (0x8d) .....................26
8.3. TE-Circuit-Path LSA (0x8C) ................................28
8.4. TE-Summary LSAs ...........................................31
8.4.1. TE-Summary Network LSA (0x83) ......................32
8.4.2. TE-Summary Router LSA (0x84) .......................33
8.5. TE-AS-external LSAs (0x85) ................................34
9. TE LSAs for Non-Packet Network .................................36
9.1. TE-Router LSA (0x81) ......................................36
9.1.1. Router-TE flags - TE Capabilities of a Router ......37
9.1.2. Link-TE Options: TE Capabilities of a TE Link ......38
9.2. TE-positional-ring-network LSA (0x82) .....................38
9.3. TE-Router-Proxy LSA (0x8e) ................................40
10. Abstract Topology Representation with TE Support ..............42
11. Changes to Data Structures in OSPF-xTE Nodes ..................44
11.1. Changes to Router Data Structure .........................44
11.2. Two Sets of Neighbors ....................................44
11.3. Changes to Interface Data Structure ......................44
12. IANA Considerations ...........................................45
12.1. TE LSA Type Values .......................................45
12.2. TE TLV Tag Values ........................................46
13. Acknowledgements ..............................................46
14. Security Considerations .......................................47
15. Normative References ..........................................48
16. Informative References ........................................481. Introduction ✨
This doc defines OSPF-xTE, an experimental traffic engineering (TE) extension to the link-state routing protocol OSPF 💅 The goal is to discover the TE network topology and spread TE metrics around an autonomous system (AS). It builds a stand-alone TE Link State Database (TE-LSDB), different from the native OSPF LSDB, so TE circuit paths can be computed. Designing the algorithms for computing TE circuit paths is not the job of this document, so don't come here looking for that 🙈
OSPF-xTE is different from the Opaque-LSA-based approach outlined in [OPQLSA-TE]. Section 4 explains the motivations behind the design of OSPF-xTE. Section 6 lays out a transition path for anyone currently using [OPQLSA-TE] for intra-area TE who wants to extend it across the whole AS using OSPF-xTE 🦋
Readers who are only interested in TE extensions for packet networks can skip section 9.0 🌈
2. Principles of Traffic Engineering 💖
The whole point of traffic engineering (TE) is to set up circuit path(s) between a pair of nodes or links, and to forward traffic of a certain forwarding equivalency class (FEC) through that circuit path. Only unicast circuit paths are considered in this section, and multicast variations are out of scope 🎀
A traffic engineered circuit path is unidirectional, and it can be identified by the tuple: (FEC, TE circuit parameters, origin node/link, destination node/link).
A forwarding equivalency class (FEC) is a grouping of traffic that a node forwards in the same manner. An FEC can be classified based on a bunch of criteria, like:
- a) traffic arriving on a specific interface,
- b) traffic arriving at a certain time of day,
- c) traffic meeting a certain packet based classification criteria (ex: based on a match of the fields in the IP and transport headers within a packet),
- d) traffic in a certain priority class,
- e) traffic arriving on a specific set of TDM (Synchronous Transport Signal (STS)) circuits on an interface, or
- f) traffic arriving on a certain wavelength of an interface.
Discerning traffic based on the FEC criteria is mandatory for Label Edge Routers (LERs) 👑 The intermediate Label-Switched Routers (LSRs) are transparent to the traffic content. LSRs are only responsible for maintaining the circuit for its lifetime. This document will not address the definition of FEC criteria, the mapping of an FEC to a circuit, or the associated signaling to set up circuits. [MPLS-TE] and [GMPLS-TE] address the FEC criteria. [RSVP-TE] and [CR-LDP] address signaling protocols to set up circuits ✨
This document is concerned with collecting TE metrics for all the TE enforceable nodes and links within an autonomous system. TE metrics for a node may include the following:
- a) Ability to perform traffic prioritization,
- b) Ability to provision bandwidth on interfaces,
- c) Support for Constrained Shortest Path First (CSPF) algorithms,
- d) Support for certain TE-Circuit switch type, and
- e) Support for a certain type of automatic protection switching.
TE metrics for a link may include the following:
- a) available bandwidth,
- b) reliability of the link,
- c) color assigned to the link,
- d) cost of bandwidth usage on the link, and
- e) membership in a Shared Risk Link Group (SRLG).
A number of CSPF (Constraint-based Shortest Path First) algorithms may be used to dynamically set up TE circuit paths in a TE network 🧚
OSPF-xTE says that the originating and terminating entities of a TE circuit path must be identifiable by IP addresses 🔥
3. Terminology 🌷
Most of the terms used in the context of the OSPF protocol are defined in [OSPF-V2]. MPLS and traffic engineering terms can be found in [MPLS-ARCH]. RSVP-TE and CR-LDP signaling-specific terms can be found in [RSVP-TE] and [CR-LDP], respectively 💜
The following subsections describe the native OSPF terms and the OSPF-xTE terms used within this document 🫶
3.1. Native OSPF Terms 🦋
- Native node (Non-TE node) 💅
okay so a native (or non-TE) node is an OSPF router that can totally do IP packet forwarding, but it's not in a TE network 🙈 It forwards IP traffic using the shortest-path forwarding algorithm and doesn't run the OSPF-xTE extensions. basic, but iconic 🌸
- Native link (Non-TE link) 🧚
a native (or non-TE) link is a network attachment to a TE or non-TE node that's used for IP packet traversal. it's the regular IP road, bestie 🛣️
- Native OSPF network (Non-TE network) 🎀
a native OSPF network is an OSPF network that doesn't support TE. "Non-TE network", "native-OSPF network", and "non-TE topology" all mean the same thing throughout the document, so don't let the names confuse you 💜
- LSP ✨
LSP stands for "Label-Switched Path" 🔥 an LSP is a TE circuit path in a packet network. in the context of packet networks, "LSP" and "TE circuit path" are used synonymously, so they're literally the same thing 💖
- LSA 🌈
LSA stands for OSPF "Link State Advertisement" 📣
- LSDB 🍓
LSDB stands for "Link State Database" 🗂️ an LSDB holds a representation of a network's topology. a native LSDB, made of native OSPF LSAs, represents the topology of a native IP network. the TE-LSDB, on the other hand, is made of TE LSAs and represents the TE network topology. two databases, two vibes 👑
3.2. OSPF-xTE Terms 🎀
- TE node 🌟
a TE node is a node in the traffic engineering (TE) network. every TE node has a minimum of one TE link attached to it. each TE node has a set of supported TE metrics associated with it. a TE node may also take part in a native IP network 💅
in a SONET/TDM or photonic cross-connect network, a TE node isn't required to be an OSPF-xTE node. an external OSPF-xTE node may act as a proxy for the TE nodes that can't be routers themselves 🫶
- TE link 🦋
a TE link is a network attachment point to a TE node, and it's meant for traffic engineering use. each TE link has a set of supported TE metrics associated with it. a TE link may also optionally carry native IP traffic ✨
out of all the links attached to a TE node, only the ones that take part in a traffic-engineered network are called TE links. main character energy 👑
- TE circuit path 🛤️
a TE circuit path is a unidirectional data path defined by a list of TE nodes connected to each other through TE links. people also often just call it a circuit path or a circuit 💖
for OSPF-xTE purposes, the originating and terminating entities of a TE circuit path must be identifiable by their IP addresses. as a general rule, all nodes and links that are part of a traffic-engineered network should be uniquely identifiable by an IP address 🔥
- OSPF-xTE node (OSPF-xTE router) 💜
an OSPF-xTE node is a TE node that runs the OSPF routing protocol and the OSPF-xTE extensions described in this document. an autonomous system (AS) can be a mix of native and OSPF-xTE nodes 🌈
- TE Control network 🎧
the IP network the OSPF-xTE nodes use for OSPF-xTE communication is referred to as the TE control network, or simply the control network. the control network can be independent of the TE data network 🧚
- TE network (TE topology) 🕸️
a TE network is a network of connected TE nodes and TE links, set up for the purpose of establishing one or more TE circuit paths. "TE network", "TE data network", and "TE topology" all mean the same thing throughout the document 🍓
- Packet-TE network (Packet network) 📦
a packet-TE network is a TE network in which the nodes switch MPLS packets. [MPLS-TE] defines an MPLS packet as a packet with an MPLS header, followed by data octets. the intermediary node(s) of a circuit path in a packet-TE network do MPLS label swapping to emulate the circuit 🪄
unless specified otherwise, the term "packet network" is used throughout the document to mean a packet-TE network 💅
- Non-packet-TE network (Non-packet network) 💡
a non-packet-TE network is a TE network in which the nodes switch non-packet entities, like STS time slots, Lambda wavelengths, or simply interfaces 🌟
SONET/TDM and fiber cross-connect networks are examples of non-packet-TE networks. circuit emulation in these networks is done by the switch fabric in the intermediary nodes, based on TDM time slot, fiber interface, or Lambda 🔆
unless specified otherwise, the term non-packet network is used throughout the document to mean a non-packet-TE network ✨
- Mixed network 🌸
a mixed network is a network made of both packet-TE and non-TE networks. traffic in the network is strictly datagram oriented, meaning IP datagrams or MPLS packets 📮 routers in a mixed network may be TE or native nodes.
OSPF-xTE can be used within a packet network or a mixed network 💖
- Peer network 🤝
a peer network is a network made of packet-TE and non-packet-TE networks combined. in a peer network, a TE node could potentially support TE links for both packet and non-packet data 🫶
OSPF-xTE can be used within a packet network, a non-packet network, or a peer network, which is a combination of the two 🦄
- CSPF 🧠
CSPF stands for "Constrained Shortest Path First". given a TE LSDB and a set of constraints that must be satisfied to form a circuit path, there may be several CSPF algorithms that find a TE circuit path meeting the criteria 🗺️
- TLV 📏
a TLV stands for a data object in the form Tag-Length-Value. all TLVs are assumed to follow the format below, unless specified otherwise. the Tag and Length are each 16 bits wide. the Length includes the 4 octets needed for the Tag and Length specification. all TLVs described in this document are padded to 32-bit alignment. any padding needed for alignment is not counted in the length field, though 🙈 TLVs are used to describe the traffic engineering characteristics of TE nodes, TE links, and TE circuit paths 💜
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag | Length (4 or more) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Router-TE TLVs (Router TLVs) 🎀
TLVs used to describe the TE capabilities of a TE node 🧁
- Link-TE TLVs (Link TLVs) 🎀
TLVs used to describe the TE capabilities of a TE link 🧁
4. Motivations behind the Design of OSPF-xTE ✨
there are a few big reasons why OSPF-xTE was designed the way it was 💅 OSPF-xTE is scalable, efficient, and usable across a variety of network topologies. each of these motivations gets its own explanation in the subsections below. the last subsection lists real-world network scenarios that benefit from OSPF-xTE 🌈
4.1. Scalable Design 📈
in OSPF-xTE, an area-level abstraction gives the scaling needed for the TE topology in a large autonomous system (AS). an OSPF-xTE area border router advertises summary LSAs for TE and non-TE topologies, independent of each other 🫧 if you want a topological view of the AS from the perspective of an OSPF-xTE node in an area, check out section 10 🗺️
[OPQLSA-TE], on the other hand, is designed for intra-area use and isn't scalable to AS-wide scope 🙃
4.2. Operable in Mixed and Peer Networks 🤹
OSPF-xTE assumes an AS may be made up of coexisting TE and non-TE networks 🫶 OSPF-xTE dynamically discovers the TE topology and the associated TE metrics of the nodes and links that form the TE network. so OSPF-xTE generates a stand-alone TE-LSDB that fully represents the TE network 💖 a stand-alone TE-LSDB allows for speedy TE computations ⚡
[OPQLSA-TE] is designed for packet networks and isn't suitable for mixed and peer networks 🙅♀️ its TE-LSDB is derived from a combination of Opaque LSAs and the native LSDB. and the TE-LSDB derived that way has no knowledge of the TE capabilities of the routers in the network 💀
4.3. Efficient in Flooding Reach 📡
OSPF-xTE can identify the TE topology in a mixed network and limit the flooding of TE LSAs to only the TE nodes. non-TE nodes aren't bombarded with TE LSAs 🛡️
in a TE network, some TE metrics may change rapidly, while others stay mostly the same 🎢 changes in TE metrics have to be communicated as early as possible throughout the network, so the TE-LSDB stays up-to-date everywhere. as a general rule, a TE network is likely to generate way more control traffic than a native network 😭 the extra traffic is almost directly proportional to how fast TE circuits get set up and torn down in the TE network. TE database synchronization should happen much quicker than the aggregate circuit set up and tear-down rates 🏃♀️ OSPF-xTE defines the TE-Incremental-Link-update LSA (section 8.2) to advertise only a subset of the metrics that are prone to rapid changes 🎯
the more frequent and wider the flooding, the more retransmissions and acknowledgements there are. the same information (needed or not) can reach a router through multiple links. even if the router didn't forward the information past the node, it would still have to send acknowledgements across all the various links the LSAs tried to converge on 🙄 it's just not it to flood non-TE nodes with TE information 🚫
4.4. Ability to Reserve TE-Exclusive Links 🔒
OSPF-xTE draws a clear line between TE and non-TE links 🖍️ a TE link can be configured to permit TE traffic alone, and not permit best-effort IP traffic on the link. this makes TE enforceability on the TE links possible 💪
when the links of a TE topology don't overlap the links of a native IP network, OSPF-xTE allows for virtual isolation of the two networks 🫧 best-effort IP networks and TE networks often have different service requirements. keeping the two networks physically isolated can be expensive 💸 combining them into a single physically connected network brings economies of scale, while service enforceability can still be maintained for each of the TE and non-TE sections of the network 🧠✨
[OPQLSA-TE] doesn't support isolating best-effort IP traffic from TE traffic on a link. all links are subject to best-effort IP traffic. an OSPF router could potentially pick a TE link as its least cost link and flood it with best-effort IP traffic, which makes the link unusable for TE purposes 😱
4.5. Extensible Design 🧩
the OSPF-xTE design is based on the tried-and-tested OSPF paradigm, so it inherits all the benefits of OSPF, present and future 🥰 TE LSAs are extensible, just like the native OSPF that OSPF-xTE is built on ✨
4.6. Unified for Packet and Non-Packet Networks ✨
okay so OSPF-xTE can be used inside a packet network, inside a non-packet network, or in a combo peer network that mixes both 🫶
signaling protocols like RSVP and LDP work the same way across packet and non-packet networks 💅 they just need the TE characteristics of nodes and links so they can tell the nodes how to formulate TE circuit paths. in a peer network, the underlying control protocol must be capable of providing a unified LSDB for all TE nodes (nodes with packet-TE links as well as non-packet-TE links) in the network. and OSPF-xTE meets this requirement, bestie 👑
4.7. Networks Benefiting from the OSPF-xTE Design 🌈
here are some real-world network scenarios that get major glow-ups from OSPF-xTE 🦋
- IP providers transitioning to provide TE services 🌸
providers that need to support MPLS-based TE in their IP network can choose to transition gradually 🍓 they can add new TE links or convert existing links into TE links within an area first, and then progressively move on to offering MPLS in the entire AS.
not every router will support TE extensions at the same time during the migration. using TE-specific LSAs, and flooding them to OSPF-xTE only nodes, lets the vendor introduce MPLS TE without destabilizing the existing network 🫧 the native OSPF-LSDB stays undisturbed while newer TE links get added to the network.
- Providers offering best-effort-IP & TE services 💜
providers who want to offer both best-effort-IP and TE-based packet services at the same time on the same physically connected network will benefit from the OSPF-xTE design ✨ by keeping independent LSDBs for each type of service, TE links don't get cannibalized in a mixed network. no drama 💅
- Large TE networks 👑
the OSPF-xTE design is a big win in large TE networks that need the AS to be sub-divided into multiple areas 🗺️ OSPF-xTE allows inter-area exchange of TE information, which makes sure that all nodes in the AS have up-to-date, AS-wide TE reachability knowledge. and that is what makes TE circuit setup predictable and computationally bounded 🧚
- Non-Packet Networks and Peer Networks 🦋
vendors can also use OSPF-xTE for their non-packet TE networks 🌸 OSPF-xTE defines the following functions to support them:
- (a) "Positional-Ring" type network LSAs.
- (b) Router proxying, which means allowing a router to advertise on behalf of other nodes (that are not packet/OSPF-capable).
5. OSPF-xTE Solution Overview 🎀
5.1. OSPF-xTE Solution 💖
okay the locally-scoped Opaque LSA (type 9) is what gets used to discover the TE topology within a network 🔍 Section 7.1 goes into detail on how the type 9 Opaque LSA is used for TE topology discovery. TE LSAs are designed for use by the OSPF-xTE nodes, and Section 8.0 describes them in detail. the changes needed to the OSPF data structures to support OSPF-xTE are covered in section 11.0 🧠 and a brand new TE-neighbors data structure will be used to advertise TE LSAs along the TE topology.
an OSPF-xTE node will have a native LSDB and a TE-LSDB, while a native OSPF node will only have a native LSDB. picture the OSPF area, made up of OSPF-xTE and native OSPF routers, shown in Figure 1 🦋 RT1, RT2, RT3, and RT6 are OSPF-xTE routers with TE and non-TE link attachments. RT4 and RT5 are native OSPF routers with no TE links. once the LSA database is synchronized, every node shares the same native LSDB. only the OSPF-xTE nodes get the extra TE-LSDB 🫶
+---+
| |--------------------------------------+
|RT6|\\ |
+---+ \\ |
|| \\ |
|| \\ |
|| \\ |
|| +---+ |
|| | |----------------+ |
|| |RT1|\\ | |
|| +---+ \\ | |
|| //| \\ | |
|| // | \\ | |
|| // | \\ | |
+---+ // | \\ +---+ |
|RT2|// | \\|RT3|------+
| |----------|----------------| |
+---+ | +---+
| |
| |
| |
+---+ +---+
|RT5|--------------|RT4|
+---+ +---+
Legend:
-- Native (non-TE) network link
| Native (non-TE) network link
\\ TE network link
|| TE network link
Figure 1. A (TE + native) OSPF Network Topology5.2. Assumptions 🧐
OSPF-xTE is an extension to the native OSPF protocol and does not mandate changes to the existing OSPF 🌷 the OSPF-xTE design makes the following assumptions:
- (1) An OSPF-xTE node will need to establish router adjacency with at least one other OSPF-xTE node in the area in order for the router's TE database to be synchronized within the area. Failing this, the OSPF router will not be in the TE calculations of other TE routers in the area.
it is the responsibility of the network administrator(s) to ensure connectedness of the TE network 🚧 otherwise, there can be disjoint TE topologies within a network, and nobody wants that 💀
- (2) OSPF-xTE nodes must advertise the link state of its TE links. TE links are not obligated to support native IP traffic. Hence, an OSPF-xTE node cannot be required to synchronize its link-state database with neighbors on all its links. the only requirement is to have the TE LSDB synchronized across all OSPF-xTE nodes in the area 🫧
- (3) A link in a packet network may be designated as a TE link or a native-IP link or both. For example, a link may be used for both TE and non-TE traffic, as long as the link is under subscribed in bandwidth for TE traffic (for example, 50% of the link capacity is set aside for TE traffic) 🍰
- (4) Non-packet TE sub-topologies must have a minimum of one node running OSPF-xTE protocol. For example, a SONET/SDH TDM ring must have a minimum of one Gateway Network Element (GNE) running OSPF-xTE. The OSPF-xTE node will advertise on behalf of all the TE nodes in the ring 💍
6. Strategy for Transition of Opaque LSAs to OSPF-xTE 🦋
okay so here's a strategy for moving implementations that are currently using Opaque LSAs ([OPQLSA-TE]) within an area over to OSPF-xTE, one gradual step at a time across the AS 🌈
- (1) Use [OPQLSA-TE] within an area. Derive the TE topology within the area from the combination of Opaque LSAs and the native LSDB 🧩
- (2) Use TE-Summary LSAs and TE-AS-external LSAs for inter-area communication. Use the TE topology within an area to summarize the TE networks in that area, and advertise the same to all TE nodes in the backbone. The TE-ABRs (TE area border routers) on the backbone area will in turn advertise these summaries within their connected areas 📣
7. OSPF-xTE Router Adjacency -- TE Topology Discovery 💜
OSPF creates adjacencies between neighboring routers so they can exchange routing information 🤝 the subsections below describe how locally-scoped Opaque LSAs are used to discover OSPF-xTE neighboring routers. that capability is the basis for building a TE topology 🗺️
7.1. The OSPF-xTE Router Adjacency 🔑
OSPF uses the options field in the Hello packet to advertise optional router capabilities [OSPF-V2]. however, all the bits in this field have been allocated, so there is no way to advertise OSPF-xTE capability using the options field at this time 😭 this document proposes using the local-scope Opaque LSA (OPAQUE-9 LSA) to advertise support for OSPF-xTE and establish OSPF-xTE adjacency. in order to exchange Opaque LSAs, the neighboring routers must have the O-bit (Opaque option bit) set in the options field.
[OSPF-CAP] proposes a format for exchanging router capabilities via OPAQUE-9 LSA. Routers supporting OSPF-xTE will be required to set the "OSPF Experimental TE" bit within the router capabilities field. two routers will not become TE neighbors unless they share a common network link on which both routers advertise support for OSPF-xTE 🫶 routers that don't support OSPF-xTE may simply ignore the advertisement, no biggie ✨
7.2. The Hello Protocol 👋
the Hello protocol is primarily responsible for dynamically establishing and maintaining neighbor adjacencies 🌸 in a TE network, it is not required for all links and neighbors to establish adjacency using this protocol. OSPF-xTE router adjacency between two routers is established using the method described in the previous section.
for non-broadcast multi-access (NBMA) and broadcast networks, the HELLO protocol is responsible for electing the Designated Router and the Backup Designated Router 👑 routers supporting the TE option shall be given a higher precedence for becoming a designated router over those that do not support TE 💅
7.3. The Designated Router 👑
when a router's non-TE link first becomes functional, it checks to see whether there is currently a Designated Router for the network 🔎 if there is one, it accepts that Designated Router, regardless of its router priority, so long as the current designated router is TE compliant. otherwise, the router itself becomes Designated Router if it has the highest Router Priority on the network and is TE compliant.
OSPF-xTE must be implemented on the most robust routers, since they become likely candidates to take on the role of Designated Router 💪🔥
7.4. The Backup Designated Router 🧚
the Backup Designated Router is also elected by the Hello Protocol 🫧 each Hello Packet has a field that specifies the Backup Designated Router for the network. once again, TE-compliance must be weighed in conjunction with router priority when electing the Backup Designated Router 🎀
7.5. Flooding and the Synchronization of Databases ✨
okay so in OSPF, adjacent routers in an area are required to sync their databases 🫶 but the cleaner way to say it is that every router in an area has to converge on the same LSDB 💅. Remember item 2 of section 5.2? The big idea of OSPF-xTE is that the links the control network uses for flooding don't have to be the same links the data network uses for real-time forwarding 🦋. So it should not be required to send OSPF-xTE messages over a TE link that's set up to reject non-TE traffic 🙈. The control network does still need to be set up so there's at least one path between any two OSPF or OSPF-xTE routers in the network, just for flooding purposes 🌸. This tweaked connectivity requirement doesn't mess with LSDB convergence in an area at all ✨.
In a mixed network, where some neighbors are TE compliant and some aren't, the designated OSPF-xTE router sends different sets of LSAs to different neighbors 💜. TE LSAs only go to TE neighbors. Native LSAs go to everyone, TE and non-TE alike 🌈. Limiting TE LSA flooding to just the OSPF-xTE nodes doesn't affect the native nodes hanging out alongside them, so no drama there 💖.
Now, the control traffic for a TE network (aka TE LSA advertisements) is likely to be higher than what you'd see in a native OSPF network 😭. Why? The TE metrics can change every time a TE circuit gets set up, and those state changes have to be advertised right away, without exceeding the MinLSInterval of 5 seconds ⭐. To stop everyone from re-advertising the same stuff over and over, OSPF-xTE defines a new TE-incremental-Link-update LSA (section 8.2) 🔥. It only advertises the TLVs that changed for a link, which is honestly iconic 👑.
The OSPFIGP-TE well-known multicast address 224.0.0.24 was assigned by IANA for exchanging TE-compliant database descriptors during database synchronization 🎀.
7.6. The Graph of Adjacencies 🍓
if two routers have multiple networks in common, they can end up with multiple adjacencies between them 🧚. The adjacency can be one of two types: native OSPF adjacency or TE adjacency. OSPF-xTE routers form both types 💅.
There are two types of adjacency graphs, and which one you get depends on whether a Designated Router is elected for the network 🦋. On physical point-to-point networks, point-to-multipoint networks, and virtual links, neighboring routers become adjacent whenever they can talk to each other directly. That adjacency can be either (a) TE-compliant or (b) native 💜. On broadcast and NBMA networks, though, the designated router and the backup designated router may keep two sets of adjacency 🌸. The rest of the routers end up with either TE-compliant or native adjacency 🙈.
Check out Figure 2 below. Routers RT7 and RT3 get picked as the Designated and Backup Designated Routers, respectively 👑. RT3, RT4, and RT7 are TE-compliant, but RT5 and RT6 aren't 💀. So RT4 has TE-compliant adjacency with the designated and backup routers, while RT5 and RT6 only get native adjacency with them 😭.
Network Adjacency
+---+ +---+
|RT1|------------|RT2| o-----------------o
+---+ N1 +---+ RT1 RT2
RT7
o:::::
+---+ +---+ +---+ /| :
|RT7| |RT3| |RT4| / | :
+---+ +---+ +---+ / | :
| | | / | :
+-----------------------+ RT5o RT6o oRT4
N2 | | * * ;
+---+ +---+ * * ;
|RT5| |RT6| * * ;
+---+ +---+ ** ;
o;;;;;
RT3
Adjacency Legend:
----- Native adjacency (primary)
***** Native adjacency (backup)
::::: TE-compliant adjacency (primary)
;;;;; TE-compliant adjacency (backup)
Figure 2. Two Adjacency Graphs with TE-Compliant Routers8. TE LSAs for Packet Network 💖
the OSPFv2 protocol currently has a total of 11 LSA types 🌈. LSA types 1 through 5 are defined in [OSPF-V2]. LSA types 6, 7, and 8 are defined in [MOSPF], [NSSA], and [BGP-OSPF], respectively. LSA types 9 through 11 are defined in [OPAQUE] 🧚.
Every LSA type has its own unique flooding scope 🦋. Opaque LSA types 9 through 11 are general purpose LSAs, with flooding scope set to link-local, area-local, and AS-wide (except stub areas), in that order 💅.
In the subsections that follow, we define new LSAs for traffic engineering (TE) use 🎀. The values for the new TE LSA types are assigned with the high bit of the LSA-type octet set to 1 ✨. The new TE LSAs are mostly modeled after the existing LSAs for content format, and each one has a unique flooding scope 💜.
The TE-router LSA is defined to advertise the TE characteristics of an OSPF-xTE router and all the TE links attached to it 👑. The TE-incremental-Link-Update LSA is defined to advertise incremental updates to the metrics of a TE link 🔥. The flooding scope for both of these LSAs is restricted to an area 🌸.
The TE-Summary network and router LSAs are defined to advertise the reachability of area-specific TE networks and area border routers (along with router TE characteristics) to external areas 🍓. The flooding scope of the TE-Summary LSAs is the TE topology in the entire AS, minus the non-backbone area for which the advertising router is an ABR 🙈. Just like native OSPF summary LSAs, the TE-Summary LSAs don't reveal the topological details of an area to external areas 🫶.
The TE-AS-external LSA and the TE-Circuit-Path LSA are defined to advertise AS external network reachability and pre-engineered TE circuits, respectively 🌈. Flooding scope for both of these can be the entire AS, but flooding scope for the pre-engineered TE circuit LSA may optionally be restricted to just the TE topology within an area 🦋.
8.1. TE-Router LSA (0x81) 🧚
The TE-router LSA (0x81) is modeled after the router LSA and has the same flooding scope as the router LSA 💅. The difference is that its scope is restricted to only the OSPF-xTE nodes within the area 🎀. The TE router LSA describes the TE metrics of the router as well as the TE links attached to the router ✨. Here's the format of the TE-router LSA 💜. Unless specified explicitly otherwise, the fields mean the same thing they do in a router LSA, so we'll only go over the differences. The Router-TE flags, Router-TE TLVs, Link-TE options, and Link-TE TLVs each get their own sub-section below 👑.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 0x81 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |V|E|B| 0 | Router-TE flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router-TE flags (contd.) | Router-TE TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .... | # of TE links |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | 0 | Link-TE flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link-TE flags (contd.) | Zero or more Link-TE TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |8.1.1. Router-TE Flags: TE Capabilities of the Router 💖
these flags describe the TE capabilities of an OSPF-xTE router 🌈. The remaining bits of the 32-bit word are reserved for future use 🦋.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L|L|P| | | | |L|S|C|
|S|E|S| | | | |S|I|S|
|R|R|C| | | | |P|G|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|<---- Boolean TE flags ------->|<- TE flags pointing to TLVs ->|Bit LSR: when set, the router is considered to have LSR (Label-Switched Router) capability 💜.Bit LER: when set, the router is considered to have LER capability 🧚. All MPLS border routers will be required to have LER capability 👑. Setting both the LER and E bits indicates an AS Boundary router with LER capability 🔥. Setting both the LER and B bits indicates an area border router with LER capability 🌸.Bit PSC: indicates the node is packet-switch capable 🍓.Bit LSP: an MPLS Label switch TLVTE-NODE-TLV-MPLS-SWITCHINGfollows 🙈. This only applies when the PSC flag is set 🫶.Bit SIG: an MPLS Signaling-protocol-support TLVTE-NODE-TLV-MPLS-SIG-PROTOCOLSfollows 🌈.BIT CSPF: a CSPF algorithm support TLVTE-NODE-TLV-CSPF-ALGfollows 🦋.
8.1.2. Router-TE TLVs 💅
the following Router-TE TLVs are defined 🎀.
8.1.2.1. TE-NODE-TLV-MPLS-SWITCHING
Okay bestie, MPLS switching TLV is only for packet switched nodes 📦✨ It tells everyone what MPLS packet switching powers the TE node has 💅
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x8001 | Length = 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Depth | QOS | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Label Depth is how deep a label stack the node can handle on its ingress interfaces 🎀 It's one octet, and if the TLV isn't listed, we just assume a default value of 1 🌸 This matters when an LER has to pop multiple labels off the MPLS stack 🧚
QOS is a single-octet field that may be set to '1' or '0' 💜 Nodes that support QOS can read the EXP bits in the MPLS header and use them to prioritize multiple classes of traffic through the same LSP 🔥
8.1.2.2. TE-NODE-TLV-MPLS-SIG-PROTOCOLS
The MPLS signaling protocols TLV is the list of every signaling protocol the node supports 🦋 Each one gets its own octet 💖
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x8002 | Length = 5, 6 or 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol-1 | ... | .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+RSVP-TE is 1, CR-LDP is 2, and LDP is 3 🍓 Right now these are the only permitted signaling protocols, so no sneaking in others 🙈
8.1.2.3. TE-NODE-TLV-CSPF-ALGORITHMS
The CSPF algorithms TLV lists every CSPF algorithm code the node supports 🧚 Supporting CSPF algorithms makes the node eligible to compute complete or partial circuit paths 🌈 It also helps you figure out whether a node can expand loose routes (in an MPLS signaling request) into a detailed circuit path 👑
Each CSPF algorithm code takes two octets 💅 The algorithm codes may be vendor defined, and they only need to be unique within an Autonomous System 🫶 If the node supports 'n' CSPF algorithms, the Length is (4 + 4 * ((n+1)/2)) octets 🔥
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x8003 | Length = 4(1 + (n+1)/2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSPF-1 | .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSPF-n | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+8.1.2.4. TE-NODE-TLV-NULL
When a TE-Router or a TE link has several TLVs describing its metrics, the NULL TLV is what ends the TLV list 🛑✨
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x8888 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+8.1.3. Link-TE Flags: TE Capabilities of a Link
Okay so these flags describe the TE capabilities of a link 🦋 The remaining bits of the 32-bit word are reserved for future use 🔮
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|N|P| | | |D| |S|L|B|C|
|E|T|K| | | |B| |R|U|W|O|
| |E|T| | | |S| |L|G| |L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|<---- Boolean TE flags ------->|<- TE flags pointing to TLVs ->|- Bit TE tells you whether TE is permitted on the link 💖 A link can be denied for TE use by setting the flag to 0 🙅♀️
- Bit NTE tells you whether non-TE traffic is permitted on the TE link 🎀 This flag only matters when the TE flag is set 💅
- Bit PKT tells you whether or not the link can do IP packet processing 📦
- Bit DBS tells you whether or not database synchronization is permitted on this link 🔄
- Bit SRLG means the Shared Risk Link Group TLV TE-LINK-TLV-SRLG follows 🌸
- Bit LUG means the Link Usage Cost Metric TLV TE-LINK-TLV-LUG follows 💜
- Bit BW means one or more Link Bandwidth TLVs follow 🍓
- Bit COL means the Link Color TLV TE-LINK-TLV-COLOR follows 🌈
8.1.4. Link-TE TLVs
8.1.4.1. TE-LINK-TLV-SRLG
The SRLG describes the list of Shared Risk Link Groups the link belongs to 🧚 Each SRLG takes two octets 💅 If the link belongs to 'n' SRLGs, the Length is (4 + 4 * ((n+1)/2)) octets 🫶
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0001 | Length = 4(1 + (n+1)/2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG-1 | .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG-n | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+8.1.4.2. TE-LINK-TLV-BANDWIDTH-MAX
The Bandwidth TLV specifies the maximum bandwidth of the link, like so 📈
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0002 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Bandwidth is expressed in units of 32 bytes/sec (256 bits/sec) 🌟 A 32-bit field for bandwidth would permit specification not exceeding 1 terabit/sec 💫
Maximum Bandwidth is the maximum link capacity, expressed in bandwidth units 💖 Portions or all of this bandwidth may be used for TE use 🎀
8.1.4.3. TE-LINK-TLV-BANDWIDTH-MAX-FOR-TE
The Bandwidth TLV specifies the maximum bandwidth available for TE use, like this 🦋
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0003 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Bandwidth available for TE use |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Bandwidth is expressed in units of 32 bytes/sec (256 bits/sec) 🌟 A 32-bit field for bandwidth would permit specification not exceeding 1 terabit/sec 💫
"Maximum Bandwidth available for TE use" is the total reservable bandwidth on the link for use by all the TE circuit paths traversing the link 🧚 The link is oversubscribed when this field is more than the Maximum Bandwidth 🙈 When the field is less than the Maximum Bandwidth, the remaining bandwidth on the link may be used for non-TE traffic in a mixed network 🌈
8.1.4.4. TE-LINK-TLV-BANDWIDTH-TE
The Bandwidth TLV specifies the bandwidth reserved for TE, 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE Bandwidth subscribed |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Bandwidth is expressed in units of 32 bytes/sec (256 bits/sec) 🌟 A 32-bit field for bandwidth would permit specification not exceeding 1 terabit/sec 💫
"TE Bandwidth subscribed" is the bandwidth that is currently subscribed from the link 💖 "TE Bandwidth subscribed" must be less than the "Maximum bandwidth available for TE use" 🎀 New TE circuit paths can claim no more than the difference between the two bandwidths for reservation 🫶
8.1.4.5. TE-LINK-TLV-LUG
The link usage cost TLV specifies the bandwidth unit usage cost, the TE circuit set-up cost, and any time constraints for setting up and tearing down TE circuits on the link 🔥
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0005 | Length = 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth unit usage cost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE circuit set-up cost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE circuit set-up time constraint |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE circuit tear-down time constraint |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Circuit Setup time constraint 🧚
This 64-bit number specifies the time at or after which a TE-circuit path may be set up on the link ⏰ The set-up time constraint is the number of seconds from the start of January 1, 1970 UTC 📅 A reserved value of 0 implies no circuit setup time constraint 🌸
Circuit Teardown time constraint 🧚
This 64-bit number specifies the time at or before which all TE-circuit paths using the link must be torn down ⏰ The teardown time constraint is the number of seconds from the start of January 1 1970 UTC 📅 A reserved value of 0 implies no circuit teardown time constraint 🌸
8.1.4.6. TE-LINK-TLV-COLOR 🎨
okay so the color TLV is basically the SRLG TLV's fashionable cousin 💅 An Autonomous System can decide to hand out colors to a TE link when it meets certain criteria. Each color takes up two octets. If a link is in 'n' colors, the Length works out to 4 + 4 * ((n+1)/2) octets. (Yes, the bracket math is a whole vibe 🙈)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0006 | Length = 4(1 + (n+1)/2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Color-1 | .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Color-n | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+8.1.4.7. TE-LINK-TLV-NULL 🫶
when a TE link has a bunch of TLVs describing its metrics, the NULL TLV is what closes out the TLV list, like the final bow on the outfit 🎀 The TE-LINK-TLV-NULL is the same as the TE-NODE-TLV-NULL we covered in section 8.1.2.4.
8.2. TE-Incremental-Link-Update LSA (0x8d) 🦋
okay this one is lowkey the star of the show 🌟 A big difference between a regular OSPF network and a TE network is that TE networks can get hit with frequent real-time circuit pinning and tend to have TE-state updates all the time. Some links change way more often than others, and flooding the whole network with TE-router LSAs at the combined speed of every single link metric change is just not it 😭 So the TE-incremental-link-update LSA is a smaller one that only advertises the incremental link updates.
A TE-incremental-link-update LSA gets advertised as often as the link state changes, but never more than once every MinLSInterval seconds. Its TE link sequence is mostly an advertisement of a sub-portion of the router LSA. Its sequence number increments using the TE-router LSA's sequence as the starting point. When an updated TE-router LSA gets advertised within 30 minutes of the previous advertisement, that updated TE-router LSA takes a sequence number larger than that of the most frequently updated of its links. Iconic behaviour, honestly 👑
Here's the format of the TE-incremental-link-update LSA:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 0x8d |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID (same as Link ID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | 0 | Link-TE options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link-TE options | Zero or more Link-TE TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # TOS | metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TOS | 0 | TOS metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Link State ID 🧚
this is exactly the same as what would've been specified for Link ID, for a link inside the router LSA. Same energy, different LSA 💜
Link Data 🌸
this specifies the router ID the link belongs to. Most of the time it's the same as the advertising router. This choice for Link Data is mainly there to make proxy advertisement for incremental link updates easier.
Picture this: a proxy router LSA was used to advertise the TE-router LSA of a SONET/TDM node, and now that proxy router has to advertise an incremental-link-update for that same SONET/TDM node. Naming the actual router-ID the link belongs to in the incremental-link-update LSA helps receiving nodes find the exact match for the LSA in their database. Lowkey genius 🧠
The tuple of (LS Type, LSA ID, Advertising router) uniquely identifies the LSA, and it replaces LSAs with the same tuple and an older sequence number. There is one exception to this rule for TE-link-update LSAs, though 👀 A TE-link-update LSA starts out with the sequence number of the TE-router LSA it belongs to. Then, whenever a new TE-router LSA update with a larger sequence number gets advertised, all the link LSAs take on that newer sequence number. Periodt 💅
8.3. TE-Circuit-Path LSA (0x8C) ⭐
TE-Circuit-path LSA (next page) can be used to advertise the availability of pre-engineered TE circuit path(s) that start from any router in the network. The flooding scope can be area-wide or AS-wide. The fields go like this:
Link State ID 💖
this is the ID of the far-end router, or the far-end link-ID, that the TE circuit path(s) is being advertised to.
TE-circuit-path(s) flags 🌈
the flags are set up like this:
Bit G - When set, the flooding scope is set to be AS-wide.
Otherwise, the flooding scope is set to be area-wide.
Bit E - When set, the advertised Link-State ID is an AS boundary
router (E is for external). The advertising router and
the Link State ID belong to the same area.
Bit B - When set, the advertised Link State ID is an area border
router (B is for Border)
Bit D - When set, this indicates that the duration of circuit
path validity follows.
Bit S - When set, this indicates that setup time of the circuit
path follows.
Bit T - When set, this indicates that teardown time of the
circuit path follows.
CktType - This 4-bit field specifies the circuit type of the
Forward Equivalency Class (FEC).
0x01 - Origin is Router, Destination is Router.
0x02 - Origin is Link, Destination is Link.
0x04 - Origin is Router, Destination is Link.
0x08 - Origin is Link, Destination is Router.Here's the layout of the TE-Circuit-path LSA:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 0x84 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |G|E|B|D|S|T|CktType| Circuit Duration (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Circuit Duration cont... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Circuit Duration cont.. | Circuit Setup time (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Circuit Setup time cont... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Circuit Setup time cont.. |Circuit Teardown time(Optional)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Circuit Teardown time cont... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Circuit Teardown time cont.. | No. of TE Circuit Paths |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Circuit-TE ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Circuit-TE Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | 0 | Circuit-TE flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Circuit-TE flags (contd.) | Zero or more Circuit-TE TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Circuit-TE ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Circuit-TE Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |Circuit Duration (Optional) ⏳
this 64-bit number specifies the seconds, counted from the time of the LSA advertisement, for which the pre-engineered circuit path will be valid. This field only shows up when the D-bit is set in the TE-circuit-path flags.
Circuit Setup time (Optional) 🕰️
this 64-bit number specifies the time at which the TE circuit path may be set up. This field only shows up when the S-bit is set in the TE-circuit-path flags. The set-up time is given as the number of seconds from the start of January 1, 1970 UTC.
Circuit Teardown time (Optional) 🌙
this 64-bit number specifies the time at which the TE circuit path may be torn down. This field only shows up when the T-bit is set in the TE-circuit-path flags. The teardown time is given as the number of seconds from the start of January 1 1970 UTC.
No. of TE Circuit Paths 🔢
this specifies how many pre-engineered TE circuit paths there are between the advertising router and the router named in the Link State ID.
Circuit-TE ID 🪪
this is the ID of the far-end router for a given TE circuit path segment.
Circuit-TE Data 🎀
this is the virtual link identifier on the near-end router for a given TE circuit path segment. It can be a private interface, or a handle the near-end router uses to identify the virtual link.
The sequence of (Circuit-TE ID, Circuit-TE Data) pairs lists the end-point nodes and links in the LSA as a series. Main character energy 👑
Circuit-TE flags ✨
this lists the zero or more TE-link TLVs that all member elements of the LSP meet. that's the whole chain, bestie 🌈
8.4. TE-Summary LSAs ✨
okay bestie, TE-Summary LSAs are the Type 0x83 and 0x84 ones 🦋 They get originated by area border routers (ABRs). A TE-Summary-network LSA (0x83) tells everyone what TE networks are reachable in a non-backbone area, and the ABR is the one advertising it 🌸 A Type 0x84 summary LSA covers area border routers and AS border routers, plus their TE capabilities 💅
the main-character benefit of having multiple areas in an AS is that all the chatty TE advertisements inside one area stay inside that area 🤫 Only the TE abstractions that make sense for the external areas get advertised outside. literally so efficient 😭
8.4.1. TE-Summary Network LSA (0x83)
a TE-Summary network LSA can be used to advertise reachability of TE-networks that are accessible to areas outside the originating area 🧚 It's not the same as a native Summary LSA, though. Both the content and the flooding scope are different 👑
the flooding scope for a TE-Summary network LSA is AS-wide, except for the originating area and the stub areas 🌈 The area border router for each non-backbone area is in charge of advertising the reachability of backbone networks into that area 🫶
here's the twist: unlike a native summary network LSA, a TE-Summary network LSA does not advertise summary costs for reaching networks inside an area 💀 That's because TE parameters aren't necessarily additive or comparable, and they can be expressed in lots of different ways 🙈 For example, a TE-Summary network LSA won't summarize a network whose links don't fall under an SRLG (Shared-Risk Link Group) 🔥 So the TE-Summary LSA just says "these TE networks are reachable in this area," and nothing more ✨ The specific circuit paths can be computed by the ABR. Pre-engineered circuit paths get advertised using TE-Circuit-path LSAs (refer to Section 8.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 0x83 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID (IP Network Number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router (Area Border Router) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+8.4.2. TE-Summary Router LSA (0x84)
a TE-Summary router LSA can be used to advertise the availability of area border routers (ABRs) and AS border routers (ASBRs) that are TE-capable 🧚 These are originated by the Area Border Routers, and the flooding scope is the non-backbone area that the advertising ABR belongs to 🌸
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 0x84 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router (ABR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |E|B| 0 | No. of Areas |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router-TE flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router-TE TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Link State ID 🫶 The ID of the area border router or the AS border router whose TE capability is being advertised.
Advertising Router 👑 The ABR that advertises its own TE capabilities (plus the OSPF areas it belongs to), or the TE capabilities of an ASBR sitting inside one of the areas where the ABR is a border router.
No. of Areas 🌈 How many OSPF areas the link state ID belongs to.
Area-ID 🦋 The OSPF area(s) the link state ID belongs to. When the link state ID is the same as the advertising router ID, the Area-ID lists every area the ABR belongs to. If the link state ID is an ASBR, the Area-ID just lists the area that ASBR is in. The advertising router is assumed to be the ABR from the same area the ASBR is located in.
Summary-router-TE flags 🎀
Bit E: when this is set, the advertised Link-State ID is an AS boundary router (E is for external). The advertising router and the Link State ID belong to the same area.Bit B: when this is set, the advertised Link state ID is an Area border router (B is for Border).
Router-TE flags, Router-TE TLVs ✨ These describe the TE capabilities of the link-state-ID router. TE Flags and TE TLVs apply to the ABR/ASBR named in the link state ID, and they mean the same thing as they do in the Router-TE LSA 🧚
8.5. TE-AS-external LSAs (0x85)
TE-AS-external LSAs are the Type 0x85 LSAs 💖 They're modeled after the AS-external LSA format and flooding scope 🫶 They get originated by AS boundary routers with TE extensions, and they describe the TE networks and pre-engineered circuit paths that live outside the AS 🌍 Just like with AS-external LSAs, the flooding scope of a TE-AS-external LSA is AS-wide, except for stub areas 🔥
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 0x85 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Forwarding address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| External Route Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # of Virtual TE links | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link-TE flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link-TE TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE-Forwarding address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| External Route TE Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |Network Mask 🌸 The IP address mask for the advertised TE destination. For instance, you can use it to point at one specific TE node or TE link with a mask of 0xffffffff. It can also cover an aggregated set of destinations with a different mask, like 0xff000000 🧚
Link-TE flags, Link-TE TLVs 💅 These describe the TE attributes of this route. They're optional, and they only show up when one or more pre-engineered circuits can be specified with the advertisement. Without them, the LSA just says there's TE reachability 🙈
Forwarding address 🦋 Data traffic for the advertised destination gets forwarded to this address. If the Forwarding address is set to 0.0.0.0, the traffic goes to the LSA's originator instead (that's the responsible AS boundary router) 👑
External Route Tag 💜 A 32-bit field attached to each external route. OSPF itself doesn't use it. It can be used to pass info between AS boundary routers, and the exact nature of that info is outside the scope of this specification 🫶
9. TE LSAs for Non-Packet Network 🌈
a non-packet network uses the TE LSAs from the previous section, just with some variations 🧚 Those variations are described in the subsections that follow ✨
Two new LSAs, TE-Positional-ring-network LSA and TE-Router-Proxy LSA, are defined for use in non-packet TE networks 🎀
Readers may refer to [SONET-SDH] for a detailed description of the terms used in the context of SONET/SDH TDM networks, 🦋
9.1. TE-Router LSA (0x81) 💖
okay so this section is all about the router links, aka each interface on a router 🔗. every router link gets a type, and the Type field tells you what kind of link you're looking at. slay 💅
Type
ok the big news here is a brand new link type: "Positional-Ring Type" (value 5) 🎀 it's basically a connection to a TDM-Ring, and it's not the same as a LAN/NBMA transit network, bestie. three reasons:
- first, nodes on a TDM ring don't necessarily have a terminating path between themselves 🌀
- second, the order of the links matters for working out the circuit path 📍
- third, the protection switching and the number of fibers going from a node into the ring are decided by the ring's characteristics. think 2-fiber vs. 4-fiber rings, and Unidirectional Path Switched Ring (UPSR) vs. Bidirectional Line Switched Ring (BLSR) 🌈
here's the full list of type values:
Type Description
__________________________________________________
1 Point-to-point connection to another router
2 Connection to a transit network
3 Connection to a stub network
4 Virtual link
5 Positional-Ring type.Link ID
this tells you what the link is connected to 🧚 the value depends on the link's Type. for a positional-ring type, the Link ID is the IP Network/Subnet number, just like with a broadcast transit network. here's the updated Link ID table:
Type Link ID
______________________________________
1 Neighboring router's Router ID
2 IP address of Designated Router
3 IP network/subnet number
4 Neighboring router's Router ID
5 IP network/subnet numberLink Data
this one depends on the Type field too 🍓 for type-5 links, it gives you the router interface's IP address.
9.1.1. Router-TE flags - TE Capabilities of a Router 🦋
these flags are for the non-packet TE nodes, so here's the vibe check:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L|L|P|T|L|F| |S|S|S|C|
|S|E|S|D|S|S| |T|E|I|S|
|R|R|C|M|C|C| |A|L|G|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|<---- Boolean TE flags ------->|<- TE flags pointing to TLVs ->|- TDM bit: the node is TDM circuit switch capable 🔌
- LSC bit: the node can do Lambda switching 💡
- FSC bit: the node can do fiber-switching (it can also be a non-fiber link type) ✨
9.1.2. Link-TE Options: TE Capabilities of a TE Link 🎀
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|N|P|T|L|F|D| |S|L|B|C|
|E|T|K|D|S|S|B| |R|U|W|O|
| |E|T|M|C|C|S| |L|G|A|L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|<---- Boolean TE flags ------->|<- TE flags pointing to TLVs ->|the TDM, LSC and FSC bits mean the same thing as they do for the router TE options 🌸
9.2. TE-positional-ring-network LSA (0x82) 🌈
okay so a regular Network LSA is fine for packet TE networks, but for the type-5 link networks found in non-packet networks like SONET/SDH TDM rings, we get a brand new TE-positional-ring-network LSA 💫 a type-5 ring is a bunch of network elements (NEs) forming a closed loop 🔁 each NE hooks up to two neighbouring NEs with a duplex connection, which gives you redundancy. the order the NEs sit on the ring matters a lot 😤
the NE that handles the OSPF-xTE functionality is called the Gateway Network Element (GNE) 👑 how the GNE gets picked is outside the scope of this document. the GNE is also known as the Designated Router for the ring.
the TE-positional-ring-network LSA (0x82) is modeled on the network LSA and has the same flooding scope as the network LSA among the OSPF-xTE nodes within the area 🦋 here's the format. unless it's explicitly said otherwise, the fields mean the same thing as they do in a network LSA, so only the differences get explained below 🙈
a TE-positional-ring-network LSA is originated for each Positional-Ring type network in the area. the tuple of (Link State ID, Network Mask) uniquely represents a ring, and the TE option must be set in the Options flag while the LSA is propagated 💜
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 0x82 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ring Type | Capacity Unit | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ring capacity |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Element Node Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |Link State ID 🆔
this is the IP interface address of the network's Gateway Network Element, which is also the designated router 🌟
Advertising Router 📣
the Router ID of the network's Designated Router 💖
Ring type 💍
there are 8 types of SONET/SDH rings, and they go like this:
- 1 - A Unidirectional Line Switched 2-fiber ring (2-fiber ULSR)
- 2 - A Bidirectional Line switched 2-fiber ring (2-fiber BLSR)
- 3 - A Unidirectional Path Switched 2-fiber ring (2-fiber UPSR)
- 4 - A Bidirectional Path switched 2-fiber ring (2-fiber BPSR)
- 5 - A Unidirectional Line Switched 4-fiber ring (4-fiber ULSR)
- 6 - A Bidirectional Line switched 4-fiber ring (4-fiber BLSR)
- 7 - A Unidirectional Path Switched 4-fiber ring (4-fiber UPSR)
- 8 - A Bidirectional Path switched 4-fiber ring (4-fiber BPSR)
Capacity Unit 📏
two units are defined right now:
- 1 - Synchronous Transport Signal (STS), the basic signal rate for SONET signals. an STS signal runs at 51.84 Mbps 🚀
- 2 - Synchronous Transport Multiplexer (STM), the basic signal rate for SDH signals. an STM signal runs at 155.52 Mbps 🌊
Ring capacity 🍯
the ring capacity, expressed as a number of Capacity Units 🦄
Network Element Node Id 🧚♀️
this is the Router ID of each router in the positional-ring network. the list must start with the designated router as the first element. the Network Elements (NEs) must be listed in strict clockwise order as they appear on the ring, starting with the Gateway Network Element (GNE) 🔄 the number of NEs in the ring can be worked out from the LSA header's length field 🧮
9.3. TE-Router-Proxy LSA (0x8e) 🫶
this is a variation of the TE-router LSA. the difference is that the TE-router LSA isn't advertised by the network element itself, it's advertised by a trusted TE-router Proxy 🛡️ this usually happens in a non-packet TE network, where some nodes don't have OSPF functionality and rely on a helper node to do the advertising for them. a classic example is the SONET/SDH Add-Drop Multiplexer (ADM) nodes in a TDM ring 🧃 those nodes will mostly lean on the GNE (Gateway Network Element) to advertise for them 🥹 the TE-router-Proxy LSA shall not be used to advertise area border routers and/or AS border routers 🚫
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 0x8e |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID (Router ID of the TE Network Element) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Router-TE flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router-TE flags (contd.) | Router-TE TLVs |
+---------------------------------------------------------------+
| .... |
+---------------------------------------------------------------+
| .... | # of TE links |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | 0 | Link-TE options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link-TE flags | Zero or more Link-TE TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |10. Abstract Topology Representation with TE Support ✨
Okay so picture this bestie 🧚 we've got a TE network made of three OSPF areas, Area-1, Area-2, and Area-3, all linked together through the backbone area 🦋. Area-1 has one area border router, ABR-A1, and no ASBRs, which is lowkey the simplest setup. Area-2 has an area border router ABR-A2 and an AS border router ASBR-S1. Area-3 has two area border routers, ABR-A2 and ABR-A3, plus an AS border router ASBR-S2. The network also assumes pre-engineered TE circuit paths between ABR-A1 and ABR-A2, between ABR-A1 and ABR-A3, between ABR-A2 and ASBR-S1, and between ABR-A3 and ASBR-S2 💅.
The next figure is an inter-area topology abstraction from the point of view of the routers in Area-1. It shows how TE networks and nodes inside the area can reach the external areas in the same AS and the external ASes 🌈. It also shows the pre-engineered TE circuit paths that ABRs and ASBRs advertise ✨.
+-------+
|Area-1 |
+-------+
+-------------+ |
|Reachable TE | +--------+
|networks in |-------| ABR-A1 |
|backbone area| +--------+
+-------------+ | | |
+--------------+ | +-----------------+
| | |
+-----------------+ | +-----------------+
|Pre-engineered TE| +----------+ |Pre-engineered TE|
|circuit path(s) | | Backbone | |circuit path(s) |
|to ABR-A2 | | Area | |to ABR-A3 |
+-----------------+ +----------+ +-----------------+
| | | |
+----------+ | +--------------+ |
+-----------+ | | | | +-----------+
|Reachable | +--------+ +--------+ |Reachable |
|TE networks|------| ABR-A2 | | ABR-A3 |--|TE networks|
|in Area A2 | +--------+ +--------+ |in Area A3 |
+-----------+ | | | | | | +-----------+
+-------------+ | | +-----------------+ | +----------+
| | +-----------+ | | |
+-----------+ +--------------+ | | | +--------------+
|Reachable | |Pre-engineered| | | | |Pre-engineered|
|TE networks| |TE Ckt path(s)| +------+ +------+ |TE Ckt path(s)|
|in Area A3 | |to ASBR-S1 | |Area-2| |Area-3| |to ASBR-S2 |
+-----------+ +--------------+ +------+ +------+ +--------------+
| | | |
| +--------+ | +-----------+
+-------------+ | | | |
|AS external | +---------+ +---------+
|TE-network |----| ASBR-S1 | | ASBR-S2 |
|reachability | +---------+ +---------+
|from ASBR-S1 | | | |
+-------------+ +---+ +-------+ +-----------+
| | |
+-----------------+ +-------------+ +-----------------+
|Pre-engineered TE| |AS External | |Pre-engineered TE|
|circuit path(s) | |TE-Network | |circuit path(s) |
|reachable from | |reachability | |reachable from |
|ASBR-S1 | |from ASBR-S2 | |ASBR-S2 |
+-----------------+ +-------------+ +-----------------+
Figure 3: Inter-Area Abstraction as viewed by Area-1 TE-routers11. Changes to Data Structures in OSPF-xTE Nodes
11.1. Changes to Router Data Structure
Here's the deal 💖: an OSPF-xTE router must be able to include the router-TE capabilities (as specified in section 8.1) in the router data structure. OSPF-xTE routers that provide proxy service to other TE routers must also track the router and associated interface data structures for all the TE client nodes they're proxying for 🫶. Presumably, the interaction between the Proxy server and the proxy clients is out-of-band 🙈.
11.2. Two Sets of Neighbors
Two sets of neighbor data structures are required 👑. The TE-neighbors set is used to advertise TE LSAs, and only the TE nodes will be members of it. The Native neighbors set is used to advertise native LSAs, and all neighboring nodes that support non-TE links are part of it ✨.
11.3. Changes to Interface Data Structure
The following new fields are introduced to the interface data structure 🎀.
TePermitted
If the value of the flag is TRUE, the interface may be advertised as a TE-enabled interface 🦋.
NonTePermitted
If the value of the flag is TRUE, the interface permits non-TE traffic on the interface. Specifically, this is applicable to packet networks, where data links may permit both TE and IP packets 🌸. For FSC and LSC TE networks, this flag is set to FALSE.
FloodingPermitted
If the value of the flag is TRUE, the interface may be used for OSPF and OSPF-xTE packet exchange to synchronize the LSDB across all adjacent neighbors. This is TRUE by default for all NonTePermitted interfaces that are enabled for OSPF. However, it is possible to set this to FALSE for some of the interfaces 💅.
TE-TLVs
Each interface may define any number of TLVS that describe the link characteristics 🧚.
The following existing fields in the Interface data structure will take on additional values to support TE extensions 🌈.
Type
The OSPF interface type can also be of type "Positional-Ring". The Positional-Ring type is different from other types (such as broadcast and NBMA) in that the exact location of the nodes on the ring is relevant, even though they are all on the same ring. A SONET ADM ring is a good example of this. A complete ring positional-ring description may be provided by the GNE on a ring as a TE-network LSA for the ring 💜.
List of Neighbors
The list may be statically defined for an interface without requiring the use of the Hello protocol 🍓.
12. IANA Considerations
The IANA has assigned multicast address 224.0.0.24 to OSPFIGP-TE for the exchange of TE database descriptors 📮.
TE LSA types and TE TLVs will be maintained by the IANA, using the following criteria 💖.
12.1. TE LSA Type Values
LSA type is an 8-bit field required by each LSA. TE LSA types will have the high bit set to 1. TE LSAs can range from 0x80 through 0xFF. The following values are defined in sections 8.0 and 9.0. The remaining values are available for assignment by the IANA with IETF Consensus [RFC2434] 🔥.
TE LSA Type Value
_________________________________________
TE-Router LSA 0x81
TE-Positional-ring-network LSA 0x82
TE-Summary Network LSA 0x83
TE-Summary router LSA 0x84
TE-AS-external LSAs 0x85
TE-Circuit-paths LSA 0x8C
TE-incremental-link-Update LSA 0x8d
TE-Router-Proxy LSA 0x8e12.2. TE TLV Tag Values
TLV type is a 16-bit field required by each TE TLV. The TLV type shall be unique across the router and link TLVs. A TLV type can range from 0x0001 through 0xFFFF, and TLV type 0 is reserved and unassigned 🙈. The following TLV types are defined in sections 8.0 and 9.0. The remaining values are available for assignment by the IANA with IETF Consensus [RFC2434] ✨.
TE TLV Tag Reference Value
Section
_________________________________________________________
TE-LINK-TLV-SRLG Section 8.1.4.1 0x0001
TE-LINK-TLV-BANDWIDTH-MAX Section 8.1.4.2 0x0002
TE-LINK-TLV-BANDWIDTH-MAX-FOR-TE Section 8.1.4.3 0x0003
TE-LINK-TLV-BANDWIDTH-TE Section 8.1.4.4 0x0004
TE-LINK-TLV-LUG Section 8.1.4.5 0x0005
TE-LINK-TLV-COLOR Section 8.1.4.6 0x0006
TE-LINK-TLV-NULL Section 8.1.4.7 0x8888
TE-NODE-TLV-MPLS-SWITCHING Section 8.1.2.1 0x8001
TE-NODE-TLV-MPLS-SIG-PROTOCOLS Section 8.1.2.2 0x8002
TE-NODE-TLV-CSPF-ALG Section 8.1.2.3 0x8003
TE-NODE-TLV-NULL Section 8.1.2.4 0x888813. Acknowledgements
The authors wish to specially thank Chitti Babu and his team 🫶 for implementing the protocol specified in a packet network and verifying several portions of the specification in a mixed packet network 🌟. The authors also wish to thank Vishwas Manral, Riyad Hartani, and Tricci So for their valuable comments and feedback on the document 💜. Lastly, the authors wish to thank Alex Zinin and Mike Shand for their document (now defunct) titled "Flooding optimizations in link state routing protocols" 🦋. The document inspired the authors to be sensitive to the high flooding rate that is likely in TE networks 🔥.
14. Security Considerations ✨
okay, security is the part where we get serious bestie 🔐💅. Base OSPF security lives in [OSPF-V2] and [SEC-OSPF], and this memo does not add any new security issues for OSPF 🫶. The native OSPF security measures (refer [SEC-OSPF]) apply directly to the TE LSAs in this doc, so you get those for free ✨. Below is what matters when processing TE LSAs.
Secure communication between OSPF-xTE nodes has four parts: authorization, authentication, integrity and confidentiality 🎀.
Authorization is about whether a particular OSPF-xTE node is allowed to receive or propagate TE LSAs to its neighbors. If authorization fails, it could mean someone is trying to steal resources or advertise resources they shouldn't 👀. Either way, OSPF-xTE nodes should audit or log those attempts so the administrator gets alerted and can take action 🚨. OSPF-xTE nodes may also refuse to talk to neighbors that fail to prompt the required credentials 🙅♀️.
Authentication is confirming who actually sent a datagram 🪪. Without strong credentials for authenticating OSPF-xTE LSAs, the TE service the network provides can be seriously jeopardized 💀. If you don't authenticate a neighbor, an attacker can spoof a "legitimate" OSPF-xTE node, manipulate the state, and mess with the TE database, including the topology and the collected metrics. That could cause denial-of-service on the TE network 😭. Another problem: an attacker could pose as an OSPF-xTE neighbor and reply in a way that diverts TE data to them 🙈.
Integrity makes sure an OSPF-xTE message hasn't been accidentally or maliciously altered or destroyed 🔒. In an untrusted environment, no integrity enforcement means an imposter could alter messages from a legitimate adjacent neighbor. That could bring OSPF-xTE on a node, and the whole network, to a halt, or cause denial of service for the TE circuit paths affected by the change 🛑.
Confidentiality means TE LSAs are only accessible to authorized entities 🤫. In an untrusted environment, no confidentiality lets an intruder do traffic flow analysis and snoop on the TE control network. They can monitor traffic metrics and see how fast circuit paths are being set up and torn down 👁️. The intruder could also take over a less secure OSPF-xTE node and destroy or compromise its state and TE-LSDB 💥. Needless to say, the least secure OSPF-xTE node becomes the Achilles heel and makes the whole TE network vulnerable to attacks 🥀.
15. Normative References 📚
[MPLS-ARCH] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, Jaunary 2001.
[MPLS-TE] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
McManus, "Requirements for Traffic Engineering Over
MPLS", RFC 2702, September 1999.
[OSPF-V2] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[SEC-OSPF] Murphy, S., Badger, M., and B. Wellington, "OSPF with
Digital Signatures", RFC 2154, June 1997.
[OSPF-CAP] Lindem, A., Ed., Shen, N., Vasseur, J., Aggarwal, R., and
S. Schaffer, "Extensions to OSPF for Advertising
Optional Router Capabilities", RFC 4970, July 2007.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.16. Informative References 🧠
[BGP-OSPF] Ferguson, D., "The OSPF External Attribute LSA",
unpublished.
[CR-LDP] Jamoussi, B., Andersson, L., Callon, R., Dantu, R., Wu,
L., Doolan, P., Worster, T., Feldman, N., Fredette, A.,
Girish, M., Gray, E., Heinanen, J., Kilty, T., and A.
Malis, "Constraint-Based LSP Setup using LDP", RFC 3212,
January 2002.
[GMPLS-TE] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
[MOSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March
1994.
[NSSA] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option",
RFC 3101, January 2003.
[OPAQUE] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July
1998.
[OPQLSA-TE] Katz, D., Yeung, D., and K. Kompella, "Traffic
Engineering Extensions to OSPF", RFC 3630, September
2003.
[RSVP-TE] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[SONET-SDH] Chow, M.-C., "Understanding SONET/SDH Standards and
Applications", Holmdel, N.J.: Andan Publisher, 1995.Authors' Addresses 💌
Pyda Srisuresh
Kazeon Systems, Inc.
1161 San Antonio Rd.
Mountain View, CA 94043
U.S.A.
Phone: (408) 836-4773
EMail: srisuresh@yahoo.com
Paul Joseph
Consultant
10100 Torre Avenue, # 121
Cupertino, CA 95014
U.S.A.
Phone: (408) 777-8493
EMail: paul_95014@yahoo.comFull Copyright Statement ©️
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 🪄
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available. It also doesn't represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat, and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification, can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Acknowledgement 🌸
Funding for the RFC Editor function is currently provided by the Internet Society. 💖
📦 where this page comes from
- ietf: rfc4973 2007-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms