< draft-srisuresh-ospf-te-01.txt   draft-srisuresh-ospf-te-02.txt >
Network Working Group P. Srisuresh Network Working Group P. Srisuresh
INTERNET-DRAFT Kuokoa Networks INTERNET-DRAFT Kuokoa Networks
Expires as of January 20, 2002 P. Joseph Expires as of July 04, 2002 P. Joseph
Jasmine Networks Vivace Networks
July, 2001 January 4, 2002
TE LSAs to extend OSPF for Traffic Engineering TE LSAs to extend OSPF for Traffic Engineering
<draft-srisuresh-ospf-te-01.txt> <draft-srisuresh-ospf-te-02.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
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 35 skipping to change at page 1, line 35
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
OSPF is a well established link state routing protocol used for OSPF is a link state routing protocol used for IP-network
topology discovery and computing forwarding table based on topology discovery and collection and dissemination of link
shortest-Path criteria. Traffic Engineering extensions (OSPF-TE) access metrics. The resulting Link State Database (LSDB) is
will use criteria different from shortest-path so as to route used to compute IP address forwarding table based on
traffic around congestion paths and meet varying Service Level shortest-path criteria. Traffic Engineering extensions(OSPF-TE)
agreements. OSPF-TE may also be used by non-IP networks such as outlined in this document are built on the native OSPF
photonic and TDM (SONET/SDH) circuit switch networks for foundation, utilizing new LSAs, designed specifically for TE.
light-path or TDM circuit setup between two end-points. The OSPF-TE sets out to discover TE network topology and perform
approach outlined in this document differs from that of collection and dissemination of TE metrics within the TE network.
[OPQLSA-TE]. The document does not suggest the use of Opaque LSAs This results in the generation of an independent TE-LSDB, that
to add TE extensions to OSPF. Rather, new TE LSAs, modeled after would permit computation of TE circuit paths. Unlike the native
existing LSAs and flooding scope are proposed to overcome the OSPF link metrics, TE metrics can be rapidly changing and
scaling limitations of the approach outlined in [OPQLSA-TE]. The varied across different elements of the network. TE circuit
document draws a distinction between TE and non-TE topologies and paths are computed using varied TE criteria, often different
restricts flooding of TE LSAs into non-TE topology. The document from the shortest-path, to route traffic around congestion
covers OSPF extensions for packet and non-packet networks alike, paths. Principal motivations to designing the OSPF-TE over
providing a unified extension mechanism for all networks. As such, [OPQLSA-TE] and transition path for vendors currently using
this approach improves interoperability between peer network [OPQLSA-TE] to adapt the OSPF-TE are outlined in separate
elements. Lastly, the document specifies a transition path for sections within the document. OSPF-TE provides a single unified
vendors currently using opaque LSAs to transition to using new mechanism for traffic engineering across packet and non-packet
TE LSAs outlined here. networks, and may be adapted for a peer networking model.
Table of Contents Table of Contents
1. Introduction ................................................3 1. Introduction ................................................3
2. Traffic Engineering .........................................4 2. Traffic Engineering .........................................4
3. Terminology .................................................5 3. Terminology .................................................5
3.1. OSPF-TE router (or) TE-compliant OSPF router ...........5 3.1. OSPF-TE node ...........................................5
3.2. Native OSPF router .....................................5 3.2. Native OSPF node .......................................5
3.3. TE nodes vs. non-TE (native) nodes .....................6 3.3. TE nodes vs. native(non-TE) nodes ......................6
3.4. TE links vs. non-TE (native) links .....................6 3.4. TE links vs. native(non-TE) links ......................6
3.5. Packet interface vs. non-packet interface ..............6 3.5. Packet-TE network vs. non-packet-TE network ............6
3.6. TE topology vs. non-TE topology ........................6 3.6. TE topology vs. non-TE topology ........................6
3.7. TLV ....................................................7 3.7. TLV ....................................................7
3.8. Router-TE TLVs .........................................7 3.8. Router-TE TLVs .........................................7
3.9. Link-TE TLVs ...........................................7 3.9. Link-TE TLVs ...........................................7
4. Motivation and Implicit assumptions for the TE extensions ...7 4. Motivations to designing the OSPF-TE using TE-LSAs ..........7
5. The OSPF Options field ......................................9 4.1. Clean design - TE-LSDB, independent of the native LSDB .7
6. Bringing up TE adjacencies; TE vs. Non-TE topologies .......10 4.2. Extendible design - based on the OSPF foundation .......8
6.1. The Hello Protocol ...................................10 4.3. Scalable design - TE-AS may be sub-divided into areas ..9
6.2. Flooding and the Synchronization of Databases .........10 4.4. Unified design - for packet and non-packet networks ....9
6.3. The Designated Router ................................11 4.5. Efficient design - in LSA content and flooding reach ..10
6.4. The Backup Designated Router .........................12 4.6. SLA enforceable TE network can coexist with IP network 10
6.5. The graph of adjacencies .............................12 4.7. Right Framework for future OSPF extensibility .........11
7. TE LSAs ....................................................13 4.8. Network scenarios benefiting from the OSPF-TE design ..12
7.1. TE-Router LSA .........................................14 4.8.1. IP providers transitioning to TE services ......12
7.2. Changes to Network LSA ................................20 4.8.2. Providers offering Best-effort IP & TE services.12
7.2.1. Positional-Ring type network LSA ...............20 4.8.3. Multi-area networks ............................12
7.3. TE-Summary LSAs .......................................20 4.8.4. Non-packet and Peer-networking models ..........12
7.3.1. TE-Summary Network LSA (0x83) ..................20 5. OSPF-TE solution, assumptions and limitations ..............13
7.3.2. TE-Summary router LSA (0x84) ...................21 5.1. OSPF-TE Solution ......................................14
7.4. TE-AS-external LSAs (0x85) ............................23 5.2. Assumptions ...........................................16
7.5. TE-Circuit-paths LSA (0x8C) ...........................24 5.3. Limitations ...........................................16
7.6. TE-Link-Update LSA (0x8d) .............................25 6. Transition strategy for implementations using Opaque LSAs ..16
7.7. TE-Router-Proxy LSA (0x8e) ............................27 7. The OSPF Options field .....................................16
8. Link State Databases .......................................28 8. Bringing up TE adjacencies; TE vs. Non-TE topologies .......17
9. Abstract topology representation with TE support ...........29 8.1. The Hello Protocol ....................................17
10. Changes to Data structures in OSPF-TE routers ..............32 8.2. Flooding and the Synchronization of Databases .........18
10.1. Changes to Router data structure .....................32 8.3. The Designated Router .................................19
10.2. Two set of Neighbors .................................32 8.4. The Backup Designated Router ..........................19
10.3. Changes to Interface data structure ..................32 8.5. The graph of adjacencies ..............................19
11. Motivations to this approach ...............................33 9. TE LSAs ....................................................20
11.1. TE flooding isolated to TE-only nodes ................33 9.1. TE-Router LSA (0x81) ..................................22
11.2. Clean separation between native and TE LSDBs .........34 9.1.1. Router-TE flags - TE capabilities of the router.24
11.3. Scalability across a hierarchical Area topology ......35 9.1.2. Router-TE TLVs .................................25
11.4. Usable across packet and non-packet TE networks ......35 9.1.3. Link-TE options - TE capabilities of a TE-link .26
11.5. SLA enforceable network modeling .....................36 9.1.4. Link-TE TLVs ...................................26
11.6. Framework for future extensibility ...................36 9.2. TE-incremental-link-Update LSA (0x8d) .................27
11.7. Real-world scenarios benefiting from this approach ...37 9.3. TE-Circuit-paths LSA (0x8C) ...........................29
12. Transition strategy for implementations using Opaque LSAs ..37 9.4. TE-Summary LSAs .......................................30
13. IANA Considerations ........................................38 9.4.1. TE-Summary Network LSA (0x83) ..................30
13.1. TE-compliant-SPF routers Multicast address allocation 38 9.4.2. TE-Summary router LSA (0x84) ...................31
13.2. New TE-LSA Types .....................................38 9.5. TE-AS-external LSAs (0x85) ............................33
13.3. New TLVs (Router-TE and Link-TE TLVs) ................38 9.6. Changes to Network LSA ................................34
13.3.1. TE-selection-Criteria TLV (Tag ID = 1) .......38 9.6.1. Positional-Ring type network LSA ...............34
13.3.2. MPLS-Signaling protocol TLV (Tag ID = 3) .....38 9.7. TE-Router-Proxy LSA (0x8e) ............................35
13.3.3. Constraint-SPF algorithms-Support TLV (Tag ID=4) 9.8. Others ................................................36
13.3.4. SRLG-TLV (Tag ID = 0x81) .....................38 10. Abstract topology representation with TE support ...........36
13.3.5. BW-TLV (Tag ID = 0x82) .......................38 11. Changes to Data structures in OSPF-TE routers ..............38
13.3.6. CO-TLV (Tag ID = ox83) .......................38 11.1. Changes to Router data structure .....................38
14. Acknowledgements ...........................................39 11.2. Two set of Neighbors .................................38
15. Security Considerations ....................................39 11.3. Changes to Interface data structure ..................38
12. IANA Considerations ........................................39
12.1. TE-compliant-SPF routers Multicast address allocation 39
12.2. New TE-LSA Types .....................................39
12.3. New TLVs (Router-TE and Link-TE TLVs) ................39
12.3.1. TE-selection-Criteria TLV (Tag ID = 1) .......39
12.3.2. MPLS-Signaling protocol TLV (Tag ID = 3) .....39
12.3.3. Constraint-SPF algorithms-Support TLV (Tag ID=4)
12.3.4. SRLG-TLV (Tag ID = 0x81) .....................39
12.3.5. BW-TLV (Tag ID = 0x82) .......................40
12.3.6. CO-TLV (Tag ID = ox83) .......................40
13. Acknowledgements ...........................................40
14. Security Considerations ....................................40
References .....................................................40 References .....................................................40
1. Introduction 1. Introduction
There is substantial industry experience with deploying OSPF link There is substantial industry experience with deploying OSPF link
state routing protocol. That makes OSPF a good candidate to adapt state routing protocol. That makes OSPF a good candidate to adapt
for traffic engineering purposes. The dynamic discovery of network for traffic engineering purposes. The dynamic discovery of network
topology, flooding algorithm and the hierarchical organization of topology, link access metrics, flooding algorithm and the
areas can all be used effectively in creating and tearing traffic hierarchical organization of areas can all be used effectively in
links on demand. The intent of the document is to build an abstract creating and tearing traffic links on demand. The intent of
view of the topology in conjunction with the traffic engineering OSPF-TE is to discover TE network topology and the TE metrics
characteristics of the nodes and links involved. of the nodes and links in the network.
The connectivity topology may remain relatively stable, except when The objective of traffic engineering is to set up circuit path(s)
the existing links or networking nodes go down or flap or new nodes across a pair of nodes or links, as the case may be, so as to
and links are added to the network. The objective of traffic forward traffic of a certain forwarding equivalency class. Circuit
engineering is to set up circuit path(s) across a pair of nodes or emulation in a packet network is accomplished by each MPLS
links, as the case may be, so as to forward traffic of a certain intermediary node performing label swapping. Whereas, circuit
forwarding equivalency class. Circuit emulation in a packet network emulation in a TDM or Fiber cross-connect network is accomplished
is accomplished by each MPLS intermediary node performing label by configuring the switch fabric in each intermediary node to do
swapping. Whereas, circuit emulation in a TDM or Fiber cross-connect the appropriate switching (TDM, fiber or Lamda) for the duration
network is accomplished by configuring the switch fabric in each of the circuit.
intermediary node to do the appropriate switching (TDM, fiber or
Lamda) for the duration of the circuit.
The objective of this document is not how to set up traffic circuits, The objective of this document is not how to set up traffic circuits,
but rather provide the necessary TE parameters for the nodes and but rather provide the necessary TE parameters for the nodes and
links that constitute the TE topology. Unlike the traditional OSPF, links that constitute the TE topology. Unlike the native OSPF,
the TE extended OSPF will be used to build circuit paths, meeting OSPF-TE will be used to build circuit paths, meeting certain TE
certain TE criteria. The only requirement is that end-nodes and/or criteria. The only requirement is that end-nodes and/or end-links of
end-links of a circuit be identifiable with an IP address. For a circuit be identifiable with an IP address.
non-IP networks (such as TDM or photonic cross connect networks),
Mapping IP addresses to a well-known name can be done through a
DNS-like mechanism.
The approach suggested in this document is different from the The approach suggested in this document is different from the
Opaque-LSA-based approach outlined in [OPQLSA-TE]. Section 11 Opaque-LSA-based approach outlined in [OPQLSA-TE]. Section 4
describes the motivations behind conceiving this approach and describes the motivations behind designing OSPF-TE. Section 6
why the authors claim the benefits of the approach significantly outlines a strategy to transition Opaque-LSA based implementations
substantial over the opaque LSA based approach. Section 12 to adapt the OSPF-TE outlined here.
outlines a strategy to transition from Opaque-LSA based deployments
to the new-TE-LSA approach outlined here.
2. Traffic Engineering 2. Traffic engineering overview
A traffic engineered circuit may be identified by the tuple of A traffic engineered circuit may be identified by the tuple of
(Forwarding Equivalency Class, TE parameters for the circuit, (Forwarding Equivalency Class, TE parameters for the circuit,
Origin Node/Link, Destination node/Link). Origin Node/Link, Destination node/Link).
The forwarding Equivalency class(FEC) may be constituted of a number The Forwarding Equivalency Class(FEC) may be constituted of a number
of criteria such as (a) Traffic arriving on a specific interface, of criteria such as (a) Traffic arriving on a specific interface,
(b) Traffic meeting a certain classification criteria (ex: based on (b) Traffic meeting a certain classification criteria (ex: based on
fields in the IP and transport headers), (c) Traffic in a certain fields in the IP and transport headers), (c) Traffic in a certain
priority class, (d) Traffic arriving on a specific set of TDM (STS) priority class, (d) Traffic arriving on a specific set of TDM (STS)
circuits on an interface, (e) Traffic arriving on a certain circuits on an interface, (e) Traffic arriving on a certain
wave-length of an interface, (f) Traffic arriving at a certain time wave-length of an interface, (f) Traffic arriving at a certain time
of day, and so on. A FEC may be constituted as a combination of one of day, and so on. A FEC may be constituted as a combination of one
or more of the above criteria. Discerning traffic based on the FEC or more of the above criteria. Discerning traffic based on the FEC
criteria is a mandatory requirement on Label Edge Routers (LERs). criteria is a mandatory requirement on Label Edge Routers (LERs).
Traffic content is transparent to the Intermediate Label Switched Traffic content is transparent to the Intermediate Label Switched
Routers (LSRs), once a circuit is formed. LSRs are simply Routers (LSRs), once a circuit is formed. LSRs are simply
responsible for keeping the circuit in-tact for the lifetime of the responsible for keeping the circuit in-tact for the lifetime of the
circuit(s). As such, this document will not address FEC or the circuit(s). As such, this document will not address FEC or the
associated signaling to setup circuits. [MPLS-TE] and [GMPLS-TE] associated signaling to setup circuits. [MPLS-TE] and [GMPLS-TE]
address the FEC criteria. Whereas, [RSVP-TE] and [CR-LDP] address address the FEC criteria. Whereas, [RSVP-TE] and [CR-LDP] address
different types of signaling protocols. different types of signaling protocols.
As for TE parameters for the circuit, this refers to the TE This document is concerned with the collection of TE parameters for
parameters for all the nodes and links constituting a circuit. all the nodes and links within an autonomous system. TE parameters
Typically, TE parameters for a node in a TE circuit may include for a node may include a) ability to perform traffic prioritization,
the following. b) ability to provision bandwidth on interfaces, c) support for zero
or more CSPF algorithms, d) support for a specific TE-Circuit switch
* Traffic prioritization ability, type, e) support for a certain type of automatic protection
* Ability to provision bandwidth on interfaces, switching and so forth. TE parameters for a link may include
* Support of CSPF algorithms, a) available bandwidth, b) reliability of the link, c) color
* TE-Circuit switch type, assigned to the link, d) cost of bandwidth usage on the link, and
* Automatic protection switching. e) membership to a Shared Risk Link Group (SRLG) and so forth.
TE parameters for the link include:
* Bandwidth availability,
* reliability of the link,
* color assigned to the link
* cost of bandwidth usage on the link.
* membership to a Shared Risk Link Group and so on.
Only the unicast paths circuit paths are considered here. Multicast Only the unicast paths circuit paths are considered here. Multicast
variations are currently considered out of scope for this document. variations are currently considered out of scope for this document.
The requirement is that the originating as well as the terminating The requirement is that the originating as well as the terminating
entities of a TE path are identifiable by their IP address. entities of a TE path are identifiable by their IP address.
3. Terminology 3. Terminology
Definitions for majority of the terms used in this document with Definitions for majority of the terms used in this document with
regard to OSPF protocol may be found in [OSPF-V2]. MPLS and traffic regard to OSPF protocol may be found in [OSPF-V2]. MPLS and traffic
engineering terms may be found in [MPLS-ARCH]. RSVP-TE and CR-LDP engineering terms may be found in [MPLS-ARCH]. RSVP-TE and CR-LDP
signaling specific terms may be found in [RSVP-TE] and [CR-LDP] signaling specific terms may be found in [RSVP-TE] and [CR-LDP]
respectively. respectively.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALLNOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALLNOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119. this document are to be interpreted as described in RFC 2119.
Below are definitions for the terms used within this document. Below are definitions for the terms used within this document.
3.1. OSPF-TE node (or) TE-compliant OSPF node 3.1. OSPF-TE node
This is a router that supports the OSPF TE extensions described This is a router that supports the OSPF-TE described in this
in this document and at least one of the attached links support TE document. At least one of the attached links for the node
extensions. Further, this requires that at least one of the supports IP packet termination and runs the OSPF-TE protocol.
attached links support Packet termination and run the OSPF-TE
protocol.
An OSPF-TE node supports native OSPF as well as the TE extensions An OSPF-TE node supports native OSPF as well as the OSPF-TE.
outlined here.
3.2. Native OSPF router 3.2. Native OSPF node
A native OSPF router is an OSPF router that does not support A native OSPF node is an OSPF router that does not support
the TE extensions described in this document or does not have the TE extensions described in this document or does not have
a TE link attached to it. An autonomous system (AS) could be a TE link attached to it. A Native OSPF node forwards IP
constituted of a combination of native-OSPF and OSPF-TE nodes. traffic, using the shortest-path forwarding algorithm.
A native OSPF router, when enhanced to include the extensions A native OSPF node may be enhanced to be an OSPF-TE node. An
described in this document can become a OSPF-TE node. autonomous system (AS) could be constituted of a combination
of native-OSPF and OSPF-TE nodes.
3.3. TE nodes vs. non-TE (native) nodes 3.3. TE nodes vs. native(non-TE) nodes
A TE-Node is an intermediate or edge node taking part in the A TE-Node is an intermediate or edge node taking part in the
traffic engineered (TE) network. Specifically, a TE circuit traffic engineered (TE) network. A TE-circuit is constituted of
is constituted of a series of TE nodes connected to each other a series of TE nodes connected to each other through TE links.
via the TE links. In a SONET/TDM network or a photonic cross-connect network,
a TE node is not required to support OSPF-TE. An external
OSPF-TE node may represent the TE node for protocol processing.
A non-TE node or a native node is a node that does not have any A native (or non-TE) node is an IP router capable of IP packet
TE links attached to it and does not take part in a TE network. forwarding, does not have TE link attachments and does not take
Specifically, native OSPF nodes that do not take part in a TE part in a TE network.
network fall under this category.
3.4. TE links vs. non-TE (native) links 3.4. TE links vs. native(non-TE) links
A TE Link is a network attachment that supports traffic A TE Link is a network attachment that supports traffic
engineering. Specifically, a TE circuit can only be setup using engineering. A TE-circuit is constituted of a series of TE
a combination of TE nodes and TE links connected to each other. nodes connected to each other through TE links.
Non-TE link or a native link is one that supports IP packet A native (or non-TE) link is one that is used for IP packet
communication, but does not support traffic engineering on the traversal. A link may be configured to be pure TE link or
link. For example, native OSPF protocol and least-cost criteria native link or a both.
may be used to determine reachability of subnets in a network
constituted of native OSPF nodes and native OSPF links.
3.5. Packet interface vs. non-packet interface 3.5. Packet-TE network vs. non-packet-TE network
Interfaces on an OSPF-TE node may be characterized as those that Packet-TE network is one in which TE-circuit emulation is
terminate (i.e., send and receive) IP packet data and those that accomplished by each MPLS intermediary node performing label
do not. Both types of links can be part of a traffic engineered swapping on the packet data.
network. In contrast, a native OSPF router does not support
non-packet interfaces.
Needless to say, the OSPF protocol and its TE extensions can only Non-packet-TE network, such as SONET/TDM or Fiber
be enabled on interfaces supporting IP packet termination. While cross-connect network is one in which TE-circuit emulation is
the OSPF protocol can be run only on interfaces terminating IP accomplished by configuring the switch fabric in each
packets - the protocol can advertise link state information of intermediary node to do the appropriate switching (TDM, fiber
non-packet interfaces attached to it - thereby allowing for traffic or Lamda) for the duration of the circuit.
engineering over non-packet links. For example - control interfaces
can advertise link state information of the SONET interfaces on a In either case, OSPF-TE can only be enabled on interfaces
SONET Add-Drop Multiplexer. supporting IP packet termination. Interfaces supporting OSPF
and/or OSPF-TE constitute the OSPF control network. The OSPF
control network can be independent of the packet or non-packet
data network.
3.6. TE topology vs. non-TE topology 3.6. TE topology vs. non-TE topology
A TE topology is constituted of a set of contiguous TE nodes and A TE topology is constituted of a set of contiguous TE nodes and
TE links. Associated with each TE node and TE link is a set of TE TE links. Associated with each TE node and link is a set of TE
criteria that may be supported at any given time. A TE topology criteria that may be supported at any given time. A TE topology
allows circuits to be overlayed statically or dynamically based allows circuits to be overlayed statically or dynamically based
on a specific TE criteria. on a specific TE criteria.
A non-TE topology specifically refers to the network that does not A non-TE topology specifically refers to the network that does not
support TE. Control protocols such as OSPF may be run on the non-TE support TE. Control protocols such as OSPF may be run on the non-TE
topology. IP forwarding table used to forward IP packets on this topology. IP forwarding table used to forward IP packets on this
network is built based on the control protocol specific algorithm, network is built based on the control protocol specific algorithm,
such as OSPF shortest-path criteria. such as OSPF shortest-path criteria.
3.7. TLV 3.7. TLV
A TLV, strictly stands for an object in the form of Tag-Length-Value. A TLV stands for an object in the form of Tag-Length-Value. All TLVs
However, this term is also used in the document, at times, to simply are assumed to be of the following format, unless specified
refer a Traffic Engineering attribute of a TE-node or TE-link.
All TLVs are assumed to be of the following format, unless specified
otherwise. The Tag and length are 16 bits wide each. The length otherwise. The Tag and length are 16 bits wide each. The length
includes the 4 bytes required for Tag and Length specification. includes the 4 bytes required for Tag and Length specification.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag | Length (4 or more) | | Tag | Length (4 or more) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value .... | | Value .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 7, line 44 skipping to change at page 7, line 38
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.8. Router-TE TLVs 3.8. Router-TE TLVs
TLVs used to describe the TE capabilities of a TE-node. TLVs used to describe the TE capabilities of a TE-node.
3.9. Link-TE TLVs 3.9. Link-TE TLVs
TLVs used to describe the TE capabilities of a TE-link. TLVs used to describe the TE capabilities of a TE-link.
4. Motivation and Implicit assumptions for the TE extensions 4. Motivations to designing the OSPF-TE using TE-LSAs
The motivation behind the OSPF-TE described in this document is to The motivation behind designing the OSPF-TE using TE-LSAs is
dynamically discover the TE-network topology, devise a scalable that the approach is clean, extendible, scalable, unified,
flooding methodology and benefit from the hierarchical area efficient, and SLA enforceable. The approach also provides
organization and other techniques of the native OSPF. The result the right framework for future OSPF extensibility. Each of
would be the ability to build an abstract view of a network these motivations is explained in detail in the following
topology with all the traffic engineering characteristics. subsections.
With traditional OSPF, the goal is to build a forwarding table to The last subsection lists network scenarios that benefit from
reach various subnets in the IP network with least-cost as the the TE-LSA design.
basis. However, the goal of OSPF-TE is to determine a circuit path
(that can be pinned-down for a desired duration) meeting a certain
set of traffic engineering criteria. Further, the circuit path
could consist entirely of nodes and links that do not carry IP
traffic.
The following assumptions are made throughout the document for 4.1. Clean design - TE-LSDB, independent of the native LSDB
the discussion of OSPF-TE. OSPF-TE using TE LSAs provides a clean separation of Link State
Data Bases (LSDB) between native (SPF-based) and TE networks.
The OSPF-TE dynamically discovers TE network topology and the
associated TE metrics of the nodes and links in the TE network.
OSPF-TE design is based on the tried and tested OSPF paradigm.
As such, it inherits all the benefits of the OSPF, present and
future.
1. Interfaces on an OSPF-TE node may be characterized as those With OSPF-TE, native OSPF nodes will keep just the native OSPF
that can terminate (i.e., send and receive) IP packet data and link state database. The OSPF-TE nodes will keep the native as
those that wont. Both types of links can be part of a traffic well as the TE LSDB. In the case, where the network is used
engineered network. Needless to say, the OSPF-TE protocol can only for Traffic engineering purposes, the native-LSDB
only be enabled on interfaces that support IP packet data describes the control topology.
termination. As such, the control network over which TE LSAs
are exchanged may be constituted of a combination of non-TE
links and TE links that also permit non-TE packet traffic.
2. Unlike traditional OSPF, OSPF-TE protocol must be capable of In the Opaque-LSA-based TE scheme([OPQLSA-TE]), the TE-LSDB built
advertising link state of interfaces that are not capable of using opaque LSAs refers the native LSDB to build the TE topology.
handling packet data. As such, the OSPF-TE protocol cannot be Further, the LSDB has no knowledge of the TE capabilities of the
required to synchronize its link-state database with neighbors routers. Point-to-point links are the only type of links that can
across all its links. It is sufficient to synchronize form a TE network. It is apparent that [OPQLSA-TE] is a new
link-state database in an area, across a subset of the links - protocol in itself within the constraints of an Opaque-LSA and is
say, the packet terminating interfaces. Yet, the TE LSDB not tailored to benefit from the tried and tested native-OSPF.
(LSA database) should be synchronized across all OSPF-TE nodes
within an area.
All interfaces or links described by the TE LSAs will be 4.2. Extendible design - based on the OSPF foundation
present in the TE topology database (a.k.a. TE LSDB).
3. An OSPF-TE node with links in an OSPF area will need to TE LSAs are extendible, just as the native OSPF on which OSPF-TE
is founded. [OPQLSA-TE], on the other hand, is not extendible
and is constrained by the Opaque LSA on which it is founded.
For example, Opaque LSAs are not suited to advertising summary
LSAs along a restricted flooding scope (as with TE-Summary
network LSA). Opaque LSAs are also not suited to advertising
incremental TLV changes. A change in any TLV of a TE-link will
mandate the entire Opaque-LSA (with all the TLVs included) to be
transmitted. TE-incremental-link-update LSA, on the other hand,
is capable of advertising just the delta TLVs. Opaque LSAs
are also not extendible to support advertisement of TLVs for
non-members of the OSPF control network. This is a necessity
for certain non-packet networks such as a SONET/TDM network. In
a SONET/TDM network, data-path topology often differs from
its OSPF control network counterpart. TE-Router-Proxy-LSA
(section 9.7) permits advertising LSAs for non-members via
a proxy node that is a member of the control network.
Lastly, the expressibility of data in an Opaque LSA is strictly
restricted to being in the form of TLVs and sub-TLVs, some
mandatorily required and some positionally dependent in the
TLV sequence for interpretation.
4.3. Scalable design - TE-AS may be sub-divided into areas
OSPF-TE using TE LSAs inherits the hierarchical area organization
used within native-OSPF. Without revealing the nodes and
characteristics of the attached links within a TE-area, the
TE-Summary network LSA (refer section 9.4) advertises the
reachability of TE networks within an area to the areas outside
in the same AS.
Providing area level abstraction and having the abstraction be
distinct for TE and native topologies is a necessity for
inter-area communication. When the topologies are separate, the
area border routers can advertise different summary LSAs to TE
and non-TE routers. For example, a native Area Border router (ABR)
simply announces the shortest path network summary LSAs (LSA
type 3) for nodes outside the area. A TE-ABR, on the other hand,
would use TE-summary network LSA to advertise network Reachability
information - not aggregated path metric as required for a native
OSPF LSDB. Clearly, the data content and flooding scope should be
different for the TE nodes. The flooding boundary for TE-summary
LSAs would be (AS - OriginatingArea - StubAreas - NSSAs).
Opaque-LSA-based TE scheme([OPQLSA-TE]) is restricted for use
within an area and is not applicable for flooding across areas.
As-wide scope Opaque LSAs (Type 11 LSAs) will be unable to restrict
flooding in its own originating area.
4.4. Unified design - for packet and non-packet networks
OSPF-TE uses the same set of TE LSAs for disseminating TE
characteristics - irrespective of whether the network is a packet
network or a non-packet network or a combination of both. Only
the TLVs used to describe the characteristics will vary. Each TE
node will be required to advertise its own TE capabilities and
that of the attached TE links.
In a peer networking TE model, the TE nodes are heterogeneous
and have different TE characteristics. As such, the signaling
protocols will need the TE characteristics of all nodes and
attached links so they can signal the nodes to formulate TE
circuits across heterogeneous nodes. The underlying control
protocol must be capable of providing a unified LSDB for all
nodes in the network. OSPF-TE clearly meets this requirement.
Opaque-LSA-based TE scheme([OPQLSA-TE]) is limited in scope for
packet networks. Extensions ([OPQLSA-GMPLS]) are underway to
support GMPLS links within opaque LSAs. However, neither
[OPQLSA-TE] nor [OPQLSA-GMPLS] is sufficient by itself or when
combined for use within a peer networking model with heterogeneous
nodes. Neither of the Opaque LSA based extensions have provision
to distinguish between the various nodes and link attachments that
are different from point-to-point connections. SONET specific
ring topologies and packet network specific LAN and other mesh
topologies are not permitted.
4.5. Efficient design - in LSA content and flooding reach
OSPF-TE is capable of identifying the boundaries of a TE topology
and limits the flooding of TE LSAs to only the TE-nodes. Nodes
that do not have TE link attachments are not bombarded with TE
specific LSAs. This is a useful characteristic for networks
supporting native and TE traffic in the same connected network.
The more frequent and wider the flooding scope, the larger the
number of retransmissions and acknowledgements. The same
information (needed or not) may reach a router through multiple
links. Even if the router did not forward the information past
the node, it would still have to send acknowledgements across
all the various links on which the LSAs tried to converge.
Clearly, it is not desirable to flood LSAs to nodes that do not
require it. This can be a considerable impediment to non-TE
nodes in a network that is constituted of native and TE nodes.
Opaque-LSA-based TE scheme([OPQLSA-TE]) makes no distinction
between TE and native OSPF nodes as far as LSA flooding is
concerned. It is possible for the native OSPF nodes to silently
ignore the unsupported Opaque LSAs or add knobs within
implementation to decide whether or not a certain opaque LSA
mandates dijkstra SPF recomputation. In any case, unintended
LSAs are disruptive and can be the cause of a large number of
acknowledgements and retransmissions.
TE metrics in a network could be rapidly changing. Only a subset
of the metrics may be prone to rapid change, while others remain
largely unchanged. Changes must be communicated at the earliest
throughout the network to ensure that the TE-LSDB is up-to-date.
TE-Incremental-Link-update LSA (section 9.2) permits advertising
only a subset of the link metrics and not the entire router-LSA
all over. [OPQLSA-TE] does not have provision to advertise just
the TLVs that changed. A change in any TLV of a TE-link will
mandate the entire LSA to be transmitted. This is clearly a
serious shortcoming in the protocol.
4.6. SLA enforceable TE network can coexist with IP network
OSPF-TE is designed to draw distinction between links that
support TE traffic and links that support native best-effort
IP traffic. This flexibility to configure links as appropriate
for a service, permits enforceability of service level
agreements (SLAs). A link, configured to support TE traffic
alone will not permit native IP traffic on the link.
Best-effort IP transit network and constraint based TE network
have different SLA requirements and hence different billing
models. Keeping the two networks physically isolated will enable
SLA enforceability, but can be expensive. Combining the two
networks into a single physically connected network will bring
economies of scale, if the SLA enforceability can be retained.
When the links of a TE-network LSDB do not overlap the links
of a native LSDB, such a virtual isolation of networks and
hence SLA enforceability becomes possible.
Opaque-LSA-based TE scheme([OPQLSA-TE]) is inherently not capable
of having two virtual networks in a single physically connected
network. All point-to-point links in a packet network are subject
to best-effort IP traffic, irrespective of whether a link is
usable for TE traffic or not. In order to ensure that TE links are
not cannibalized by best-effort traffic, the network provider will
simply have to restrict best-effort traffic from entering the
network. This is a severe limitation and is a direct result of
not having LSDB isolation. When TE and native topologies
are not separated (as is the case with Opaque-LSAs), a native OSPF
node could be utilizing a TE link as its least cost link, thereby
stressing the TE link and rendering the TE link ineffective for
TE purposes.
4.7. Right Framework for future OSPF extensibility
OSPF-TE design provides the right framework for future OSPF
extensions based on independent service provider needs. The
framework essentially calls for building independent service
specific LSDBs. Each such LSDB will consist of service specific
metrics of all resources within the service-specific topology.
The TE-LSDB permits TLV scalability as well as the ability
to perform fast searches through the database. Just as the
TE-LSDB may be used for MPLS TE application, a different type
of LSDB may be used for a different type of application across
the same physically connected IP network. E.g., one can derive
QOS based IP forwarding on an IP network.
Limiting flooding scope of service specific LSAs within the
service specific topology eliminates LSA contamination between
virtual service networks of a single physically connected
network. Using service specific LSAs provides flexibility in
LSA content and flooding scope.
Opaque-LSA-based TE scheme([OPQLSA-TE]) works best when a single
type of service is assumed for a single physically connected
network. As such, multiple disparate networks can function
running various flavors of OSPF. [OSPF-v2] for native best-effort
IP networks, [OPQLSA-TE] for packet networks and [OPQLSA-GMPLS]
for non-packet networks.
4.8. Network scenarios benefiting from the OSPF-TE design
Many real-world scenarios are better served by the new-TE-LSAs
scheme. Here are a few examples.
4.8.1. IP providers transitioning to TE services
Providers needing to support MPLS based TE in their IP network
may choose to transition gradually. Perhaps, add new TE links
or convert existing links into TE links within an area first
and progressively advance to offer in the entire AS.
Not all routers will support TE extensions at the same time
during the migration process. Use of TE specific LSAs and their
flooding to OSPF-TE only nodes will allow the vendor to
introduce MPLS TE without destabilizing the existing network.
As such, the native OSPF-LSDB will remain undisturbed while
newer TE links are added to network.
4.8.2. Providers offering Best-effort-IP & TE services
Providers choosing to offer both best-effort-IP and TE based
packet services simultaneously on the same physically connected
network will benefit from the OSPF-TE design. By maintaining
independent LSDBs for each type of service, TE links are not
cannibalized by the non-TE routers for SPF forwarding. Unlike
the [OPQLSA-TE] scheme, OSPF-TE provides the framework for SLA
enforcement.
4.8.3. Multi-area networks
The OSPF-TE design parallels the tried and tested native-OSPF
design. Unlike [OPQLSA-TE], OSPF-TE scales naturally to multi-area
networks.
4.8.4. Non-packet and Peer-networking models
OSPF-TE is the only scheme that can support the following
network attachments For a non-Packet TE network.
(a) "Positional-Ring" type network LSA and
(b) Router Proxying - allowing a router to advertise on behalf
of other nodes (that are not Packet/OSPF capable).
Opaque LSA based extensions ([OPQLSA-TE], [OPQLSA-GMPLS]) are not
suited to distinguish the heterogeneous nodes in a peer-connected
network. Opaque-LSA based extensions are also not suited to support
link attachments that are different from point-to-point connections.
5. OSPF-TE solution, assumptions and limitations
5.1. OSPF-TE Solution
The OSPF-TE uses the options flag as a means to determine the
TE topology. New TE LSAs are designed to generate an independent
TE-service tailored LSDB. Sections 8.0 and 9.0 describe the TE
extensions in detail. Changes required of the OSPF data
structures in order to support OSPF-TE are described in section
11.0. The OSPF-TE design is based on the tried and tested OSPF
paradigm. With TE-LSDB, you have the advantages of retaining the
scalability of TLV's and the ability to run fast searches through
the database.
With the new TE-LSA scheme, an OSPF-TE node will have two types
of Link state databases (LSDB). A native LSDB that describes the
native control topology and a TE-LSDB that describes the TE
topology. Shortest-Path-First algorithm will be used to forward
IP packets along the native control network. OSPF neighbors data
structure will be used for flooding along the control topology.
The TE-LSDB is constituted only of TE nodes and TE links. A variety
of CSPF algorithms may be used to dynamically setup TE circuit
paths along the TE network. A new TE-neighbors data structure will
be used to flood TE LSAs along the TE-only topology. Clearly, the
the TE nodes will need the control (non-TE) network for OSPF
communication. The control network may also be used for pinging
OSPF-TE nodes and performing any debug and monitoring tasks on
the nodes. However, the ability to make distinction between
TE and non-TE topologies, allows the bandwidth on TE links to be
strictly SLA enforceable, even as a TE link is packet-capable.
The actual characteristics of the TE-link are irrelevant from the
OPSF-TE perspective. As such, that allows for packet and non-packet
networks to operate in peer mode.
Consider the following network where some of the routers and links
are TE enabled and others are native OSPF routers and links. All
nodes in the network belong to the same OSPF area.
+---+
| |--------------------------------------+
|RT6|\\ |
+---+ \\ |
|| \\ |
|| \\ |
|| \\ |
|| +---+ |
|| | |----------------+ |
|| |RT1|\\ | |
|| +---+ \\ | |
|| //| \\ | |
|| // | \\ | |
|| // | \\ | |
+---+ // | \\ +---+ |
|RT2|// | \\|RT3|------+
| |----------|----------------| |
+---+ | +---+
| |
| |
| |
+---+ +---+
|RT5|--------------|RT4|
+---+ +---+
Legend:
-- Native(non-TE) network link
| Native(non-TE) network link
\\ TE network link
|| TE network link
Figure 6: A (TE + native) OSPF network topology
In the above network, TE and native OSPF Link State Data bases
(LSDB) would have been synchronized within the area along the
following nodes.
Native OSPF LSDB nodes TE-LSDB nodes
---------------------- -------------
RT1, RT2, RT3. RT4, RT5, RT6 RT1, RT2, RT3, RT6
Nodes such as RT1 will have two LSDBs, a native LSDB and a TE-LSDB
to reach native and TE networks. The TE LSA updates will not impact
non-TE nodes RT4 and RT5.
5.2. Assumptions
OSPF-TE design makes the following assumptions.
1. An OSPF-TE node with links in an OSPF area will need to
establish router adjacency with at least one other neighboring establish router adjacency with at least one other neighboring
OSPF-TE node in order for the router's database to be OSPF-TE node in order for the router's database to be
synchronized with other routers in the area. Failing this, the synchronized with other routers in the area. Failing this, the
OSPF router will not be in the TE calculations of other TE OSPF router will not be in the TE calculations of other TE
routers in the area. Refer [OSPF-FL1] for flooding routers in the area. Refer [FLOOD-OPT] for flooding
optimizations. optimizations.
However, two routers that are physically connected to the same 2. Unlike the native OSPF, OSPF-TE must be capable of advertising
link (or broadcast network) neednt be router adjacent via the link state of interfaces that are not capable of handling IP
Hello protocol, if the link is not packet terminated. packet data. As such, the OSPF-TE protocol cannot be required
to synchronize its link-state database with neighbors across
all its links. It is sufficient to synchronize link-state
database in an area, across a subset of the IP termination
links. Yet, the TE LSDB (LSA database) should be synchronized
across all OSPF-TE nodes within an area.
4. Each IP subnet on a TE-configurable network MUST have a minimum All nodes and interfaces described by the TE LSAs will be
of one node with an interface running OSPF-TE protocol. This is present in the TE topology database (a.k.a. TE LSDB).
despite the fact that all nodes on the subnet may take part in
Traffic Engineering. (Example: SONET/SDH TDM ring with a single
Gateway Network Element, a.k.a. GNE running the OSPF protocol,
yet all other nodes in the ring are also full members of a TE
circuit).
An OSPF-TE node may advertise more than itself and the links 3. A link in a packet network can be a TE-link or a native-IP
it is directly attached to. It may also advertise other TE link or both. There may be different ways by which to use
participants and their links, on their behalf. a link for TE and non-TE traffic. For example, a link may
be used for both types of traffic and satisfy the TE SLA
requirements, so long as the link is under-subscribed for
TE (say, 50% of the link capacity is being used). Once the
TE capacity requirement exceeds the set mark (say, the 50%
mark), the link may be removed from the non-TE topology.
4. This document does not require any changes to the existing OSPF
LSDB implementation. Rather, it suggests the use of another
database, the TE-LSDB, comprised of the TE LSAs, for TE purposes.
5. As a general rule, all nodes and links that may be party 5. As a general rule, all nodes and links that may be party
to a TE circuit should be uniquely identifiable by an IP to a TE circuit should be uniquely identifiable by an IP
address. As for router ID, a separate loopback IP address address. As for router ID, a separate loopback IP address
for the router, independent of the links attached, is for the router, independent of the links attached, is
recommended. recommended.
6. This document does not require any changes to the existing OSPF 6. The assumption about to be stated is principally meant for
LSDB implementation. Rather, it suggests the use of another non-packet networks such as a SONET TDM network. In non-packet
database, the TE-LSDB, comprised of the TE LSAs, for TE networks, each IP subnet on a TE-configurable network MUST have
purposes. TE nodes may have 2 types of link state databases - a minimum of one node with an interface running OSPF-TE protocol.
a native OSPF LSDB and a TE-LSDB. A native OSPF LSDB, For example, a SONET/SDH TDM ring must have a minimum of one node
constituted of native links and nodes attached to these links (say, a Gateway Network Element) running the OSPF protocol in
(i.e., non-TE as well as TE nodes), will use shortest-path order to enable TE configuration on all nodes within the ring.
criteria to forward IP packets over native links. The TE-LSDB,
constituted only of TE nodes and TE links, may be used to setup
TE circuit paths along the TE topology.
5. The OSPF Options field An OSPF-TE node may advertise more than itself and the links
it is directly attached to. It may also advertise other TE
participants and their links, on their behalf.
A new TE flag is introduced to identify TE extensions to the OSPF. 5.3. Limitations
With this, the OSPF v2 will have no more reserved bits left for
future option extensions. This bit will be used to distinguish Below are the limitations of the OSPF-TE.
1. Disjoint TE topologies would have the same problem as an
OSPF-TE node not forming adjacencies with any other node.
The disjoint nodes will not be included in the TE topology
of the rest of the TE routers. It will be the
responsibility of the network administrator(s) to ensure
connectedness of the TE network.
For example, two routers that are physically connected to
the same link (or broadcast network) need not be router
adjacent via the Hello protocol, if the link is not IP
packet terminated.
6. Transition strategy for implementations using Opaque LSAs
Below is a strategy to transition implementations using opaque
LSAs to adapt the new TE LSA scheme in a gradual fashion.
1. Restrict the use of Opaque-LSAs to within an area.
2. Fold in the TE option flag to construct the TE and non-TE
topologies in an area, even if the topologies cannot be used
for flooding within the area.
3. Use TE-Summary LSAs and TE-AS-external-LSAs for inter-area
Communication. Make use of the TE-topology within area to
summarize the TE networks in the area and advertise the same
to all TE-routers in the backbone. The TE-ABRs on the backbone
area will in-turn advertise these summaries again within their
connected areas.
7. The OSPF Options field
A new TE flag is introduced within the options field to identify
TE extensions to the OSPF. This bit will be used to distinguish
between routers that support Traffic engineering extensions and between routers that support Traffic engineering extensions and
those that do not. those that do not. The OSPF options field is present in OSPF
Hello packets, Database Description packets and all link state
advertisements. The TE bit, however, is a requirement only for
the Hello packets. Use of TE-bit is optional in Database
Description packets or LSAs.
The OSPF options field is present in OSPF Hello packets, Database Below is a description of the TE-Bit. Refer [OSPF-V2], [OSPF-NSSA]
Description packets and all link state advertisements. See and [OPAQUE] for a description of the remaining bits in options
[OSPF-V2], [OSPF-NSSA] and [OPAQUE] for a description of the field.
bits in options field. Only the TE-Bit is described in this
section.
-------------------------------------- --------------------------------------
|TE | O | DC | EA | N/P | MC | E | * | |TE | O | DC | EA | N/P | MC | E | * |
-------------------------------------- --------------------------------------
The OSPF options field - TE support The OSPF options field - TE support
TE-Bit: This bit is set to indicate support for Traffic Engineering TE-Bit: This bit is set to indicate support for Traffic Engineering
extensions to the OSPF. The Hello protocol which is used for extensions to the OSPF. The Hello protocol which is used for
establishing router adjacency and bidirectionality of the establishing router adjacency and bidirectionality of the
link will use the TE-bit to build adjacencies between two link will use the TE-bit to build adjacencies between two
nodes that are either both TE-compliant or not. Two routers nodes that are either both TE-compliant or not. Two routers
will not become TE-neighbors unless they agree on the state will not become TE-neighbors unless they agree on the state
of the TE-bit. TE-compliant OSPF extensions are advertised of the TE-bit. TE-compliant OSPF extensions are advertised
only to the TE-compliant routers. All other routers may only to the TE-compliant routers. All other routers may
simply ignore the advertisements. simply ignore the advertisements.
6. Bringing up TE adjacencies; TE vs. Non-TE topologies There is however a caveat with the above use of the last remaining
reserved bit in the options field. OSPF v2 will have no more
reserved bits left for future option extensions. If it is deemed
necessary to leave this bit as is, we could use OPAQUE-9 LSA (Local
scope) along each interface to communicate the support for OSPF-TE.
8. Bringing up TE adjacencies; TE vs. Non-TE topologies
OSPF creates adjacencies between neighboring routers for the purpose OSPF creates adjacencies between neighboring routers for the purpose
of exchanging routing information. In the following subsections, we of exchanging routing information. In the following subsections, we
describe the use of Hello protocol to establish TE capability describe the use of Hello protocol to establish TE capability
compliance between neighboring routers of an area. Further, the compliance between neighboring routers of an area. Further, the
capability is used as the basis to build a TE vs. non-TE network capability is used as the basis to build a TE vs. non-TE network
topology. topology.
6.1. The Hello Protocol 8.1. The Hello Protocol
The Hello Protocol is primarily responsible for dynamically The Hello Protocol is primarily responsible for dynamically
establishing and maintaining neighbor adjacencies. In a TE network, establishing and maintaining neighbor adjacencies. In a TE network,
it may not be required or possible for all links and neighbors to it may not be required or possible for all links and neighbors to
establish adjacency using this protocol. establish adjacency using this protocol.
The Hello protocol will use the TE-bit to establish Traffic The Hello protocol will use the TE-bit to establish Traffic
Engineering capability (or not) between two OSPF routers. Engineering capability (or not) between two OSPF routers.
For NBMA and broadcast networks, this protocol is responsible for For NBMA and broadcast networks, this protocol is responsible for
electing the designated router and the backup designated router. electing the designated router and the backup designated router.
For a TDM ring network, the designated and backup designated For a TDM ring network, the designated and backup designated
routers may either be preselected (ex: GNE, backup-GNE) or routers may either be preselected (ex: GNE, backup-GNE) or
determined via the same Hello protocol. In any case, routers determined via the same Hello protocol. In any case, routers
supporting the TE option shall be given a higher precedence supporting the TE option shall be given a higher precedence for
for becoming a designated router over those that donot support TE. becoming a designated router over those that do not support TE.
6.2. Flooding and the Synchronization of Databases 8.2. Flooding and the Synchronization of Databases
In OSPF, adjacent routers within an area must synchronize their In OSPF, adjacent routers within an area must synchronize their
databases. However, as observed in [OSPF-FL1], the requirement databases. However, as observed in [FLOOD-OPT], the requirement
may be stated more concisely that all routers in an area must may be stated more concisely that all routers in an area must
converge on the same link state database. To do that, it suffices converge on the same link state database. To do that, it suffices
to send single copies of LSAs to the neighboring routers in an to send single copies of LSAs to the neighboring routers in an
area, rather than send one copy on each of the connected area, rather than send one copy on each of the connected
interfaces. [OSPF-FL1] describes in detail how to minimize interfaces. [FLOOD-OPT] describes in detail how to minimize
flooding (Initial LSDB synchronization as well as the flooding (Initial LSDB synchronization as well as the
asynchronous LSA updates) within an area. asynchronous LSA updates) within an area.
With the OSPF-TE described here, a TE-only network topology is With the OSPF-TE described here, a TE-only network topology is
constructed based on the TE option flag in the Hello packet. constructed based on the TE option flag in the Hello packet.
Subsequent to that, TE LSA flooding in an area is limited to Subsequent to that, TE LSA flooding in an area is limited to
TE-only routers in the area, and do not impact non-TE routers TE-only routers in the area, and do not impact non-TE routers
in the area. A network may be constituted of a combination of in the area. A network may be constituted of a combination of
a TE topology and a non-TE (control) topology. Standard IP a TE topology and a non-TE (control) topology. Standard IP
packet forwarding and routing protocols are possible along the packet forwarding and routing protocols are possible along the
skipping to change at page 11, line 43 skipping to change at page 19, line 11
into the Opaque-LSA based TE scheme ([OPQLSA-TE]), because into the Opaque-LSA based TE scheme ([OPQLSA-TE]), because
Opaque LSAs (say, LSA #10) have a pre-determined flooding Opaque LSAs (say, LSA #10) have a pre-determined flooding
scope. Even as a TE topology is available from the use of scope. Even as a TE topology is available from the use of
TE option flag, the TE topology is not usable for flooding TE option flag, the TE topology is not usable for flooding
unless a new TE LSA is devised, whose boundaries can be set to unless a new TE LSA is devised, whose boundaries can be set to
span the TE-only routers in an area. span the TE-only routers in an area.
NOTE, a new All-SPF-TE Multicast address may be used for the NOTE, a new All-SPF-TE Multicast address may be used for the
exchange of TE compliant database descriptors. exchange of TE compliant database descriptors.
6.3. The Designated Router 8.3. The Designated Router
The Designated Router is elected by the Hello Protocol on broadcast The Designated Router is elected by the Hello Protocol on broadcast
and NBMA networks. In general, when a router's interface to a and NBMA networks. In general, when a router's interface to a
network first becomes functional, it checks to see whether there is network first becomes functional, it checks to see whether there is
currently a Designated Router for the network. If there is, it currently a Designated Router for the network. If there is, it
accepts that Designated Router, regardless of its Router Priority, accepts that Designated Router, regardless of its Router Priority,
so long as the current designated router is TE compliant. Otherwise, so long as the current designated router is TE compliant. Otherwise,
the router itself becomes Designated Router if it has the highest the router itself becomes Designated Router if it has the highest
Router Priority on the network and is TE compliant. Router Priority on the network and is TE compliant.
Clearly, TE-compliance must be implemented on the most robust Clearly, TE-compliance must be implemented on the most robust
routers only, as they become most likely candidates to take on routers only, as they become most likely candidates to take on
additional role as designated router. additional role as designated router.
Alternatively, there can be two sets of designated routers, one for Alternatively, there can be two sets of designated routers, one for
the TE compliant routers and another for the native OSPF routers the TE compliant routers and another for the native OSPF routers
(non-TE compliant). (non-TE compliant).
6.4. The Backup Designated Router 8.4. The Backup Designated Router
The Backup Designated Router is also elected by the Hello The Backup Designated Router is also elected by the Hello
Protocol. Each Hello Packet has a field that specifies the Protocol. Each Hello Packet has a field that specifies the
Backup Designated Router for the network. Once again, TE-compliance Backup Designated Router for the network. Once again, TE-compliance
must be weighed in conjunction with router priority in determining must be weighed in conjunction with router priority in determining
the backup designated router. Alternatively, there can be two sets the backup designated router. Alternatively, there can be two sets
of backup designated routers, one for the TE compliant routers and of backup designated routers, one for the TE compliant routers and
another for the native OSPF routers (non-TE compliant). another for the native OSPF routers (non-TE compliant).
6.5. The graph of adjacencies 8.5. The graph of adjacencies
An adjacency is bound to the network that the two routers have An adjacency is bound to the network that the two routers have
in common. If two routers have multiple networks in common, in common. If two routers have multiple networks in common,
they may have multiple adjacencies between them. The adjacency they may have multiple adjacencies between them. The adjacency
may be split into two different types - Adjacency between may be split into two different types - Adjacency between
TE-compliant routers and adjacency between non-TE compliant TE-compliant routers and adjacency between non-TE compliant
routers. A router may choose to support one or both types of routers. A router may choose to support one or both types of
adjacency. adjacency.
Two graphs are possible, depending on whether a Designated Two graphs are possible, depending on whether a Designated
skipping to change at page 13, line 25 skipping to change at page 20, line 38
+-----------------------+ RT5o RT6o oRT4 : +-----------------------+ RT5o RT6o oRT4 :
| | N2 * * ; : | | N2 * * ; :
+---+ +---+ * * ; : +---+ +---+ * * ; :
|RT5| |RT6| * * ; : |RT5| |RT6| * * ; :
+---+ +---+ **; : +---+ +---+ **; :
o:::::::::: o::::::::::
RT3 RT3
Figure 6: The graph of adjacencies with TE-compliant routers. Figure 6: The graph of adjacencies with TE-compliant routers.
7. TE LSAs 9. TE LSAs
The native OSPF protocol, as of now, has a total of 11 LSA types. The native OSPF protocol, as of now, has a total of 11 LSA types.
LSA types 1 through 5 are defined in [OSPF-v2]. LSA types 6, 7 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. and 8 are defined in [MOSPF], [NSSA] and [BGP-OSPF] respectively.
Lastly, LSA types 9 through 11 are defined in [OPAQUE]. Lastly, LSA types 9 through 11 are defined in [OPAQUE].
Each of the LSA types have a unique flooding scope defined. Each of the LSA types have a unique flooding scope defined.
Opaque LSA types 9 through 11 are general purpose LSAs, with Opaque LSA types 9 through 11 are general purpose LSAs, with
flooding scope set to link-local, area-local and AS-wide (except flooding scope set to link-local, area-local and AS-wide (except
stub areas) respectively. As will become apparent from this stub areas) respectively. As will become apparent from this
skipping to change at page 14, line 39 skipping to change at page 22, line 5
these LSAs can be the TE-topology in the entire AS, flooding these LSAs can be the TE-topology in the entire AS, flooding
scope for the pre-engineered TE circuit LSA may optionally be scope for the pre-engineered TE circuit LSA may optionally be
restricted to just the TE topology within an area. restricted to just the TE topology within an area.
Lastly, the new TE LSAs are defined so as to permit peer Lastly, the new TE LSAs are defined so as to permit peer
operation of packet networks and non-packet networks alike. operation of packet networks and non-packet networks alike.
As such, a new TE-Router-Proxy LSA is defined to allow As such, a new TE-Router-Proxy LSA is defined to allow
advertisement of a TE router, that is not OSPF capable, by advertisement of a TE router, that is not OSPF capable, by
an OSPF-TE node as a proxy. an OSPF-TE node as a proxy.
7.1. TE-Router LSA 9.1. TE-Router LSA (0x81)
Router LSAs are Type 1 LSAs. The TE-router LSA is modeled after the The TE-router LSA (0x81) is modeled after the router LSA with the
router LSA with the same flooding scope as the router-LSA, except same flooding scope as the router-LSA, except that the scope is
that the scope is further restricted to TE-only nodes within the restricted to TE-only nodes within the area. The TE-router LSA
area. A value of 0x81 is assigned to TE-router LSA. The TE-router describes the TE metrics of the router as well as the TE-links
LSA describes the router-TE metrics as well as the link-TE metrics attached to the router. Below is the format of the TE-router LSA.
of the TE links attached to the router. Below is the format of the Unless specified explicitly otherwise, the fields carry the same
TE-router LSA. Unless specified explicitly otherwise, the fields meaning as they do in a router LSA. Only the differences are
carry the same meaning as they do in a router LSA. Only the explained below. Router-TE flags, Router-TE TLVs, Link-TE options,
differences are explained below. and Link-TE TLVs are each independently described in a separate
sub-section.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 0x81 | | LS age | Options | 0x81 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID | | Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router | | Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 15, line 39 skipping to change at page 23, line 6
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link-TE flags (contd.) | Zero or more Link-TE TLVs | | Link-TE flags (contd.) | Zero or more Link-TE TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link ID | | Link ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Data | | Link Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
Option Option
In TE-capable router nodes, the TE-compliance bit is set to 1. In TE-capable router nodes, the TE-bit may be set to 1.
Router-TE flags field (TE capabilities of the router node) The following fields are used to describe each router link (i.e.,
interface). Each router link is typed (see the below Type field).
The Type field indicates the kind of link being described.
Type
A new link type "Positional-Ring Type" (value 5) is defined.
This is essentially a connection to a TDM-Ring. TDM ring network
is different from LAN/NBMA transit network in that, nodes on the
TDM ring do not necessarily have a terminating path between
themselves. Secondly, the order of links is important in
determining the circuit path. Third, the protection switching
and the number of fibers from a node going into a ring are
determined by the ring characteristics. I.e., 2-fiber vs
4-fiber ring and UPSR vs BLSR protected ring.
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
Identifies the object that this router link connects to.
Value depends on the link's Type. For a positional-ring type,
the Link ID shall be IP Network/Subnet number, just as with a
broadcast transit network. The following table summarizes the
updated Link ID values.
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 number
Link Data
This depends on the link's Type field. For type-5 links, this
specifies the router interface's IP address.
9.1.1. Router-TE flags - TE capabilities of the router
Below is an initial set of definitions. More may be standardized Below is an initial set of definitions. More may be standardized
if necessary. The TLVs are not expanded in the current rev. Will if necessary. The TLVs are not expanded in the current rev. Will
be done in the follow-on revs. The field imposes a restriction be done in the follow-on revs. The field imposes a restriction
of no more than 32 flags to describe the TE capabilities of a of no more than 32 flags to describe the TE capabilities of a
router-TE. router-TE.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L|L|P|T|L|F| |S|S|S|C| |L|L|P|T|L|F| |S|S|S|C|
|S|E|S|D|S|S| |T|E|I|S| |S|E|S|D|S|S| |T|E|I|S|
skipping to change at page 16, line 49 skipping to change at page 25, line 11
Bit SEL Bit SEL
TE Selection Criteria TLV, supported by the router, follows. TE Selection Criteria TLV, supported by the router, follows.
Bit SIG Bit SIG
MPLS Signaling protocol support TLV follows. MPLS Signaling protocol support TLV follows.
BIT CSPF BIT CSPF
CSPF algorithm support TLV follows. CSPF algorithm support TLV follows.
Router-TE TLVs 9.1.2. Router-TE TLVs
The following Router-TE TLVs are defined. The following Router-TE TLVs are defined.
TE-selection-Criteria TLV (Tag ID = 1) TE-selection-Criteria TLV (Tag ID = 1)
The values can be a series of resources that may be used The values can be a series of resources that may be used
as the criteria for traffic engineering (typically with the as the criteria for traffic engineering (typically with the
aid of a signaling protocol such as RSVP-TE or CR-LDP or LDP). aid of a signaling protocol such as RSVP-TE or CR-LDP or LDP).
- Bandwidth based LSPs (1) - Bandwidth based LSPs (1)
- Priority based LSPs (2) - Priority based LSPs (2)
skipping to change at page 18, line 6 skipping to change at page 26, line 16
routes (in an MPLS signaling request) into an LSP. Further, routes (in an MPLS signaling request) into an LSP. Further,
the CSPF algorithm support on an intermediate node can be the CSPF algorithm support on an intermediate node can be
beneficial when the node terminates one or more of the beneficial when the node terminates one or more of the
hierarchical LSP tunnels. hierarchical LSP tunnels.
Label Stack Depth TLV (Tag ID = 5) Label Stack Depth TLV (Tag ID = 5)
Applicable only for PSC-Type traffic. A default value of 1 Applicable only for PSC-Type traffic. A default value of 1
is assumed. This indicates the depth of label stack the is assumed. This indicates the depth of label stack the
node is capable of processing on an ingress interface. node is capable of processing on an ingress interface.
The following fields are used to describe each router link (i.e., 9.1.3. Link-TE options - TE capabilities of a TE-link
interface). Each router link is typed (see the below Type field).
The Type field indicates the kind of link being described.
Type
A new link type "Positional-Ring Type" (value 5) is defined.
This is essentially a connection to a TDM-Ring. TDM ring network
is different from LAN/NBMA transit network in that, nodes on the
TDM ring donot necessarily have a terminating path between
themselves. Secondly, the order of links is important in
determining the circuit path. Third, the protection switching
and the number of fibers from a node going into a ring are
determined by the ring characteristics. I.e., 2-fiber vs
4-fiber ring and UPSR vs BLSR protected ring.
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
Identifies the object that this router link connects to.
Value depends on the link's Type. For a positional-ring type,
the Link ID shall be IP Network/Subnet number, just as with a
broadcast transit network. The following table summarizes the
updated Link ID values.
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 number
Link Data
This depends on the link's Type field. For type-5 links, this
specifies the router interface's IP address.
Link-TE options (TE capabilities of a link)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|N|P|T|L|F|D| |S|L|B|C| |T|N|P|T|L|F|D| |S|L|B|C|
|E|T|K|D|S|S|B| |R|U|W|O| |E|T|K|D|S|S|B| |R|U|W|O|
| |E|T|M|C|C|S| |L|G|A|L| | |E|T|M|C|C|S| |L|G|A|L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|<---- Boolean TE flags ------->|<- TE flags pointing to TLVs ->| |<---- Boolean TE flags ------->|<- TE flags pointing to TLVs ->|
TE - Indicates whether TE is permitted on the link. A link TE - Indicates whether TE is permitted on the link. A link
can be denied for TE use by setting the flag to 0. can be denied for TE use by setting the flag to 0.
skipping to change at page 19, line 33 skipping to change at page 26, line 49
is permitted on this link. is permitted on this link.
SRLG Bit - Shared Risk Link Group TLV follows. SRLG Bit - Shared Risk Link Group TLV follows.
LUG bit - Link usage cost metric TLV follows. LUG bit - Link usage cost metric TLV follows.
BWA bit - Data Link bandwidth TLV follows. BWA bit - Data Link bandwidth TLV follows.
COL bit - Data link Color TLV follows. COL bit - Data link Color TLV follows.
Link-TE TLVs 9.1.4. Link-TE TLVs
SRLG-TLV SRLG-TLV
This describes the list of Shared Risk Link Groups the link This describes the list of Shared Risk Link Groups the link
belongs to. Use 2 bytes to list each SRLG. belongs to. Use 2 bytes to list each SRLG.
BWA-TLV BWA-TLV
This indicates the maximum bandwidth, available bandwidth, This indicates the maximum bandwidth, available bandwidth,
reserved bandwidth for later use etc. This TLV may also reserved bandwidth for later use etc. This TLV may also
describe the Data link Layer protocols supported and the describe the Data link Layer protocols supported and the
Data link MTU size. Data link MTU size.
skipping to change at page 20, line 11 skipping to change at page 27, line 26
usage cost, LSP setup cost, minimum and maximum durations usage cost, LSP setup cost, minimum and maximum durations
permitted for setting up the TLV etc., including any time permitted for setting up the TLV etc., including any time
of day constraints. of day constraints.
COLOR-TLV COLOR-TLV
This is similar to the SRLG TLV, in that an autonomous This is similar to the SRLG TLV, in that an autonomous
system may choose to issue colors to link based on a system may choose to issue colors to link based on a
certain criteria. This TLV can be used to specify the certain criteria. This TLV can be used to specify the
color assigned to the link within the scope of the AS. color assigned to the link within the scope of the AS.
7.2. Changes to Network LSA 9.2. TE-incremental-link-Update LSA (0x8d)
Network-LSA is the Type 2 LSA. With the exception of the following, A significant difference between a non-TE OSPF network and a TE OSPF
no additional changes will be required to this LSA for TE network is that the latter is subject to dynamic circuit pinning and
compatibility. The LSA format and flooding scope remains unchanged. is more likely to undergo state updates. Specifically, some links
might undergo changes more frequently than others. Advertising the
entire TE-router LSA in response to a change in any single link
could be repetitive. Flooding the network with TE-router LSAs at the
aggregated speed of all the dynamic changes is simply not desirable.
The TE-incremental-link-update LSA advertises only the incremental
link updates.
A network-LSA is originated for each broadcast, NBMA and The TE-incremental-link-Update LSA will be advertised as frequently
Positional-Ring type network in the area which supports two or as the link state is changed. The TE-link sequence is largely the
more routers. The TE option is also required to be set while advertisement of a sub-portion of router LSA. The sequence number on
propagating the TDM network LSA. this will be incremented with the TE-router LSA's sequence as the
basis. When an updated TE-router LSA is advertised within 30 minutes
of the previous advertisement, the updated TE-router LSA will assume
a sequence no. that is larger than the most frequently updated of
its links.
7.2.1. Positional-Ring type network LSA - New Network type for TDM-ring. Below is the format of the TE-incremental-link-update LSA.
- Ring ID: (Network Address/Mask)
- No. of elements in the ring (a.k.a. ring neighbors)
- Ring Bandwidth
- Ring Protection (UPSR/BLSR)
- ID of individual nodes (Interface IP address)
- Ring type (2-Fiber vs. 4-Fiber, SONET vs. SDH)
Network LSA will be required for SONET RING. Unlike the broadcast 0 1 2 3
type, the sequence in which the NEs are placed on a RING-network 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
is pertinent. The nodes in the ting must be described clock wise, +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
assuming the GNE as the starting element. | 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7.3. TE-Summary LSAs Link State ID
This would be exactly the same as would have been specified as
as Link ID for a link within the router-LSA.
Link Data
This specifies the router ID the link belongs to. In majority of
cases, this would be same as the advertising router. This choice
for Link Data is primarily to facilitate proxy advertisement for
incremental link updates.
Say, a router-proxy-LSa was used to advertise the TE-router-LSA
of a SONET/TDM node. Say, the proxy router is now required to
advertise incremental-link-update for the same SONET/TDM node.
Specifying the actual router-ID the link in the
incremental-link-update-LSA belongs to helps receiving nodes in
finding the exact match for the LSA in their database.
The tuple of (LS Type, LSA ID, Advertising router) uniquely identify
the LSA and replace LSAs of the same tuple with an older sequence
number. However, there is an exception to this rule in the context
of TE-link-update LSA. TE-Link update LSA will initially assume the
sequence number of the TE-router LSA it belongs to. Further, when a
new TE-router LSA update with a larger sequence number is advertised,
the newer sequence number is assumed by al the link LSAs.
9.3. TE-Circuit-paths LSA (0x8C)
TE-Circuit-paths LSA may be used to advertise the availability of
pre-engineered TE circuit path(s) originating from any router in
the network. The flooding scope may be Area wide or AS wide.
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 |S|E|B| 0 | # of TE circuit paths |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE-Link ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE-Link Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | 0 | Link-TE flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link-TE flags (contd.) | Zero or more Link-TE TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE-Link ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE-Link Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Link State ID
The ID of the router to which the TE circuit path(s) is being
advertised.
TE-circuit-path(s) flags
Bit S - 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)
No. of Virtual TE Links
This indicates the number of pre-engineered TE links between the
advertising router and the router specified in the link state ID.
TE-Link ID
This is the ID by which to identify the virtual link on the
advertising router. This can be any private interface index or
handle that the advertising router uses to identify the
pre-engineered TE virtual link to the ABR/ASBR.
TE-Link Data
This specifies the IP address of the physical interface
on the advertising router.
9.4. TE-Summary LSAs
TE-Summary-LSAs are the Type 0x83 and 0x84 LSAs. These LSAs are TE-Summary-LSAs are the Type 0x83 and 0x84 LSAs. These LSAs are
originated by area border routers. TE-Summary-network-LSA (0x83) originated by area border routers. TE-Summary-network-LSA (0x83)
describes the reachability of TE networks in a non-backbone describes the reachability of TE networks in a non-backbone
area, advertised by the Area Border Router. Type 0x84 area, advertised by the Area Border Router. Type 0x84
summary-LSA describes the reachability of Area Border Routers summary-LSA describes the reachability of Area Border Routers
and AS border routers and their TE capabilities. and AS border routers and their TE capabilities.
One of the benefits of having multiple areas within an AS is One of the benefits of having multiple areas within an AS is
that frequent TE advertisements within the area donot impact that frequent TE advertisements within the area do not impact
outside the area. Only the TE abstractions as befitting the outside the area. Only the TE abstractions as befitting the
external areas are advertised. external areas are advertised.
7.3.1. TE-Summary Network LSA (0x83) 9.4.1. TE-Summary Network LSA (0x83)
TE-summary network LSA may be used to advertise reachability of TE-summary network LSA may be used to advertise reachability of
TE-networks accessible to areas external to the originating TE-networks accessible to areas external to the originating
area. The scope of flooding is AS wide, with the exception of area. The content and the flooding scope of a TE-Summary LSA
the originating area and the stub areas. For example, the is different from that of a native summary LSA.
TE-summary network LSA advertised by the border router of a
non-backbone area is readvertised to all other areas, not just
the backbone area. The area border router for each
non-backbone area is responsible for advertising the
reachability of backbone networks into the area.
The flooding scope of TE-summary network LSA is unlike that The scope of flooding for a TE-summary network is AS wide, with
of the summary network LSA (type 0x03), which simply uses this the exception of the originating area and the stub areas. The
as an inter-area exchange of network accessibility and limits area border router for each non-backbone area is responsible
the flooding scope to just the backbone area. for advertising the reachability of backbone networks into the
area.
Unlike a native-summary network LSA, TE-summary network LSA does
not advertise summary costs to reach networks within an area.
This is because, TE parameters are not necessarily additive or
comparative. The parameters can be varied in their expression.
A TE-summary network LSA will not be know to summarize a
network whose links do not fall under an SRLG (Shared-Risk Link
Group). This is way, the TE-summary LSA merely advertises the
reachable of TE networks within an area. The specific circuit
paths can be computed by the BDRs. On the other hand, if there
are specific circuit paths to advertise, that can be done
independently using TE-Circuit-path LSA (refer: section 9.3)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 0x83 | | LS age | Options | 0x83 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID (IP Network Number) | | Link State ID (IP Network Number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router (Area Border Router) | | Advertising Router (Area Border Router) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number | | LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length | | LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Mask | | Network Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area-ID | | Area-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7.3.2. TE-Summary router LSA (0x84) 9.4.2. TE-Summary router LSA (0x84)
TE-summary router LSA may be used to advertise the availability of TE-summary router LSA may be used to advertise the availability of
Area Border Routers (ABRs) and AS Border Routers (ASBRs) that are Area Border Routers (ABRs) and AS Border Routers (ASBRs) that are
TE capable. The TE-summary router LSAs are originated by the Area TE capable. The TE-summary router LSAs are originated by the Area
Border Routers. The scope of flooding for the TE-summary router LSA Border Routers. The scope of flooding for the TE-summary router LSA
is the entire AS, with the exception of the non-backbone areas the is the non-backbone area the advertising ABR belongs to.
advertising ABRs belong to.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 0x84 | | LS age | Options | 0x84 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID | | Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router (ABR) | | Advertising Router (ABR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 23, line 4 skipping to change at page 32, line 50
ASBR belongs to. The advertising router is assumed to be the ASBR belongs to. The advertising router is assumed to be the
ABR from the same area the ASBR is located in. ABR from the same area the ASBR is located in.
Summary-router-TE flags Summary-router-TE flags
Bit E - When set, the advertised Link-State ID is an AS boundary Bit E - When set, the advertised Link-State ID is an AS boundary
router (E is for external). The advertising router and router (E is for external). The advertising router and
the Link State ID belong to the same area. the Link State ID belong to the same area.
Bit B - When set, the advertised Link state ID is an Area Bit B - When set, the advertised Link state ID is an Area
border router (B is for Border) border router (B is for Border)
Router-TE flags, Router-TE flags,
Router-TE TLVs (TE capabilities of the link-state-ID router) Router-TE TLVs (TE capabilities of the link-state-ID router)
TE Flags and TE TLVs are as applicable to the ABR/ASBR TE Flags and TE TLVs are as applicable to the ABR/ASBR
specified in the link state ID. The semantics is same as specified in the link state ID. The semantics is same as
specified in the Router-TE LSA. specified in the Router-TE LSA.
7.4. TE-AS-external LSAs (0x85) 9.5. TE-AS-external LSAs (0x85)
TE-AS-external-LSAs are the Type 0x85 LSAs. This is modeled after TE-AS-external-LSAs are the Type 0x85 LSAs. This is modeled after
AS-external LSA format and flooding scope. These LSAs are originated AS-external LSA format and flooding scope. These LSAs are originated
by AS boundary routers with TE extensions (say, a BGP node which can by AS boundary routers with TE extensions (say, a BGP node which can
communicate MPLS labels across to external ASes), and describe communicate MPLS labels across to external ASes), and describe
networks and pre-engineered TE links external to the AS. The networks and pre-engineered TE links external to the AS. The
flooding scope of this LSA is similar to that of an AS-external LSA. flooding scope of this LSA is similar to that of an AS-external LSA.
I.e., AS wide, with the exception of stub areas. I.e., AS wide, with the exception of stub areas.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 0x85 | | LS age | Options | 0x85 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID | | Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router | | Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 24, line 35 skipping to change at page 34, line 34
this address. If the Forwarding address is set to 0.0.0.0, data this address. If the Forwarding address is set to 0.0.0.0, data
traffic will be forwarded instead to the LSA's originator (i.e., traffic will be forwarded instead to the LSA's originator (i.e.,
the responsible AS boundary router). the responsible AS boundary router).
External Route Tag External Route Tag
A 32-bit field attached to each external route. This is not A 32-bit field attached to each external route. This is not
used by the OSPF protocol itself. It may be used to communicate used by the OSPF protocol itself. It may be used to communicate
information between AS boundary routers; the precise nature of information between AS boundary routers; the precise nature of
such information is outside the scope of this specification. such information is outside the scope of this specification.
7.5. TE-Circuit-paths LSA (0x8C) 9.6. Changes to Network LSA
TE-Circuit-paths LSA may be used to advertise the availability of
pre-engineered TE circuit path(s) originating from any router in
the network. The flooding scope may be Area wide or AS wide.
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 |S|E|B| 0 | # of TE circuit paths |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE-Link ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE-Link Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | 0 | Link-TE flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link-TE flags (contd.) | Zero or more Link-TE TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE-Link ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE-Link Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Link State ID
The ID of the router to which the TE circuit path(s) is being
advertised.
TE-circuit-path(s) flags
Bit S - 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)
No. of Virtual TE Links
This indicates the number of pre-engineered TE links between the
advertising router and the router specified in the link state ID.
TE-Link ID
This is the ID by which to identify the virtual link on the
advertising router. This can be any private interface index or
handle that the advertising router uses to identify the
pre-engineered TE virtual link to the ABR/ASBR.
TE-Link Data
This specifies the IP address of the physical interface
on the advertising router.
7.6. TE-Link-Update LSA (0x8d)
A significant difference between a non-TE OSPF network and a TE OSPF
network is that the latter is subject to dynamic circuit pinning and
is more likely to undergo state updates. Specifically, some links
might undergo more changes and more frequently than others.
Advertising the entire TE-router LSA in response to a change in any
single link could be repetitive. Flooding the network with TE-router
LSAs at the aggregated speed of all the dynamic changes is simply
not desirable. Hence, the new TE-link-update LSA, that advertises
link specific updates alone.
The TE-link-Update LSA will be advertised as frequently as the link
state is changed. The TE-link sequence is largely the advertisement
of a sub-portion of router LSA. The sequence number on this will be
incremented with the TE-router LSA's sequence as the basis. When an
updated TE-router LSA is advertised within 30 minutes of the
previous advertisement, the updated TE-router LSA will assume a
sequence no. that is larger than the most frequently updated of
its links.
Below is the format of the TE-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 Network-LSA is the Type 2 LSA. With the exception of the following,
This would be exactly the same as would have been specified as no additional changes will be required to this LSA for TE
as Link ID for a link within the router-LSA. compatibility. The LSA format and flooding scope remains unchanged.
Link Data A network-LSA is originated for each broadcast, NBMA and
This specifies the router ID the link belongs to. In majority of Positional-Ring type network in the area which supports two or
cases, this would be same as the advertising router. more routers. The TE option is also required to be set while
propagating the TDM network LSA.
The tuple of (LS Type, LSA ID, Advertising router) uniquely identify 9.6.1. Positional-Ring type network LSA - New Network type for TDM-ring.
the LSA and replace LSAs of the same tuple with an older sequence - Ring ID: (Network Address/Mask)
number. However, there is an exception to this rule in the context - No. of elements in the ring (a.k.a. ring neighbors)
of TE-link-update LSA. TE-Link update LSA will initially assume the - Ring Bandwidth
sequence number of the TE-router LSA it belongs to. Further, - Ring Protection (UPSR/BLSR)
when a new TE-router LSA update with a larger sequence number is - ID of individual nodes (Interface IP address)
advertised, the newer sequence number is assumed by al the link - Ring type (2-Fiber vs. 4-Fiber, SONET vs. SDH)
LSAs. Network LSA will be required for SONET RING. Unlike the broadcast
type, the sequence in which the NEs are placed on a RING-network
is pertinent. The nodes in the ting must be described clock wise,
assuming the GNE as the starting element.
7.7. TE-Router-Proxy LSA (0x8e) 9.7. TE-Router-Proxy LSA (0x8e)
This is a variation to the TE-router LSA in that the TE-router LSA This is a variation to the TE-router LSA in that the TE-router LSA
is not advertised by the network element, but rather by a trusted is not advertised by the network element, but rather by a trusted
TE-router Proxy. This is typically the scenario in a non-packet TE-router Proxy. This is typically the scenario in a non-packet
TE network, where some of the nodes donot have OSPF functionality TE network, where some of the nodes do not have OSPF functionality
and count on a helper node to do the advertisement for them. One and count on a helper node to do the advertisement for them. One
such example would be the SONET/SDH ADM nodes in a TDM ring. The such example would be the SONET/SDH ADM nodes in a TDM ring. The
nodes may principally depend upon the GNE (Gateway Network Element) nodes may principally depend upon the GNE (Gateway Network Element)
to do the advertisement for them. TE-router-Proxy LSA shall not be to do the advertisement for them. TE-router-Proxy LSA shall not be
used to advertise Area Border Routers and/or AS border Routers. used to advertise Area Border Routers and/or AS border Routers.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 0x8e | | LS age | Options | 0x8e |
skipping to change at page 28, line 24 skipping to change at page 36, line 10
| Type | 0 | Link-TE options | | Type | 0 | Link-TE options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link-TE flags | Zero or more Link-TE TLVs | | Link-TE flags | Zero or more Link-TE TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link ID | | Link ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Data | | Link Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
8. Link State Databases 9.8. Others
With the new TE-LSA scheme, an OSPF-TE node will have two types
of Link state databases (LSDB). A native LSDB that describes the
control (non-TE) topology and a TE-LSDB that describes the TE
topology. Shortest-Path-First algorithm will be used to forward
IP packets along the native control network. OSPF neighbors data
structure will be used for flooding along the control topology.
The TE-LSDB is constituted only of TE nodes and TE links. A variety
of CSPF algorithms may be used to dynamically setup TE circuit
paths along the TE network. A new TE-neighbors data structure will
be used to flood TE LSAs along the TE-only topology. Clearly, the
the TE nodes will need the control (non-TE) network for OSPF
communication. The control network may also be used for pinging
OSPF-TE nodes and performing any debug and monitoring tasks on
the nodes. However, the ability to make distinction between
TE and non-TE topologies, allows the bandwidth on TE links to be
strictly SLA enforceable, even as a TE link is packet-capable.
The actual characteristics of the TE-link are irrelevant from the
OPSF-TE perspective. As such, that allows for packet and non-packet
networks to operate in peer mode.
Consider the following network where some of the routers and links
are TE enabled and others are native OSPF routers and links. All
nodes in the network belong to the same OSPF area.
+---+
| |--------------------------------------+
|RT6|\\ |
+---+ \\ |
|| \\ |
|| \\ |
|| \\ |
|| +---+ |
|| | |----------------+ |
|| |RT1|\\ | |
|| +---+ \\ | |
|| //| \\ | |
|| // | \\ | |
|| // | \\ | |
+---+ // | \\ +---+ |
|RT2|// | \\|RT3|------+
| |----------|----------------| |
+---+ | +---+
| |
| |
| |
+---+ +---+
|RT5|--------------|RT4|
+---+ +---+
Legend:
-- Native(non-TE) network link
| Native(non-TE) network link
\\ TE network link
|| TE network link
Figure 6: A (TE + native) OSPF network topology
In the above network, TE and native OSPF Link State Data bases
(LSDB) would have been synchronized within the area along the
following nodes.
Native OSPF LSDB nodes TE-LSDB nodes
---------------------- -------------
RT1, RT2, RT3. RT4, RT5, RT6 RT1, RT2, RT3, RT6
Nodes such as RT1 will have two LSDBs, a native LSDB and a TE-LSDB We may also introduce a new TE-NSSA LSA, similar to the native-NSSA
to reach native and TE networks. The TE LSA updates will not impact LSA. TE-NSSA will help ensure that not all external TE routes are
non-TE nodes RT4 and RT5. flooded into the NSSA area. A TE capable router can become the NSSA
translator. All parameters and contents of TE-NSSA LSAs are
transferred as is.
9. Abstract topology representation with TE support 10. Abstract topology representation with TE support
Below, we assume a TE network that is composed of three OSPF areas, Below, we assume a TE network that is composed of three OSPF areas,
namely Area-1, Area-2 and Area-3, attached together through the namely Area-1, Area-2 and Area-3, attached together through the
backbone area. The following figure is an inter-area topology backbone area. The following figure is an inter-area topology
abstraction from the perspective of routers in Area-1. The abstraction from the perspective of routers in Area-1. The
abstraction is similar, but not the same, as that of the non-TE abstraction is similar, but not the same, as that of the non-TE
abstraction. As such, the authors claim the model is easy to abstraction. As such, the authors claim the model is easy to
understand and emulate. The abstraction illustrates reachability understand and emulate. The abstraction illustrates reachability
of TE networks and nodes in areas external to the local area and of TE networks and nodes in areas external to the local area and
ASes external to the local AS. The abstraction also illustrates ASes external to the local AS. The abstraction also illustrates
skipping to change at page 33, line 5 skipping to change at page 38, line 5
+-------------+ | | | +-------------+ | | |
+-----------------+ +-------------+ +-----------------+ +-----------------+ +-------------+ +-----------------+
|Pre-engineered TE| |AS External | |Pre-engineered TE| |Pre-engineered TE| |AS External | |Pre-engineered TE|
|circuit path(s) | |TE-Network | |circuit path(s) | |circuit path(s) | |TE-Network | |circuit path(s) |
|reachable from | |reachability | |reachable from | |reachable from | |reachability | |reachable from |
|ASBR-S1 | |from ASBR-S2 | |ASBR-S2 | |ASBR-S1 | |from ASBR-S2 | |ASBR-S2 |
+-----------------+ +-------------+ +-----------------+ +-----------------+ +-------------+ +-----------------+
Figure 9: Inter-Area Abstraction as viewed by Area-1 TE-routers Figure 9: Inter-Area Abstraction as viewed by Area-1 TE-routers
10. Changes to Data structures in OSPF-TE nodes 11. Changes to Data structures in OSPF-TE nodes
10.1. Changes to Router data structure 11.1. Changes to Router data structure
The router with TE extensions must be able to include all the The router with TE extensions must be able to include all the
TE capabilities (as specified in section 7.1) in the router data TE capabilities (as specified in section 7.1) in the router data
structure. Further, routers providing proxy service to other TE structure. Further, routers providing proxy service to other TE
routers must also track the router and associated interface data routers must also track the router and associated interface data
structures for all the TE client nodes for which the proxy structures for all the TE client nodes for which the proxy
service is being provided. Presumably, the interaction between service is being provided. Presumably, the interaction between
the Proxy server and the proxy clients is out-of-band. the Proxy server and the proxy clients is out-of-band.
10.2. Two set of Neighbors 11.2. Two set of Neighbors
Two sets of neighbor data structures will need to be maintained. Two sets of neighbor data structures will need to be maintained.
TE-neighbors set is used to advertise TE LSAs. Only the TE-nodes TE-neighbors set is used to advertise TE LSAs. Only the TE-nodes
will be members of the TE-neighbor set. Native neighbors set will will be members of the TE-neighbor set. Native neighbors set will
be used to advertise native LSAs. All neighboring nodes supporting be used to advertise native LSAs. All neighboring nodes supporting
non-TE links can be part of this set. As for flooding optimizations non-TE links can be part of this set. As for flooding optimizations
based on neighbors set, readers may refer [OSPF-FL1]. based on neighbors set, readers may refer [FLOOD-OPT].
10.3. Changes to Interface data structure 11.3. Changes to Interface data structure
The following new fields are introduced to the interface data The following new fields are introduced to the interface data
structure. These changes are in addition to the changes specified structure. These changes are in addition to the changes specified
in [OSPF-FL1]. in [FLOOD-OPT].
TePermitted TePermitted
If the value of the flag is TRUE, the interface is permissible If the value of the flag is TRUE, the interface is permissible
to be advertised as a TE-enabled interface. to be advertised as a TE-enabled interface.
NonTePermitted NonTePermitted
If the value of the flag is TRUE, the interface permits non-TE If the value of the flag is TRUE, the interface permits non-TE
traffic on the interface. Specifically, this is applicable to traffic on the interface. Specifically, this is applicable to
packet networks, where data links may permit both TE and non-TE packet networks, where data links may permit both TE and non-TE
packets. For FSC and LSC TE networks, this flag will be set to packets. For FSC and LSC TE networks, this flag will be set to
FALSE. For Packet networks that donot permit non-TE traffic on FALSE. For Packet networks that do not permit non-TE traffic on
TE links also, this flag is set to TRUE. TE links also, this flag is set to TRUE.
PktTerminated PktTerminated
If the value of the flag is TRUE, the interface terminates If the value of the flag is TRUE, the interface terminates
Packet data and hence may be used for IP and OSPF data exchange. Packet data and hence may be used for IP and OSPF data exchange.
AdjacencySychRequired AdjacencySychRequired
If the value of the flag is TRUE, the interface may be used to If the value of the flag is TRUE, the interface may be used to
synchronize the LSDB across all adjacent neighbors. This is synchronize the LSDB across all adjacent neighbors. This is
TRUE by default to all PktTerminated interfaces that are TRUE by default to all PktTerminated interfaces that are
skipping to change at page 34, line 26 skipping to change at page 39, line 26
as broadcast and NBMA) in that the exact location of the nodes as broadcast and NBMA) in that the exact location of the nodes
on the ring is relevant, even as they are all on the same on the ring is relevant, even as they are all on the same
ring. SONET ADM ring is a good example of this. Complete ring ring. SONET ADM ring is a good example of this. Complete ring
positional-ring description may be provided by the GNE on a positional-ring description may be provided by the GNE on a
ring as a TE-network LSA for the ring. ring as a TE-network LSA for the ring.
List of Neighbors List of Neighbors
The list may be statically defined for an interface, without The list may be statically defined for an interface, without
requiring the use of Hello protocol. requiring the use of Hello protocol.
11. Motivations to this approach 12. IANA Considerations
Use of TE LSAs bring substantial benefits over using Opaque LSAs
as described below. These benefits cannot be retrofitted into
Opaque LSAs due to fundamental scalability limitations of the
Opaque-LSA approach.
The primary motivation behind the TE-LSA model is that the
approach is clean (clean separation of LSDB between TE vs non-TE
networks), scalable (across more than one OSPF area), unified
(for packet and non-packet networks alike), efficient (efficient
flooding algorithm) and SLA enforceable. The model proposed also
provides the right framework for future enhancements.
11.1. TE flooding isolated to TE-only nodes
A TE network can generate a large number of LSA updates due
to the many state changes the TE links undergo dynamically. For
example, bandwidth assignment on a TE link for a specific circuit
path setup will mandate that the change in bandwidth availability
be communicated network wide. While such frequent link state
updates is reasonable for an OSPF-TE node, neither the frequency
nor the content of TE link state is desirable for native OSPF
nodes. This can be a considerable interruption to non-TE nodes in
a network that is constituted of multiple types of nodes and links
(ex: A network constituted of packet routing nodes/links and SONET
network ADMs/links, A packet-network where the ratio of TE nodes
to non-TE nodes is quite considerable).
The wider the flooding scope (and number of TE nodes), the larger
the number of retransmissions and acknowledgements. The same
information (needed or not) may reach a router through multiple
links. Even if the router did not forward the information past the
node, it would still have to send acknowledgements across all the
multiple links on which the LSAs tried to converge. By restricting
the flooding of TE LSAs to TE-only nodes within a TE topology, we
obviate any TE based processing for non-TE nodes.
The flooding topology for opaque LSAs makes no distinction between
TE and native OSPF nodes. In a network where the TE and native
nodes coexist, a native OSPF router would be bombarded with opaque
LSAs. It is possible for the native OSPF nodes to silently ignore
the unsupported Opaque LSAs (during network migration) or add
knobs within implementation to decide whether or not a certain
opaque LSA mandates dijkstra SPF recomputation. But, the latter
can be tricky and will need non-trivial amounts of Opaque LSA
processing to make the determination. In the case where routers
donot validate the need to recompute, routers might end up
recomputing for all new Opaque LSA advertisements. Clearly, that
would be a considerable computational demand and can be cause for
instability on the OSPF routers.
11.2. Clean separation between native and TE LSDBs
Most vendors wishing to support MPLS based TE in their network
tend to migrate gradually to support the TE extensions. Perhaps,
add new TE links or convert existing links into TE links within
an area first and progressively advance to offer in the entire
AS. As such, the TE network cannot be assumed to exist
independently without native OSPF network even in the long term.
Not all routers will support TE extensions at the same time
during the migration process. Use of TE specific LSAs and their
flooding to OSPF-TE only nodes will allow the vendor to
introduce MPLS TE without destabilizing the existing network.
As such, the native OSPF-LSDB will remain undisturbed while
newer TE links are added to network.
With the new TE-LSA scheme, native OSPF nodes will keep just the
native OSPF link state database. The OSPF-TE nodes will keep
native as well as the TE LSDB. The native LSDB describes the
control (non-TE) topology. Shortest-Path-First algorithm will be
used to forward IP packets along this network. OSPF neighbors
data structure will be used for flooding along the control
topology.
In the Opaque-LSA-based TE scheme, the TE-LSDB built using opaque
LSAs will be required to refer the native LSDB to build the TE
topology. Even with that, there is way to know the TE capabilities
of the routers. The Opaque-LSA approach does not deal with TE
capabilities for a router. Opaque LSAs are flooded to all nodes.
Some nodes that happen to support the TE extensions will have a
hit and accept the opaque LSAs. Others that donot support will
have a miss and simply drop the received Opaque LSAs. This type of
hit-and-miss approach is not only disruptive, but also blind to
SLA requirements on TE links.
11.3. Scalability across a hierarchical Area topology
Use of TE LSAs for inter-area communication is clearly superior
to using Opaque LSAs with AS wide scoping. Without revealing
the TE nodes and characteristics of the attached links, an Opaque
LSA (type 11) simply does not disseminate reachability of TE
networks and nodes outside the area. Stated differently,
Use of opaque LSA can, work at best, for a single area AS.
Providing area level abstraction and having this abstraction be
distinct for TE and native topologies is a necessity in inter-area
communication. When the topologies are separate, the area border
routers can advertise different summary LSAs for TE and
non-TE routers. For example, a native Area Border router (ABR)
simply announces the shortest path network summary LSAs (LSA
type 3) for nodes outside the area. A TE ABR, on the other hand,
could use TE-summary network LSA to advertise network Reachability
information - not aggregated path metric as required for a native
OSPF LSDB. Clearly, the data content and flooding scope should be
different for the TE nodes. The flooding boundary for TE-summary
LSAs would be (AS - OriginatingArea - StubAreas - NSSAs).
Opaque-LSAs are suitable neither for content nor for flooding scope
in the context of inter-area communication. The flooding boundaries
of Opaque LSAs make the approach suitable at best to single-area
topologies. For example, Opaque LSAs cannot support the flooding
scope of TE-summary-networks. Opaque LSAs (AS-wide scope) will be
unable to restrict flooding in its own originating area.
Opaque LSAs are also not adequate to establish TE peering
relationship with neighbors.
11.4. Usable across packet and non-packet TE networks
In a peer networking TE model, you are likely to want different
types of TE information flooded by various nodes, as they are
heterogenous and will remain that way. The TE LSA based approach
offers a single set of LSAs that may uniformly be used across
packet and non-packet nodes and links. Once a link is declared
as TE, the TE properties advertised of the link can be link
specific, but all advertisements would use the same LSA format.
Implementations reusing the opaque LSA with GMPLS extensions
are burden for the routers that do not need it. Clear
separation (as proposed here) between TE and native LSAs
and having independent flooding scopes for native and TE state
information will be extremely useful in inheriting the right
set of LSAs for the right application (i.e, TE vs native).
11.5. SLA enforceable network modeling
When TE and native topologies are not separated (as is the case
with Opaque-LSAs), a native OSPF node could be utilizing a TE
link as its least cost link, thereby stressing the TE link and
effectively rendering the TE link ineffective for TE purposes.
Separating the two topologies (as advocated by this document with
new TE LSAs and TE option flag) ensure that the SLA objectives on
TE links are properly met.
11.6. Framework for future extensibility
The approach outlined provides a framework for future
extensibility based on service provider needs.
There may be many types of information that should not be
disseminated along the Opaque LSA flooding boundaries. Take for
example, the TE-summary network LSA. This LSA does not follow
the scope of an area or an AS, but something in between. As a
general rule, the proposed framework can be extended to define
newer TE LSAs with a suitable flooding scope.
Having a clean framework which argues for having different
link state databases for different applications on the same network
will provide the right forum for future extensibility. Just as
the TE LSDB may be used for MPLS TE application, a different type
of LSDB may be used for yet another type of application (such as
QOS based IP forwarding) using the same IP network.
lastly, an opaque LSA is restricted in the format in which it can
express different types of data. Everything should be expressible
in the form of a TLV. Summary-TE-networks-from each Area, TE-ABR
routers, TE-ASBR routers, TE-AS-External-networks, TE-Router
Capabilities, TE-link updates, Pre-engineered-TE-Links - All of
these data have to be engineered to be expressible in a TLV form
with one or more sub-TLVs. Some of the TLVs will be required to
be mandatory. Some would be expected to appear in a pre-specified
order and some are expected to appear just once in the LSA.
TLVs should not be a panacea for all kinds of TE data. TLVs are
generally more difficult to process and debug than fixed format
messages.
Opaque LSAs demand more processing to assimilate into topology
abstraction. A single Opaque LSA type is bent in many
ways (using a variety of TLVs) to update the native OSPF topology
abstraction nodes. Not a framework that could be easily extended
for future applications.
11.7. Real-world scenarios benefiting from this approach
Many real-world scenarios are better served by the new-TE-LSAs
scheme. Here are a few examples.
1. Multi-area network.
2. Single-Area networks - The TE links are not cannibalized by the
non-TE routers for SPF forwarding.
3. Credible SLA enforcement in a (TE + non-TE) packet network.
Ability to restrict flooding to some links (say, non-TE links)
ensures the service provider is able to devote the entire
bandwidth of a TE-link for TE circuit purposes. This makes SLA
enforcement credible.
4. For a non-Packet TE network, the Opaque-LSA-based-TE scheme is
not adequate to represent
(a) "Positional-Ring" type network LSA and
(b) Router Proxying - allowing a router to advertise on behalf
of other nodes (that are not Packet/OSPF capable).
12. Transition strategy for implementations using Opaque LSAs
Below is a strategy to transition current implementations to
adapt the new TE LSA scheme in a gradual fashion. Implementations
using Opaque-LSAs can take the following steps to accomplish this.
Once the OSPF-TE is completely transitioned to using the new TE
LSAs as described here, the TE network can reap the full benefits
of the scheme. Amongst other things, packet and non-packet networks
may be combined with ease into a unified network. As such, the MPLS
traffic engineering can be based on either of the overlayed or peer
models espoused in [GMPLS-TE].
1. Restrict the use of Opaque-LSAs for within an area.
2. Fold in the TE option flag to construct the TE and non-TE
topologies in an area, even if the topologies cannot be used
for flooding within the area.
3. Use TE-Summary LSAs and AS-external-LSAs for inter-area
Communication. Make use of the TE-topology within area to
summarize the TE networks in the area and advertise the same
to all TE-routers in the backbone. The TE-ABRs on the backbone
area will in-turn advertise these summaries again within their
connected areas.
4. Replace Opaque LSAs with TE LSAs within the area as well.
13. IANA Considerations
13.1. TE-compliant-SPF routers Multicast address allocation 12.1. TE-compliant-SPF routers Multicast address allocation
13.2. New TE-LSA Types 12.2. New TE-LSA Types
13.3. New TLVs (Router-TE and Link-TE TLVs) 12.3. New TLVs (Router-TE and Link-TE TLVs)
13.3.1. TE-selection-Criteria TLV (Tag ID = 1) 12.3.1. TE-selection-Criteria TLV (Tag ID = 1)
- Bandwidth based LSPs (1) - Bandwidth based LSPs (1)
- Priority based LSPs (2) - Priority based LSPs (2)
- Backup LSP (3) - Backup LSP (3)
- Link cost (4) - Link cost (4)
13.3.2. MPLS-Signaling protocol TLV (Tag ID = 3) 12.3.2. MPLS-Signaling protocol TLV (Tag ID = 3)
- RSVP-TE signaling - RSVP-TE signaling
- LDP signaling - LDP signaling
- CR-LDP signaling - CR-LDP signaling
13.3.3. Constraint-SPF algorithms-Support TLV (Tag ID = 4) 12.3.3. Constraint-SPF algorithms-Support TLV (Tag ID = 4)
- CSPF Algorithm Codes. - CSPF Algorithm Codes.
13.3.4. SRLG-TLV (Tag ID = 0x81) 12.3.4. SRLG-TLV (Tag ID = 0x81)
- SRLG group IDs - SRLG group IDs
12.3.5. BW-TLV (Tag ID = 0x82)
13.3.5. BW-TLV (Tag ID = 0x82) 12.3.6 CO-TLV (Tag ID = 0x83)
13.3.6 CO-TLV (Tag ID = ox83) 13. Acknowledgements
14. Acknowledgements
The authors wish to thank Vishwas manral, Riyad Hartani and Tricci The authors wish to thank Vishwas Manral, Chitti Babu, Riyad
So for their valuable comments and feedback on the draft. Hartani and Tricci So for their valuable comments and feedback
on the draft.
15. Security Considerations 14. Security Considerations
This memo does not create any new security issues for the OSPF This memo does not create any new security issues for the OSPF
protocol. Security considerations for the base OSPF protocol are protocol. Security considerations for the base OSPF protocol are
covered in [OSPF-v2]. As a general rule, a TE network is likely covered in [OSPF-v2]. As a general rule, a TE network is likely
to generate significantly more control traffic than a native to generate significantly more control traffic than a native
OSPF network. The excess traffic is almost directly proportional OSPF network. The excess traffic is almost directly proportional
to the rate at which TE circuits are setup and torn down within to the rate at which TE circuits are setup and torn down within
an autonomous system. It is important to ensure that TE database an autonomous system. It is important to ensure that TE database
sychronizations happen quickly when compared to the aggregate synchronizations happen quickly when compared to the aggregate
circuit setup an tear-down rates. circuit setup an tear-down rates.
REFERENCES REFERENCES
[IETF-STD] Bradner, S., " The Internet Standards Process -- [IETF-STD] Bradner, S., " The Internet Standards Process --
Revision 3", RFC 1602, IETF, October 1996. Revision 3", RFC 1602, IETF, October 1996.
[RFC 1700] J. Reynolds and J. Postel, "Assigned Numbers", [RFC 1700] J. Reynolds and J. Postel, "Assigned Numbers",
RFC 1700 RFC 1700
[MPLS-TE] Awduche, D., et al, "Requirements for Traffic [MPLS-TE] Awduche, D., et al, "Requirements for Traffic
Engineering Over MPLS," RFC 2702, September 1999. Engineering Over MPLS," RFC 2702, September 1999.
[GMPLS-TE] P.A. Smith et. al, "Generalized MPLS - Signaling [GMPLS-TE] P.A. Smith et. al, "Generalized MPLS - Signaling
Functional Description", Functional Description", work in progress,
draft-ietf-mpls-generalized-signaling-03.txt, work draft-ietf-mpls-generalized-signaling-03.txt
in progress.
[RSVP-TE] Awduche, D.O., L. Berger, Der-Hwa Gan, T. Li, [RSVP-TE] Awduche, D., L. Berger, D. Gan, T. Li, V. Srinivasan,
V. Srinivasan and G. Swallow, "RSVP-TE: Extensions and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
to RSVP for LSP Tunnels", Work in progress, Tunnels", RFC3209, IETF, December 2001
draft-ietf-mpls-rsvp-lsp-tunnel-08.txt
[CR-LDP] Jamoussi, B. et. al, "Constraint-Based LSP Setup [CR-LDP] Jamoussi, B. et al, "Constraint-Based LSP Setup
using LDP", draft-ietf-mpls-cr-ldp-05.txt, using LDP", draft-ietf-mpls-cr-ldp-06.txt,
Work in Progress. Work in Progress.
[OSPF-v2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. [OSPF-v2] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
[MOSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584, [MOSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584,
March 1994. March 1994.
[NSSA] Coltun, R., V. Fuller and P. Murphy, "The OSPF NSSA [NSSA] Coltun, R., V. Fuller and P. Murphy, "The OSPF NSSA
Option", draft-ietf-ospf-nssa-update-10.txt, Work in Option", draft-ietf-ospf-nssa-update-10.txt, Work in
Progress. Progress.
[OPAQUE] Coltun, R., "The OSPF Opaque LSA Option," RFC 2370, [OPAQUE] Coltun, R., "The OSPF Opaque LSA Option," RFC 2370,
July 1998. July 1998.
[OSPF-FL1] Zinin, A. and M. Shand, "Flooding Optimizations in [FLOOD-OPT] Zinin, A. and M. Shand, "Flooding Optimizations in
link-state routing protocols", work in progress, link-state routing protocols", work in progress,
<draft-ietf-ospf-isis-flood-opt-01.txt> <draft-ietf-ospf-isis-flood-opt-01.txt>
[OSPF-FL2] Moy, J., "Flooding over a subset topology",
<draft-ietf-ospf-subset-flood-00.txt>, work in progress.
[OPQLSA-TE] Katz, D., D. Yeung and K. Kompella, "Traffic [OPQLSA-TE] Katz, D., D. Yeung and K. Kompella, "Traffic
Engineering Extensions to OSPF", work in progress, Engineering Extensions to OSPF", work in progress,
<draft-katz-yeung-ospf-traffic-05.txt> <draft-katz-yeung-ospf-traffic-06.txt>
[OPQLSA-GMPLS] Kompella, K., Y. Rekhter, A. Banerjee, J. Drake,
G. Bernstein, D. Fedyk, E. Mannie, D. Saha and
V. Sharma, "OSPF Extensions in Support of Generalized
MPLS", <draft-ietf-ccamp-ospf-gmpls-extensions-01.txt>,
work in progress.
Authors' Addresses Authors' Addresses
Pyda Srisuresh Pyda Srisuresh
Kuokoa Networks, Inc. Kuokoa Networks, Inc.
2901 Tasman Dr., Suite 202 2901 Tasman Dr., Suite 202
Santa Clara, CA 95054 Santa Clara, CA 95054
U.S.A. U.S.A.
EMail: srisuresh@yahoo.com EMail: srisuresh@yahoo.com
Paul Joseph Paul Joseph
Jasmine Networks Vivace Networks
3061 Zanker Road, Suite B 2730 Orchard Parkway
San Jose, CA 95134 San Jose, CA 95134
U.S.A. U.S.A.
EMail: pjoseph@jasminenetworks.com Tel: (408) 432 7655
EMail: paul.joseph@vivacenetworks.com
 End of changes. 119 change blocks. 
829 lines changed or deleted 901 lines changed or added

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