< draft-srisuresh-ospf-te-00.txt   draft-srisuresh-ospf-te-01.txt >
Network Working Group P. Srisuresh Network Working Group P. Srisuresh
INTERNET-DRAFT P. Joseph INTERNET-DRAFT Kuokoa Networks
Expires as of December 25, 2001 Jasmine Networks Expires as of January 20, 2002 P. Joseph
June, 2001 Jasmine Networks
July, 2001
New TE LSAs to extend OSPF for Traffic Engineering TE LSAs to extend OSPF for Traffic Engineering
<draft-srisuresh-ospf-te-00.txt> <draft-srisuresh-ospf-te-01.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 2, line 12 skipping to change at page 2, line 13
scaling limitations of the approach outlined in [OPQLSA-TE]. The scaling limitations of the approach outlined in [OPQLSA-TE]. The
document draws a distinction between TE and non-TE topologies and document draws a distinction between TE and non-TE topologies and
restricts flooding of TE LSAs into non-TE topology. The document restricts flooding of TE LSAs into non-TE topology. The document
covers OSPF extensions for packet and non-packet networks alike, covers OSPF extensions for packet and non-packet networks alike,
providing a unified extension mechanism for all networks. As such, providing a unified extension mechanism for all networks. As such,
this approach improves interoperability between peer network this approach improves interoperability between peer network
elements. Lastly, the document specifies a transition path for elements. Lastly, the document specifies a transition path for
vendors currently using opaque LSAs to transition to using new vendors currently using opaque LSAs to transition to using new
TE LSAs outlined here. TE LSAs outlined here.
Table of Contents
1. Introduction ................................................3
2. Traffic Engineering .........................................4
3. Terminology .................................................5
3.1. OSPF-TE router (or) TE-compliant OSPF router ...........5
3.2. Native OSPF router .....................................5
3.3. TE nodes vs. non-TE (native) nodes .....................6
3.4. TE links vs. non-TE (native) links .....................6
3.5. Packet interface vs. non-packet interface ..............6
3.6. TE topology vs. non-TE topology ........................6
3.7. TLV ....................................................7
3.8. Router-TE TLVs .........................................7
3.9. Link-TE TLVs ...........................................7
4. Motivation and Implicit assumptions for the TE extensions ...7
5. The OSPF Options field ......................................9
6. Bringing up TE adjacencies; TE vs. Non-TE topologies .......10
6.1. The Hello Protocol ...................................10
6.2. Flooding and the Synchronization of Databases .........10
6.3. The Designated Router ................................11
6.4. The Backup Designated Router .........................12
6.5. The graph of adjacencies .............................12
7. TE LSAs ....................................................13
7.1. TE-Router LSA .........................................14
7.2. Changes to Network LSA ................................20
7.2.1. Positional-Ring type network LSA ...............20
7.3. TE-Summary LSAs .......................................20
7.3.1. TE-Summary Network LSA (0x83) ..................20
7.3.2. TE-Summary router LSA (0x84) ...................21
7.4. TE-AS-external LSAs (0x85) ............................23
7.5. TE-Circuit-paths LSA (0x8C) ...........................24
7.6. TE-Link-Update LSA (0x8d) .............................25
7.7. TE-Router-Proxy LSA (0x8e) ............................27
8. Link State Databases .......................................28
9. Abstract topology representation with TE support ...........29
10. Changes to Data structures in OSPF-TE routers ..............32
10.1. Changes to Router data structure .....................32
10.2. Two set of Neighbors .................................32
10.3. Changes to Interface data structure ..................32
11. Motivations to this approach ...............................33
11.1. TE flooding isolated to TE-only nodes ................33
11.2. Clean separation between native and TE LSDBs .........34
11.3. Scalability across a hierarchical Area topology ......35
11.4. Usable across packet and non-packet TE networks ......35
11.5. SLA enforceable network modeling .....................36
11.6. Framework for future extensibility ...................36
11.7. Real-world scenarios benefiting from this approach ...37
12. Transition strategy for implementations using Opaque LSAs ..37
13. IANA Considerations ........................................38
13.1. TE-compliant-SPF routers Multicast address allocation 38
13.2. New TE-LSA Types .....................................38
13.3. New TLVs (Router-TE and Link-TE TLVs) ................38
13.3.1. TE-selection-Criteria TLV (Tag ID = 1) .......38
13.3.2. MPLS-Signaling protocol TLV (Tag ID = 3) .....38
13.3.3. Constraint-SPF algorithms-Support TLV (Tag ID=4)
13.3.4. SRLG-TLV (Tag ID = 0x81) .....................38
13.3.5. BW-TLV (Tag ID = 0x82) .......................38
13.3.6. CO-TLV (Tag ID = ox83) .......................38
14. Acknowledgements ...........................................39
15. Security Considerations ....................................39
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 for state routing protocol. That makes OSPF a good candidate to adapt
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, flooding algorithm and the hierarchical organization of
areas can all be used effectively in creating and tearing traffic areas can all be used effectively in creating and tearing traffic
links on demand. The intent of the document is to build an abstract links on demand. The intent of the document is to build an abstract
view of the topology in conjunction with the traffic engineering view of the topology in conjunction with the traffic engineering
characteristics of the nodes and links involved. characteristics of the nodes and links involved.
The connectivity topology may remain relatively stable, except when The connectivity topology may remain relatively stable, except when
the existing links or networking nodes go down or flap or new nodes the existing links or networking nodes go down or flap or new nodes
and links are added to the network. The objective of traffic and links are added to the network. The objective of traffic
engineering is to set up circuit path(s) across a pair of nodes or engineering is to set up circuit path(s) across a pair of nodes or
skipping to change at page 2, line 46 skipping to change at page 4, line 14
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 traditional OSPF,
the TE extended OSPF will be used to build circuit paths, meeting the TE extended OSPF will be used to build circuit paths, meeting
certain TE criteria. The only requirement is that end-nodes and/or certain TE criteria. The only requirement is that end-nodes and/or
end-links of a circuit be identifiable with an IP address. For end-links of a circuit be identifiable with an IP address. For
non-IP networks (such as TDM or photonic cross connect networks), non-IP networks (such as TDM or photonic cross connect networks),
Mapping IP addresses to a well-known name can be done through a Mapping IP addresses to a well-known name can be done through a
DNS-like mechanism. 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 10 Opaque-LSA-based approach outlined in [OPQLSA-TE]. Section 11
compares the two approaches and outlines a strategy to transition describes the motivations behind conceiving this approach and
from Opaque-LSA based deployments to the new-TE-LSA approach why the authors claim the benefits of the approach significantly
outlined here. substantial over the opaque LSA based approach. Section 12
outlines a strategy to transition from Opaque-LSA based deployments
to the new-TE-LSA approach outlined here.
2. Traffic Engineering 2. Traffic Engineering
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
skipping to change at page 3, line 34 skipping to change at page 4, line 50
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 As for TE parameters for the circuit, this refers to the TE
parameters for all the nodes and links constituting a circuit. parameters for all the nodes and links constituting a circuit.
Typically, TE parameters for a node in a TE circuit may include Typically, TE parameters for a node in a TE circuit may include
the following. the following.
* Traffic prioritization ability, * Traffic prioritization ability,
* Ability to provision bandwidth on interfaces, * Ability to provision bandwidth on interfaces,
* Support of CSPF algorithms, * Support of CSPF algorithms,
* TE-Circuit switch type, * TE-Circuit switch type,
* Automatic protection switching. * Automatic protection switching.
TE parameters for the link include: TE parameters for the link include:
* Bandwidth availability, * Bandwidth availability,
* reliability of the link, * reliability of the link,
* color assigned to the link * color assigned to the link
* cost of bandwidth usage on the link. * cost of bandwidth usage on the link.
* membership to a Shared Risk Link Group and so on. * 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 router (or) TE-compliant OSPF router 3.1. OSPF-TE node (or) TE-compliant OSPF node
This is a router that supports the OSPF TE extensions described This is a router that supports the OSPF TE extensions described
in this document. This requires that at least one of the links in this document and at least one of the attached links support TE
attached to the router support TE extensions and, at least one of extensions. Further, this requires that at least one of the
the links attached to the router support Packet termination and attached links support Packet termination and run the OSPF-TE
run the OSPF-TE protocol. protocol.
An OSPF-TE router supports native OSPF as well as the TE An OSPF-TE node supports native OSPF as well as the TE extensions
extensions outlined here. outlined here.
3.2. Native OSPF router 3.2. Native OSPF router
A native OSPF router is an OSPF router that does not support A native OSPF router is an OSPF router that does not support
the TE extensions described in this document. An autonomous the TE extensions described in this document or does not have
system could be constituted of a combination of native OSPF a TE link attached to it. An autonomous system (AS) could be
routers and OSPF-TE routers. constituted of a combination of native-OSPF and OSPF-TE nodes.
A native OSPF router, when enhanced to include the extensions A native OSPF router, when enhanced to include the extensions
described in this document can become a OSPF-TE router. described in this document can become a OSPF-TE node.
3.3. TE nodes vs. non-TE (bormal) nodes 3.3. TE nodes vs. non-TE (native) 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. Specifically, a TE circuit
is constituted of a series of TE nodes connected to each other is constituted of a series of TE nodes connected to each other
via the TE links. via the TE links.
A non-TE node or a normal node is a node that does not have any A non-TE node or a native node is a node that does not have any
TE links attached to it and does not take part in a TE network. TE links attached to it and does not take part in a TE network.
Specifically, native OSPF-nodes that do not take part in a TE Specifically, native OSPF nodes that do not take part in a TE
network fall under this category. network fall under this category.
3.4. TE links vs. non-TE (normal) links 3.4. TE links vs. non-TE (native) 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. Specifically, a TE circuit can only be setup using
a combination of TE nodes and TE links connected to each other. a combination of TE nodes and TE links connected to each other.
Non-TE links or a normal link is one that that does not Non-TE link or a native link is one that supports IP packet
support traffic engineering. For example, native OSPF protocol communication, but does not support traffic engineering on the
and least cost criteria may be used to determine reachability link. For example, native OSPF protocol and least-cost criteria
of subnets in a network constituted of normal OSPF nodes and may be used to determine reachability of subnets in a network
normal OSPF links. constituted of native OSPF nodes and native OSPF links.
3.5. Packet interface vs. non-packet interface 3.5. Packet interface vs. non-packet interface
Interfaces on an OSPF-TE router may be characterized as those Interfaces on an OSPF-TE node may be characterized as those that
that can terminate (i.e., send and receive) IP packet data and terminate (i.e., send and receive) IP packet data and those that
those that can not. Both types of links can be part of a do not. Both types of links can be part of a traffic engineered
traffic engineered network. In contrast, a native OSPF router network. In contrast, a native OSPF router does not support
does not support non-packet interfaces. non-packet interfaces.
Needless to say, the OSPF protocol and its TE extensions can only Needless to say, the OSPF protocol and its TE extensions can only
be enabled on interfaces supporting IP packet termination. be enabled on interfaces supporting IP packet termination. While
the OSPF protocol can be run only on interfaces terminating IP
packets - the protocol can advertise link state information of
non-packet interfaces attached to it - thereby allowing for traffic
engineering over non-packet links. For example - control interfaces
can advertise link state information of the SONET interfaces on a
SONET Add-Drop Multiplexer.
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 TE 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,
skipping to change at page 6, line 5 skipping to change at page 7, line 26
3.7. TLV 3.7. TLV
A TLV, strictly stands for an object in the form of Tag-Length-Value. A TLV, strictly stands for an object in the form of Tag-Length-Value.
However, this term is also used in the document, at times, to simply However, this term is also used in the document, at times, to simply
refer a Traffic Engineering attribute of a TE-node or TE-link. refer a Traffic Engineering attribute of a TE-node or TE-link.
All TLVs are assumed to be of the following format, unless specified 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 .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .... | | .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.8. Router-TE TLVs 3.8. Router-TE TLVs
skipping to change at page 6, line 43 skipping to change at page 8, line 19
reach various subnets in the IP network with least-cost as the reach various subnets in the IP network with least-cost as the
basis. However, the goal of OSPF-TE is to determine a circuit path 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 (that can be pinned-down for a desired duration) meeting a certain
set of traffic engineering criteria. Further, the circuit path set of traffic engineering criteria. Further, the circuit path
could consist entirely of nodes and links that do not carry IP could consist entirely of nodes and links that do not carry IP
traffic. traffic.
The following assumptions are made throughout the document for The following assumptions are made throughout the document for
the discussion of OSPF-TE. the discussion of OSPF-TE.
1. Interfaces on an OSPF-TE router may be characterized as those 1. Interfaces on an OSPF-TE node may be characterized as those
that can terminate (i.e., send and receive) IP packet data and that can terminate (i.e., send and receive) IP packet data and
those that wont. Both types of links can be part of a traffic those that wont. Both types of links can be part of a traffic
engineered network. Needless to say, the OSPF-TE protocol can engineered network. Needless to say, the OSPF-TE protocol can
only be enabled on interfaces that support IP packet data only be enabled on interfaces that support IP packet data
termination. And, TE LSAs may be exchanged over non-TE links. 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 2. Unlike traditional OSPF, OSPF-TE protocol must be capable of
advertising link state of interfaces that are not capable of advertising link state of interfaces that are not capable of
handling packet data. As such, the OSPF-TE protocol cannot be handling packet data. As such, the OSPF-TE protocol cannot be
required to synchronize its link-state database with neighbors required to synchronize its link-state database with neighbors
across all its links. It is sufficient to synchronize across all its links. It is sufficient to synchronize
link-state database in an area, across a subset of the links - link-state database in an area, across a subset of the links -
say, the packet terminating interfaces. Yet, the TE LSDB say, the packet terminating interfaces. Yet, the TE LSDB
(LSA database) should be synchronized across all OSPF-TE nodes (LSA database) should be synchronized across all OSPF-TE nodes
within an area. within an area.
All interfaces or links described by the TE LSAs will be All interfaces or links described by the TE LSAs will be
present in the TE topology database (a.k.a. TE LSDB). present in the TE topology database (a.k.a. TE LSDB).
3. An OSPF-TE router with links in an OSPF area will need to 3. An OSPF-TE node with links in an OSPF area will need to
establish router adjacency with at least one other OSPF-TE establish router adjacency with at least one other neighboring
neighboring router 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 [OSPF-FL1] for flooding
optimizations. optimizations.
However, two routers that are physically connected to the same However, two routers that are physically connected to the same
link (or broadcast network) neednt be router adjacent via the link (or broadcast network) neednt be router adjacent via the
Hello protocol, if the link is not packet terminated. Hello protocol, if the link is not packet terminated.
4. Each IP subnet on a TE-configurable network MUST have a minimum 4. Each IP subnet on a TE-configurable network MUST have a minimum
skipping to change at page 7, line 46 skipping to change at page 9, line 23
An OSPF-TE node may advertise more than itself and the links An OSPF-TE node may advertise more than itself and the links
it is directly attached to. It may also advertise other TE it is directly attached to. It may also advertise other TE
participants and their links, on their behalf. participants and their links, on their behalf.
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. TE nodes may have 2 types of link state databases - a normal 6. This document does not require any changes to the existing OSPF
LSDB and a TE-LSDB. A normal LSDB, constituted of non-TE LSDB implementation. Rather, it suggests the use of another
links and nodes attached to these links(i.e., non-TE as well database, the TE-LSDB, comprised of the TE LSAs, for TE
as TE nodes), will use shortest-path criteria to forward IP purposes. TE nodes may have 2 types of link state databases -
packets over normal non-TE links. The TE-LSDB, constituted a native OSPF LSDB and a TE-LSDB. A native OSPF LSDB,
of TE nodes and TE links, may be used to setup TE circuit constituted of native links and nodes attached to these links
paths along the TE topology. (i.e., non-TE as well as TE nodes), will use shortest-path
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 5. The OSPF Options field
A new TE flag is introduced to identify TE extensions to the OSPF. A new TE flag is introduced to identify TE extensions to the OSPF.
With this, the OSPF v2 will have no more reserved bits left for With this, the OSPF v2 will have no more reserved bits left for
future option extensions. This bit will be used to distinguish future option extensions. 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 The OSPF options field is present in OSPF Hello packets, Database
Description packets and all link state advertisements. See Description packets and all link state advertisements. See
[OSPF-V2], [OSPF-NSSA] and [OPAQUE] for a description of the [OSPF-V2], [OSPF-NSSA] and [OPAQUE] for a description of the
bits in options field. Only the TE-Bit is described in this bits in options field. Only the TE-Bit is described in this
section. 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 6. 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.
skipping to change at page 9, line 40 skipping to change at page 11, line 20
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
control topology. control topology.
In the case where some of the neighbors are TE compliant and In the case where some of the neighbors are TE compliant and
others are not, the designated router will exchange different others are not, the designated router will exchange different
sets of LSAs with its neighbors. TE LSAs are exchanged only sets of LSAs with its neighbors. TE LSAs are exchanged only
with the TE neighbors. Normal LSAs do not include description with the TE neighbors. Native LSAs do not include description
for TE links. As such, normal LSAs are exchanged with all for TE links. As such, native LSAs are exchanged with all
neighbors (TE and non-TE alike) over a shared non-TE link. neighbors (TE and non-TE alike) over a shared non-TE link.
Flooding optimization in a TE network is essential Flooding optimization in a TE network is essential
for two reasons. First, the control traffic for a TE network is for two reasons. First, the control traffic for a TE network is
likely to be much higher than that of a non-TE network. Flooding likely to be much higher than that of a non-TE network. Flooding
optimizations help to minimize the announcements and the optimizations help to minimize the announcements and the
associated retransmissions and acknowledgements on the network. associated retransmissions and acknowledgements on the network.
Secondly, the TE nodes need to converge at the earliest to keep Secondly, the TE nodes need to converge at the earliest to keep
up with TE state changes occuring throughout the TE network. up with TE state changes occurring throughout the TE network.
This process of flooding along a TE topology cannot be folded This process of flooding along a TE topology cannot be folded
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
skipping to change at page 11, line 22 skipping to change at page 13, line 5
broadcast and NBMA networks the Designated Router and the broadcast and NBMA networks the Designated Router and the
Backup Designated Router may maintain two sets of adjacency. Backup Designated Router may maintain two sets of adjacency.
However, the remaining routers will participate in either However, the remaining routers will participate in either
TE-compliant adjacency or non-TE-compliant adjacency, but not TE-compliant adjacency or non-TE-compliant adjacency, but not
both. In the Broadcast network below, you will notice that both. In the Broadcast network below, you will notice that
routers RT7 and RT3 are chosen as the designated and backup routers RT7 and RT3 are chosen as the designated and backup
routers respectively. Within the network, Routers RT3, RT4 routers respectively. Within the network, Routers RT3, RT4
and RT7 are TE-compliant. RT5 and RT6 are not. So, you will and RT7 are TE-compliant. RT5 and RT6 are not. So, you will
notice the adjacency variation with RT4 vs. RT5 or RT6. notice the adjacency variation with RT4 vs. RT5 or RT6.
+---+ +---+ +---+ +---+
|RT1|------------|RT2| o---------------o |RT1|------------|RT2| o---------------o
+---+ N1 +---+ RT1 RT2 +---+ N1 +---+ RT1 RT2
RT7 RT7
o:::::::::: o::::::::::
+---+ +---+ +---+ /|: : +---+ +---+ +---+ /|: :
|RT7| |RT3| |RT4| / | : : |RT7| |RT3| |RT4| / | : :
+---+ +---+ +---+ / | : : +---+ +---+ +---+ / | : :
| | | / | : : | | | / | : :
+-----------------------+ 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. New TE LSAs 7. TE LSAs
The native OSPF protocol has a total of 11 LSA types. Definitions The native OSPF protocol, as of now, has a total of 11 LSA types.
for LSA types 1 through 5 may be found in [OSPF-v2]. LSA type 6 is LSA types 1 through 5 are defined in [OSPF-v2]. LSA types 6, 7
defined in [MOSPF]. LSA type 7 definition may be found in [NSSA]. and 8 are defined in [MOSPF], [NSSA] and [BGP-OSPF] respectively.
LSA type 8 may be found in [BGP-OSPF]. Lastly, LSA types 9 through Lastly, LSA types 9 through 11 are defined in [OPAQUE].
11 are defined in [OPAQUE].
Each of the LSA types defined are different in content and flooding Each of the LSA types have a unique flooding scope defined.
scope. For instance, Opaque LSA types 9 through 11 are general Opaque LSA types 9 through 11 are general purpose LSAs, with
purpose LSAs, with flooding scope set to link-local, area-local and flooding scope set to link-local, area-local and AS-wide (except
AS-wide (except into stub areas) respectively. As will become stub areas) respectively. As will become apparent from this
apparent soon, the boundaries for Opaque LSAs are not appropriate document, the general purpose content format and the coarse
for flooding TE data. flooding scope of Opaque LSAs are not suitable for disseminating
TE data.
In the following subsections, we define new LSAs for Traffic In the following subsections, we define new LSAs for Traffic
engineering use. The new TE LSAs are largely modeled after the engineering use. The Values for the new TE LSA types are assigned
existing LSAs for content format and flooding scope. The LSA types such that the high bit of the LS-type octet is set to 1. The new
are assigned such that the high bit of the LS-type octet is set TE LSAs are largely modeled after the existing LSAs for content
to 1. Standard link-state database flooding mechanisms (with format and have a custom suited flooding scope. Flooding
optimizations discussed in previous sections) are used for optimizations discussed in previous sections shall be used to
distribution of TE LSAs along the TE-restricted topology. The disseminate TE LSAs along the TE-restricted topology.
flooding scope is also defined for each of the newly defined TE
LSAs. A TE-router LSA is defined to advertise TE characteristics
of the router and all the TE-links attached to the TE-router.
TE-Link-Update LSA is defined to advertise individual link
specific TE updates. Flooding scope for both these LSAs is the
TE topology within the area to which the links belong. I.e.,
only those OSPF nodes within the area with TE links will receive
these TE LSAs.
TE-Summary network and router LSAs are defined to advertise
the reachability of area-specific TE networks and Area border
routers(along with router TE characteristics) to external
areas. Flooding Scope of the TE-Summary LSAs is the TE topology
in the entire AS less the non-backbone area for which the
the advertising router is an ABR. Just as with native OSPF
summary LSAs, the TE-summary LSAs do not reveal the topological
details of an area to external areas. But, the two summary LSAs
do differ in some respects. The flooding scope of TE summary
LSAs is different. As for content, TE summary network LSAs
simply describe reachability without summarization of network
access costs. And, unlike the native summary router LSA,
TE-summary router LSA content includes TE capabilities of the
advertising TE router.
TE-AS-external LSA and TE-Circuit-Path LSA are defined to
advertise AS external network reachability and pre-engineered
TE circuits respectively. While flooding scope for both
these LSAs can be the TE-topology in the entire AS, flooding
scope for the pre-engineered TE circuit LSA may optionally be
restricted to just the TE topology within an area.
Lastly, the new TE LSAs are defined so as to permit peer
operation of packet networks and non-packet networks alike.
As such, a new TE-Router-Proxy LSA is defined to allow
advertisement of a TE router, that is not OSPF capable, by
an OSPF-TE node as a proxy.
7.1. TE-Router LSA 7.1. TE-Router LSA
Router LSAs are Type 1 LSAs. The TE-router LSA is modeled after the Router LSAs are Type 1 LSAs. The TE-router LSA is modeled after the
router LSA with the same flooding scope as the router-LSA, except router LSA with the same flooding scope as the router-LSA, except
that the scope is further restricted to TE-only nodes within the that the scope is further restricted to TE-only nodes within the
area. A value of 0x81 is assigned to TE-router LSA. The TE-router area. A value of 0x81 is assigned to TE-router LSA. The TE-router
LSA describes the router-TE metrics as well as the link-TE metrics LSA describes the router-TE metrics as well as the link-TE metrics
of the TE links attached to the router. Below is the format of the of the TE links attached to the router. Below is the format of the
TE-router LSA. Unless specified explicitly otherwise, the fields TE-router LSA. Unless specified explicitly otherwise, the fields
carry the same meaning as they do in a router LSA. Only the carry the same meaning as they do in a router LSA. Only the
differences are explained below. differences are explained below.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number | | LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length | | LS checksum | length |
skipping to change at page 13, line 25 skipping to change at page 15, line 39
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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-compliance bit is set to 1.
Router-TE flags field (TE capabilities of the router node) Router-TE flags field (TE capabilities of the router node)
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|
|R|R|C|M|C|C| |A|L|G|P| |R|R|C|M|C|C| |A|L|G|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|<---- Boolean TE flags ------->|<- TE flags pointing to TLVs ->| |<---- Boolean TE flags ------->|<- TE flags pointing to TLVs ->|
Bit LSR Bit LSR
When set, the router is considered to have LSR capability. When set, the router is considered to have LSR capability.
Bit LER Bit LER
When set, the router is considered to have LER capability. When set, the router is considered to have LER capability.
All MPLS border routers will be required to have the LER All MPLS border routers will be required to have the LER
capability. When the E bit is also set, that indicates an capability. When the E bit is also set, that indicates an
AS Boundary router with LER capability. When the B bit is AS Boundary router with LER capability. When the B bit is
also set, that indicates an area border router with LER also set, that indicates an area border router with LER
capability. capability.
Bit PSC Bit PSC
Indicates the node is Packet Switch Capable. Indicates the node is Packet Switch Capable.
Bit TDM Bit TDM
Indicates the node is TDM circuit switch capable. Indicates the node is TDM circuit switch capable.
Bit LSC Bit LSC
Indicates the node is Lamda switch Capable. Indicates the node is Lamda switch Capable.
Bit FSC Bit FSC
Indicates the node is Fibre (can also be a non-fibre link Indicates the node is Fiber (can also be a non-fiber link
type) switch capable. type) switch capable.
Bit STA Bit STA
Label Stack Depth limit TLV follows. This is applicable only Label Stack Depth limit TLV follows. This is applicable only
when the PSC flag is set. when the PSC flag is set.
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 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)
- Backup LSP (3) - Backup LSP (3)
- Link cost (4) - Link cost (4)
Bandwidth criteria is often used in conjunction with Packet Bandwidth criteria is often used in conjunction with Packet
Switch Capable nodes. The unit of bandwidth permitted to be Switch Capable nodes. The unit of bandwidth permitted to be
configured may however vary from vendor to vendor. Bandwidth configured may however vary from vendor to vendor. Bandwidth
criteria may also be used in conjunction with TDM nodes. Once criteria may also be used in conjunction with TDM nodes. Once
again, the granularity of bandwidth allocation may vary from again, the granularity of bandwidth allocation may vary from
vendor to vendor. vendor to vendor.
Priority based traffic switching is relevant only to Packet Priority based traffic switching is relevant only to Packet
Switch Capable nodes. Nodes supporting this criteria will Switch Capable nodes. Nodes supporting this criteria will
be able to interpret the EXP bits on the MPLS header to be able to interpret the EXP bits on the MPLS header to
prioritize the traffic across the same LSP. prioritize the traffic across the same LSP.
Backup criteria refers to whether or not the node is capable Backup criteria refers to whether or not the node is capable
of finding automatic protection path in the case the of finding automatic protection path in the case the
originally selected link fails. Such a local recovery is originally selected link fails. Such a local recovery is
specific to the node and may not need to be notified to the specific to the node and may not need to be notified to the
upstream node. upstream node.
MPLS-Signaling protocol TLV (Tag ID = 3) MPLS-Signaling protocol TLV (Tag ID = 3)
The value can be 2 bytes long, listing a combination of The value can be 2 bytes long, listing a combination of
RSVP-TE, CR-LDP and LDP. RSVP-TE, CR-LDP and LDP.
Constraint-SPF algorithms-Support TLV (Tag ID = 4) Constraint-SPF algorithms-Support TLV (Tag ID = 4)
List all the CSPF algorithms supported. Support for CSPF List all the CSPF algorithms supported. Support for CSPF
algorithms on a node is an indication that the node may be algorithms on a node is an indication that the node may be
requested for all or partial circuit path selection during requested for all or partial circuit path selection during
circuit setup time. Further, the CSPF algorithm support on circuit setup time. This can be beneficial in knowing
an intermediate node can be beneficial when the node whether or not the node is capable of expanding loose
terminates one or more of the hierarchical LSP tunnels. routes (in an MPLS signaling request) into an LSP. Further,
the CSPF algorithm support on an intermediate node can be
beneficial when the node terminates one or more of the
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., The following fields are used to describe each router link (i.e.,
interface). Each router link is typed (see the below Type field). interface). Each router link is typed (see the below Type field).
The Type field indicates the kind of link being described. The Type field indicates the kind of link being described.
Type Type
A new link type "Positional-Ring Type" (value 5) is defined. A new link type "Positional-Ring Type" (value 5) is defined.
This is essentially a connection to a TDM-Ring. TDM ring network This is essentially a connection to a TDM-Ring. TDM ring network
is different from LAN/NBMA transit network in that, nodes on the is different from LAN/NBMA transit network in that, nodes on the
TDM ring donot necessarily have a terminating path between TDM ring donot necessarily have a terminating path between
themselves. Secondly, the order of links is important in themselves. Secondly, the order of links is important in
determining the circuit path. Third, the protection switching determining the circuit path. Third, the protection switching
and the number of fibers from a node going into a ring are and the number of fibers from a node going into a ring are
determined by the ring characteristics. I.e., 2-fibre vs determined by the ring characteristics. I.e., 2-fiber vs
4-fibre ring and UPSR vs BLSR protected ring. 4-fiber ring and UPSR vs BLSR protected ring.
Type Description Type Description
__________________________________________________ __________________________________________________
1 Point-to-point connection to another router 1 Point-to-point connection to another router
2 Connection to a transit network 2 Connection to a transit network
3 Connection to a stub network 3 Connection to a stub network
4 Virtual link 4 Virtual link
5 Positional-Ring Type. 5 Positional-Ring Type.
Link ID Link ID
Identifies the object that this router link connects to. Identifies the object that this router link connects to.
Value depends on the link's Type. For a positional-ring type, 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 the Link ID shall be IP Network/Subnet number, just as with a
broadcast transit network. The following table summarizes the broadcast transit network. The following table summarizes the
updated Link ID values. updated Link ID values.
Type Link ID Type Link ID
______________________________________ ______________________________________
1 Neighboring router's Router ID 1 Neighboring router's Router ID
2 IP address of Designated Router 2 IP address of Designated Router
3 IP network/subnet number 3 IP network/subnet number
4 Neighboring router's Router ID 4 Neighboring router's Router ID
5 IP network/subnet number 5 IP network/subnet number
Link Data Link Data
This depends on the link's Type field. For type-5 links, this This depends on the link's Type field. For type-5 links, this
specifies the router interface's IP address. specifies the router interface's IP address.
Link-TE options (TE capabilities of a link) 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.
NTE - Indicates whether non-TE traffic is permitted on the NTE - Indicates whether non-TE traffic is permitted on the
TE link. This flag is relevant only when the TE TE link. This flag is relevant only when the TE
flag is set. flag is set.
PKT - Indicates whether or not the link is capable of PKT - Indicates whether or not the link is capable of
packet termination. packet termination.
TDM, LSC, FSC bits TDM, LSC, FSC bits
- Same as defined for router TE options. - Same as defined for router TE options.
DBS - Indicates whether or not Database synchronization DBS - Indicates whether or not Database synchronization
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 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.
LUG-TLV LUG-TLV
This indicates the link usage cost - Bandwidth unit, Unit This indicates the link usage cost - Bandwidth unit, Unit
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 LSAs 7.2. Changes to Network LSA
Network-LSAs are the Type 2 LSAs. With the exception of the Network-LSA is the Type 2 LSA. With the exception of the following,
following, no additional changes will be required to this LSA no additional changes will be required to this LSA for TE
for TE compatibility. The LSA format and flooding scope compatibility. The LSA format and flooding scope remains unchanged.
remains unchanged.
A network-LSA is originated for each broadcast, NBMA and A network-LSA is originated for each broadcast, NBMA and
Positional-Ring type network in the area which supports two or Positional-Ring type network in the area which supports two or
more routers. The TE option is also required to be set while more routers. The TE option is also required to be set while
propagating the TDM network LSA. propagating the TDM network LSA.
7.2.1. Positional-Ring type network LSA - New Network type for TDM-ring. 7.2.1. Positional-Ring type network LSA - New Network type for TDM-ring.
- Ring ID: (Network Address/Mask) - Ring ID: (Network Address/Mask)
- No. of elements in the ring (a.k.a. ring neighbors) - No. of elements in the ring (a.k.a. ring neighbors)
- Ring Bandwidth - Ring Bandwidth
- Ring Protection (UPSR/BLSR) - Ring Protection (UPSR/BLSR)
- ID of individual nodes (Interface IP address) - ID of individual nodes (Interface IP address)
- Ring type (2-Fibre vs. 4-Fibre, SONET vs. SDH) - Ring type (2-Fiber vs. 4-Fiber, SONET vs. SDH)
Network LSA will be required for SONET RING. Unlike the broadcast Network LSA will be required for SONET RING. Unlike the broadcast
type, the sequence in which the NEs are placed on a RING-network 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, is pertinent. The nodes in the ting must be described clock wise,
assuming the GNE as the starting element. assuming the GNE as the starting element.
7.3. TE-Summary LSAs 7.3. 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)
skipping to change at page 18, line 49 skipping to change at page 21, line 17
non-backbone area is readvertised to all other areas, not just non-backbone area is readvertised to all other areas, not just
the backbone area. The area border router for each the backbone area. The area border router for each
non-backbone area is responsible for advertising the non-backbone area is responsible for advertising the
reachability of backbone networks into the area. reachability of backbone networks into the area.
The flooding scope of TE-summary network LSA is unlike that The flooding scope of TE-summary network LSA is unlike that
of the summary network LSA (type 0x03), which simply uses this of the summary network LSA (type 0x03), which simply uses this
as an inter-area exchange of network accessibility and limits as an inter-area exchange of network accessibility and limits
the flooding scope to just the backbone area. the flooding scope to just the backbone area.
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 |
skipping to change at page 19, line 30 skipping to change at page 21, line 44
7.3.2. TE-Summary router LSA (0x84) 7.3.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 entire AS, with the exception of the non-backbone areas the
advertising ABRs belong 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number | | LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length | | LS checksum | length |
skipping to change at page 20, line 31 skipping to change at page 22, line 47
Specifies the OSPF area(s) the link state ID belongs to. When Specifies the OSPF area(s) the link state ID belongs to. When
the link state ID is same as the advertising router ID, this the link state ID is same as the advertising router ID, this
lists all the areas the ABR belongs to. In the case the lists all the areas the ABR belongs to. In the case the
link state ID is an ASBR, this simply lists the area the link state ID is an ASBR, this simply lists the area the
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) 7.4. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number | | LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length | | LS checksum | length |
skipping to change at page 21, line 41 skipping to change at page 24, line 10
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE-Forwarding address | | TE-Forwarding address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| External Route TE Tag | | External Route TE Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
Network Mask Network Mask
The IP address mask for the advertised TE destination. For The IP address mask for the advertised TE destination. For
example, this can be used to specify access to a specific example, this can be used to specify access to a specific
TE-node or TE-link with an mask of 0xffffffff. This can also TE-node or TE-link with an mask of 0xffffffff. This can also
be used to specify access to an aggregated set of destinations be used to specify access to an aggregated set of destinations
using a different mask, ex: 0xff000000. using a different mask, ex: 0xff000000.
Link-TE flags, Link-TE flags,
Link-TE TLVs Link-TE TLVs
The TE attributes of this route. These fields are optional and The TE attributes of this route. These fields are optional and
are provided only when one or more pre-engineered circuits can are provided only when one or more pre-engineered circuits can
be specified with the advertisement. Without these fields, be specified with the advertisement. Without these fields,
the LSA will simply state TE reachability info. the LSA will simply state TE reachability info.
Forwarding address Forwarding address
Data traffic for the advertised destination will be forwarded to Data traffic for the advertised destination will be forwarded to
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) 7.5. TE-Circuit-paths LSA (0x8C)
TE-Circuit-paths LSA may be used to advertise the availability of TE-Circuit-paths LSA may be used to advertise the availability of
pre-engineered TE circuit path(s) originating from any router in pre-engineered TE circuit path(s) originating from any router in
the network. The flooding scope may be Area wide or AS wide. the network. The flooding scope may be Area wide or AS wide.
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 | | Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number | | LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length | | LS checksum | length |
skipping to change at page 23, line 13 skipping to change at page 25, line 29
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
Link State ID Link State ID
The ID of the router to which the TE circuit path(s) is being The ID of the router to which the TE circuit path(s) is being
advertised. advertised.
TE-circuit-path(s) flags TE-circuit-path(s) flags
Bit S - When set, the flooding scope is set to be AS wide. Bit S - When set, the flooding scope is set to be AS wide.
Otherwise, the flooding scope is set to be area wide. Otherwise, the flooding scope is set to be area wide.
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 border Bit B - When set, the advertised Link state ID is an Area border
router (B is for Border) router (B is for Border)
No. of Virtual TE Links No. of Virtual TE Links
This indicates the number of pre-engineered TE links between the This indicates the number of pre-engineered TE links between the
advertising router and the router specified in the link state ID. advertising router and the router specified in the link state ID.
TE-Link ID TE-Link ID
This is the ID by which to identify the virtual link on the This is the ID by which to identify the virtual link on the
advertising router. This can be any private interface index or advertising router. This can be any private interface index or
handle that the advertising router uses to identify the handle that the advertising router uses to identify the
pre-engineered TE virtual link to the ABR/ASBR. pre-engineered TE virtual link to the ABR/ASBR.
TE-Link Data TE-Link Data
This specifies the IP address of the physical interface This specifies the IP address of the physical interface
on the advertising router. on the advertising router.
7.6. TE-Link-Update LSA (0x8d) 7.6. TE-Link-Update LSA (0x8d)
A significant difference between a non-TE OSPF network and a TE OSPF 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 network is that the latter is subject to dynamic circuit pinning and
is more likely to undergo state updates. Specifically, some links is more likely to undergo state updates. Specifically, some links
might undergo more changes and more frequently than others. might undergo more changes and more frequently than others.
Advertising the entire TE-router LSA in response to a change in any Advertising the entire TE-router LSA in response to a change in any
single link could be repetitive. Flooding the network with TE-router single link could be repetitive. Flooding the network with TE-router
LSAs at the aggregated speed of all the dynamic changes is simply LSAs at the aggregated speed of all the dynamic changes is simply
skipping to change at page 24, line 12 skipping to change at page 26, line 28
state is changed. The TE-link sequence is largely the advertisement 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 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 incremented with the TE-router LSA's sequence as the basis. When an
updated TE-router LSA is advertised within 30 minutes of the updated TE-router LSA is advertised within 30 minutes of the
previous advertisement, the updated TE-router LSA will assume a previous advertisement, the updated TE-router LSA will assume a
sequence no. that is larger than the most frequently updated of sequence no. that is larger than the most frequently updated of
its links. its links.
Below is the format of the TE-link update LSA. Below is the format of the TE-link update LSA.
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 | 0x8d | | LS age | Options | 0x8d |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID (same as Link ID) | | Link State ID (same as Link ID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router | | Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number | | LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length | | LS checksum | length |
skipping to change at page 25, line 20 skipping to change at page 27, line 36
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 donot 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID (Router ID of the TE Network Element) | | Link State ID (Router ID of the TE Network Element) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router | | Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number | | LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length | | LS checksum | length |
skipping to change at page 26, line 8 skipping to change at page 28, line 24
| 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. Abstract topology representation with TE support 8. Link State Databases
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
to reach native and TE networks. The TE LSA updates will not impact
non-TE nodes RT4 and RT5.
9. 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 27, line 49 skipping to change at page 32, line 49
|reachability | +---------+ +-------------+ |reachability | +---------+ +-------------+
|from ASBR-S1 | | | | |from ASBR-S1 | | | |
+-------------+ | | | +-------------+ | | |
+-----------------+ +-------------+ +-----------------+ +-----------------+ +-------------+ +-----------------+
|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 8: Inter-Area Abstraction as viewed by Area-1 TE-routers Figure 9: Inter-Area Abstraction as viewed by Area-1 TE-routers
9. Changes to Data structures in OSPF-TE routers 10. Changes to Data structures in OSPF-TE nodes
9.1. Changes to Router data structure 10.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.
9.2. Two set of Neighbors 10.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-neighbors set is used to advertise TE LSAs. Only the TE-nodes
TE-routers will be members of the TE-neighbor set. will be members of the TE-neighbor set. Native neighbors set will
Normal neighbors set will be used to advertise native LSAs. All be used to advertise native LSAs. All neighboring nodes supporting
neighboring nodes supporting non-TE links canbe part of this non-TE links can be part of this set. As for flooding optimizations
set. As for flooding optimizations based on neighbors set, based on neighbors set, readers may refer [OSPF-FL1].
readers may refer [OSPF-FL1].
9.3. Changes to Interface data structure 10.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 [OSPF-FL1].
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 donot permit non-TE traffic on
TE links alos, 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
enabled for OSPF. However, it is possible to set this to FALSE enabled for OSPF. However, it is possible to set this to FALSE
skipping to change at page 29, line 27 skipping to change at page 34, 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.
10. Comparison between Opaque-LSAs & the new TE-LSAs 11. Motivations to this approach
The following subsections attempt to identify the various issues Use of TE LSAs bring substantial benefits over using Opaque LSAs
such as flooding scope and scalability that are fundamentally as described below. These benefits cannot be retrofitted into
lacking in the Opage-LSA based approach. Section 10.2 goes on to Opaque LSAs due to fundamental scalability limitations of the
describe a transition strategy to eventually transition completely Opaque-LSA approach.
to the new TE-LSA scheme.
Once the OSPF-TE is completely transitioned to the scheme The primary motivation behind the TE-LSA model is that the
described in this document, the packet and non-packet networks approach is clean (clean separation of LSDB between TE vs non-TE
can be combined and issued addresses across the unified network. networks), scalable (across more than one OSPF area), unified
As such, the traffic engineering can be based on the overlayed or (for packet and non-packet networks alike), efficient (efficient
the peer model espoused in [GMPLS-TE]. flooding algorithm) and SLA enforceable. The model proposed also
provides the right framework for future enhancements.
10.1. TE flooding load on a non-TE network 11.1. TE flooding isolated to TE-only nodes
In a non-TE network, when a link is flapping, that can cause A TE network can generate a large number of LSA updates due
considerable hardship on all routers in the area. The hardship is to the many state changes the TE links undergo dynamically. For
not so much because of the LSAs that are generated, but because example, bandwidth assignment on a TE link for a specific circuit
that causes the OSPF routing table to be recalculated. 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).
A TE network can also have a large number of LSA updates due to The wider the flooding scope (and number of TE nodes), the larger
the many state changes the TE links undergo dynamically. These the number of retransmissions and acknowledgements. The same
LSA updates are neither infrequent nor undesirable as with link information (needed or not) may reach a router through multiple
flaps. 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.
Now, consider the case where Opaque LSAs are used for TE The flooding topology for opaque LSAs makes no distinction between
extensions. The flooding topology for opaque LSAs makes no TE and native OSPF nodes. In a network where the TE and native
distinction between TE nodes and non-TE nodes. In a network nodes coexist, a native OSPF router would be bombarded with opaque
where the TE and non-TE nodes coexist, a non-TE router would be LSAs. It is possible for the native OSPF nodes to silently ignore
bombarded with Opaque LSAs. 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.
These Opaque LSAs carry TE metric state changes, which the non-TE 11.2. Clean separation between native and TE LSDBs
router does not care about. If the router simply dropped the opaque
LSAs and didnt recompute the dijkstra, that might be OK. But, it
may be that some routers will recompute routes (because they process
some of the Opaque LSAs that say that a particular link is no longer
available for non-TE use). In the latter case, the routers might
choose to simply recompute for all new Opaque LSA advertisements.
Clearly, that would be a considerable computational demand and
cause for instability on non-TE routers, triggered by the frequent
opaque LSA advertisements.
Secondly, If the TE and non-TE topologies are not separated (as is Most vendors wishing to support MPLS based TE in their network
the case with Opaque-LSAs), the non-TE router could be utilizing the tend to migrate gradually to support the TE extensions. Perhaps,
TE link as its least cost link, thereby stressing the TE link and add new TE links or convert existing links into TE links within
effectively rendering the TE link ineffective for TE purposes. an area first and progressively advance to offer in the entire
Separating the two topologies (as advocated by this document with AS. As such, the TE network cannot be assumed to exist
new TE LSAs and TE option flag) ensure that the SLA objectives on independently without native OSPF network even in the long term.
TE links are properly met.
Thirdly, the wider the flooding scope, the larger the number of Not all routers will support TE extensions at the same time
retransmissions and acknowledgements. The same information or during the migration process. Use of TE specific LSAs and their
sometimes unneeded information may reach a router through multiple flooding to OSPF-TE only nodes will allow the vendor to
links. Even if the router didnt forward the information past the introduce MPLS TE without destabilizing the existing network.
time, it would still have to send acknowledgements across all the As such, the native OSPF-LSDB will remain undisturbed while
multiple links on which the LSAs tried to converge. By moving the newer TE links are added to network.
concept of flooding from "per interface" to "per neighbor", we
minimize the flooding, without compromising on the untimate goal
of LSDB convergence for TE and non-TE networks.
Lastly, separating TE and non-TE topologies is beneficial in With the new TE-LSA scheme, native OSPF nodes will keep just the
inter-area communication. When the topologies are separate, the native OSPF link state database. The OSPF-TE nodes will keep
area border routers can advertise different summary LSAs for TE and native as well as the TE LSDB. The native LSDB describes the
non-TE routers. Opaque LSAs are not adequate to establish control (non-TE) topology. Shortest-Path-First algorithm will be
TE peering relationship with the neighbors. used to forward IP packets along this network. OSPF neighbors
data structure will be used for flooding along the control
topology.
For example, a non-TE Area Border router (ABR) could simply announce In the Opaque-LSA-based TE scheme, the TE-LSDB built using opaque
the non-TE-network summary LSAs (LSA type 3) for non-TE networks LSAs will be required to refer the native LSDB to build the TE
outside the area. A TE ABR, on the other hand, could advertise topology. Even with that, there is way to know the TE capabilities
just the TE-network summary LSAs (0x83). Clearly, the advertised of the routers. The Opaque-LSA approach does not deal with TE
data is different. The boundary of TE-network summary LSA flooding capabilities for a router. Opaque LSAs are flooded to all nodes.
is also different. The flooding boundary for TE-summary LSAs would Some nodes that happen to support the TE extensions will have a
be (AS - OriginatingArea - StubAreas - NSSAs). Clearly, the hit and accept the opaque LSAs. Others that donot support will
Opaque-LSA flooding boundary will not permit this type of flooding have a miss and simply drop the received Opaque LSAs. This type of
granularity. Without an AS-wide flooding (with the exception of stub hit-and-miss approach is not only disruptive, but also blind to
areas), it is impossible to know which outside-are networks are SLA requirements on TE links.
TE-configurable and which are not.
In summary, lack of flexible flooding topology can be an operational 11.3. Scalability across a hierarchical Area topology
and functional nightmare. Folks will be forced to an unscalable,
single-area topology to get around the shortcoming of the opaque
LSAs.
10.2. Scaling concerns What is lacking in Opaque-LSA-based TE scheme? 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.
The Opaque LSA based mechanism has the following fundamental scaling Providing area level abstraction and having this abstraction be
problems. These cannot be fixed by mere extensions to the same distinct for TE and native topologies is a necessity in inter-area
approach. We suggest below a transition strategy to migrate to the communication. When the topologies are separate, the area border
scheme proposed in this document. 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).
1. The flooding boundaries of Opaque LSAs make the OSPF-TE suitable Opaque-LSAs are suitable neither for content nor for flooding scope
at best to single-area topologies. Extending TE beyond one area in the context of inter-area communication. The flooding boundaries
can cause a lot of flooding problems. e.g.: Opaque LSAs cannot of Opaque LSAs make the approach suitable at best to single-area
support the flooding scope of TE-summary-networks. topologies. For example, Opaque LSAs cannot support the flooding
Opaque LSAs (AS-wide scope) will be unable to restrict flooding scope of TE-summary-networks. Opaque LSAs (AS-wide scope) will be
in its own originating area. unable to restrict flooding in its own originating area.
Opaque LSAs are also not adequate to establish TE peering
relationship with neighbors.
2. The Opaque LSA is also restricted in the way it can express 11.4. Usable across packet and non-packet TE networks
different types of data. Everything should be expressible in
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. 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 In a peer networking TE model, you are likely to want different
abstraction. A single Opaque LSA type is bent in many types of TE information flooded by various nodes, as they are
ways (using a variety of TLVs) to update the native OSPF topology heterogenous and will remain that way. The TE LSA based approach
abstraction nodes. 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.
One way to transition from the current Opaque-LSA-based TE scheme to Implementations reusing the opaque LSA with GMPLS extensions
the new-TE scheme could be as follows. 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).
1. Use the existing Opaque-LSA-based-TE scheme for single area 11.5. SLA enforceable network modeling
topologies. You will still need to find a way that a non-TE
router doesnt cannibalize a TE-link for SPF forwarding.
2. Fold in the TE option flag to construct the TE and non-TE When TE and native topologies are not separated (as is the case
topologies in an area, even if the topologies cannot be used with Opaque-LSAs), a native OSPF node could be utilizing a TE
for flooding within the area. 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.
3. Do away with Opaque LSAs for inter-area communication. Make use 11.6. Framework for future extensibility
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. Use new LS types
for summary LSAs, AS-external-LSAs and so forth, as specified
in this document.
4. Replace the use of Opaque LSAs with the TE LSAs within the area The approach outlined provides a framework for future
as well. extensibility based on service provider needs.
10.3. Link State Database. 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.
With the new TE-LSA scheme, a TE node will have two types of Having a clean framework which argues for having different
Link state databases. The normal LSDB describes the control link state databases for different applications on the same network
(non-TE) topology. Shortest-Path-First algorithm will be used to will provide the right forum for future extensibility. Just as
forward IP packets along this network. OSPF neighbors data the TE LSDB may be used for MPLS TE application, a different type
structure will be used for flooding along the control topology. of LSDB may be used for yet another type of application (such as
QOS based IP forwarding) using the same IP network.
The TE node will have a separate TE-LSDB that describes the TE lastly, an opaque LSA is restricted in the format in which it can
topology, constituted only of TE nodes and TE links. A variety of express different types of data. Everything should be expressible
CSPF algorithms may be used to dynamically setup TE circuit paths in the form of a TLV. Summary-TE-networks-from each Area, TE-ABR
along this TE network. TE-neighbors data structure is used for routers, TE-ASBR routers, TE-AS-External-networks, TE-Router
flooding TE LSAs alongs the TE-only topology. Having a clear Capabilities, TE-link updates, Pre-engineered-TE-Links - All of
distinction between the two LSDBs (and hence topologies) makes these data have to be engineered to be expressible in a TLV form
this approach more desirable to service providers desiring to with one or more sub-TLVs. Some of the TLVs will be required to
offer strictly enforceable SLAs (Service Level Agreements) be mandatory. Some would be expected to appear in a pre-specified
along their TE topology. 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.
Whereas, in the Opaque-LSA-based TE scheme, the TE-LSDB built Opaque LSAs demand more processing to assimilate into topology
using opaque LSAs will be required to refer the normal LSDB to abstraction. A single Opaque LSA type is bent in many
build the TE topology. Even with that, there is way to know the ways (using a variety of TLVs) to update the native OSPF topology
TE capabilities of the routers. The Opaque-LSA approach does abstraction nodes. Not a framework that could be easily extended
not deal with TE capabilities for a router. Opaque LSAs for future applications.
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 the SLA requirements
on TE links.
10.4. Real-world scenarios better served by the new-TE-LSAs scheme. 11.7. Real-world scenarios benefiting from this approach
Many real-world scenarios are better served by the new-TE-LSAs Many real-world scenarios are better served by the new-TE-LSAs
scheme. Here are a few examples. scheme. Here are a few examples.
1. Multi-area network. 1. Multi-area network.
2. Single-Area networks - The TE links are not cannibalized by the 2. Single-Area networks - The TE links are not cannibalized by the
non-TE routers for SPF forwarding. non-TE routers for SPF forwarding.
3. Credible SLA enforcement in a (TE + non-TE) packet network. 3. Credible SLA enforcement in a (TE + non-TE) packet network.
Ability to restrict flooding to some links (say, non-TE links) Ability to restrict flooding to some links (say, non-TE links)
ensures the service provider is able to devote the entire ensures the service provider is able to devote the entire
bandwidth of a TE-link for TE circuit purposes. This makes SLA bandwidth of a TE-link for TE circuit purposes. This makes SLA
enforcement credible. enforcement credible.
4. For a non-Packet TE network, the Opaque-LSA-based-TE scheme is 4. For a non-Packet TE network, the Opaque-LSA-based-TE scheme is
not adequate to represent not adequate to represent
(a) "Positional-Ring" type network LSA and (a) "Positional-Ring" type network LSA and
(b) Router Proxying - allowing a router to advertise on behalf (b) Router Proxying - allowing a router to advertise on behalf
of other nodes (that are not Packet/OSPF capable). of other nodes (that are not Packet/OSPF capable).
11. IANA Considerations 12. Transition strategy for implementations using Opaque LSAs
11.1. All-TE-compliant-SPF routers Multicast address allocation 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].
11.2. New TE-LSA Types 1. Restrict the use of Opaque-LSAs for within an area.
11.3. New TLVs (Router-TE and Link-TE TLVs) 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.
11.3.1. TE-selection-Criteria TLV (Tag ID = 1) 3. Use TE-Summary LSAs and AS-external-LSAs for inter-area
- Bandwidth based LSPs (1) Communication. Make use of the TE-topology within area to
- Priority based LSPs (2) summarize the TE networks in the area and advertise the same
- Backup LSP (3) to all TE-routers in the backbone. The TE-ABRs on the backbone
- Link cost (4) area will in-turn advertise these summaries again within their
connected areas.
11.3.2. MPLS-Signaling protocol TLV (Tag ID = 3) 4. Replace Opaque LSAs with TE LSAs within the area as well.
- RSVP-TE signaling
- LDP signaling
- CR-LDP signaling
11.3.3. Constraint-SPF algorithms-Support TLV (Tag ID = 4) 13. IANA Considerations
- CSPF Algorithm Codes.
11.3.4. SRLG-TLV (Tag ID = 0x81) 13.1. TE-compliant-SPF routers Multicast address allocation
- SRLG group IDs
11.3.5. BW-TLV (Tag ID = 0x82) 13.2. New TE-LSA Types
11.3.6 CO-TLV (Tag ID = ox83) 13.3. New TLVs (Router-TE and Link-TE TLVs)
12. Security Considerations 13.3.1. TE-selection-Criteria TLV (Tag ID = 1)
- Bandwidth based LSPs (1)
- Priority based LSPs (2)
- Backup LSP (3)
- Link cost (4)
This memo does not create any new security issues for the OSPF 13.3.2. MPLS-Signaling protocol TLV (Tag ID = 3)
protocol. Security considerations for the base OSPF protocol are - RSVP-TE signaling
covered in [OSPF-v2]. As a general rule, a TE network is likely - LDP signaling
to generate significantly more control traffic than a native - CR-LDP signaling
OSPF network. The excess traffic is almost directly proportional
to the rate at which TE circuits are setup and torn down within 13.3.3. Constraint-SPF algorithms-Support TLV (Tag ID = 4)
an autonomous system. It is important to ensure that TE database - CSPF Algorithm Codes.
sychronizations happen quickly when compared to the aggregate
circuit setup an tear-down rates. 13.3.4. SRLG-TLV (Tag ID = 0x81)
- SRLG group IDs
13.3.5. BW-TLV (Tag ID = 0x82)
13.3.6 CO-TLV (Tag ID = ox83)
14. Acknowledgements
The authors wish to thank Vishwas manral, Riyad Hartani and Tricci
So for their valuable comments and feedback on the draft.
15. Security Considerations
This memo does not create any new security issues for the OSPF
protocol. Security considerations for the base OSPF protocol are
covered in [OSPF-v2]. As a general rule, a TE network is likely
to generate significantly more control traffic than a native
OSPF network. The excess traffic is almost directly proportional
to the rate at which TE circuits are setup and torn down within
an autonomous system. It is important to ensure that TE database
sychronizations happen quickly when compared to the aggregate
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",
draft-ietf-mpls-generalized-signaling-03.txt, work draft-ietf-mpls-generalized-signaling-03.txt, work
in progress. in progress.
[RSVP-TE] Awduche, D.O., L. Berger, Der-Hwa Gan, T. Li, [RSVP-TE] Awduche, D.O., L. Berger, Der-Hwa Gan, T. Li,
V. Srinivasan and G. Swallow, "RSVP-TE: Extensions V. Srinivasan and G. Swallow, "RSVP-TE: Extensions
to RSVP for LSP Tunnels", Work in progress, to RSVP for LSP Tunnels", Work in progress,
draft-ietf-mpls-rsvp-lsp-tunnel-08.txt 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-05.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 [OSPF-FL1] 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", [OSPF-FL2] Moy, J., "Flooding over a subset topology",
<draft-ietf-ospf-subset-flood-00.txt>, work in progress. <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-05.txt>
Authors' Addresses Authors' Addresses
Pyda Srisuresh Pyda Srisuresh
Jasmine Networks Kuokoa Networks, Inc.
3061 Zanker Road, Suite B 2901 Tasman Dr., Suite 202
San Jose, CA 95134 Santa Clara, CA 95054
U.S.A. U.S.A.
EMail: srisuresh@yahoo.com EMail: srisuresh@yahoo.com
Paul Joseph Paul Joseph
Jasmine Networks Jasmine Networks
3061 Zanker Road, Suite B 3061 Zanker Road, Suite B
San Jose, CA 95134 San Jose, CA 95134
U.S.A. U.S.A.
EMail: pjoseph@jasminenetworks.com EMail: pjoseph@jasminenetworks.com
 End of changes. 151 change blocks. 
478 lines changed or deleted 706 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/