< draft-srisuresh-ospf-te-03.txt   draft-srisuresh-ospf-te-04.txt >
Network Working Group P. Srisuresh Network Working Group P. Srisuresh
INTERNET-DRAFT Kuokoa Networks INTERNET-DRAFT Kuokoa Networks
Expires as of March 16, 2003 P. Joseph Expires as of June 8, 2003 P. Joseph
Force10 Networks Force10 Networks
September 16, 2002 December 8, 2002
TE LSAs to extend OSPF for Traffic Engineering OSPF-TE: An experimental extension to OSPF for Traffic Engineering
<draft-srisuresh-ospf-te-03.txt> <draft-srisuresh-ospf-te-04.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
OSPF is a link state routing protocol used for IP-network This document defines OSPF-TE, an experimental traffic engineering
topology discovery and collection and dissemination of link (TE) extension to the link-state routing protocol OSPF. New TE
access metrics. The resulting Link State Database (LSDB) is LSAs are designed to disseminate TE metrics within an autonomous
used to compute IP address forwarding table based on System (AS) - intra-area as well as inter-area. An Autonomous
shortest-path criteria. Traffic Engineering extensions(OSPF-TE) System may consist of TE and non-TE nodes. Non-TE nodes are
outlined in this document are built on the native OSPF uneffected by the distribution of TE LSAs. A stand-alone TE Link
foundation, utilizing new LSAs, designed specifically for TE. State Database (TE-LSDB), separate from the native OSPF LSDB, is
OSPF-TE sets out to discover TE network topology and perform generated for the computation of TE circuit paths. OSPF-TE is
collection and dissemination of TE metrics within the TE network. also extendible to non-packet networks such as SONET/TDM and
This results in the generation of an independent TE-LSDB, that optical networks. A transition path is provided for those
would permit computation of TE circuit paths. Unlike the native currently using [OPQLSA-TE] and wish to adapt OSPF-TE.
OSPF link metrics, TE metrics can be rapidly changing and
varied across different elements of the network. TE circuit
paths are computed using varied TE criteria, often different
from the shortest-path, to route traffic around congestion
paths. Principal motivations to designing the OSPF-TE over
[OPQLSA-TE] and transition path for vendors currently using
[OPQLSA-TE] to adapt the OSPF-TE are outlined in separate
sections within the document. OSPF-TE provides a single unified
mechanism for traffic engineering across packet and non-packet
networks, and may be adapted for a peer networking model.
Table of Contents Table of Contents
1. Introduction ................................................3 1. Introduction ................................................3
2. Traffic Engineering .........................................4 2. Principles of traffic engineering ...........................3
3. Terminology .................................................5 3. Terminology .................................................5
3.1. OSPF-TE node ...........................................5 3.1. TE node ................................................5
3.2. Native OSPF node .......................................5 3.2. TE link ................................................5
3.3. TE nodes vs. native(non-TE) nodes ......................6 3.3. TE circuit path ........................................5
3.4. TE links vs. native(non-TE) links ......................6 3.4. OSPF-TE node ...........................................6
3.5. Packet-TE network vs. non-packet-TE network ............6 3.5. TE control network .....................................6
3.6. TE topology vs. non-TE topology ........................6 3.6. TE network (TE topology) ...............................6
3.7. TLV ....................................................7 3.7. Packet-TE network ......................................6
3.8. Router-TE TLVs .........................................7 3.8. Non-packet-TE network ..................................6
3.9. Link-TE TLVs ...........................................7 3.9. Native (non-TE) node ...................................7
4. Motivations to designing the OSPF-TE using TE-LSAs ..........7 3.10. Native (non-TE) link ..................................7
4.1. Clean design - TE-LSDB, independent of the native LSDB .7 3.11. Non-TE network (Non-TE topology) ......................7
4.2. Extendible design - based on the OSPF foundation .......8 3.12. Peer network (combination network) ....................7
4.3. Scalable design - TE-AS may be sub-divided into areas ..9 3.13. LSP ...................................................7
4.4. Unified design - for packet and non-packet networks ....9 3.14. LSA ...................................................7
4.5. Efficient design - in LSA content and flooding reach ..10 3.14. LSDB ..................................................7
4.6. SLA enforceable TE network can coexist with IP network 10 3.15. CSPF ..................................................7
4.7. Right Framework for future OSPF extensibility .........11 3.16. TLV ...................................................8
4.8. Network scenarios benefiting from the OSPF-TE design ..12 3.17. Router-TE TLVs ........................................8
4.8.1. IP providers transitioning to TE services ......12 3.18. Link-TE TLVs ..........................................8
4.8.2. Providers offering Best-effort IP & TE services.12 4. Motivations behind the design of OSPF-TE ....................8
4.8.3. Multi-area networks ............................12 4.1. Scalable design ........................................9
4.8.4. Non-packet and Peer-networking models ..........12 4.2. Coexistent design ......................................9
5. OSPF-TE solution, assumptions and limitations ..............13 4.3. Efficient in flooding reach ............................9
5.1. OSPF-TE Solution ......................................14 4.4. Ability to reserve TE-exclusive links .................10
5.2. Assumptions ...........................................16 4.5. Extendible design .....................................10
5.3. Limitations ...........................................16 4.6. Unified for packet and non-packet networks ............11
6. Transition strategy for implementations using Opaque LSAs ..16 4.7. Networks benefiting from the OSPF-TE design ...........11
7. The OSPF Options field .....................................16 5. OSPF-TE solution overview ..................................12
8. Bringing up TE adjacencies; TE vs. Non-TE topologies .......17 5.1. OSPF-TE Solution ......................................12
8.1. The Hello Protocol ....................................17 5.2. Assumptions ...........................................13
8.2. Flooding and the Synchronization of Databases .........18 6. Opaque LSAs to OSPF-TE transition strategy .................14
8.3. The Designated Router .................................19 7. OSPF-TE router adjacency - TE topology discovery ...........14
8.4. The Backup Designated Router ..........................19 7.1. The OSPF Options field ................................15
8.5. The graph of adjacencies ..............................19 7.2. The Hello Protocol ....................................15
9. TE LSAs ....................................................20 7.3. Flooding and the Synchronization of Databases .........16
9.1. TE-Router LSA (0x81) ..................................22 7.4. The Designated Router .................................16
9.1.1. Router-TE flags - TE capabilities of the router.24 7.5. The Backup Designated Router ..........................16
9.1.2. Router-TE TLVs .................................25 7.6. The graph of adjacencies ..............................17
9.1.3. Link-TE options - TE capabilities of a TE-link .26 8. TE LSAs - Packet network ...................................18
9.1.4. Link-TE TLVs ...................................26 8.1. TE-Router LSA (0x81) ..................................19
9.2. TE-incremental-link-Update LSA (0x8d) .................27 8.2. TE-incremental-link-Update LSA (0x8d) .................26
9.3. TE-Circuit-paths LSA (0x8C) ...........................29 8.3. TE-Circuit-paths LSA (0x8C) ...........................27
9.4. TE-Summary LSAs .......................................31 8.4. TE-Summary LSAs .......................................30
9.4.1. TE-Summary Network LSA (0x83) ..................31 8.5. TE-AS-external LSAs (0x85) ............................33
9.4.2. TE-Summary router LSA (0x84) ...................32 9. TE LSAs - Non-packet network ...............................34
9.5. TE-AS-external LSAs (0x85) ............................34 9.1. TE-Router LSA (0x81) ..................................34
9.6. Changes to Network LSA ................................35 9.2. Changes to Network LSA ................................36
9.6.1. Positional-Ring type network LSA ...............36 9.3. TE-Router-Proxy LSA (0x8e) ............................36
9.7. TE-Router-Proxy LSA (0x8e) ............................36
9.8. Others ................................................37
10. Abstract topology representation with TE support ...........37 10. Abstract topology representation with TE support ...........37
11. Changes to Data structures in OSPF-TE routers ..............39 11. Changes to Data structures in OSPF-TE routers ..............40
11.1. Changes to Router data structure .....................39 11.1. Changes to Router data structure .....................40
11.2. Two set of Neighbors .................................39 11.2. Two set of Neighbors .................................40
11.3. Changes to Interface data structure ..................39 11.3. Changes to Interface data structure ..................40
12. IANA Considerations ........................................40 12. IANA Considerations ........................................41
12.1. TE-compliant-SPF routers Multicast address allocation 40 12.1. TE LSA type values ...................................41
12.2. New TE-LSA Types .....................................40 12.2. TE TLV tag values ....................................42
12.3. New TLVs (Router-TE and Link-TE TLVs) ................40 13. Acknowledgements ...........................................42
12.3.1. TE-selection-Criteria TLV (Tag ID = 1) .......40 14. Security Considerations ....................................42
12.3.2. MPLS-Signaling protocol TLV (Tag ID = 3) .....40 15. Normative References .......................................44
12.3.3. Constraint-SPF algorithms-Support TLV (Tag ID=4) 16. Informative References .....................................44
12.3.4. SRLG-TLV (Tag ID = 0x81) .....................40
12.3.5. BW-TLV (Tag ID = 0x82) .......................41
12.3.6. CO-TLV (Tag ID = ox83) .......................41
13. Acknowledgements ...........................................41
14. Security Considerations ....................................41
References .....................................................41
1. Introduction 1. Introduction
There is substantial industry experience with deploying OSPF link This document defines OSPF-TE, an experimental traffic engineering
state routing protocol. That makes OSPF a good candidate to adapt (TE) extension to the link-state routing protocol OSPF. The
for traffic engineering purposes. The dynamic discovery of network objective of OSPF-TE is to discover TE network topology and
topology, link access metrics, flooding algorithm and the disseminate TE metrics within an autonomous system(AS). A
hierarchical organization of areas can all be used effectively in stand-alone TE Link State Database (TE-LSDB), different from
creating and tearing traffic links on demand. The intent of the native OSPF LSDB, is created to facilitate computation of TE
OSPF-TE is to discover TE network topology and the TE metrics circuit paths. Algorithms to compute TE circuit paths is however
of the nodes and links in the network. not the objective of this document.
The objective of traffic engineering is to set up circuit path(s) OSPF-TE is different from the Opaque-LSA-based design outlined
across a pair of nodes or links, as the case may be, so as to in [OPQLSA-TE]. Section 4 describes the motivations behind the
forward traffic of a certain forwarding equivalency class. Circuit design of OSPF-TE. Section 6 outlines a strategy to transition
emulation in a packet network is accomplished by each MPLS Opaque-LSA based implementations to adapt OSPF-TE.
intermediary node performing label swapping. Whereas, circuit
emulation in a TDM or Fiber cross-connect network is accomplished
by configuring the switch fabric in each intermediary node to do
the appropriate switching (TDM, fiber or Lamda) for the duration
of the circuit.
The objective of this document is not how to set up traffic circuits, Those interested in TE extensions for the packet networks only
but rather provide the necessary TE parameters for the nodes and may skip section 9.0.
links that constitute the TE topology. Unlike the native OSPF,
OSPF-TE will be used to build circuit paths, meeting certain TE
criteria. The only requirement is that end-nodes and/or end-links of
a circuit be identifiable with an IP address.
The approach suggested in this document is different from the 2. Principles of traffic engineering
Opaque-LSA-based approach outlined in [OPQLSA-TE]. Section 4
describes the motivations behind designing OSPF-TE. Section 6
outlines a strategy to transition Opaque-LSA based implementations
to adapt the OSPF-TE outlined here.
2. Traffic engineering overview The objective of traffic engineering is to set up circuit
path(s) between a pair of nodes or links and to forward traffic
of a certain forwarding equivalency class through the circuit
path. Only the unicast circuit paths are considered here.
Multicast variations are out of scope for this document.
A traffic engineered circuit may be identified by the tuple of A traffic engineered circuit path may be identified by the
(Forwarding Equivalency Class, TE parameters for the circuit, tuple of (Forwarding Equivalency Class, TE parameters for the
Origin Node/Link, Destination node/Link). circuit, Origin Node/Link, Destination node/Link).
The Forwarding Equivalency Class(FEC) may be constituted of a number Forwarding Equivalency Class (FEC) is a grouping of traffic
of criteria such as (a) Traffic arriving on a specific interface, that is forwarded in the same manner by a node. A FEC may be
(b) Traffic meeting a certain classification criteria (ex: based on classified based on a number of criteria as follows.
fields in the IP and transport headers), (c) Traffic in a certain a) Traffic arriving on a specific interface,
priority class, (d) Traffic arriving on a specific set of TDM (STS) b) Traffic arriving at a certain time of day,
circuits on an interface, (e) Traffic arriving on a certain c) Traffic meeting a certain classification criteria
wave-length of an interface, (f) Traffic arriving at a certain time (ex: based on a match of the fields in the IP and
of day, and so on. A FEC may be constituted as a combination of one transport headers),
or more of the above criteria. Discerning traffic based on the FEC d) Traffic in a certain priority class,
criteria is a mandatory requirement on Label Edge Routers (LERs). e) Traffic arriving on a specific set of TDM (STS) circuits
Traffic content is transparent to the Intermediate Label Switched on an interface,
Routers (LSRs), once a circuit is formed. LSRs are simply f) Traffic arriving on a certain wavelength of an interface
responsible for keeping the circuit in-tact for the lifetime of the
circuit(s). As such, this document will not address FEC or the
associated signaling to setup circuits. [MPLS-TE] and [GMPLS-TE]
address the FEC criteria. Whereas, [RSVP-TE] and [CR-LDP] address
different types of signaling protocols.
This document is concerned with the collection of TE parameters for Discerning traffic based on the FEC criteria is mandatory for
all the nodes and links within an autonomous system. TE parameters Label Edge Routers (LERs). The intermediate Label Switched Routers
for a node may include a) ability to perform traffic prioritization, (LSRs) are transparent to the traffic content. LSRs are merely
b) ability to provision bandwidth on interfaces, c) support for zero responsible for keeping the circuit in-tact for the circuit
or more CSPF algorithms, d) support for a specific TE-Circuit switch lifetime. This document will not address defining FEC criteria,
type, e) support for a certain type of automatic protection or the mapping of a FEC to circuit, or the associated signaling to
switching and so forth. TE parameters for a link may include set up circuits. [MPLS-TE] and [GMPLS-TE] address the FEC criteria.
a) available bandwidth, b) reliability of the link, c) color [RSVP-TE] and [CR-LDP] address signaling protocols to set up
assigned to the link, d) cost of bandwidth usage on the link, and circuits.
e) membership to a Shared Risk Link Group (SRLG) and so forth.
Only the unicast paths circuit paths are considered here. Multicast This document is concerned with the collection of TE metrics for
variations are currently considered out of scope for this document. all the TE enforceable nodes and links within an autonomous system.
The requirement is that the originating as well as the terminating TE metrics for a node may include the following.
entities of a TE path are identifiable by their IP address. a) Ability to perform traffic prioritization,
b) Ability to provision bandwidth on interfaces,
c) Support for Constrained Shortest Path First (CSPF)
algorithms,
d) Support for certain TE-Circuit switch type,
e) Support for a certain type of automatic protection
switching
TE metrics for a link may include the following.
a) Available bandwidth,
b) Reliability of the link,
c) Color assigned to the link,
d) Cost of bandwidth usage on the link,
e) Membership to a Shared Risk Link Group (SRLG)
A number of CSPF algorithms may be used to dynamically set up
TE circuit paths in a TE network.
As for origin node/link and destination node/link, the originating
and the terminating entities of a TE circuit path are identifiable
by their IP addresses.
3. Terminology 3. Terminology
Definitions for majority of the terms used in this document with Definitions of terms used in the context of the OSPF protocol may be
regard to OSPF protocol may be found in [OSPF-V2]. MPLS and traffic found in [OSPF-V2]. MPLS and traffic engineering terms may be found
engineering terms may be found in [MPLS-ARCH]. RSVP-TE and CR-LDP in [MPLS-ARCH]. RSVP-TE and CR-LDP signaling specific terms may be
signaling specific terms may be found in [RSVP-TE] and [CR-LDP] 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 [IETF-STD].
Below are definitions for the terms used within this document. Below are definitions for the terms used within this document.
3.1. OSPF-TE node 3.1. TE node
This is a router that supports the OSPF-TE described in this TE-Node is a node in the traffic engineered (TE) network. A
document. At least one of the attached links for the node TE-node has a minimum of one TE-link attached to it. Associated
supports IP packet termination and runs the OSPF-TE protocol. with each TE node is a set of supported TE metrics. A TE node
may also participate in a native IP network.
An OSPF-TE node supports native OSPF as well as the OSPF-TE. In a SONET/TDM or photonic cross-connect network, a TE node is
not required to be an OSPF-TE router. An external OSPF-TE router
may act as proxy for the TE nodes that cannot be routers
themselves.
3.2. Native OSPF node 3.2. TE link
A native OSPF node is an OSPF router that does not support TE Link is a network attachment point to a TE-node and is
the TE extensions described in this document or does not have intended for traffic engineering use. Associated with each
a TE link attached to it. A Native OSPF node forwards IP TE link is a set of supported TE metrics. A TE link may also
traffic, using the shortest-path forwarding algorithm. optionally carry native IP traffic.
A native OSPF node may be enhanced to be an OSPF-TE node. An Of the various links attached to a TE-node, only the links that
autonomous system (AS) could be constituted of a combination take part in a traffic engineered network are called the TE
of native-OSPF and OSPF-TE nodes. links.
3.3. TE nodes vs. native(non-TE) nodes 3.3. TE circuit path
A TE-Node is an intermediate or edge node taking part in the A TE circuit path is a uni-directional data path, defined by a
traffic engineered (TE) network. A TE-circuit is constituted of list of TE nodes connected to each other through TE links. A
a series of TE nodes connected to each other through TE links. TE circuit path is also often referred merely as a circuit path
In a SONET/TDM network or a photonic cross-connect network, or a circuit.
a TE node is not required to support OSPF-TE. An external
OSPF-TE node may represent the TE node for protocol processing.
A native (or non-TE) node is an IP router capable of IP packet For the purposes of OSPF-TE, the originating and terminating
forwarding, does not have TE link attachments and does not take entities of a TE circuit path must be identifiable by their
part in a TE network. IP addresses. As a general rule, all nodes and links party to a
Traffic Engineered network should be uniquely identifiable by an
IP address.
3.4. TE links vs. native(non-TE) links 3.4. OSPF-TE node
A TE Link is a network attachment that supports traffic An OSPF-TE node is a TE node that runs the OSPF routing protocol
engineering. A TE-circuit is constituted of a series of TE and the OSPF-TE extensions described in this document.
nodes connected to each other through TE links.
A native (or non-TE) link is one that is used for IP packet An autonomous system (AS) may be constituted of a combination of
traversal. A link may be configured to be pure TE link or native and OSPF-TE nodes.
native link or a both.
3.5. Packet-TE network vs. non-packet-TE network 3.5. TE Control network
Packet-TE network is one in which TE-circuit emulation is The IP network used by the OSPF-TE nodes for OSPF-TE
accomplished by each MPLS intermediary node performing label communication is referred as the TE control network or simply
swapping on the packet data. the control network. The control network can be independent of
the TE data network.
Non-packet-TE network, such as SONET/TDM or Fiber 3.6. TE network (TE topology)
cross-connect network is one in which TE-circuit emulation is
accomplished by configuring the switch fabric in each
intermediary node to do the appropriate switching (TDM, fiber
or Lamda) for the duration of the circuit.
In either case, OSPF-TE can only be enabled on interfaces A TE network is a network of connected TE-nodes and TE-links
supporting IP packet termination. Interfaces supporting OSPF for the purpose of setting up one or more TE circuit paths.
and/or OSPF-TE constitute the OSPF control network. The OSPF The terms TE network, TE data network and TE topology are
control network can be independent of the packet or non-packet used synonymously throughout the document.
data network.
3.6. TE topology vs. non-TE topology 3.7. Packet-TE network
A TE topology is constituted of a set of contiguous TE nodes and A packet-TE network is a TE network in which the nodes switch
TE links. Associated with each TE node and link is a set of TE MPLS packets. An MPLS packet is defined in [MPLS-TE] as a
criteria that may be supported at any given time. A TE topology packet with an MPLS header, followed by data octets. The
allows circuits to be overlayed statically or dynamically based intermediary node(s) of a circuit path in a packet-TE network
on a specific TE criteria. perform MPLS label swapping to emulate the circuit.
A non-TE topology specifically refers to the network that does not Unless specified otherwise, the term packet network is used
support TE. Control protocols such as OSPF may be run on the non-TE throughout the document to refer a packet-TE network.
topology. IP forwarding table used to forward IP packets on this
network is built based on the control protocol specific algorithm,
such as OSPF shortest-path criteria.
3.7. TLV 3.8. Non-packet-TE network
A TLV stands for an object in the form of Tag-Length-Value. All TLVs A non-packet-TE network is TE-network in which the nodes
are assumed to be of the following format, unless specified switch non-packet entities such as an STS time slot, a Lambda
otherwise. The Tag and length are 16 bits wide each. The length wavelength or simply an interface.
includes the 4 bytes required for Tag and Length specification.
0 1 2 3 SONET/TDM and Fiber cross-connect networks are examples of
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 non-packet-TE networks. Circuit emulation in these networks
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ is accomplished by the switch fabric in the intermediary
| Tag | Length (4 or more) | nodes (based on TDM time slot, fiber interface or Lambda).
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.8. Router-TE TLVs Unless specified otherwise, the term non-packet network is
used throughout the document to refer a non-packet-TE
network.
TLVs used to describe the TE capabilities of a TE-node. 3.9. Native (non-TE) node
3.9. Link-TE TLVs A native or non-TE node is an OSPF router capable of IP packet
forwarding and does not take part in a TE network. A native
OSPF node forwards IP traffic using the shortest-path
forwarding algorithm and does not run the OSPF-TE extensions.
TLVs used to describe the TE capabilities of a TE-link. 3.10. Native (non-TE) link
4. Motivations to designing the OSPF-TE using TE-LSAs A native (or non-TE) link is a network attachment to a TE or
non-TE node used for IP packet traversal.
The motivation behind designing the OSPF-TE using TE-LSAs is 3.11. non-TE network (Non-TE topology)
that the approach is clean, extendible, scalable, unified,
efficient, and SLA enforceable. The approach also provides
the right framework for future OSPF extensibility. Each of
these motivations is explained in detail in the following
subsections.
The last subsection lists network scenarios that benefit from A non-TE network refers to an OSPF network that does not
the TE-LSA design. support TE. Non-TE network, native-OSPF network and non-TE
topology are used synonymously throughout the document.
4.1. Clean design - TE-LSDB, independent of the native LSDB 3.12. Peer network (combination network)
OSPF-TE using TE LSAs provides a clean separation of Link State
Data Bases (LSDB) between native (SPF-based) and TE networks.
The OSPF-TE dynamically discovers TE network topology and the
associated TE metrics of the nodes and links in the TE network.
OSPF-TE design is based on the tried and tested OSPF paradigm.
As such, it inherits all the benefits of the OSPF, present and
future.
With OSPF-TE, native OSPF nodes will keep just the native OSPF A peer network is a network that is constituted of packet
link state database. The OSPF-TE nodes will keep the native as and non-packet networks combined. In a peer network, a TE
well as the TE LSDB. In the case, where the network is used node could potentially support TE links for the packet as
only for Traffic engineering purposes, the native-LSDB well as non-packet data.
describes the control topology.
In the Opaque-LSA-based TE scheme([OPQLSA-TE]), the TE-LSDB built OSPF-TE is usable within a packet network or a non-packet
using opaque LSAs refers the native LSDB to build the TE topology. network or a peer network, which is a combination of the two.
Further, the LSDB has no knowledge of the TE capabilities of the
routers. Point-to-point links are the only type of links that can
form a TE network. It is apparent that [OPQLSA-TE] is a new
protocol in itself within the constraints of an Opaque-LSA and is
not tailored to benefit from the tried and tested native-OSPF.
4.2. Extendible design - based on the OSPF foundation 3.13. LSP
TE LSAs are extendible, just as the native OSPF on which OSPF-TE LSP stands for "Label Switched Path". LSP is a TE circuit path
is founded. [OPQLSA-TE], on the other hand, is not extendible in a packet network. The terms LSP and TE circuit path are
and is constrained by the Opaque LSA on which it is founded. used synonymously in the context of packet networks.
For example, Opaque LSAs are not suited to advertising summary 3.14. LSA
LSAs along a restricted flooding scope (as with TE-Summary
network LSA). Opaque LSAs are also not suited to advertising
incremental TLV changes. A change in any TLV of a TE-link will
mandate the entire Opaque-LSA (with all the TLVs included) to be
transmitted. TE-incremental-link-update LSA, on the other hand,
is capable of advertising just the delta TLVs. Opaque LSAs
are also not extendible to support advertisement of TLVs for
non-members of the OSPF control network. This is a necessity
for certain non-packet networks such as a SONET/TDM network. In
a SONET/TDM network, data-path topology often differs from
its OSPF control network counterpart. TE-Router-Proxy-LSA
(section 9.7) permits advertising LSAs for non-members via
a proxy node that is a member of the control network.
Lastly, the expressibility of data in an Opaque LSA is strictly LSA stands for OSPF "Link State Advertisement".
restricted to being in the form of TLVs and sub-TLVs, some
mandatorily required and some positionally dependent in the
TLV sequence for interpretation.
4.3. Scalable design - TE-AS may be sub-divided into areas 3.15. LSDB
OSPF-TE using TE LSAs inherits the hierarchical area organization LSDB stands for "LSA Database". LSDB is a representation of the
used within native-OSPF. Without revealing the nodes and topology of a network. A native LSDB, constituted of native OSPF
characteristics of the attached links within a TE-area, the LSAs, represents the topology of a native IP network. TE-LSDB, on
TE-Summary network LSA (refer section 9.4) advertises the the other hand, is constituted of TE LSAs and is a representation
reachability of TE networks within an area to the areas outside of the TE network topology.
in the same AS.
Providing area level abstraction and having the abstraction be 3.16. CSPF
distinct for TE and native topologies is a necessity for
inter-area communication. When the topologies are separate, the
area border routers can advertise different summary LSAs to TE
and non-TE routers. For example, a native Area Border router (ABR)
simply announces the shortest path network summary LSAs (LSA
type 3) for nodes outside the area. A TE-ABR, on the other hand,
would use TE-summary network LSA to advertise network Reachability
information - not aggregated path metric as required for a native
OSPF LSDB. Clearly, the data content and flooding scope should be
different for the TE nodes. The flooding boundary for TE-summary
LSAs would be (AS - OriginatingArea - StubAreas - NSSAs).
Opaque-LSA-based TE scheme([OPQLSA-TE]) is restricted for use CSPF stands for "Constrained Shortest Path First". Given a TE
within an area and is not applicable for flooding across areas. LSDB and a set of constraints that must be satisfied to form a
As-wide scope Opaque LSAs (Type 11 LSAs) will be unable to restrict circuit path, there may be several CSPF algorithms to obtain a
flooding in its own originating area. TE circuit path that meets the criteria.
4.4. Unified design - for packet and non-packet networks 3.17. TLV
OSPF-TE uses the same set of TE LSAs for disseminating TE A TLV stands for an object in the form of Tag-Length-Value. All
characteristics - irrespective of whether the network is a packet TLVs are assumed to be of the following format, unless specified
network or a non-packet network or a combination of both. Only otherwise. The Tag and length are 16 bits wide each. The length
the TLVs used to describe the characteristics will vary. Each TE includes the 4 octets required for Tag and Length specification.
node will be required to advertise its own TE capabilities and All TLVs described in this document are padded to 32-bit
that of the attached TE links. alignment. Any padding required for alignment will not be a part
of the length field, however. TLVs are used to describe traffic
engineering characteristics of the TE nodes, TE links and TE circuit
paths.
In a peer networking TE model, the TE nodes are heterogeneous 0 1 2 3
and have different TE characteristics. As such, the signaling 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
protocols will need the TE characteristics of all nodes and +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
attached links so they can signal the nodes to formulate TE | Tag | Length (4 or more) |
circuits across heterogeneous nodes. The underlying control +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
protocol must be capable of providing a unified LSDB for all | Value .... |
nodes in the network. OSPF-TE clearly meets this requirement. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Opaque-LSA-based TE scheme([OPQLSA-TE]) is limited in scope for 3.18. Router-TE TLVs
packet networks. Extensions ([OPQLSA-GMPLS]) are underway to
support GMPLS links within opaque LSAs. However, neither
[OPQLSA-TE] nor [OPQLSA-GMPLS] is sufficient by itself or when TLVs used to describe the TE capabilities of a TE-node.
combined for use within a peer networking model with heterogeneous
nodes. Neither of the Opaque LSA based extensions have provision
to distinguish between the various nodes and link attachments that
are different from point-to-point connections. SONET specific
ring topologies and packet network specific LAN and other mesh
topologies are not permitted.
4.5. Efficient design - in LSA content and flooding reach 3.19. Link-TE TLVs
TLVs used to describe the TE capabilities of a TE-link.
4. Motivations behind the design of OSPF-TE
There are several motivations that lead to the design of OSPF-TE.
OSPF-TE is scalable, coexistent and efficient in flooding reach.
The motivations are explained in detail in the following
subsections. Also listed in the last subsection are network
scenarios that benefit from the OSPF-TE design.
4.1. Scalable design
Area level abstraction provides the scaling necessary for a large
autonomous system (AS). OSPF-TE allows for independent area
abstractions for the TE and native topologies. The TE and native
area border routers will advertise different summary LSAs to TE
and non-TE routers. Readers may refer section 10 for a
topological view of the AS from an OSPF-TE node in an area.
4.2. Coexistent design
OSPF-TE regards an AS as constituted of a TE and non-TE networks
coexisting within the same bounds. OSPF-TE dynamically discovers
TE topology and the associated TE metrics of the nodes and links
within, just as the native OSPF does in a non-TE network. An
independent TE-LSDB, representative of the TE topology is
generated as a result. A stand-alone TE-LSDB allows for speedy
searches through the database.
In [OPQLSA-TE], the TE-LSDB is derived from the combination of
opaque LSAs and native LSDB. The TE-LSDB derived has no
knowledge of the TE capabilities of the routers in the network.
4.3. Efficient in flooding reach
OSPF-TE is capable of identifying the boundaries of a TE topology OSPF-TE is capable of identifying the boundaries of a TE topology
and limits the flooding of TE LSAs to only the TE-nodes. Nodes and limits the flooding of TE LSAs to only the TE-nodes. Non-TE
that do not have TE link attachments are not bombarded with TE nodes are not bombarded with TE LSAs. This is a useful
specific LSAs. This is a useful characteristic for networks characteristic for networks supporting native and TE traffic in
supporting native and TE traffic in the same connected network. the same connected network.
The more frequent and wider the flooding scope, the larger the A subset of the TE metrics may be prone to rapid change, while
number of retransmissions and acknowledgements. The same others remain largely unchanged. Changes in TE metrics must be
communicated at the earliest throughout the network to ensure
that the TE-LSDB is up-to-date within the network. 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 set up and torn down within the TE network. The TE database
synchronization should occur much quicker compared to the
aggregate circuit set up and tear-down rates.
TE-Incremental-Link-update LSA (section 8.2) permits advertising
a subset of the link metrics.
The more frequent and wider the flooding frequency, the larger
the number of retransmissions and acknowledgements. The same
information (needed or not) may reach a router through multiple information (needed or not) may reach a router through multiple
links. Even if the router did not forward the information past links. Even if the router did not forward the information past
the node, it would still have to send acknowledgements across the node, it would still have to send acknowledgements across
all the various links on which the LSAs tried to converge. all the various links on which the LSAs tried to converge.
Clearly, it is not desirable to flood LSAs to nodes that do not It is undesirable to flood non-TE nodes with TE information.
require it. This can be a considerable impediment to non-TE
nodes in a network that is constituted of native and TE nodes.
Opaque-LSA-based TE scheme([OPQLSA-TE]) makes no distinction [OPQLSA-TE] uses Opaque LSAs for advertising TE information.
between TE and native OSPF nodes as far as LSA flooding is Opaque LSAs reach all nodes within the network - TE-nodes and
concerned. It is possible for the native OSPF nodes to silently non-TE nodes alike. [OPQLSA-TE] also does not have provision
ignore the unsupported Opaque LSAs or add knobs within to advertise just the TLVs that changed. A change in any TLV
implementation to decide whether or not a certain opaque LSA of a TE-link will mandate the entire LSA to be transmitted.
mandates dijkstra SPF recomputation. In any case, unintended
LSAs are disruptive and can be the cause of a large number of
acknowledgements and retransmissions.
TE metrics in a network could be rapidly changing. Only a subset 4.4. Ability to reserve TE-exclusive links
of the metrics may be prone to rapid change, while others remain
largely unchanged. Changes must be communicated at the earliest
throughout the network to ensure that the TE-LSDB is up-to-date.
TE-Incremental-Link-update LSA (section 9.2) permits advertising
only a subset of the link metrics and not the entire router-LSA
all over. [OPQLSA-TE] does not have provision to advertise just
the TLVs that changed. A change in any TLV of a TE-link will
mandate the entire LSA to be transmitted. This is clearly a
serious shortcoming in the protocol.
4.6. SLA enforceable TE network can coexist with IP network OSPF-TE is designed to draw distinction between TE-links and
OSPF-TE is designed to draw distinction between links that non-TE links. A TE link, configured to support TE traffic
support TE traffic and links that support native best-effort alone, will not permit best-effort IP traffic on the link.
IP traffic. This flexibility to configure links as appropriate This permits TE enforceability on the TE links.
for a service, permits enforceability of service level
agreements (SLAs). A link, configured to support TE traffic
alone will not permit native IP traffic on the link.
Best-effort IP transit network and constraint based TE network When links of a TE-topology do not overlap the links of a
have different SLA requirements and hence different billing native IP network, OSPF-TE allows for virtual isolation of
models. Keeping the two networks physically isolated will enable the two networks. Best-effort IP transit network and
SLA enforceability, but can be expensive. Combining the two constraint based TE network often have different service
networks into a single physically connected network will bring requirements. Keeping the two networks physically isolated
economies of scale, if the SLA enforceability can be retained. will enable SLA enforceability, but can be expensive. Combining
When the links of a TE-network LSDB do not overlap the links the two networks into a single physically connected network
of a native LSDB, such a virtual isolation of networks and will bring economies of scale, if the service enforceability
hence SLA enforceability becomes possible. can be retained.
Opaque-LSA-based TE scheme([OPQLSA-TE]) is inherently not capable [OPQLSA-TE] does not support the ability to isolate best-
of having two virtual networks in a single physically connected effort IP traffic from TE traffic on a link. All links are
network. All point-to-point links in a packet network are subject subject to best-effort IP traffic. An OSPF router could
to best-effort IP traffic, irrespective of whether a link is potentially select a TE link to be its least cost link and
usable for TE traffic or not. In order to ensure that TE links are inundate the link with best-effort IP traffic, thereby
not cannibalized by best-effort traffic, the network provider will rendering the link unusable for TE purposes.
simply have to restrict best-effort traffic from entering the
network. This is a severe limitation and is a direct result of
not having LSDB isolation. When TE and native topologies
are not separated (as is the case with Opaque-LSAs), a native OSPF
node could be utilizing a TE link as its least cost link, thereby
stressing the TE link and rendering the TE link ineffective for
TE purposes.
4.7. Right Framework for future OSPF extensibility 4.5. Extendible design
OSPF-TE design provides the right framework for future OSPF OSPF-TE design is based on the tried and tested OSPF paradigm,
extensions based on independent service provider needs. The and inherits all the benefits of the OSPF, present and future.
framework essentially calls for building independent service TE-LSAs are extendible, just as the native OSPF on which OSPF-TE
specific LSDBs. Each such LSDB will consist of service specific is founded.
metrics of all resources within the service-specific topology.
The TE-LSDB permits TLV scalability as well as the ability
to perform fast searches through the database. Just as the
TE-LSDB may be used for MPLS TE application, a different type
of LSDB may be used for a different type of application across
the same physically connected IP network. E.g., one can derive
QOS based IP forwarding on an IP network.
Limiting flooding scope of service specific LSAs within the [OPQLSA-TE], on the other hand, is constrained by the semantics
service specific topology eliminates LSA contamination between of the Opaque LSA on which it is founded. The content within an
virtual service networks of a single physically connected Opaque LSA is restricted to being in the form of TLVs and
network. Using service specific LSAs provides flexibility in sub-TLVs, some of which are mandatory and some of which are
LSA content and flooding scope. positionally dependent in the TLV sequence for proper
interpretation. Opaque LSAs are also restrictive when the flooding
scope for the content is required to be different from the scope
of the opaque LSA itself.
Opaque-LSA-based TE scheme([OPQLSA-TE]) works best when a single 4.6. Unified for packet and non-packet networks
type of service is assumed for a single physically connected
network. As such, multiple disparate networks can function
running various flavors of OSPF. [OSPF-v2] for native best-effort
IP networks, [OPQLSA-TE] for packet networks and [OPQLSA-GMPLS]
for non-packet networks.
4.8. Network scenarios benefiting from the OSPF-TE design OSPF-TE is usable within a packet network or a non-packet
network or a combination peer network.
Many real-world scenarios are better served by the new-TE-LSAs Signaling protocols such as RSVP and LDP work the same across
packet and non-packet networks. Signaling protocols merely need
the TE characteristics of nodes and links so they can signal the
nodes to formulate TE circuit paths. In a peer network, the
underlying control protocol must be capable of providing a
unified LSDB for all TE nodes (nodes with packet-TE links as well
as non-packet-TE links) in the network. OSPF-TE meets this
requirement.
[OPQLSA-TE] is limited in scope for packet networks. An
independent [OPQLSA-GMPLS] is required to support GMPLS links in
a non-packet network. Neither of the Opaque LSA based extensions
have provision to distinguish between node types.
4.7. Networks benefiting from the OSPF-TE design
Many real-world networks are better served by the new-TE-LSAs
scheme. Here are a few examples. scheme. Here are a few examples.
4.8.1. IP providers transitioning to TE services 4.7.1. IP providers transitioning to provide TE services
Providers needing to support MPLS based TE in their IP network Providers needing to support MPLS based TE in their IP network
may choose to transition gradually. Perhaps, add new TE links may choose to transition gradually. Perhaps, add new TE links
or convert existing links into TE links within an area first or convert existing links into TE links within an area first
and progressively advance to offer in the entire AS. and progressively advance to offer in the entire AS.
Not all routers will support TE extensions at the same time Not all routers will support TE extensions at the same time
during the migration process. Use of TE specific LSAs and their during the migration process. Use of TE specific LSAs and their
flooding to OSPF-TE only nodes will allow the vendor to flooding to OSPF-TE only nodes will allow the vendor to
introduce MPLS TE without destabilizing the existing network. introduce MPLS TE without destabilizing the existing network.
As such, the native OSPF-LSDB will remain undisturbed while The native OSPF-LSDB will remain undisturbed while newer TE
newer TE links are added to network. links are added to the network.
4.8.2. Providers offering Best-effort-IP & TE services 4.7.2. Providers offering Best-effort-IP & TE services
Providers choosing to offer both best-effort-IP and TE based Providers choosing to offer both best-effort-IP and TE based
packet services simultaneously on the same physically connected packet services simultaneously on the same physically connected
network will benefit from the OSPF-TE design. By maintaining network will benefit from the OSPF-TE design. By maintaining
independent LSDBs for each type of service, TE links are not independent LSDBs for each type of service, TE links are not
cannibalized by the non-TE routers for SPF forwarding. Unlike cannibalized.
the [OPQLSA-TE] scheme, OSPF-TE provides the framework for SLA
enforcement.
4.8.3. Multi-area networks 4.7.3. Large TE networks
The OSPF-TE design parallels the tried and tested native-OSPF The OSPF-TE design is advantageous in large TE networks that
design. Unlike [OPQLSA-TE], OSPF-TE scales naturally to multi-area require the AS to be sub-divided into multiple areas.
networks.
4.8.4. Non-packet and Peer-networking models 4.7.4. Non-packet networks and Peer networks
OSPF-TE is the only scheme that can support the following OSPF-TE is also the right choice for vendors opting for a
network attachments For a non-Packet TE network. stable, well-founded protocol for their non-IP TE networks.
OSPF-TE is uniquely qualified to support the following network
attachments in non-Packet TE networks.
(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).
Opaque LSA based extensions ([OPQLSA-TE], [OPQLSA-GMPLS]) are not 5. OSPF-TE solution overview
suited to distinguish the heterogeneous nodes in a peer-connected
network. Opaque-LSA based extensions are also not suited to support
link attachments that are different from point-to-point connections.
5. OSPF-TE solution, assumptions and limitations
5.1. OSPF-TE Solution 5.1. OSPF-TE Solution
The OSPF-TE uses the options flag as a means to determine the A new TE flag is introduced within the OSPF options field to
TE topology. New TE LSAs are designed to generate an independent to enable discovery of TE topology. Section 8.0 describes the
TE-service tailored LSDB. Sections 8.0 and 9.0 describe the TE semantics of the TE flag. TE LSAs are designed for use by the
extensions in detail. Changes required of the OSPF data OSPF-TE nodes. Section 9.0 describes the TE LSAs in detail.
structures in order to support OSPF-TE are described in section Changes required of the OSPF data structures to support
11.0. The OSPF-TE design is based on the tried and tested OSPF OSPF-TE are described in section 11.0. A new TE-neighbors data
paradigm. With TE-LSDB, you have the advantages of retaining the structure will be used to flood TE LSAs along TE-topology.
scalability of TLV's and the ability to run fast searches through
the database.
With the new TE-LSA scheme, an OSPF-TE node will have two types
of Link state databases (LSDB). A native LSDB that describes the
native control topology and a TE-LSDB that describes the TE
topology. Shortest-Path-First algorithm will be used to forward
IP packets along the native control network. OSPF neighbors data
structure will be used for flooding along the control topology.
The TE-LSDB is constituted only of TE nodes and TE links. A variety
of CSPF algorithms may be used to dynamically setup TE circuit
paths along the TE network. A new TE-neighbors data structure will
be used to flood TE LSAs along the TE-only topology. Clearly, the
the TE nodes will need the control (non-TE) network for OSPF
communication. The control network may also be used for pinging
OSPF-TE nodes and performing any debug and monitoring tasks on
the nodes. However, the ability to make distinction between
TE and non-TE topologies, allows the bandwidth on TE links to be
strictly SLA enforceable, even as a TE link is packet-capable.
The actual characteristics of the TE-link are irrelevant from the
OPSF-TE perspective. As such, that allows for packet and non-packet
networks to operate in peer mode.
Consider the following network where some of the routers and links An OSPF-TE node will have the native LSDB and the TE-LSDB,
are TE enabled and others are native OSPF routers and links. All A native OSPF node will have just the native LSDB.
nodes in the network belong to the same OSPF area. Consider the following OSPF area constituted of OSPF-TE and
native OSPF routers. Nodes RT1, RT2, RT3 and RT6 are OSPF-TE
routers with TE and non-TE link attachments. Nodes RT4 and RT5
are native OSPF routers with no TE links. When the LSA database
is synchronized, all nodes will share the same native LSDB
OSPF-TE nodes alone will have the additional TE-LSDB.
+---+ +---+
| |--------------------------------------+ | |--------------------------------------+
|RT6|\\ | |RT6|\\ |
+---+ \\ | +---+ \\ |
|| \\ | || \\ |
|| \\ | || \\ |
|| \\ | || \\ |
|| +---+ | || +---+ |
|| | |----------------+ | || | |----------------+ |
skipping to change at page 14, line 37 skipping to change at page 13, line 37
|RT5|--------------|RT4| |RT5|--------------|RT4|
+---+ +---+ +---+ +---+
Legend: Legend:
-- Native(non-TE) network link -- Native(non-TE) network link
| Native(non-TE) network link | Native(non-TE) network link
\\ TE network link \\ TE network link
|| TE network link || TE network link
Figure 6: A (TE + native) OSPF network topology Figure 6: A (TE + native) OSPF network topology
In the above network, TE and native OSPF Link State Data bases
(LSDB) would have been synchronized within the area along the
following nodes.
Native OSPF LSDB nodes TE-LSDB nodes
---------------------- -------------
RT1, RT2, RT3. RT4, RT5, RT6 RT1, RT2, RT3, RT6
Nodes such as RT1 will have two LSDBs, a native LSDB and a TE-LSDB
to reach native and TE networks. The TE LSA updates will not impact
non-TE nodes RT4 and RT5.
5.2. Assumptions 5.2. Assumptions
OSPF-TE design makes the following assumptions. OSPF-TE is an extension to the native OSPF protocol and does not
mandate changes to the existing OSPF. OSPF-TE design makes the
1. An OSPF-TE node with links in an OSPF area will need to following assumptions.
establish router adjacency with at least one other neighboring
OSPF-TE node in order for the router's database to be
synchronized with other routers in the area. Failing this, the
OSPF router will not be in the TE calculations of other TE
routers in the area. Refer [FLOOD-OPT] for flooding
optimizations.
2. Unlike the native OSPF, OSPF-TE must be capable of advertising
link state of interfaces that are not capable of handling IP
packet data. As such, the OSPF-TE protocol cannot be required
to synchronize its link-state database with neighbors across
all its links. It is sufficient to synchronize link-state
database in an area, across a subset of the IP termination
links. Yet, the TE LSDB (LSA database) should be synchronized
across all OSPF-TE nodes within an area.
All nodes and interfaces described by the TE LSAs will be
present in the TE topology database (a.k.a. TE LSDB).
3. A link in a packet network can be a TE-link or a native-IP
link or both. There may be different ways by which to use
a link for TE and non-TE traffic. For example, a link may
be used for both types of traffic and satisfy the TE SLA
requirements, so long as the link is under-subscribed for
TE (say, 50% of the link capacity is being used). Once the
TE capacity requirement exceeds the set mark (say, the 50%
mark), the link may be removed from the non-TE topology.
4. This document does not require any changes to the existing OSPF
LSDB implementation. Rather, it suggests the use of another
database, the TE-LSDB, comprised of the TE LSAs, for TE purposes.
5. As a general rule, all nodes and links that may be party
to a TE circuit should be uniquely identifiable by an IP
address. As for router ID, a separate loopback IP address
for the router, independent of the links attached, is
recommended.
6. The assumption about to be stated is principally meant for
non-packet networks such as a SONET TDM network. In non-packet
networks, each IP subnet on a TE-configurable network MUST have
a minimum of one node with an interface running OSPF-TE protocol.
For example, a SONET/SDH TDM ring must have a minimum of one node
(say, a Gateway Network Element) running the OSPF protocol in
order to enable TE configuration on all nodes within the ring.
An OSPF-TE node may advertise more than itself and the links 1. An OSPF-TE node will need to establish router adjacency with
it is directly attached to. It may also advertise other TE at least one other OSPF-TE node in the area in order for the
participants and their links, on their behalf. router's TE-database to be synchronized within the area.
Failing this, the OSPF router will not be in the TE
calculations of other TE routers in the area.
5.3. Limitations It is the responsibility of the network administrator(s) to
ensure connectedness of the TE network. Otherwise, there can
be disjoint TE topologies within a network.
Below are the limitations of the OSPF-TE. 2. OSPF-TE nodes must advertise the link state of its TE-links.
TE-links are not obligated to support native IP traffic.
Hence, an OSPF-TE node cannot be required to synchronize
its link-state database with neighbors on all its links.
The only requirement is to have the TE LSDB synchronized
across all OSPF-TE nodes in the area. Refer [FLOOD-OPT] for
flooding optimizations.
1. Disjoint TE topologies would have the same problem as an 3. A link in a packet network may be designated as a TE-link or
OSPF-TE node not forming adjacencies with any other node. a native-IP link or both. For example, a link may be used for
The disjoint nodes will not be included in the TE topology both TE and non-TE traffic, so long as the link is
of the rest of the TE routers. It will be the under-subscribed in bandwidth for TE traffic - say, 50% of
responsibility of the network administrator(s) to ensure the link capacity is set aside for TE traffic.
connectedness of the TE network.
For example, two routers that are physically connected to 4. Non-packet TE sub-topologies MUST have a minimum of one node
the same link (or broadcast network) need not be router running OSPF-TE protocol. For example, a SONET/SDH TDM ring
adjacent via the Hello protocol, if the link is not IP must have a minimum of one Gateway Network Element(GNE)
packet terminated. running OSPF-TE. The OSPF-TE node will advertise on behalf
of all the in the ring.
6. Transition strategy for implementations using Opaque LSAs 6. Opaque LSAs to OSPF-TE transition strategy
Below is a strategy to transition implementations using opaque Below is a strategy to transition implementations using opaque
LSAs to adapt the new TE LSA scheme in a gradual fashion. LSAs to adapt the OSPF-TE scheme in a gradual fashion.
1. Restrict the use of Opaque-LSAs to within an area. 1. Restrict the use of Opaque-LSAs to within an area.
2. Fold in the TE option flag to construct the TE and non-TE 2. Fold in the TE option flag to construct the TE topologies
topologies in an area, even if the topologies cannot be used area-wise. By doing this, the TE topology for the AS will
for flooding within the area. be available at area level abstraction.
3. Use TE-Summary LSAs and TE-AS-external-LSAs for inter-area 3. Use TE-Summary LSAs and TE-AS-external-LSAs for inter-area
Communication. Make use of the TE-topology within area to Communication. Make use of the TE-topology within an area to
summarize the TE networks in the area and advertise the same summarize the TE networks in the area and advertise the same
to all TE-routers in the backbone. The TE-ABRs on the backbone to all TE-routers in the backbone. The TE-ABRs on the backbone
area will in-turn advertise these summaries again within their area will in-turn advertise these summaries within their
connected areas. connected areas.
7. The OSPF Options field 7. OSPF-TE router adjacency - TE topology discovery
A new TE flag is introduced within the options field to identify OSPF creates adjacencies between neighboring routers for the purpose
TE extensions to the OSPF. This bit will be used to distinguish of exchanging routing information. In the following subsections, we
between routers that support Traffic engineering extensions and describe modifications to the OSPF options field and the use of
those that do not. The OSPF options field is present in OSPF Hello protocol to establish TE capability compliance between
Hello packets, Database Description packets and all link state neighboring routers in an area. The capability is used as the basis
advertisements. The TE bit, however, is a requirement only for to build TE topology.
the Hello packets. Use of TE-bit is optional in Database
Description packets or LSAs. 7.1. The OSPF Options field
A new TE flag is introduced within the options field by this draft
to identify TE extensions to the OSPF. This bit will be used to
distinguish routers that support OSPF-TE. The OSPF options field
is present in OSPF Hello packets, Database Description packets,
and all link state advertisements. The TE bit, however, is a
requirement only for the Hello packets. Use of TE-bit is optional
in Database Description packets or LSAs.
Below is a description of the TE-Bit. Refer [OSPF-V2], [OSPF-NSSA] Below is a description of the TE-Bit. Refer [OSPF-V2], [OSPF-NSSA]
and [OPAQUE] for a description of the remaining bits in options and [OPAQUE] for a description of the remaining bits in the
field. options field.
-------------------------------------- --------------------------------------
|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 will use the TE-bit to
link will use the TE-bit to build adjacencies between two establish OSPF-TE adjacency. Two routers will not become
nodes that are either both TE-compliant or not. Two routers TE-neighbors unless they agree on the state of the TE-bit.
will not become TE-neighbors unless they agree on the state TE-compliant OSPF extensions are advertised only to the
of the TE-bit. TE-compliant OSPF extensions are advertised TE-compliant routers. All other routers may simply ignore
only to the TE-compliant routers. All other routers may the advertisements.
simply ignore the advertisements.
There is however a caveat with the above use of the last remaining There is however a caveat with the above use of the last remaining
reserved bit in the options field. OSPF v2 will have no more reserved bit in the options field. OSPF v2 will have no more
reserved bits left for future option extensions. If it is deemed reserved bits left for future option extensions. If deemed
necessary to leave this bit as is, we could use OPAQUE-9 LSA (Local necessary to leave this bit as is, the OPAQUE-9 LSA (local scope)
scope) along each interface to communicate the support for OSPF-TE. can be used on each interface to communicate the support for
OSPF-TE.
8. Bringing up TE adjacencies; TE vs. Non-TE topologies
OSPF creates adjacencies between neighboring routers for the purpose
of exchanging routing information. In the following subsections, we
describe the use of Hello protocol to establish TE capability
compliance between neighboring routers of an area. Further, the
capability is used as the basis to build a TE vs. non-TE network
topology.
8.1. The Hello Protocol 7.2. The Hello Protocol
The Hello Protocol is primarily responsible for dynamically The Hello Protocol is primarily responsible for dynamically
establishing and maintaining neighbor adjacencies. In a TE network, establishing and maintaining neighbor adjacencies. In a TE network,
it may not be required or possible for all links and neighbors to it is not required for all links and neighbors to establish
establish adjacency using this protocol. adjacency using this protocol. The Hello protocol will use the
TE-bit to establish traffic engineering capability between two
The Hello protocol will use the TE-bit to establish Traffic OSPF routers.
Engineering capability (or not) between two OSPF routers.
For NBMA and broadcast networks, this protocol is responsible for For NBMA and broadcast networks, this protocol is responsible for
electing the designated router and the backup designated router. electing the Designated Router and the Backup Designated Router.
For a TDM ring network, the designated and backup designated For a TDM ring network, the designated and backup designated
routers may either be preselected (ex: GNE, backup-GNE) or routers may either be preselected (ex: GNE, backup-GNE) or
determined via the same Hello protocol. In any case, routers determined via the same Hello protocol. In any case, routers
supporting the TE option shall be given a higher precedence for supporting the TE option shall be given a higher precedence for
becoming a designated router over those that do not support TE. becoming a designated router over those that do not support TE.
8.2. Flooding and the Synchronization of Databases If deemed necessary to leave the TE-bit unused in the options
field, the OSPF-TE routers could use OPAQUE-9 LSA (local scope)
In OSPF, adjacent routers within an area must synchronize their to communicate TE capability between two OSPF routers.
databases. However, as observed in [FLOOD-OPT], the requirement
may be stated more concisely that all routers in an area must
converge on the same link state database. To do that, it suffices
to send single copies of LSAs to the neighboring routers in an
area, rather than send one copy on each of the connected
interfaces. [FLOOD-OPT] describes in detail how to minimize
flooding (Initial LSDB synchronization as well as the
asynchronous LSA updates) within an area.
With the OSPF-TE described here, a TE-only network topology is
constructed based on the TE option flag in the Hello packet.
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
in the area. A network may be constituted of a combination of
a TE topology and a non-TE (control) topology. Standard IP
packet forwarding and routing protocols are possible along the
control topology.
In the case where some of the neighbors are TE compliant and
others are not, the designated router will exchange different
sets of LSAs with its neighbors. TE LSAs are exchanged only
with the TE neighbors. Native LSAs do not include description
for TE links. As such, native LSAs are exchanged with all
neighbors (TE and non-TE alike) over a shared non-TE link.
Flooding optimization in a TE network is essential
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
optimizations help to minimize the announcements and the
associated retransmissions and acknowledgements on the network.
Secondly, the TE nodes need to converge at the earliest to keep
up with TE state changes occurring throughout the TE network.
This process of flooding along a TE topology cannot be folded
into the Opaque-LSA based TE scheme ([OPQLSA-TE]), because
Opaque LSAs (say, LSA #10) have a pre-determined flooding
scope. Even as a TE topology is available from the use of
TE option flag, the TE topology is not usable for flooding
unless a new TE LSA is devised, whose boundaries can be set to
span the TE-only routers in an area.
NOTE, a new All-SPF-TE Multicast address may be used for the
exchange of TE compliant database descriptors.
8.3. The Designated Router 7.3. The Designated Router
The Designated Router is elected by the Hello Protocol on broadcast The Designated Router is elected by the Hello Protocol on broadcast
and NBMA networks. In general, when a router's interface to a and NBMA networks. In general, when a router's non-TE link first
network first becomes functional, it checks to see whether there is becomes functional, it checks to see whether there is currently a
currently a Designated Router for the network. If there is, it Designated Router for the network. If there is one, it accepts that
accepts that Designated Router, regardless of its Router Priority, Designated Router, regardless of its Router Priority, so long as
so long as the current designated router is TE compliant. Otherwise, the current designated router is TE compliant. Otherwise,
the router itself becomes Designated Router if it has the highest the router itself becomes Designated Router if it has the highest
Router Priority on the network and is TE compliant. Router Priority on the network and is TE compliant.
Clearly, TE-compliance must be implemented on the most robust TE-compliance (I.e., OSPF-TE) must be implemented on the most robust
routers only, as they become most likely candidates to take on routers, as they become likely candidates to take on the role as
additional role as designated router. designated router.
Alternatively, there can be two sets of designated routers, one for Alternatively, there can be two sets of designated routers, one for
the TE compliant routers and another for the native OSPF routers the TE compliant routers and another for the native OSPF routers
(non-TE compliant). (non-TE compliant).
8.4. The Backup Designated Router 7.4. The Backup Designated Router
The Backup Designated Router is also elected by the Hello The Backup Designated Router is also elected by the Hello
Protocol. Each Hello Packet has a field that specifies the Protocol. Each Hello Packet has a field that specifies the
Backup Designated Router for the network. Once again, TE-compliance Backup Designated Router for the network. Once again, TE-compliance
must be weighed in conjunction with router priority in determining must be weighed in conjunction with router priority in electing
the backup designated router. Alternatively, there can be two sets the backup designated router.
of backup designated routers, one for the TE compliant routers and
another for the native OSPF routers (non-TE compliant).
8.5. The graph of adjacencies Alternatively, there can be two sets of backup designated routers,
one for the TE compliant routers and another for the native OSPF
routers (non-TE compliant).
An adjacency is bound to the network that the two routers have 7.5. Flooding and the Synchronization of Databases
in common. If two routers have multiple networks in common,
they may have multiple adjacencies between them. The adjacency
may be split into two different types - Adjacency between
TE-compliant routers and adjacency between non-TE compliant
routers. A router may choose to support one or both types of
adjacency.
Two graphs are possible, depending on whether a Designated In OSPF, adjacent routers within an area must synchronize their
Router is elected for the network. On physical point-to-point databases. However, as observed in [FLOOD-OPT], a more concise
networks, Point-to-MultiPoint networks and virtual links, requirement of OSPF is that all routers in an area must converge
neighboring routers become adjacent whenever they can on the same link state database. It is sufficient to send a
communicate directly. The adjacency can only be one of single copy of the LSAs to the neighboring routers in an area
(a) TE-compliant or (b) non-TE compliant. In contrast, on than send one copy on each connected interface. [FLOOD-OPT]
broadcast and NBMA networks the Designated Router and the describes in detail how to minimize flooding (Initial LSDB
Backup Designated Router may maintain two sets of adjacency. synchronization as well as the asynchronous LSA updates) within
However, the remaining routers will participate in either an area.
TE-compliant adjacency or non-TE-compliant adjacency, but not
both. In the Broadcast network below, you will notice that In the case where some of the neighbors are TE compliant and
routers RT7 and RT3 are chosen as the designated and backup others are not, the designated OSPF-TE router will exchange
routers respectively. Within the network, Routers RT3, RT4 different sets of LSAs with its neighbors. TE LSAs are
and RT7 are TE-compliant. RT5 and RT6 are not. So, you will exchanged only with the TE neighbors. Native LSAs are
notice the adjacency variation with RT4 vs. RT5 or RT6. exchanged with all neighbors (TE and non-TE alike).
A new OSPFIGP-TE multicast address 224.0.0.24 may be used for
the exchange of TE compliant database descriptors. Flooding
optimization in a TE network is essential as the control
traffic for a TE network is likely to be higher than that of a
non-TE network. Flooding optimization will help minimize LSA
announcements and the associated retransmissions and
acknowledgements on the network.
7.6. The graph of adjacencies
If two routers have multiple networks in common, they may have
multiple adjacencies between them. The adjacency may be one of
two types - native OSPF adjacency and TE adjacency. OSPF-TE
routers will form both types of adjacency.
Two types of adjacency graphs are possible depending on whether
a Designated Router is elected for the network. On physical
point-to-point networks, Point-to-Multipoint networks and
Virtual links, neighboring routers become adjacent whenever they
can communicate directly. The adjacency can be one of
(a) TE-compliant or (b) native. In contrast, on broadcast and
NBMA networks the designated router and the backup designated
router may maintain two sets of adjacency. The remaining routers
will form either TE-compliant or native adjacency. In the
Broadcast network below, routers RT7 and RT3 are chosen as the
designated and backup routers respectively. Routers RT3, RT4
and RT7 are TE-compliant. RT5 and RT6 are not. So, RT4 will
have TE and native adjacencies with the designated and backup
routers. RT5 and RT6 will only have native adjacency with the
designated and backup routers.
+---+ +---+ +---+ +---+
|RT1|------------|RT2| o---------------o |RT1|------------|RT2| o---------------o
+---+ N1 +---+ RT1 RT2 +---+ N1 +---+ RT1 RT2
RT7 RT7
o:::::::::: o::::::::::
+---+ +---+ +---+ /|: : +---+ +---+ +---+ /|: :
|RT7| |RT3| |RT4| / | : : |RT7| |RT3| |RT4| / | : :
+---+ +---+ +---+ / | : : +---+ +---+ +---+ / | : :
skipping to change at page 20, line 38 skipping to change at page 18, line 25
+-----------------------+ 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.
9. TE LSAs 8. TE LSAs - Packet network
The native OSPF protocol, as of now, has a total of 11 LSA types. The OSPFv2 protocol, as of now, has a total of 11 LSA types.
LSA types 1 through 5 are defined in [OSPF-v2]. LSA types 6, 7 LSA types 1 through 5 are defined in [OSPF-v2]. LSA types 6, 7
and 8 are defined in [MOSPF], [NSSA] and [BGP-OSPF] respectively. and 8 are defined in [MOSPF], [NSSA] and [BGP-OSPF] respectively.
Lastly, LSA types 9 through 11 are defined in [OPAQUE]. LSA types 9 through 11 are defined in [OPAQUE].
Each of the LSA types have a unique flooding scope defined. Each LSA type has a unique flooding scope. Opaque LSA types
Opaque LSA types 9 through 11 are general purpose LSAs, with 9 through 11 are general purpose LSAs, with flooding
flooding scope set to link-local, area-local and AS-wide (except scope set to link-local, area-local and AS-wide (except stub
stub areas) respectively. As will become apparent from this areas) respectively.
document, the general purpose content format and the coarse
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 Values for the new TE LSA types are assigned engineering (TE) use. The Values for the new TE LSA types are
such that the high bit of the LS-type octet is set to 1. The new assigned such that the high bit of the LSA-type octet is set
TE LSAs are largely modeled after the existing LSAs for content to 1. The new TE LSAs are largely modeled after the existing
format and have a custom suited flooding scope. Flooding LSAs for content format and have a unique flooding scope.
optimizations discussed in previous sections shall be used to
disseminate TE LSAs along the TE-restricted topology.
A TE-router LSA is defined to advertise TE characteristics TE-router LSA is defined to advertise TE characteristics of
of the router and all the TE-links attached to the TE-router. an OSPF-TE router and all the TE-links attached to the
TE-Link-Update LSA is defined to advertise individual link router. TE-incremental-Link-Update LSA is defined to
specific TE updates. Flooding scope for both these LSAs is the advertise incremental updates to the metrics of a TE link.
TE topology within the area to which the links belong. I.e., Flooding scope for both these LSAs is restricted to the
only those OSPF nodes within the area with TE links will receive TE nodes in the area.
these TE LSAs.
TE-Summary network and router LSAs are defined to advertise TE-Summary network and router LSAs are defined to advertise
the reachability of area-specific TE networks and Area border the reachability of area-specific TE networks and Area Border
routers(along with router TE characteristics) to external Routers (along with router TE characteristics) to external
areas. Flooding Scope of the TE-Summary LSAs is the TE topology areas. Flooding Scope of the TE-Summary LSAs is the TE topology
in the entire AS less the non-backbone area for which the in the entire AS less the non-backbone area for which the
the advertising router is an ABR. Just as with native OSPF the advertising router is an ABR. Just as with native OSPF
summary LSAs, the TE-summary LSAs do not reveal the topological summary LSAs, the TE-summary LSAs do not reveal the topological
details of an area to external areas. But, the two summary LSAs details of an area to external areas.
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 TE-AS-external LSA and TE-Circuit-Path LSA are defined to
advertise AS external network reachability and pre-established advertise AS external network reachability and pre-engineered
TE circuits respectively. While flooding scope for both TE circuits respectively. While flooding scope for both these
these LSAs can be the TE-topology in the entire AS, flooding LSAs can be the entire AS, flooding scope for the
scope for the pre-established TE circuit LSA may optionally be pre-engineered TE circuit LSA may optionally be restricted to
restricted to just the TE topology within an area. 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.
9.1. TE-Router LSA (0x81) 8.1. TE-Router LSA (0x81)
The TE-router LSA (0x81) is modeled after the router LSA with the The TE-router LSA (0x81) is modeled after the router LSA and has the
same flooding scope as the router-LSA, except that the scope is same flooding scope as the router-LSA. However, the scope is
restricted to TE-only nodes within the area. The TE-router LSA restricted to only the OSPF-TE nodes within the area. The TE-router
describes the TE metrics of the router as well as the TE-links LSA describes the TE metrics of the router as well as the TE-links
attached to the router. Below is the format of the TE-router LSA. attached to the router. Below is the format of the TE-router LSA.
Unless specified explicitly otherwise, the fields carry the same Unless specified explicitly otherwise, the fields carry the same
meaning as they do in a router LSA. Only the differences are meaning as they do in a router LSA. Only the differences are
explained below. Router-TE flags, Router-TE TLVs, Link-TE options, explained below. Router-TE flags, Router-TE TLVs, Link-TE options,
and Link-TE TLVs are each independently described in a separate and Link-TE TLVs are each described in the following sub-sections.
sub-section.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 0x81 | | LS age | Options | 0x81 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID | | Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router | | Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 23, line 8 skipping to change at page 20, line 23
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link ID | | Link ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Data | | Link Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
Option Option
In TE-capable router nodes, the TE-bit may be set to 1. In TE-capable router nodes, the TE-bit may be set to 1.
The following fields are used to describe each router link (i.e., 8.1.1. Router-TE flags - TE capabilities of the router
interface). Each router link is typed (see the below Type field).
The Type field indicates the kind of link being described.
Type
A new link type "Positional-Ring Type" (value 5) is defined.
This is essentially a connection to a TDM-Ring. TDM ring network
is different from LAN/NBMA transit network in that, nodes on the
TDM ring do not necessarily have a terminating path between
themselves. Secondly, the order of links is important in
determining the circuit path. Third, the protection switching
and the number of fibers from a node going into a ring are
determined by the ring characteristics. I.e., 2-fiber vs
4-fiber ring and UPSR vs BLSR protected ring.
Type Description
__________________________________________________
1 Point-to-point connection to another router
2 Connection to a transit network
3 Connection to a stub network
4 Virtual link
5 Positional-Ring Type.
Link ID
Identifies the object that this router link connects to.
Value depends on the link's Type. For a positional-ring type,
the Link ID shall be IP Network/Subnet number, just as with a
broadcast transit network. The following table summarizes the
updated Link ID values.
Type Link ID
______________________________________
1 Neighboring router's Router ID
2 IP address of Designated Router
3 IP network/subnet number
4 Neighboring router's Router ID
5 IP network/subnet number
Link Data
This depends on the link's Type field. For type-5 links, this
specifies the router interface's IP address.
9.1.1. Router-TE flags - TE capabilities of the router
Below is an initial set of definitions. More may be standardized The following flags are used to describe the TE capabilities of an
if necessary. The TLVs are not expanded in the current rev. Will OSPF-TE router. The remaining bits of the 32-bit word are reserved
be done in the follow-on revs. The field imposes a restriction for future use.
of no more than 32 flags to describe the TE capabilities of a
router-TE.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L|L|P|T|L|F| |S|S|S|C| |L|L|P| | | | |L|S|C|
|S|E|S|D|S|S| |T|E|I|S| |S|E|S| | | | |S|I|S|
|R|R|C|M|C|C| |A|L|G|P| |R|R|C| | | | |P|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
skipping to change at page 24, line 32 skipping to change at page 21, line 4
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 LSP
Indicates the node is TDM circuit switch capable. MPLS Label switch TLV TE-NODE-TLV-MPLS-SWITCHING follows.
This is applicable only when the PSC flag is set.
Bit LSC Bit SIG
Indicates the node is Lamda switch Capable. MPLS Signaling protocol support TLV
TE-NODE-TLV-MPLS-SIG-PROTOCOLS follows.
Bit FSC BIT CSPF
Indicates the node is Fiber (can also be a non-fiber link CSPF algorithm support TLV TE-NODE-TLV-CSPF-ALG follows.
type) switch capable.
Bit STA 8.1.2. Router-TE TLVs
Label Stack Depth limit TLV follows. This is applicable only
when the PSC flag is set.
Bit SEL The following Router-TE TLVs are defined.
TE Selection Criteria TLV, supported by the router, follows.
Bit SIG 8.1.2.4. TE-NODE-TLV-MPLS-SWITCHING
MPLS Signaling protocol support TLV follows.
BIT CSPF MPLS switching TLV is applicable only for packet switched nodes. The
CSPF algorithm support TLV follows. TLV specifies the MPLS packet switching capabilities of the TE
node.
9.1.2. Router-TE TLVs 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x8001 | Length = 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label depth | QOS | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following Router-TE TLVs are defined. 'Label depth' is the depth of label stack the node is capable of
processing on its ingress interfaces. An octet is used to represent
label depth. A default value of 1 is assumed when the TLV is not
listed.
TE-selection-Criteria TLV (Tag ID = 1) 'QOS' is a single octet field that may be assigned '1' or '0'. Nodes
supporting QOS are able to interpret the EXP bits in the MPLS header
to prioritize multiple classes of traffic through the same LSP.
The values can be a series of resources that may be used 8.1.2.2. TE-NODE-TLV-MPLS-SIG-PROTOCOLS
as the criteria for traffic engineering (typically with the
aid of a signaling protocol such as RSVP-TE or CR-LDP or LDP).
- Bandwidth based LSPs (1) MPLS signaling protocols TLV lists all the signaling protocol
- Priority based LSPs (2) supported by the node. An octet is used to list each signaling
- Backup LSP (3) protocol supported.
- Link cost (4)
Bandwidth criteria is often used in conjunction with Packet 0 1 2 3
Switch Capable nodes. The unit of bandwidth permitted to be 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
configured may however vary from vendor to vendor. Bandwidth +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
criteria may also be used in conjunction with TDM nodes. Once | Tag = 0x8002 | Length = 5, 6 or 7 |
again, the granularity of bandwidth allocation may vary from +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
vendor to vendor. | Protocol-1 | ... | .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Priority based traffic switching is relevant only to Packet RSVP-TE protocol is represented as 1, CR-LDP as 2 and LDP as 3.
Switch Capable nodes. Nodes supporting this criteria will These are the only permitted signaling protocols at this time.
be able to interpret the EXP bits on the MPLS header to
prioritize the traffic across the same LSP.
Backup criteria refers to whether or not the node is capable 8.1.2.3. TE-NODE-TLV-CSPF-ALGORITHMS
of finding automatic protection path in the case the
originally selected link fails. Such a local recovery is
specific to the node and may not need to be notified to the
upstream node.
MPLS-Signaling protocol TLV (Tag ID = 3) The CSPF algorithms TLV lists all the CSPF algorithm codes
The value can be 2 bytes long, listing a combination of supported. Support for CSPF algorithms makes the node eligible to
RSVP-TE, CR-LDP and LDP. compute complete or partial circuit paths. Support for CSPF
algorithms can also be beneficial in knowing whether or not a node
is capable of expanding loose routes (in an MPLS signaling request)
into a detailed circuit path.
Constraint-SPF algorithms-Support TLV (Tag ID = 4) Two octets are used to list each CSPF algorithm code. The algorithm
List all the CSPF algorithms supported. Support for CSPF codes may be vendor defined and unique within an Autonomous System.
algorithms on a node is an indication that the node may be If the node supports 'n' CSPF algorithms, the Length would be
requested for all or partial circuit path selection during (4 + 4 * ((n+1)/2)) octets.
circuit setup time. This can be beneficial in knowing
whether or not the node is capable of expanding loose
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) 0 1 2 3
Applicable only for PSC-Type traffic. A default value of 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
is assumed. This indicates the depth of label stack the +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
node is capable of processing on an ingress interface. | Tag = 0x8003 | Length = 4(1 + (n+1)/2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSPF-1 | .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSPF-n | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9.1.3. Link-TE options - TE capabilities of a TE-link 8.1.3. Link-TE flags - TE capabilities of a link
The following flags are used to describe the TE capabilities of a
link. The remaining bits of the 32-bit word are reserved for
future use.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|N|P|T|L|F|D| |S|L|B|C| |T|N|P| | | |D| |S|L|B|C|
|E|T|K|D|S|S|B| |R|U|W|O| |E|T|K| | | |B| |R|U|W|O|
| |E|T|M|C|C|S| |L|G|A|L| | |E|T| | | |S| |L|G| |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 IP
packet termination. packet processing.
TDM, LSC, FSC bits
- 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 TE-LINK-TLV-SRLG follows.
LUG bit - Link usage cost metric TLV follows. LUG bit - Link usage cost metric TLV TE-LINK-TLV-LUG follows.
BWA bit - Data Link bandwidth TLV follows. BW bit - Link bandwidth TLV TE-LINK-TLV-BANDWIDTH follows.
COL bit - Data link Color TLV follows. COL bit - Link Color TLV TE-LINK-TLV-COLOR follows.
9.1.4. Link-TE TLVs 8.1.4. Link-TE TLVs
SRLG-TLV
This describes the list of Shared Risk Link Groups the link
belongs to. Use 2 bytes to list each SRLG.
BWA-TLV 8.1.4.1. TE-LINK-TLV-SRLG
This indicates the maximum bandwidth, available bandwidth,
reserved bandwidth for later use etc. This TLV may also
describe the Data link Layer protocols supported and the
Data link MTU size.
LUG-TLV The SRLG describes the list of Shared Risk Link Groups (SRLG) the
This indicates the link usage cost - Bandwidth unit, Unit link belongs to. Two octets are used to list each SRLG. If the link
usage cost, LSP setup cost, minimum and maximum durations belongs to 'n' SRLGs, the Length would be (4 + 4 * ((n+1)/2)) octets.
permitted for setting up the TLV etc., including any time
of day constraints.
COLOR-TLV 0 1 2 3
This is similar to the SRLG TLV, in that an autonomous 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
system may choose to issue colors to link based on a +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
certain criteria. This TLV can be used to specify the | Tag = 0x0001 | Length = 4(1 + (n+1)/2) |
color assigned to the link within the scope of the AS. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG-1 | .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG-n | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9.2. TE-incremental-link-Update LSA (0x8d) 8.1.4.2. TE-LINK-TLV-BANDWIDTH
The bandwidth TLV specifies maximum bandwidth, bandwidth available
for TE use and reserved bandwidth as follows.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0002 | Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth available for TE use |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bandwidth is expressed in units of 32 bytes/sec (256 bits/sec).
A 32-bit field for bandwidth would permit specification not exceeding
1 tera-bits/sec.
'Maximum bandwidth' is be the maximum link capacity expressed in
bandwidth units.
'Bandwidth available for TE use' is the maximum reservable bandwidth
on the link for use by all the TE circuit paths traversing the link.
The link is oversubscribed when this field is more than the
'Maximum Bandwidth'. When the field is less than the
'Maximum Bandwidth', the remaining bandwidth on the link may likely
be used for non-TE traffic.
'Reserved Bandwidth' is the bandwidth that is currently subscribed
from of the link. 'Reserved Bandwidth' must be less than the
'Bandwidth available for TE use'. New TE circuit paths are able to
claim no more than the difference between the two bandwidths for
reservation.
8.1.4.3. TE-LINK-TLV-LUG
The link usage cost TLV specifies Bandwidth unit usage cost,
TE circuit set-up cost, and any time constraints for setup and
teardown of TE circuits on the link.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0003 | Length = 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth unit usage cost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE circuit set-up cost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE circuit set-up time constraint |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE circuit tear-down time constraint |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Circuit Setup time constraint
This 64-bit number specifies the time at or after which a
TE-circuit path may be set up on the link. The set-up time
constraint is specified as the number of seconds from the start
of January 1, 1970 UTC. A reserved value of 0 implies no circuit
setup time constraint.
Circuit Teardown time constraint
This 64-bit number specifies the time at or before which all
TE-circuit paths using the link must be torn down. The teardown
time constraint is specified as the number of seconds from the
start of January 1 1970 UTC. A reserved value of 0 implies no
circuit teardown time constraint.
No. of TE Circuit paths
This specifies the number of pre-engineered TE circuit paths
between the advertising router and the router specified in the
link state ID.
8.1.4.4. TE-LINK-TLV-COLOR
The color TLV is similar to the SRLG TLV, in that an Autonomous
System may choose to issue colors to a TE-link meeting certain
criteria. The color TLV can be used to specify one or more colors
assigned to the link as follows. Two octets are used to list each
color. If the link belongs to 'n' number of colors, the Length
would be (4 + 4 * ((n+1)/2)) octets.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length = 4(1 + (n+1)/2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Color-1 | .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Color-n | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8.2. TE-incremental-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 may be subject to frequent real-time
is more likely to undergo state updates. Specifically, some links circuit pinning and is likely to undergo TE-state updates. Some
might undergo changes more frequently than others. Advertising the links might undergo changes more frequently than others. Flooding
entire TE-router LSA in response to a change in any single link the network with TE-router LSAs at the aggregated speed of all
could be repetitive. Flooding the network with TE-router LSAs at the link metric changes is simply not desirable. A smaller in size,
aggregated speed of all the dynamic changes is simply not desirable. TE-incremental-link-update LSA is designed to advertise only the
The TE-incremental-link-update LSA advertises only the incremental incremental link updates.
link updates.
The TE-incremental-link-Update LSA will be advertised as frequently TE-incremental-link-Update LSA will be advertised as frequently
as the link state is changed. The TE-link sequence is largely the as the link state is changed. The TE-link sequence is largely the
advertisement of a sub-portion of router LSA. The sequence number on advertisement of a sub-portion of router LSA. The sequence number on
this will be incremented with the TE-router LSA's sequence as the this will be incremented with the TE-router LSA's sequence as the
basis. When an updated TE-router LSA is advertised within 30 minutes basis. When an updated TE-router LSA is advertised within 30 minutes
of the previous advertisement, the updated TE-router LSA will assume of the previous advertisement, the updated TE-router LSA will assume
a sequence no. that is larger than the most frequently updated of a sequence no. that is larger than the most frequently updated of
its links. its links.
Below is the format of the TE-incremental-link-update LSA. Below is the format of the TE-incremental-link-update LSA.
skipping to change at page 28, line 41 skipping to change at page 27, line 26
Link State ID Link State ID
This would be exactly the same as would have been specified as This would be exactly the same as would have been specified as
as Link ID for a link within the router-LSA. as Link ID for a link within the router-LSA.
Link Data Link Data
This specifies the router ID the link belongs to. In majority of This specifies the router ID the link belongs to. In majority of
cases, this would be same as the advertising router. This choice cases, this would be same as the advertising router. This choice
for Link Data is primarily to facilitate proxy advertisement for for Link Data is primarily to facilitate proxy advertisement for
incremental link updates. incremental link updates.
Say, a router-proxy-LSa was used to advertise the TE-router-LSA Say, a router-proxy-LSA was used to advertise the TE-router-LSA
of a SONET/TDM node. Say, the proxy router is now required to of a SONET/TDM node. Say, the proxy router is now required to
advertise incremental-link-update for the same SONET/TDM node. advertise incremental-link-update for the same SONET/TDM node.
Specifying the actual router-ID the link in the Specifying the actual router-ID the link in the
incremental-link-update-LSA belongs to helps receiving nodes in incremental-link-update-LSA belongs to helps receiving nodes in
finding the exact match for the LSA in their database. finding the exact match for the LSA in their database.
The tuple of (LS Type, LSA ID, Advertising router) uniquely identify The tuple of (LS Type, LSA ID, Advertising router) uniquely identify
the LSA and replace LSAs of the same tuple with an older sequence the LSA and replace LSAs of the same tuple with an older sequence
number. However, there is an exception to this rule in the context number. However, there is an exception to this rule in the context
of TE-link-update LSA. TE-Link update LSA will initially assume the of TE-link-update LSA. TE-Link update LSA will initially assume the
sequence number of the TE-router LSA it belongs to. Further, when a sequence number of the TE-router LSA it belongs to. Further, when a
new TE-router LSA update with a larger sequence number is advertised, new TE-router LSA update with a larger sequence number is advertised,
the newer sequence number is assumed by al the link LSAs. the newer sequence number is assumed by al the link LSAs.
9.3. TE-Circuit-paths LSA (0x8C) 8.3. TE-Circuit-path LSA (0x8C)
TE-Circuit-paths LSA may be used to advertise the availability of TE-Circuit-path LSA may be used to advertise the availability of
pre-established TE circuit path(s) originating from any router pre-engineered TE circuit path(s) originating from any router
in the network. The flooding scope may be Area wide or AS wide. in 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |G|E|B|D|S|T|CktType| Circuit Duration (Optional) | | 0 |G|E|B|D|S|T|CktType| Circuit Duration (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Circuit Duration cont... | | Circuit Duration cont... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Circuit Duartion cont.. | Circuit Setup time (Optional) | | Circuit Duration cont.. | Circuit Setup time (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Circuit Setup time cont... | | Circuit Setup time cont... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Circuit Setup time cont.. |Circuit Teardown time(Optional)| | Circuit Setup time cont.. |Circuit Teardown time(Optional)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Circuit Teardown time cont... | | Circuit Teardown time cont... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Circuit Teardown time cont.. | No. of TE circuit paths | | Circuit Teardown time cont.. | No. of TE circuit paths |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Circuit-TE ID | | Circuit-TE ID |
skipping to change at page 30, line 41 skipping to change at page 29, line 28
CktType CktType
This 4-bit field specifies the Circuit type of the Forward This 4-bit field specifies the Circuit type of the Forward
Equivalency Class (FC). Equivalency Class (FC).
0x01 - Origin is Router, Destination is Router. 0x01 - Origin is Router, Destination is Router.
0x02 - Origin is Link, Destination is Link. 0x02 - Origin is Link, Destination is Link.
0x04 - Origin is Router, Destination is Link. 0x04 - Origin is Router, Destination is Link.
0x08 - Origin is Link, Destination is Router. 0x08 - Origin is Link, Destination is Router.
Circuit Duration (Optional) Circuit Duration (Optional)
This 64-bit number specifies the seconds from the time of the This 64-bit number specifies the seconds from the time of the
LSA advertisement for which the adversited pre-established LSA advertisement for which the pre-engineered circuit path
TE circuit path will be valid. This field is specified only will be valid. This field is specified only when the D-bit is
when the D-bit is set in the TE-circuit-path flags. set in the TE-circuit-path flags.
Circuit Setup time (Optional) Circuit Setup time (Optional)
This 64-bit number specifies the time at which the TE-circuit This 64-bit number specifies the time at which the TE-circuit
path may be setup. This field is specified only when the path may be set up. This field is specified only when the
S-bit is set in the TE-circuit-path flags. The setup time is S-bit is set in the TE-circuit-path flags. The set-up time is
specified as the number of seconds from the start of January specified as the number of seconds from the start of January
1 1970 UTC. 1 1970 UTC.
Circuit Teardown time (Optional) Circuit Teardown time (Optional)
This 64-bit number specifies the time at which the TE-circuit This 64-bit number specifies the time at which the TE-circuit
path may be torn down. This field is specified only when the path may be torn down. This field is specified only when the
T-bit is set in the TE-circuit-path flags. The teardown time T-bit is set in the TE-circuit-path flags. The teardown time
is specified as the number of seconds from the start of is specified as the number of seconds from the start of
January 1 1970 UTC. January 1 1970 UTC.
No. of TE Circuit paths No. of TE Circuit paths
This indicates the number of pre-established TE circuit paths This specifies the number of pre-engineered TE circuit paths
between the advertising router and the router specified in the between the advertising router and the router specified in the
link state ID. link state ID.
Circuit-TE ID Circuit-TE ID
This is the ID of the far-end router for a given TE-circuit This is the ID of the far-end router for a given TE-circuit
path segment. path segment.
Circuit-TE Data Circuit-TE Data
This is the virtual link identifier on the near-end router for This is the virtual link identifier on the near-end router for
a given TE-circuit path segment. This can be a private a given TE-circuit path segment. This can be a private
interface or handle the near-end router uses to identify the interface or handle the near-end router uses to identify the
virtual link. virtual link.
The sequence of (circuit-TE ID, Circuit-TE Data) list the The sequence of (circuit-TE ID, Circuit-TE Data) list the
end-point nodes and links in the LSA as a series. end-point nodes and links in the LSA as a series.
Circuit-TE flags Circuit-TE flags
This lists the Zero or more TE-link TLVs that all member This lists the Zero or more TE-link TLVs that all member
elements of the LSP meet. elements of the LSP meet.
9.4. TE-Summary LSAs 8.4. TE-Summary LSAs
TE-Summary-LSAs are the Type 0x83 and 0x84 LSAs. These LSAs are TE-Summary-LSAs are the Type 0x83 and 0x84 LSAs. These LSAs are
originated by area border routers. TE-Summary-network-LSA (0x83) originated by area border routers. TE-Summary-network-LSA (0x83)
describes the reachability of TE networks in a non-backbone describes the reachability of TE networks in a non-backbone
area, advertised by the Area Border Router. Type 0x84 area, advertised by the Area Border Router. Type 0x84
summary-LSA describes the reachability of Area Border Routers summary-LSA describes the reachability of Area Border Routers
and AS border routers and their TE capabilities. and AS border routers and their TE capabilities.
One of the benefits of having multiple areas within an AS is One of the benefits of having multiple areas within an AS is
that frequent TE advertisements within the area do not impact that frequent TE advertisements within the area do not impact
outside the area. Only the TE abstractions as befitting the outside the area. Only the TE abstractions befitting the
external areas are advertised. external areas are advertised.
9.4.1. TE-Summary Network LSA (0x83) 8.4.1. TE-Summary Network LSA (0x83)
TE-summary network LSA may be used to advertise reachability of TE-summary network LSA may be used to advertise reachability of
TE-networks accessible to areas external to the originating TE-networks accessible to areas external to the originating
area. The content and the flooding scope of a TE-Summary LSA area. The content and the flooding scope of a TE-Summary LSA
is different from that of a native summary LSA. is different from that of a native summary LSA.
The scope of flooding for a TE-summary network is AS wide, with The scope of flooding for a TE-summary network is AS wide, with
the exception of the originating area and the stub areas. The the exception of the originating area and the stub areas. The
area border router for each non-backbone area is responsible area border router for each non-backbone area is responsible
for advertising the reachability of backbone networks into the for advertising the reachability of backbone networks into the
area. area.
Unlike a native-summary network LSA, TE-summary network LSA does Unlike a native-summary network LSA, TE-summary network LSA does
not advertise summary costs to reach networks within an area. not advertise summary costs to reach networks within an area.
This is because, TE parameters are not necessarily additive or This is because TE parameters are not necessarily additive or
comparative. The parameters can be varied in their expression. comparative. The parameters can be varied in their expression.
A TE-summary network LSA will not be know to summarize a For example, a TE-summary network LSA will not summarize a
network whose links do not fall under an SRLG (Shared-Risk Link network whose links do not fall under an SRLG (Shared-Risk Link
Group). This is way, the TE-summary LSA merely advertises the Group). This way, the TE-summary LSA merely advertises the
reachable of TE networks within an area. The specific circuit reachability of TE networks within an area. The specific circuit
paths can be computed by the BDRs. On the other hand, if there paths can be computed by the BDRs. Pre-engineered circuit paths
are specific circuit paths to advertise, that can be done are advertised using TE-Circuit-path LSA (refer section 8.3).
independently using TE-Circuit-path LSA (refer: section 9.3)
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 0x83 | | LS age | Options | 0x83 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID (IP Network Number) | | Link State ID (IP Network Number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router (Area Border Router) | | Advertising Router (Area Border Router) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number | | LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length | | LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Mask | | Network Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area-ID | | Area-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9.4.2. TE-Summary router LSA (0x84) 8.4.2. TE-Summary router LSA (0x84)
TE-summary router LSA may be used to advertise the availability of TE-summary router LSA may be used to advertise the availability of
Area Border Routers (ABRs) and AS Border Routers (ASBRs) that are Area Border Routers (ABRs) and AS Border Routers (ASBRs) that are
TE capable. The TE-summary router LSAs are originated by the Area TE capable. The TE-summary router LSAs are originated by the Area
Border Routers. The scope of flooding for the TE-summary router LSA Border Routers. The scope of flooding for the TE-summary router LSA
is the non-backbone area the advertising ABR belongs to. is the non-backbone area the advertising ABR belongs 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 33, line 46 skipping to change at page 32, line 30
Advertising Router Advertising Router
The ABR that advertises its TE capabilities (and the OSPF areas The ABR that advertises its TE capabilities (and the OSPF areas
it belongs to) or the TE capabilities of an ASBR within one of it belongs to) or the TE capabilities of an ASBR within one of
the areas the ABR is a border router of. the areas the ABR is a border router of.
No. of Areas No. of Areas
Specifies the number of OSPF areas the link state ID belongs to. Specifies the number of OSPF areas the link state ID belongs to.
Area-ID Area-ID
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, the
lists all the areas the ABR belongs to. In the case the Area-ID lists all the areas the ABR belongs to. In the case
link state ID is an ASBR, this simply lists the area the the link state ID is an ASBR, the Area-ID simply lists the
ASBR belongs to. The advertising router is assumed to be the area the ASBR belongs to. The advertising router is assumed to
ABR from the same area the ASBR is located in. be the 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.
9.5. TE-AS-external LSAs (0x85) 8.5. TE-AS-external LSAs (0x85)
TE-AS-external-LSAs are the Type 0x85 LSAs. This is modeled after TE-AS-external-LSAs are the Type 0x85 LSAs. This is modeled after
AS-external LSA format and flooding scope. These LSAs are originated AS-external LSA format and flooding scope. TE-AS-external LSAs are
by AS boundary routers with TE extensions (say, a BGP node which can originated by AS boundary routers with TE extensions, and describe
communicate MPLS labels across to external ASes), and describe the TE networks and pre-engineered circuit paths external to the
networks and pre-established TE links external to the AS. The AS. As with AS-external LSA, the flooding scope of the
flooding scope of this LSA is similar to that of an AS-external LSA. TE-AS-external LSA is AS wide, with the exception of stub areas.
I.e., AS wide, with the exception of stub areas.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 0x85 | | LS age | Options | 0x85 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID | | Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router | | Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 35, line 22 skipping to change at page 34, line 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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-established 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.
9.6. Changes to Network LSA 9. TE LSAs - Non-packet network
A non-packet network would use all the TE LSAs described in the
previous section for a packet network, albeit with some variations.
These variations are described in the following subsections.
TE-Router-Proxy LSA is defined to allow proxy advertisement for
non-packet TE-nodes by an OSPF-TE router.
9.1. TE-Router LSA (0x81)
The following fields are used to describe each router link (i.e.,
interface). Each router link is typed (see the below Type field).
The Type field indicates the kind of link being described.
Type
A new link type "Positional-Ring Type" (value 5) is defined.
This is essentially a connection to a TDM-Ring. TDM ring network
is different from LAN/NBMA transit network in that nodes on the
TDM ring do not necessarily have a terminating path between
themselves. Secondly, the order of links is important in
determining the circuit path. Third, the protection switching
and the number of fibers from a node going into a ring are
determined by the ring characteristics. I.e., 2-fiber vs
4-fiber ring and UPSR vs BLSR protected ring.
Type Description
__________________________________________________
1 Point-to-point connection to another router
2 Connection to a transit network
3 Connection to a stub network
4 Virtual link
5 Positional-Ring Type.
Link ID
Identifies the object that this router link connects to.
Value depends on the link's Type. For a positional-ring type,
the Link ID shall be IP Network/Subnet number just as the case
with a broadcast transit network. The following table
summarizes the updated Link ID values.
Type Link ID
______________________________________
1 Neighboring router's Router ID
2 IP address of Designated Router
3 IP network/subnet number
4 Neighboring router's Router ID
5 IP network/subnet number
Link Data
This depends on the link's Type field. For type-5 links, this
specifies the router interface's IP address.
9.1.1. Router-TE flags - TE capabilities of the router
Flags specific to non-packet TE-nodes are described below.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L|L|P|T|L|F| |S|S|S|C|
|S|E|S|D|S|S| |T|E|I|S|
|R|R|C|M|C|C| |A|L|G|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|<---- Boolean TE flags ------->|<- TE flags pointing to TLVs ->|
Bit TDM
Indicates the node is TDM circuit switch capable.
Bit LSC
Indicates the node is Lambda switch Capable.
Bit FSC
Indicates the node is Fiber (can also be a non-fiber link
type) switch capable.
9.1.2. Link-TE options - TE capabilities of a TE-link
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|N|P|T|L|F|D| |S|L|B|C|
|E|T|K|D|S|S|B| |R|U|W|O|
| |E|T|M|C|C|S| |L|G|A|L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|<---- Boolean TE flags ------->|<- TE flags pointing to TLVs ->|
TDM, LSC, FSC bits
- Same as defined for router TE options.
9.2. Changes to Network LSA
Network-LSA is the Type 2 LSA. With the exception of the following, Network-LSA is the Type 2 LSA. With the exception of the following,
no additional changes will be required to this LSA for TE no additional changes will be required to this LSA for TE
compatibility. The LSA format and flooding scope remains unchanged. compatibility. The LSA format and flooding scope 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.
9.6.1. Positional-Ring type network LSA - New Network type for TDM-ring. 9.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-Fiber vs. 4-Fiber, 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 is 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 Network Elements (NEs) are
is pertinent. The nodes in the ting must be described clock wise, placed on a RING-network is pertinent. The nodes in the ring
assuming the GNE as the starting element. must be described clock wise, assuming the Gateway Network
Element (GNE) as the starting element.
9.7. TE-Router-Proxy LSA (0x8e) 9.3. TE-Router-Proxy LSA (0x8e)
This is a variation to the TE-router LSA in that the TE-router LSA This is a variation to the TE-router LSA in that the TE-router LSA
is not advertised by the network element, but rather by a trusted is not advertised by the network element, but rather by a trusted
TE-router Proxy. This is typically the scenario in a non-packet TE-router Proxy. This is typically the scenario in a non-packet
TE network, where some of the nodes do not have OSPF functionality TE network, where some of the nodes do not have OSPF functionality
and count on a helper node to do the advertisement for them. One and count on a helper node to do the advertisement for them. One
such example would be the SONET/SDH ADM nodes in a TDM ring. The such example would be the SONET/SDH ADM nodes in a TDM ring. The
nodes may principally depend upon the GNE (Gateway Network Element) nodes may principally depend upon the GNE (Gateway Network Element)
to do the advertisement for them. TE-router-Proxy LSA shall not be to do the advertisement for them. TE-router-Proxy LSA shall not be
used to advertise Area Border Routers and/or AS border Routers. used to advertise Area Border Routers and/or AS border Routers.
skipping to change at page 37, line 19 skipping to change at page 37, line 44
| 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
9.8. Others
We may also introduce a new TE-NSSA LSA, similar to the native-NSSA
LSA. TE-NSSA will help ensure that not all external TE routes are
flooded into the NSSA area. A TE capable router can become the NSSA
translator. All parameters and contents of TE-NSSA LSAs are
transferred as is.
10. Abstract topology representation with TE support 10. Abstract topology representation with TE support
Below, we assume a TE network that is composed of three OSPF areas, Below, we consider a TE network composed of three OSPF areas -
namely Area-1, Area-2 and Area-3, attached together through the Area-1, Area-2 and Area-3, attached together through the backbone
backbone area. The following figure is an inter-area topology area. Area-1 an has a single area border router, ABR-A1 and no
abstraction from the perspective of routers in Area-1. The ASBRs. Area-2 has an area border router ABR-A2 and an AS border
abstraction is similar, but not the same, as that of the non-TE router ASBR-S1. Area-3 has two area border routers ABR-A2 and
abstraction. As such, the authors claim the model is easy to ABR-A3 and an AS border router ASBR-S2. The following network
understand and emulate. The abstraction illustrates reachability also assumes a pre-engineered TE circuit path between ABR-A1
of TE networks and nodes in areas external to the local area and and ABR-A2; between ABR-A1 and ABR-A3; between ABR-A2 and
ASes external to the local AS. The abstraction also illustrates ASBR-S1; and between ABR-A3 and ASBR-S2.
pre-established TE links that may be advertised by ABRs and ASBRs.
Area-1 an has a single border router, ABR-A1 and no ASBRs. Area-2 The following figure is an inter-area topology abstraction
has an Area border router ABR-A2 and an AS border router ASBR-S1. from the perspective of routers in Area-1. The abstraction
Area-3 has two Area border routers ABR-A2 and ABR-A3; and an AS illustrates reachability of TE networks and nodes within area
border router ASBR-S2. There may be any number of Pre-engineered to the external areas in the same AS and to the external ASes.
TE links amongst ABRs and ASBRs. The following example assumes a The abstraction also illustrates pre-engineered TE circuit
single TE-link between ABR-A1 and ABR-A2; between ABR-A1 and paths advertised by ABRs and ASBRs.
ABR-A3; between ABR-A2 to ASBR-S1; and between ABR-A3 to ASBR-S2.
All Area border routers and AS border routers are assumed to
be represented by their TE capabilities.
+-------+ +-------+
|Area-1 | |Area-1 |
+-------+ +-------+
+-------------+ | +-------------+ |
|Reachable TE | +------+ |Reachable TE | +--------+
|networks in |--------|ABR-A1| |networks in |-------| ABR-A1 |
|backbone area| +------+ |backbone area| +--------+
+-------------+ | | | +-------------+ | | |
+-------------+ | +-------------------+ +--------------+ | +-----------------+
| | | | | |
+-----------------+ | +-----------------+ +-----------------+ | +-----------------+
|Pre-engineered TE| +----------+ |Pre-engineered TE| |Pre-engineered TE| +----------+ |Pre-engineered TE|
|circuit path(s) | | Backbone | |circuit path(s) | |circuit path(s) | | Backbone | |circuit path(s) |
|to ABR-A2 | | Area | |to ABR-A3 | |to ABR-A2 | | Area | |to ABR-A3 |
+-----------------+ +----------+ +-----------------+ +-----------------+ +----------+ +-----------------+
| | | | | | | |
+----------+ | | | +----------+ | +--------------+ |
| | +--------------+ |
+-----------+ | | | | +-----------+ +-----------+ | | | | +-----------+
|Reachable | +------------+ +------+ |Reachable | |Reachable | +--------+ +--------+ |Reachable |
|TE networks|---| ABR-A2 | |ABR-A3|--|TE networks| |TE networks|------| ABR-A2 | | ABR-A3 |--|TE networks|
|in Area A2 | +------------+ +------+ |in Area A3 | |in Area A2 | +--------+ +--------+ |in Area A3 |
+-----------+ / | | | | | +-----------+ +-----------+ | | | | | | +-----------+
/ | | +-------------------+ | +----------+ +-------------+ | | +-----------------+ | +----------+
/ | +-------------+ | | | | | +-----------+ | | |
+-----------+ +--------------+ | | | +--------------+ +-----------+ +--------------+ | | | +--------------+
|Reachable | |Pre-engineered| | | | |Pre-engineered| |Reachable | |Pre-engineered| | | | |Pre-engineered|
|TE networks| |TE Ckt path(s)| +------+ +------+ |TE Ckt path(s)| |TE networks| |TE Ckt path(s)| +------+ +------+ |TE Ckt path(s)|
|in Area A3 | |to ASBR-S1 | |Area-2| |Area-3| |to ASBR-S2 | |in Area A3 | |to ASBR-S1 | |Area-2| |Area-3| |to ASBR-S2 |
+-----------+ +--------------+ +------+ +------+ +--------------+ +-----------+ +--------------+ +------+ +------+ +--------------+
| / | / | | | |
+-------------+ | / | / | +--------+ | +-----------+
|AS external | +---------+ +-------------+ +-------------+ | | | |
|TE-network |------| ASBR-S1 | | ASBR-S2 | |AS external | +---------+ +---------+
|reachability | +---------+ +-------------+ |TE-network |----| ASBR-S1 | | ASBR-S2 |
|from ASBR-S1 | | | | |reachability | +---------+ +---------+
+-------------+ | | | |from ASBR-S1 | | | |
+-----------------+ +-------------+ +-----------------+ +-------------+ +---+ +-------+ +-----------+
|Pre-engineered TE| |AS External | |Pre-engineered TE| | | |
|circuit path(s) | |TE-Network | |circuit path(s) | +-----------------+ +-------------+ +-----------------+
|reachable from | |reachability | |reachable from | |Pre-engineered TE| |AS External | |Pre-engineered TE|
|ASBR-S1 | |from ASBR-S2 | |ASBR-S2 | |circuit path(s) | |TE-Network | |circuit path(s) |
+-----------------+ +-------------+ +-----------------+ |reachable from | |reachability | |reachable from |
|ASBR-S1 | |from ASBR-S2 | |ASBR-S2 |
+-----------------+ +-------------+ +-----------------+
Figure 9: Inter-Area Abstraction as viewed by Area-1 TE-routers Figure 9: Inter-Area Abstraction as viewed by Area-1 TE-routers
11. Changes to Data structures in OSPF-TE nodes 11. Changes to Data structures in OSPF-TE nodes
11.1. Changes to Router data structure 11.1. Changes to Router data structure
The router with TE extensions must be able to include all the The router with TE extensions must be able to include all the
TE capabilities (as specified in section 7.1) in the router data TE capabilities (as specified in section 7.1) in the router data
structure. Further, routers providing proxy service to other TE structure. Further, routers providing proxy service to other TE
routers must also track the router and associated interface data routers must also track the router and associated interface data
structures for all the TE client nodes for which the proxy structures for all the TE client nodes for which the proxy
service is being provided. Presumably, the interaction between service is being provided. Presumably, the interaction between
the Proxy server and the proxy clients is out-of-band. the Proxy server and the proxy clients is out-of-band.
11.2. Two set of Neighbors 11.2. Two sets of Neighbors
Two sets of neighbor data structures will need to be maintained. Two sets of neighbor data structures are required. TE-neighbors
TE-neighbors set is used to advertise TE LSAs. Only the TE-nodes set is used to advertise TE LSAs. Only the TE-nodes will be
will be members of the TE-neighbor set. Native neighbors set will members of the TE-neighbor set. Native neighbors set will be used
be used to advertise native LSAs. All neighboring nodes supporting to advertise native LSAs. All neighboring nodes supporting
non-TE links can be part of this set. As for flooding optimizations non-TE links are part of this set. As for flooding optimizations
based on neighbors set, readers may refer [FLOOD-OPT]. based on neighbors set, readers may refer [FLOOD-OPT].
11.3. Changes to Interface data structure 11.3. Changes to Interface data structure
The following new fields are introduced to the interface data The following new fields are introduced to the interface data
structure. These changes are in addition to the changes specified structure. These changes are in addition to the changes specified
in [FLOOD-OPT]. in [FLOOD-OPT].
TePermitted TePermitted
If the value of the flag is TRUE, the interface is permissible If the value of the flag is TRUE, the interface may be
to be advertised as a TE-enabled interface. 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 IP
packets. For FSC and LSC TE networks, this flag will be set to packets. For FSC and LSC TE networks, this flag is set to
FALSE. For Packet networks that do not permit non-TE traffic on FALSE.
TE links also, this flag is set to TRUE.
PktTerminated IpTerminated
If the value of the flag is TRUE, the interface terminates If the value of the flag is TRUE, the interface processes IP
Packet data and hence may be used for IP and OSPF data exchange. Packet data and hence may be used for 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 IpTerminated 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
for some of the interfaces. for some of the interfaces.
TE-TLVs TE-TLVs
Each interface may potentially have a maximum of 16 TLVS that Each interface may potentially have a maximum of 16 TLVS that
describe the link characteristics. describe the link characteristics.
The following existing fields in Interface data structure will take The following existing fields in Interface data structure will take
on additional values to support TE extensions. on additional values to support TE extensions.
Type Type
The OSPF interface type can also be of type "Positional-RING". The OSPF interface type can also be of type "Positional-RING".
The Positional-ring type is different from other types (such The Positional-ring type is different from other types (such
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 though 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.
12. IANA Considerations 12. IANA Considerations
12.1. TE-compliant-SPF routers Multicast address allocation This document proposes that TE LSA types and TE TLVs be
maintained by the IANA. The document also proposes an OSPFIGP-TE
multicast address be assigned by the IANA for the exchange of
TE database descriptors.
12.2. New TE-LSA Types OSPFIGP-TE multicast address is suggested a value of 224.0.0.24
so as not to conflict with the recognized multicast address
definitions, as defined in
http://www.iana.org/assignments/multicast-addresses
12.3. New TLVs (Router-TE and Link-TE TLVs) The following sub-section explains the criteria to be used by the
IANA to assign TE LSA types and TE TLVs.
12.3.1. TE-selection-Criteria TLV (Tag ID = 1) 12.1. TE LSA type values
- Bandwidth based LSPs (1)
- Priority based LSPs (2)
- Backup LSP (3)
- Link cost (4)
12.3.2. MPLS-Signaling protocol TLV (Tag ID = 3) LSA type is an 8-bit field required by each LSA. TE LSA types
- RSVP-TE signaling will have the high bit set to 1. TE LSAs can range from 0x80
- LDP signaling through 0xFF. The following values are defined in sections
- CR-LDP signaling 8.0 and 9.0. The remaining values are available for assignment
by the IANA with IETF Consensus [Ref 11].
12.3.3. Constraint-SPF algorithms-Support TLV (Tag ID = 4) TE LSA Type Value
- CSPF Algorithm Codes. _________________________________________
12.3.4. SRLG-TLV (Tag ID = 0x81) TE-Router LSA 0x81
- SRLG group IDs TE-Summary Network LSA 0x83
12.3.5. BW-TLV (Tag ID = 0x82) TE-Summary router LSA 0x84
TE-AS-external LSAs 0x85
TE-Circuit-paths LSA 0x8C
TE-incremental-link-Update LSA 0x8d
TE-Router-Proxy LSA 0x8e
12.3.6 CO-TLV (Tag ID = 0x83) 12.2. TE TLV tag values
TLV type is a 16-bit field required by each TE TLV. TLV type
shall be unique across the router and link TLVs. A TLV type
can range from 0x0001 through 0xFFFF. TLV type 0 is reserved
and unassigned. The following TLV types are defined in sections
8.0 and 9.0. The remaining values are available for assignment
by the IANA with IETF Consensus [Ref 11].
TE TLV Tag Reference Value
Section
_________________________________________________________
TE-LINK-TLV-SRLG Section 8.1.4.1 0x0001
TE-LINK-TLV-BWA Section 8.1.4.2 0x0002
TE-LINK-TLV-LUG Section 8.1.4.3 0x0003
TE-LINK-TLV-COLOR Section 8.1.4.4 0x0004
TE-NODE-TLV-MPLS-SWITCHING Section 8.1.2.1 0x8001
TE-NODE-TLV-MPLS-SIG-PROTOCOLS Section 8.1.2.2 0x8002
TE-NODE-TLV-CSPF-ALG Section 8.1.2.3 0x8003
13. Acknowledgements 13. Acknowledgements
The authors wish to thank Vishwas Manral, Chitti Babu, Riyad The authors wish to specially thank Chitti Babu and his team
for verifying portions of the specification for a packet
network. The authors also wish to thank Vishwas Manral, Riyad
Hartani and Tricci So for their valuable comments and feedback Hartani and Tricci So for their valuable comments and feedback
on the draft. on the draft.
14. Security Considerations 14. Security Considerations
This memo does not create any new security issues for the OSPF Security considerations for the base OSPF protocol are covered
protocol. Security considerations for the base OSPF protocol are in [OSPF-v2] and [SEC-OSPF]. This memo does not create any new
covered in [OSPF-v2]. As a general rule, a TE network is likely security issues for the OSPF protocol. Security measures
to generate significantly more control traffic than a native applied to the native OSPF (refer [SEC-OSPF]) are directly
OSPF network. The excess traffic is almost directly proportional applicable to the TE LSAs described in the document. Discussed
to the rate at which TE circuits are setup and torn down within below are the security considerations in processing TE LSAs.
an autonomous system. It is important to ensure that TE database
synchronizations happen quickly when compared to the aggregate
circuit setup an tear-down rates.
REFERENCES Secure communication between OSPF-TE nodes has a number of
components. Authorization, authentication, integrity and
confidentiality. Authorization refers to whether a particular
OSPF-TE node is authorized to receive or propagate the TE LSAs
to its neighbors. Failing the authorization process might
indicate a resource theft attempt or unauthorized resource
advertisement. In either case, the OSPF-TE nodes should take
proper measures to audit/log such attempts so as to alert the
administrator to take necessary action. OSPF-TE nodes may refuse
to communicate with the neighboring nodes that fail to prompt
the required credentials.
[IETF-STD] Bradner, S., " The Internet Standards Process -- Authentication refers to confirming the identity of an originator
Revision 3", RFC 1602, IETF, October 1996. for the datagrams received from the originator. Lack of strong
credentials for authentication of OSPF-TE LSAs can seriously
jeopardize the TE service rendered by the network. A consequence
of not authenticating a neighbor would be that an attacker could
spoof the identity of a "legitimate" OSPF-TE node and manipulate
the state, and the TE database including the topology and
metrics collected. This could potentially lead to
denial-of-service on the TE network. Another consequence of not
authenticating is that an attacker could pose as OSPF-TE neighbor
and respond in a manner that would divert TE data to the attacker.
Integrity is required to ensure that an OSPF-TE message has not
been accidentally or maliciously altered or destroyed. The result
of a lack of data integrity enforcement in an untrusted environment
could be that an imposter will alter the messages sent by a
legitimate adjacent neighbor and bring the OSPF-TE on a node and
the whole network to a halt or cause a denial of service for the
TE circuit paths effected by the alteration.
Confidentiality of MIDCOM messages ensure that the TE LSAs are
accessible only to the authorized entities. When OSPF-TE is
deployed in an untrusted environment, lack of confidentiality will
allow an intruder to perform traffic flow analysis and snoop the
TE control network to monitor the traffic metrics and the rate at
which circuit paths are being setup and torn-down. The intruder
could cannibalize a lesser secure OSPF-TE node and destroy or
compromise the state and TE-LDSB on the node. Needless to say, the
least secure OSPF-TE will become the achilles heel and make the TE
network vulnerable to security attacks.
15. Normative References
[IETF-STD] Bradner, S., "Key words for use in RFCs to indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 1700] J. Reynolds and J. Postel, "Assigned Numbers", [RFC 1700] J. Reynolds and J. Postel, "Assigned Numbers",
RFC 1700 RFC 1700
[RFC 2434] Narten, T. and H. Alvestrand, "Guidelines for
writing an IANA Considerations Section in RFCs",
BCP 26, RFC 2434, October 1998.
[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.
[OSPF-v2] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
[SEC-OSPF] Murphy, S., Badger, M., and B. Wellington, "OSPF with
Digital Signatures", RFC 2154, June 1997
[FLOOD-OPT] Zinin, A. and M. Shand, "Flooding Optimizations in
link-state routing protocols", work in progress,
<draft-ietf-ospf-isis-flood-opt-01.txt>
15. Informative References
[GMPLS-TE] P.A. Smith et. al, "Generalized MPLS - Signaling [GMPLS-TE] P.A. Smith et. al, "Generalized MPLS - Signaling
Functional Description", work in progress, Functional Description", work in progress,
draft-ietf-mpls-generalized-signaling-03.txt draft-ietf-mpls-generalized-signaling-09.txt
[RSVP-TE] Awduche, D., L. Berger, D. Gan, T. Li, V. Srinivasan, [RSVP-TE] Awduche, D., L. Berger, D. Gan, T. Li, V. Srinivasan,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC3209, IETF, December 2001 Tunnels", RFC3209, IETF, December 2001
[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-06.txt, using LDP", draft-ietf-mpls-cr-ldp-06.txt,
Work in Progress. Work in Progress.
[OSPF-v2] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
[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-11.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.
[FLOOD-OPT] Zinin, A. and M. Shand, "Flooding Optimizations in
link-state routing protocols", work in progress,
<draft-ietf-ospf-isis-flood-opt-01.txt>
[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-06.txt> <draft-katz-yeung-ospf-traffic-09.txt>
[OPQLSA-GMPLS] Kompella, K., Y. Rekhter, A. Banerjee, J. Drake, [OPQLSA-GMPLS] Kompella, K., Y. Rekhter, A. Banerjee, J. Drake,
G. Bernstein, D. Fedyk, E. Mannie, D. Saha and G. Bernstein, D. Fedyk, E. Mannie, D. Saha and
V. Sharma, "OSPF Extensions in Support of Generalized V. Sharma, "OSPF Extensions in Support of Generalized
MPLS", <draft-ietf-ccamp-ospf-gmpls-extensions-01.txt>, MPLS", <draft-ietf-ccamp-ospf-gmpls-extensions-09.txt>,
work in progress. work in progress.
Authors' Addresses Authors' Addresses
Pyda Srisuresh Pyda Srisuresh
Kuokoa Networks, Inc. Kuokoa Networks, Inc.
475 Potrero Avenue 475 Potrero Avenue
Sunnyvale, CA 94085 Sunnyvale, CA 94085
U.S.A. U.S.A.
EMail: srisuresh@yahoo.com EMail: srisuresh@yahoo.com
 End of changes. 225 change blocks. 
1030 lines changed or deleted 1090 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/