< draft-srisuresh-ospf-te-04.txt   draft-srisuresh-ospf-te-05.txt >
Network Working Group P. Srisuresh Network Working Group P. Srisuresh
INTERNET-DRAFT Kuokoa Networks INTERNET-DRAFT Consultant
Expires as of June 8, 2003 P. Joseph Expires as of August 7, 2003 P. Joseph
Force10 Networks Force10 Networks
December 8, 2002 February 7, 2003
OSPF-TE: An experimental extension to OSPF for Traffic Engineering OSPF-xTE: An experimental extension to OSPF for Traffic Engineering
<draft-srisuresh-ospf-te-04.txt> <draft-srisuresh-ospf-te-05.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
This document defines OSPF-TE, an experimental traffic engineering This document defines OSPF-xTE, an experimental traffic engineering
(TE) extension to the link-state routing protocol OSPF. New TE (TE) extension to the link-state routing protocol OSPF. New TE LSAs
LSAs are designed to disseminate TE metrics within an autonomous are defined to disseminate TE metrics within an autonomous
System (AS) - intra-area as well as inter-area. An Autonomous System (AS) - intra-area as well as inter-area. An Autonomous
System may consist of TE and non-TE nodes. Non-TE nodes are System may consist of TE and non-TE nodes. Non-TE nodes are
uneffected by the distribution of TE LSAs. A stand-alone TE Link uneffected by the distribution of TE LSAs. A stand-alone TE Link
State Database (TE-LSDB), separate from the native OSPF LSDB, is State Database (TE-LSDB), separate from the native OSPF LSDB, is
generated for the computation of TE circuit paths. OSPF-TE is generated for the computation of TE circuit paths. OSPF-xTE is
also extendible to non-packet networks such as SONET/TDM and also extendible to non-packet networks such as SONET/TDM and
optical networks. A transition path is provided for those optical networks. A transition path is provided for those using
currently using [OPQLSA-TE] and wish to adapt OSPF-TE. [OPQLSA-TE] and wish to adapt OSPF-xTE.
Table of Contents Table of Contents
1. Introduction ................................................3 1. Introduction ................................................3
2. Principles of traffic engineering ...........................3 2. Principles of traffic engineering ...........................3
3. Terminology .................................................5 3. Terminology .................................................4
3.1. TE node ................................................5 3.1. Native OSPF terms ......................................4
3.2. TE link ................................................5 3.2. OSPF-xTE terms .........................................5
3.3. TE circuit path ........................................5 4. Motivations behind the design of OSPF-xTE ...................8
3.4. OSPF-TE node ...........................................6 4.1. Scalable design ........................................8
3.5. TE control network .....................................6 4.2. Operable in mixed and peer networks ....................9
3.6. TE network (TE topology) ...............................6
3.7. Packet-TE network ......................................6
3.8. Non-packet-TE network ..................................6
3.9. Native (non-TE) node ...................................7
3.10. Native (non-TE) link ..................................7
3.11. Non-TE network (Non-TE topology) ......................7
3.12. Peer network (combination network) ....................7
3.13. LSP ...................................................7
3.14. LSA ...................................................7
3.14. LSDB ..................................................7
3.15. CSPF ..................................................7
3.16. TLV ...................................................8
3.17. Router-TE TLVs ........................................8
3.18. Link-TE TLVs ..........................................8
4. Motivations behind the design of OSPF-TE ....................8
4.1. Scalable design ........................................9
4.2. Coexistent design ......................................9
4.3. Efficient in flooding reach ............................9 4.3. Efficient in flooding reach ............................9
4.4. Ability to reserve TE-exclusive links .................10 4.4. Ability to reserve TE-exclusive links .................10
4.5. Extendible design .....................................10 4.5. Extendible design .....................................10
4.6. Unified for packet and non-packet networks ............11 4.6. Unified for packet and non-packet networks ............10
4.7. Networks benefiting from the OSPF-TE design ...........11 4.7. Networks benefiting from the OSPF-xTE design ..........11
5. OSPF-TE solution overview ..................................12 5. OSPF-xTE solution overview .................................12
5.1. OSPF-TE Solution ......................................12 5.1. OSPF-xTE Solution .....................................12
5.2. Assumptions ...........................................13 5.2. Assumptions ...........................................13
6. Opaque LSAs to OSPF-TE transition strategy .................14 6. Opaque LSAs to OSPF-xTE transition strategy ................14
7. OSPF-TE router adjacency - TE topology discovery ...........14 7. OSPF-xTE router adjacency - TE topology discovery ..........14
7.1. The OSPF Options field ................................15 7.1. The OSPF Options field ................................15
7.2. The Hello Protocol ....................................15 7.2. The Hello Protocol ....................................15
7.3. Flooding and the Synchronization of Databases .........16 7.3. Flooding and the Synchronization of Databases .........16
7.4. The Designated Router .................................16 7.4. The Designated Router .................................16
7.5. The Backup Designated Router ..........................16 7.5. The Backup Designated Router ..........................16
7.6. The graph of adjacencies ..............................17 7.6. The graph of adjacencies ..............................17
8. TE LSAs - Packet network ...................................18 8. TE LSAs for packet network .................................18
8.1. TE-Router LSA (0x81) ..................................19 8.1. TE-Router LSA (0x81) ..................................19
8.2. TE-incremental-link-Update LSA (0x8d) .................26 8.2. TE-incremental-link-Update LSA (0x8d) .................28
8.3. TE-Circuit-paths LSA (0x8C) ...........................27 8.3. TE-Circuit-paths LSA (0x8C) ...........................30
8.4. TE-Summary LSAs .......................................30 8.4. TE-Summary LSAs .......................................32
8.5. TE-AS-external LSAs (0x85) ............................33 8.5. TE-AS-external LSAs (0x85) ............................35
9. TE LSAs - Non-packet network ...............................34 9. TE LSAs for non-packet network .............................37
9.1. TE-Router LSA (0x81) ..................................34 9.1. TE-Router LSA (0x81) ..................................37
9.2. Changes to Network LSA ................................36 9.2. TE-Positional-ring-network LSA (0x82) .................39
9.3. TE-Router-Proxy LSA (0x8e) ............................36 9.3. TE-Router-Proxy LSA (0x8e) ............................41
10. Abstract topology representation with TE support ...........37 10. Abstract topology representation with TE support ...........42
11. Changes to Data structures in OSPF-TE routers ..............40 11. Changes to Data structures in OSPF-xTE routers .............44
11.1. Changes to Router data structure .....................40 11.1. Changes to Router data structure .....................44
11.2. Two set of Neighbors .................................40 11.2. Two set of Neighbors .................................44
11.3. Changes to Interface data structure ..................40 11.3. Changes to Interface data structure ..................44
12. IANA Considerations ........................................41 12. IANA Considerations ........................................45
12.1. TE LSA type values ...................................41 12.1. TE LSA type values ...................................45
12.2. TE TLV tag values ....................................42 12.2. TE TLV tag values ....................................46
13. Acknowledgements ...........................................42 13. Acknowledgements ...........................................46
14. Security Considerations ....................................42 14. Security Considerations ....................................47
15. Normative References .......................................44 15. Normative References .......................................48
16. Informative References .....................................44 16. Informative References .....................................48
1. Introduction 1. Introduction
This document defines OSPF-TE, an experimental traffic engineering This document defines OSPF-xTE, an experimental traffic
(TE) extension to the link-state routing protocol OSPF. The engineering (TE) extension to the link-state routing protocol
objective of OSPF-TE is to discover TE network topology and OSPF. The objective of OSPF-xTE is to discover TE network
disseminate TE metrics within an autonomous system(AS). A topology and disseminate TE metrics within an autonomous system
stand-alone TE Link State Database (TE-LSDB), different from (AS). A stand-alone TE Link State Database (TE-LSDB), different
the native OSPF LSDB, is created to facilitate computation of TE from the native OSPF LSDB, is created to facilitate computation
circuit paths. Algorithms to compute TE circuit paths is however of TE circuit paths. Devising algorithms to compute TE circuit
not the objective of this document. paths is not an objective of this document.
OSPF-TE is different from the Opaque-LSA-based design outlined OSPF-xTE is different from the Opaque-LSA-based design outlined
in [OPQLSA-TE]. Section 4 describes the motivations behind the in [OPQLSA-TE]. Section 4 describes the motivations behind the
design of OSPF-TE. Section 6 outlines a strategy to transition design of OSPF-xTE. Section 6 outlines a strategy to transition
Opaque-LSA based implementations to adapt OSPF-TE. Opaque-LSA based implementations to adapt OSPF-xTE.
Those interested in TE extensions for the packet networks only Readers interested in TE extensions for the packet networks
may skip section 9.0. only may skip section 9.0.
2. Principles of traffic engineering 2. Principles of traffic engineering
The objective of traffic engineering is to set up circuit The objective of traffic engineering (TE) is to set up circuit
path(s) between a pair of nodes or links and to forward traffic path(s) between a pair of nodes or links and to forward traffic
of a certain forwarding equivalency class through the circuit of a certain forwarding equivalency class (FEC) through the
path. Only the unicast circuit paths are considered here. circuit path. Only the unicast circuit paths are considered
Multicast variations are out of scope for this document. in this section. Multicast variations are outside the scope.
A traffic engineered circuit path may be identified by the A traffic engineered circuit path is uni-directional and may
tuple of (Forwarding Equivalency Class, TE parameters for the be identified by the tuple of (FEC, TE circuit parameters,
circuit, Origin Node/Link, Destination node/Link). Origin Node/Link, Destination node/Link).
Forwarding Equivalency Class (FEC) is a grouping of traffic Forwarding Equivalency Class (FEC) is a grouping of traffic
that is forwarded in the same manner by a node. A FEC may be that is forwarded in the same manner by a node. A FEC may be
classified based on a number of criteria as follows. classified based on a number of criteria as follows.
a) Traffic arriving on a specific interface, a) Traffic arriving on a specific interface,
b) Traffic arriving at a certain time of day, b) Traffic arriving at a certain time of day,
c) Traffic meeting a certain classification criteria c) Traffic meeting a certain packet based classification
(ex: based on a match of the fields in the IP and criteria (ex: based on a match of the fields in the IP
transport headers), and transport headers within a packet),
d) Traffic in a certain priority class, d) Traffic in a certain priority class,
e) Traffic arriving on a specific set of TDM (STS) circuits e) Traffic arriving on a specific set of TDM (STS) circuits
on an interface, on an interface,
f) Traffic arriving on a certain wavelength of an interface f) Traffic arriving on a certain wavelength of an interface
Discerning traffic based on the FEC criteria is mandatory for Discerning traffic based on the FEC criteria is mandatory for
Label Edge Routers (LERs). The intermediate Label Switched Routers Label Edge Routers (LERs). The intermediate Label Switched Routers
(LSRs) are transparent to the traffic content. LSRs are merely (LSRs) are transparent to the traffic content. LSRs are merely
responsible for keeping the circuit in-tact for the circuit responsible for keeping the circuit in-tact for the circuit
lifetime. This document will not address defining FEC criteria, lifetime. This document will not address defining FEC criteria,
skipping to change at page 4, line 50 skipping to change at page 4, line 33
TE metrics for a link may include the following. TE metrics for a link may include the following.
a) Available bandwidth, a) Available bandwidth,
b) Reliability of the link, b) Reliability of the link,
c) Color assigned to the link, c) Color assigned to the link,
d) Cost of bandwidth usage on the link, d) Cost of bandwidth usage on the link,
e) Membership to a Shared Risk Link Group (SRLG) e) Membership to a Shared Risk Link Group (SRLG)
A number of CSPF algorithms may be used to dynamically set up A number of CSPF algorithms may be used to dynamically set up
TE circuit paths in a TE network. TE circuit paths in a TE network.
As for origin node/link and destination node/link, the originating OSPF-xTE mandates the originating and the terminating entities of
and the terminating entities of a TE circuit path are identifiable a TE circuit path to be identifiable by their IP addresses.
by their IP addresses.
3. Terminology 3. Terminology
Definitions of terms used in the context of the OSPF protocol may be Definitions of majority of the terms used in the context of the
found in [OSPF-V2]. MPLS and traffic engineering terms may be found OSPF protocol may be found in [OSPF-V2]. MPLS and traffic
in [MPLS-ARCH]. RSVP-TE and CR-LDP signaling specific terms may be engineering terms may be found in [MPLS-ARCH]. RSVP-TE and
found in [RSVP-TE] and [CR-LDP] respectively. CR-LDP signaling specific terms may be found in [RSVP-TE] and
[CR-LDP] respectively.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALLNOT", The following subsections describe the native OSPF terms and
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the OSPF-xTE terms used within this document.
this document are to be interpreted as described in [IETF-STD].
Below are definitions for the terms used within this document. 3.1. Native OSPF terms
3.1. TE node 3.1.1. Native node (Non-TE node)
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-xTE extensions.
3.1.2. Native link (Non-TE link)
A native (or non-TE) link is a network attachment to a TE or
non-TE node used for IP packet traversal.
3.1.3. Native OSPF network (Non-TE network)
A native OSPF network refers to an OSPF network that does not
support TE. Non-TE network, native-OSPF network and non-TE
topology are used synonymously throughout the document.
3.1.4. LSP
LSP stands for "Label Switched Path". LSP is a TE circuit path
in a packet network. The terms LSP and TE circuit path are
used synonymously in the context of packet networks.
3.1.5. LSA
LSA stands for OSPF "Link State Advertisement".
3.1.6. LSDB
LSDB stands for "LSA Database". LSDB is a representation of the
topology of a network. A native LSDB, constituted of native OSPF
LSAs, represents the topology of a native IP network. TE-LSDB, on
the other hand, is constituted of TE LSAs and is a representation
of the TE network topology.
3.2. OSPF-xTE terms
3.2.1. TE node
TE-Node is a node in the traffic engineered (TE) network. A TE-Node is a node in the traffic engineered (TE) network. A
TE-node has a minimum of one TE-link attached to it. Associated TE-node has a minimum of one TE-link attached to it. Associated
with each TE node is a set of supported TE metrics. A TE node with each TE node is a set of supported TE metrics. A TE node
may also participate in a native IP network. may also participate in a native IP network.
In a SONET/TDM or photonic cross-connect network, a TE node is 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 not required to be an OSPF-xTE node. An external OSPF-xTE node
may act as proxy for the TE nodes that cannot be routers may act as proxy for the TE nodes that cannot be routers
themselves. themselves.
3.2. TE link 3.2.2. TE link
TE Link is a network attachment point to a TE-node and is TE Link is a network attachment point to a TE-node and is
intended for traffic engineering use. Associated with each intended for traffic engineering use. Associated with each
TE link is a set of supported TE metrics. A TE link may also TE link is a set of supported TE metrics. A TE link may also
optionally carry native IP traffic. optionally carry native IP traffic.
Of the various links attached to a TE-node, only the links that Of the various links attached to a TE-node, only the links that
take part in a traffic engineered network are called the TE take part in a traffic engineered network are called the TE
links. links.
3.3. TE circuit path 3.2.3. TE circuit path
A TE circuit path is a uni-directional data path, defined by a A TE circuit path is a uni-directional data path, defined by a
list of TE nodes connected to each other through TE links. A list of TE nodes connected to each other through TE links. A
TE circuit path is also often referred merely as a circuit path TE circuit path is also often referred merely as a circuit path
or a circuit. or a circuit.
For the purposes of OSPF-TE, the originating and terminating For the purposes of OSPF-xTE, the originating and terminating
entities of a TE circuit path must be identifiable by their entities of a TE circuit path must be identifiable by their
IP addresses. As a general rule, all nodes and links party to a IP addresses. As a general rule, all nodes and links party to a
Traffic Engineered network should be uniquely identifiable by an Traffic Engineered network should be uniquely identifiable by an
IP address. IP address.
3.4. OSPF-TE node 3.2.4. OSPF-xTE node (OSPF-xTE router)
An OSPF-TE node is a TE node that runs the OSPF routing protocol An OSPF-xTE node is a TE node that runs the OSPF routing protocol
and the OSPF-TE extensions described in this document. and the OSPF-xTE extensions described in this document.
An autonomous system (AS) may be constituted of a combination of An autonomous system (AS) may be constituted of a combination of
native and OSPF-TE nodes. native and OSPF-xTE nodes.
3.5. TE Control network 3.2.5. TE Control network
The IP network used by the OSPF-TE nodes for OSPF-TE The IP network used by the OSPF-xTE nodes for OSPF-xTE
communication is referred as the TE control network or simply communication is referred as the TE control network or simply
the control network. The control network can be independent of the control network. The control network can be independent of
the TE data network. the TE data network.
3.6. TE network (TE topology) 3.2.6. TE network (TE topology)
A TE network is a network of connected TE-nodes and TE-links A TE network is a network of connected TE-nodes and TE-links
for the purpose of setting up one or more TE circuit paths. for the purpose of setting up one or more TE circuit paths.
The terms TE network, TE data network and TE topology are The terms TE network, TE data network and TE topology are
used synonymously throughout the document. used synonymously throughout the document.
3.7. Packet-TE network 3.2.7. Packet-TE network (Packet network)
A packet-TE network is a TE network in which the nodes switch A packet-TE network is a TE network in which the nodes switch
MPLS packets. An MPLS packet is defined in [MPLS-TE] as a MPLS packets. An MPLS packet is defined in [MPLS-TE] as a
packet with an MPLS header, followed by data octets. The packet with an MPLS header, followed by data octets. The
intermediary node(s) of a circuit path in a packet-TE network intermediary node(s) of a circuit path in a packet-TE network
perform MPLS label swapping to emulate the circuit. perform MPLS label swapping to emulate the circuit.
Unless specified otherwise, the term packet network is used Unless specified otherwise, the term packet network is used
throughout the document to refer a packet-TE network. throughout the document to refer a packet-TE network.
3.8. Non-packet-TE network 3.2.8. Non-packet-TE network (Non-packet network)
A non-packet-TE network is TE-network in which the nodes A non-packet-TE network is TE-network in which the nodes
switch non-packet entities such as an STS time slot, a Lambda switch non-packet entities such as an STS time slot, a Lambda
wavelength or simply an interface. wavelength or simply an interface.
SONET/TDM and Fiber cross-connect networks are examples of SONET/TDM and Fiber cross-connect networks are examples of
non-packet-TE networks. Circuit emulation in these networks non-packet-TE networks. Circuit emulation in these networks
is accomplished by the switch fabric in the intermediary is accomplished by the switch fabric in the intermediary
nodes (based on TDM time slot, fiber interface or Lambda). nodes (based on TDM time slot, fiber interface or Lambda).
Unless specified otherwise, the term non-packet network is Unless specified otherwise, the term non-packet network is
used throughout the document to refer a non-packet-TE used throughout the document to refer a non-packet-TE
network. network.
3.9. Native (non-TE) node 3.2.9. Mixed network
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.
3.10. Native (non-TE) link
A native (or non-TE) link is a network attachment to a TE or
non-TE node used for IP packet traversal.
3.11. non-TE network (Non-TE topology) A mixed network is a network that is constituted of
packet-TE and non-TE networks combined. Traffic in the
network is strictly datagram oriented - IP datagrams or
MPLS packets. Routers in a mixed network may be TE or
native nodes.
A non-TE network refers to an OSPF network that does not OSPF-xTE is usable within a packet network or a mixed
support TE. Non-TE network, native-OSPF network and non-TE network.
topology are used synonymously throughout the document.
3.12. Peer network (combination network) 3.2.10. Peer network
A peer network is a network that is constituted of packet A peer network is a network that is constituted of packet-TE
and non-packet networks combined. In a peer network, a TE and non-packet-TE networks combined. In a peer network, a TE
node could potentially support TE links for the packet as node could potentially support TE links for the packet as
well as non-packet data. well as non-packet data.
OSPF-TE is usable within a packet network or a non-packet OSPF-xTE is usable within a packet network or a non-packet
network or a peer network, which is a combination of the two. network or a peer network, which is a combination of the two.
3.13. LSP 3.2.11. CSPF
LSP stands for "Label Switched Path". LSP is a TE circuit path
in a packet network. The terms LSP and TE circuit path are
used synonymously in the context of packet networks.
3.14. LSA
LSA stands for OSPF "Link State Advertisement".
3.15. LSDB
LSDB stands for "LSA Database". LSDB is a representation of the
topology of a network. A native LSDB, constituted of native OSPF
LSAs, represents the topology of a native IP network. TE-LSDB, on
the other hand, is constituted of TE LSAs and is a representation
of the TE network topology.
3.16. CSPF
CSPF stands for "Constrained Shortest Path First". Given a TE CSPF stands for "Constrained Shortest Path First". Given a TE
LSDB and a set of constraints that must be satisfied to form a LSDB and a set of constraints that must be satisfied to form a
circuit path, there may be several CSPF algorithms to obtain a circuit path, there may be several CSPF algorithms to obtain a
TE circuit path that meets the criteria. TE circuit path that meets the criteria.
3.17. TLV 3.2.12. TLV
A TLV stands for an object in the form of Tag-Length-Value. All A TLV stands for an object in the form of Tag-Length-Value. All
TLVs are assumed to be of the following format, unless specified TLVs are assumed to be of the following format, unless specified
otherwise. The Tag and length are 16 bits wide each. The length otherwise. The Tag and length are 16 bits wide each. The length
includes the 4 octets required for Tag and Length specification. includes the 4 octets required for Tag and Length specification.
All TLVs described in this document are padded to 32-bit All TLVs described in this document are padded to 32-bit
alignment. Any padding required for alignment will not be a part alignment. Any padding required for alignment will not be a part
of the length field, however. TLVs are used to describe traffic of the length field, however. TLVs are used to describe traffic
engineering characteristics of the TE nodes, TE links and TE circuit engineering characteristics of the TE nodes, TE links and TE circuit
paths. paths.
skipping to change at page 8, line 35 skipping to change at page 8, line 30
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag | Length (4 or more) | | Tag | Length (4 or more) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value .... | | Value .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .... | | .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.18. Router-TE TLVs 3.2.13. Router-TE TLVs (Router TLVs)
TLVs used to describe the TE capabilities of a TE-node. TLVs used to describe the TE capabilities of a TE-node.
3.19. Link-TE TLVs 3.2.14. Link-TE TLVs (Link TLVs)
TLVs used to describe the TE capabilities of a TE-link. TLVs used to describe the TE capabilities of a TE-link.
4. Motivations behind the design of OSPF-TE 4. Motivations behind the design of OSPF-xTE
There are several motivations that lead to the design of OSPF-TE. There are several motivations that led to the design of OSPF-xTE.
OSPF-TE is scalable, coexistent and efficient in flooding reach. OSPF-xTE is scalable, efficient and usable across a variety of
The motivations are explained in detail in the following network topologies. These motivations are explained in detail in
subsections. Also listed in the last subsection are network the following subsections. The last subsection lists real-world
scenarios that benefit from the OSPF-TE design. network scenarios that benefit from the OSPF-xTE.
4.1. Scalable design 4.1. Scalable design
Area level abstraction provides the scaling necessary for a large OSPF-xTE area level abstraction provides the scaling required
autonomous system (AS). OSPF-TE allows for independent area for the TE topology in a large autonomous system (AS).
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 An OSPF-xTE area border router will advertise summary LSAs for
TE and non-TE topologies independent of each other. Readers
may refer to section 10 for a topological view of the AS from
the perspective of a OSPF-xTE node in an area.
OSPF-TE regards an AS as constituted of a TE and non-TE networks 4.2. Operable in mixed and peer networks
coexisting within the same bounds. OSPF-TE dynamically discovers
OSPF-xTE regards an AS as constituted of a TE and non-TE networks
coexisting within the same bounds. OSPF-xTE dynamically discovers
TE topology and the associated TE metrics of the nodes and links 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 within, just as the native OSPF does of a non-TE network. An
independent TE-LSDB, representative of the TE topology is independent TE-LSDB, representative of the TE topology is
generated as a result. A stand-alone TE-LSDB allows for speedy generated as a result. A stand-alone TE-LSDB allows for speedy
searches through the database. searches through the database.
In [OPQLSA-TE], the TE-LSDB is derived from the combination of In [OPQLSA-TE], the TE-LSDB is derived from the combination of
opaque LSAs and native LSDB. The TE-LSDB derived has no opaque LSAs and native LSDB. Further, the TE-LSDB thus derived has
knowledge of the TE capabilities of the routers in the network. no knowledge of the TE capabilities of the routers in the network.
4.3. Efficient in flooding reach 4.3. Efficient in flooding reach
OSPF-TE is capable of identifying the boundaries of a TE topology OSPF-xTE is able to identify the TE topology in a mixed network
and limits the flooding of TE LSAs to only the TE-nodes. Non-TE and will limit the flooding of TE LSAs to just the TE-nodes.
nodes are not bombarded with TE LSAs. This is a useful Non-TE nodes are not bombarded with TE LSAs.
characteristic for networks supporting native and TE traffic in
the same connected network.
A subset of the TE metrics may be prone to rapid change, while In a TE network, a subset of the TE metrics may be prone to rapid
others remain largely unchanged. Changes in TE metrics must be change, while others remain largely unchanged. Changes in TE
communicated at the earliest throughout the network to ensure metrics must be communicated at the earliest throughout the
that the TE-LSDB is up-to-date within the network. As a general network to ensure that the TE-LSDB is up-to-date within the
rule, a TE network is likely to generate significantly more network. As a general rule, a TE network is likely to generate
control traffic than a native OSPF network. The excess traffic significantly more control traffic than a native network. The
is almost directly proportional to the rate at which TE circuits excess traffic is almost directly proportional to the rate at
are set up and torn down within the TE network. The TE database which TE circuits are set up and torn down within the TE network.
synchronization should occur much quicker compared to the The TE database synchronization should occur much quicker compared
aggregate circuit set up and tear-down rates. to the aggregate circuit set up and tear-down rates. OSPF-xTE
TE-Incremental-Link-update LSA (section 8.2) permits advertising defines TE-Incremental-Link-update LSA (section 8.2) to advertise
a subset of the link metrics. just a subset of the metrics that are prone to rapid changes.
The more frequent and wider the flooding frequency, the larger The more frequent and wider the flooding frequency, the larger
the number of retransmissions and acknowledgements. The same 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.
It is undesirable to flood non-TE nodes with TE information. It is undesirable to flood non-TE nodes with TE information.
[OPQLSA-TE] uses Opaque LSAs for advertising TE information. [OPQLSA-TE] uses Opaque LSAs for advertising TE information.
Opaque LSAs reach all nodes within the network - TE-nodes and Opaque LSAs reach all nodes within the network - TE-nodes and
non-TE nodes alike. [OPQLSA-TE] also does not have provision non-TE nodes alike. [OPQLSA-TE] also does not have provision
to advertise just the TLVs that changed. A change in any TLV to advertise just the TLVs that changed. A change in any TLV
of a TE-link will mandate the entire LSA to be transmitted. of a link will mandate the entire LSA to be transmitted.
4.4. Ability to reserve TE-exclusive links 4.4. Ability to reserve TE-exclusive links
OSPF-TE is designed to draw distinction between TE-links and OSPF-xTE draws a clear distinction between TE and non-TE
non-TE links. A TE link, configured to support TE traffic links. A TE link may be configured to permit TE traffic
alone, will not permit best-effort IP traffic on the link. alone, and not permit best-effort IP traffic on the link.
This permits TE enforceability on the TE links. This permits TE enforceability on the TE links.
When links of a TE-topology do not overlap the links of a When links of a TE-topology do not overlap the links of a
native IP network, OSPF-TE allows for virtual isolation of native IP network, OSPF-xTE allows for virtual isolation of
the two networks. Best-effort IP transit network and the two networks. Best-effort IP network and TE network often
constraint based TE network often have different service have different service requirements. Keeping the two networks
requirements. Keeping the two networks physically isolated physically isolated can be expensive. Combining the two
will enable SLA enforceability, but can be expensive. Combining networks into a single physically connected network will
the two networks into a single physically connected network bring economies of scale, while service enforceability
will bring economies of scale, if the service enforceability can be maintained individually for each of the TE and non-TE
can be retained. sections of the network.
[OPQLSA-TE] does not support the ability to isolate best- [OPQLSA-TE] does not support the ability to isolate best-
effort IP traffic from TE traffic on a link. All links are effort IP traffic from TE traffic on a link. All links are
subject to best-effort IP traffic. An OSPF router could subject to best-effort IP traffic. An OSPF router could
potentially select a TE link to be its least cost link and potentially select a TE link to be its least cost link and
inundate the link with best-effort IP traffic, thereby inundate the link with best-effort IP traffic, thereby
rendering the link unusable for TE purposes. rendering the link unusable for TE purposes.
4.5. Extendible design 4.5. Extendible design
OSPF-TE design is based on the tried and tested OSPF paradigm, OSPF-xTE design is based on the tried and tested OSPF paradigm,
and inherits all the benefits of the OSPF, present and future. and inherits all the benefits of the OSPF, present and future.
TE-LSAs are extendible, just as the native OSPF on which OSPF-TE TE-LSAs are extendible, just as the native OSPF on which
is founded. OSPF-xTE is founded.
[OPQLSA-TE], on the other hand, is constrained by the semantics [OPQLSA-TE], on the other hand, is constrained by the semantics
of the Opaque LSA on which it is founded. The content within an of the Opaque LSA on which it is founded. The content within an
Opaque LSA is restricted to being in the form of TLVs and Opaque LSA is restricted to being in the form of TLVs and
sub-TLVs, some of which are mandatory and some of which are sub-TLVs, some of which are mandatory. Opaque LSAs are also
positionally dependent in the TLV sequence for proper restrictive when the flooding scope is required to be different
interpretation. Opaque LSAs are also restrictive when the flooding from the scope of the opaque LSA itself.
scope for the content is required to be different from the scope
of the opaque LSA itself.
4.6. Unified for packet and non-packet networks 4.6. Unified for packet and non-packet networks
OSPF-TE is usable within a packet network or a non-packet OSPF-xTE is usable within a packet network or a non-packet
network or a combination peer network. network or a combination peer network.
Signaling protocols such as RSVP and LDP work the same across Signaling protocols such as RSVP and LDP work the same across
packet and non-packet networks. Signaling protocols merely need packet and non-packet networks. Signaling protocols merely need
the TE characteristics of nodes and links so they can signal the the TE characteristics of nodes and links so they can signal the
nodes to formulate TE circuit paths. In a peer network, the nodes to formulate TE circuit paths. In a peer network, the
underlying control protocol must be capable of providing a underlying control protocol must be capable of providing a
unified LSDB for all TE nodes (nodes with packet-TE links as well 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 as non-packet-TE links) in the network. OSPF-xTE meets this
requirement. requirement.
[OPQLSA-TE] is limited in scope for packet networks. An [OPQLSA-TE] is limited in scope for packet networks and does
independent [OPQLSA-GMPLS] is required to support GMPLS links in not have provision to distinguish between node types within
a non-packet network. Neither of the Opaque LSA based extensions a TE network.
have provision to distinguish between node types.
4.7. Networks benefiting from the OSPF-TE design 4.7. Networks benefiting from the OSPF-xTE design
Many real-world networks are better served by the new-TE-LSAs Below are examples of some real-world network scenarios that
scheme. Here are a few examples. benefit from OSPF-xTE.
4.7.1. IP providers transitioning to provide 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-xTE only nodes will allow the vendor to
introduce MPLS TE without destabilizing the existing network. introduce MPLS TE without destabilizing the existing network.
The native OSPF-LSDB will remain undisturbed while newer TE The native OSPF-LSDB will remain undisturbed while newer TE
links are added to the network. links are added to the network.
4.7.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-xTE 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. cannibalized in a mixed network.
4.7.3. Large TE networks 4.7.3. Large TE networks
The OSPF-TE design is advantageous in large TE networks that The OSPF-xTE design is advantageous in large TE networks that
require the AS to be sub-divided into multiple areas. require the AS to be sub-divided into multiple areas. OSPF-xTE
permits inter-area exchange of TE information, which ensures
that all nodes in the AS have up-to-date As-wide TE
reachability knowledge. This in turn will make TE circuit
setup predictable and computationally bounded.
4.7.4. Non-packet networks and Peer networks 4.7.4. Non-packet networks and Peer networks
OSPF-TE is also the right choice for vendors opting for a Vendors may also use OSPF-xTE for their non-packet TE networks.
stable, well-founded protocol for their non-IP TE networks. OSPF-xTE defines the following functions in support of
OSPF-TE is uniquely qualified to support the following network non-packet TE networks.
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).
5. OSPF-TE solution overview 5. OSPF-xTE solution overview
5.1. OSPF-TE Solution 5.1. OSPF-xTE Solution
A new TE flag is introduced within the OSPF options field to A new TE flag is introduced within the OSPF options field to
to enable discovery of TE topology. Section 8.0 describes the to enable discovery of TE topology. Section 8.0 describes the
semantics of the TE flag. TE LSAs are designed for use by the semantics of the TE flag. TE LSAs are designed for use by the
OSPF-TE nodes. Section 9.0 describes the TE LSAs in detail. OSPF-xTE nodes. Section 9.0 describes the TE LSAs in detail.
Changes required of the OSPF data structures to support Changes required of the OSPF data structures to support
OSPF-TE are described in section 11.0. A new TE-neighbors data OSPF-xTE are described in section 11.0. A new TE-neighbors data
structure will be used to flood TE LSAs along TE-topology. structure will be used to flood TE LSAs along TE-topology.
An OSPF-TE node will have the native LSDB and the TE-LSDB, An OSPF-xTE node will have the native LSDB and the TE-LSDB,
A native OSPF node will have just the native LSDB. A native OSPF node will have just the native LSDB.
Consider the following OSPF area constituted of OSPF-TE and Consider the following OSPF area constituted of OSPF-xTE and
native OSPF routers. Nodes RT1, RT2, RT3 and RT6 are OSPF-TE native OSPF routers. Nodes RT1, RT2, RT3 and RT6 are OSPF-xTE
routers with TE and non-TE link attachments. Nodes RT4 and RT5 routers with TE and non-TE link attachments. Nodes RT4 and RT5
are native OSPF routers with no TE links. When the LSA database are native OSPF routers with no TE links. When the LSA database
is synchronized, all nodes will share the same native LSDB is synchronized, all nodes will share the same native LSDB
OSPF-TE nodes alone will have the additional TE-LSDB. OSPF-xTE nodes alone will have the additional TE-LSDB.
+---+ +---+
| |--------------------------------------+ | |--------------------------------------+
|RT6|\\ | |RT6|\\ |
+---+ \\ | +---+ \\ |
|| \\ | || \\ |
|| \\ | || \\ |
|| \\ | || \\ |
|| +---+ | || +---+ |
|| | |----------------+ | || | |----------------+ |
skipping to change at page 13, line 39 skipping to change at page 13, line 39
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
5.2. Assumptions 5.2. Assumptions
OSPF-TE is an extension to the native OSPF protocol and does not OSPF-xTE is an extension to the native OSPF protocol and does not
mandate changes to the existing OSPF. OSPF-TE design makes the mandate changes to the existing OSPF. OSPF-xTE design makes the
following assumptions. following assumptions.
1. An OSPF-TE node will need to establish router adjacency with 1. An OSPF-xTE node will need to establish router adjacency with
at least one other OSPF-TE node in the area in order for the at least one other OSPF-xTE node in the area in order for the
router's TE-database to be synchronized within the area. router's TE-database to be synchronized within the area.
Failing this, the OSPF router will not be in the TE Failing this, the OSPF router will not be in the TE
calculations of other TE routers in the area. calculations of other TE routers in the area.
It is the responsibility of the network administrator(s) to It is the responsibility of the network administrator(s) to
ensure connectedness of the TE network. Otherwise, there can ensure connectedness of the TE network. Otherwise, there can
be disjoint TE topologies within a network. be disjoint TE topologies within a network.
2. OSPF-TE nodes must advertise the link state of its TE-links. 2. OSPF-xTE nodes must advertise the link state of its TE-links.
TE-links are not obligated to support native IP traffic. TE-links are not obligated to support native IP traffic.
Hence, an OSPF-TE node cannot be required to synchronize Hence, an OSPF-xTE node cannot be required to synchronize
its link-state database with neighbors on all its links. its link-state database with neighbors on all its links.
The only requirement is to have the TE LSDB synchronized The only requirement is to have the TE LSDB synchronized
across all OSPF-TE nodes in the area. Refer [FLOOD-OPT] for across all OSPF-xTE nodes in the area.
flooding optimizations.
3. A link in a packet network may be designated as a TE-link or 3. A link in a packet network may be designated as a TE-link or
a native-IP link or both. For example, a link may be used for a native-IP link or both. For example, a link may be used for
both TE and non-TE traffic, so long as the link is both TE and non-TE traffic, so long as the link is
under-subscribed in bandwidth for TE traffic - say, 50% of under-subscribed in bandwidth for TE traffic - say, 50% of
the link capacity is set aside for TE traffic. the link capacity is set aside for TE traffic.
4. Non-packet TE sub-topologies MUST have a minimum of one node 4. Non-packet TE sub-topologies must have a minimum of one node
running OSPF-TE protocol. For example, a SONET/SDH TDM ring running OSPF-xTE protocol. For example, a SONET/SDH TDM ring
must have a minimum of one Gateway Network Element(GNE) must have a minimum of one Gateway Network Element(GNE)
running OSPF-TE. The OSPF-TE node will advertise on behalf running OSPF-xTE. The OSPF-xTE node will advertise on behalf
of all the in the ring. of all the TE nodes in the ring.
6. Opaque LSAs to OSPF-TE transition strategy 6. Opaque LSAs to OSPF-xTE transition strategy
Below is a strategy to transition implementations using opaque Below is a strategy to transition implementations using opaque
LSAs to adapt the OSPF-TE scheme in a gradual fashion. LSAs ([OPQLSA-TE]) to adapt OSPF-xTE 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 topologies 2. Use the TE option flag to construct the TE topologies
area-wise. By doing this, the TE topology for the AS will area-wise. By doing this, the TE topology for the AS will
be available at area level abstraction. 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 an 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-nodes in the backbone. The TE-ABRs on the backbone
area will in-turn advertise these summaries within their area will in-turn advertise these summaries within their
connected areas. connected areas.
7. OSPF-TE router adjacency - TE topology discovery 7. OSPF-xTE router adjacency - TE topology discovery
OSPF creates adjacencies between neighboring routers for the purpose OSPF creates adjacencies between neighboring routers for the purpose
of exchanging routing information. In the following subsections, we of exchanging routing information. In the following subsections, we
describe modifications to the OSPF options field and the use of describe modifications to the OSPF options field and the use of
Hello protocol to establish TE capability compliance between Hello protocol to establish TE capability compliance between
neighboring routers in an area. The capability is used as the basis neighboring routers in an area. The capability is used as the basis
to build TE topology. to build TE topology.
7.1. The OSPF Options field 7.1. The OSPF Options field
A new TE flag is introduced within the options field by this draft A new TE flag is introduced within the options field to identify TE
to identify TE extensions to the OSPF. This bit will be used to extensions to the OSPF. This bit will be used to distinguish routers
distinguish routers that support OSPF-TE. The OSPF options field that support OSPF-xTE. The OSPF options field is present in OSPF
is present in OSPF Hello packets, Database Description packets, Hello packets, Database Description packets, and all link state
and all link state advertisements. The TE bit, however, is a advertisements. The TE bit, however, is a requirement only for the
requirement only for the Hello packets. Use of TE-bit is optional Hello packets. Use of TE-bit is optional in Database Description
in Database Description packets or LSAs. packets and 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 the and [OPAQUE] for a description of the remaining bits in the
options 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 will use the TE-bit to establishing router adjacency will use the TE-bit to
establish OSPF-TE adjacency. Two routers will not become establish OSPF-xTE adjacency. Two routers will not become
TE-neighbors unless they agree on the state of the TE-bit. TE-neighbors unless they agree on the state of the TE-bit.
TE-compliant OSPF extensions are advertised only to the TE-compliant OSPF extensions are advertised only to the
TE-compliant routers. All other routers may simply ignore TE-compliant routers. All other routers may simply ignore
the advertisements. 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 deemed reserved bits left for future option extensions. If deemed
necessary to leave this bit as is, the OPAQUE-9 LSA (local scope) necessary to leave this bit as is, the OPAQUE-9 LSA (local scope)
can be used on each interface to communicate the support for can be used on each interface to communicate the support for
OSPF-TE. OSPF-xTE. For the reminder of the document, we will assume the
above defined TE-bit in options filed is permissible.
7.2. 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 is not required for all links and neighbors to establish it is not required for all links and neighbors to establish
adjacency using this protocol. The Hello protocol will use the adjacency using this protocol. The Hello protocol will use the
TE-bit to establish traffic engineering capability between two TE-bit to establish traffic engineering capability between two
OSPF routers. 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 Routers supporting the TE option shall be given a higher
routers may either be preselected (ex: GNE, backup-GNE) or precedence for becoming a designated router over those that do
determined via the same Hello protocol. In any case, routers not support TE.
supporting the TE option shall be given a higher precedence for
becoming a designated router over those that do not support TE.
If deemed necessary to leave the TE-bit unused in the options
field, the OSPF-TE routers could use OPAQUE-9 LSA (local scope)
to communicate TE capability between two OSPF routers.
7.3. The Designated Router 7.3. The Designated Router
The Designated Router is elected by the Hello Protocol on broadcast When a router's non-TE link first becomes functional, it checks to
and NBMA networks. In general, when a router's non-TE link first see whether there is currently a Designated Router for the network.
becomes functional, it checks to see whether there is currently a If there is one, it accepts that Designated Router, regardless of
Designated Router for the network. If there is one, it accepts that its Router Priority, so long as the current designated router is
Designated Router, regardless of its Router Priority, so long as TE compliant. Otherwise, the router itself becomes Designated
the current designated router is TE compliant. Otherwise, Router if it has the highest Router Priority on the network and is
the router itself becomes Designated Router if it has the highest TE compliant.
Router Priority on the network and is TE compliant.
TE-compliance (I.e., OSPF-TE) must be implemented on the most robust
routers, as they become likely candidates to take on the role as
designated router.
Alternatively, there can be two sets of designated routers, one for OSPF-xTE must be implemented on the most robust routers, as they
the TE compliant routers and another for the native OSPF routers become likely candidates to take on the role as designated router.
(non-TE compliant).
7.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 electing must be weighed in conjunction with router priority in electing
the backup designated router. the backup designated router.
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).
7.5. Flooding and the Synchronization of Databases 7.5. Flooding and the Synchronization of Databases
In OSPF, adjacent routers within an area must synchronize their In OSPF, adjacent routers within an area are required to
databases. However, as observed in [FLOOD-OPT], a more concise synchronize their databases. However, a more concise requirement
requirement of OSPF is that all routers in an area must converge is that all routers in an area must converge on the same LSDB.
on the same link state database. It is sufficient to send a However, as stated in item 2 of section 5.2, a basic assertion
single copy of the LSAs to the neighboring routers in an area by OSPF-xTE is that the links used by the OSPF-xTE control
than send one copy on each connected interface. [FLOOD-OPT] network for flooding must not be required to match the links
describes in detail how to minimize flooding (Initial LSDB used by the data network for real-time data forwarding. For
synchronization as well as the asynchronous LSA updates) within instance, it should not be required to run the OSPF-xTE messages
an area. over a TE-link that is configured not to permit non-TE traffic.
However, the control network must be setup such that a minimum
of one path exists between any two OSPF or OSPF-xTE routers
within the network for flooding purposes. This revised control
network connectivity requirement does not jeopardize
convergence of LSDB within an area.
In the case where some of the neighbors are TE compliant and In a mixed network, where some of the neighbors are TE
others are not, the designated OSPF-TE router will exchange compliant and others are not, the designated OSPF-xTE router
different sets of LSAs with its neighbors. TE LSAs are will exchange different sets of LSAs with its neighbors.
exchanged only with the TE neighbors. Native LSAs are TE LSAs are exchanged only with the TE neighbors. Native
exchanged with all neighbors (TE and non-TE alike). LSAs are exchanged with all neighbors (TE and non-TE alike).
Restricting the scope of TE LSA flooding to just the
OSPF-xTE nodes will not effect the native nodes that coexist
with the OSPF-xTE nodes.
The control traffic for a TE network (i.e., TE LSA
advertisement) is likely to be higher than that of a native
OSPF network. This is because the TE metrics may vary with each
TE circuit setup and the corresponding state change must be
advertised at the earliest, not exceeding the MinLSInterval
of 5 seconds. To minimize advertising repetitive content,
OSPF-xTE defines a new TE-incremental-Link-update LSA
(section 8.2) that would advertise just the TLVs that changed
for a link.
A new OSPFIGP-TE multicast address 224.0.0.24 may be used for A new OSPFIGP-TE multicast address 224.0.0.24 may be used for
the exchange of TE compliant database descriptors. Flooding the exchange of TE compliant database descriptors during
optimization in a TE network is essential as the control database synchronization.
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 7.6. The graph of adjacencies
If two routers have multiple networks in common, they may have If two routers have multiple networks in common, they may have
multiple adjacencies between them. The adjacency may be one of multiple adjacencies between them. The adjacency may be one of
two types - native OSPF adjacency and TE adjacency. OSPF-TE two types - native OSPF adjacency and TE adjacency. OSPF-xTE
routers will form both types of adjacency. routers will form both types of adjacency.
Two types of adjacency graphs are possible depending on whether Two types of adjacency graphs are possible depending on whether
a Designated Router is elected for the network. On physical a Designated Router is elected for the network. On physical
point-to-point networks, Point-to-Multipoint networks and point-to-point networks, Point-to-Multipoint networks and
Virtual links, neighboring routers become adjacent whenever they Virtual links, neighboring routers become adjacent whenever they
can communicate directly. The adjacency can be one of can communicate directly. The adjacency can be one of
(a) TE-compliant or (b) native. In contrast, on broadcast and (a) TE-compliant or (b) native. In contrast, on broadcast and
NBMA networks the designated router and the backup designated NBMA networks the designated router and the backup designated
router may maintain two sets of adjacency. The remaining routers router may maintain two sets of adjacency. The remaining routers
will form either TE-compliant or native adjacency. In the will form either TE-compliant or native adjacency. In the
Broadcast network below, routers RT7 and RT3 are chosen as the Broadcast network below, routers RT7 and RT3 are chosen as the
designated and backup routers respectively. Routers RT3, RT4 designated and backup routers respectively. Routers RT3, RT4
and RT7 are TE-compliant. RT5 and RT6 are not. So, RT4 will and RT7 are TE-compliant. RT5 and RT6 are not. So, RT4 will
have TE and native adjacencies with the designated and backup have TE-compliant adjacency with the designated and backup
routers. RT5 and RT6 will only have native adjacency with the routers. RT5 and RT6 will only have native adjacency with the
designated and backup routers. designated and backup routers.
+---+ +---+ Network Adjacency
|RT1|------------|RT2| o---------------o
+---+ N1 +---+ RT1 RT2 +---+ +---+
|RT1|------------|RT2| o--------------------o
+---+ N1 +---+ RT1 RT2
RT7 RT7
o:::::::::: o:::::
+---+ +---+ +---+ /|: : +---+ +---+ +---+ /| :
|RT7| |RT3| |RT4| / | : : |RT7| |RT3| |RT4| / | :
+---+ +---+ +---+ / | : : +---+ +---+ +---+ / | :
| | | / | : : | | | / | :
+-----------------------+ RT5o RT6o oRT4 : +-----------------------+ RT5o RT6o oRT4
| | N2 * * ; : | | N2 * * :
+---+ +---+ * * ; : +---+ +---+ * * :
|RT5| |RT6| * * ; : |RT5| |RT6| * * :
+---+ +---+ **; : +---+ +---+ ** :
o:::::::::: o:::::
RT3 RT3
Adjacency Legend:
----- Native adjacency (primary)
***** Native adjacency (Backup)
::::: TE-compliant adjacency (primary)
;;;;; TE-compliant adjacency (Backup)
Figure 6: The graph of adjacencies with TE-compliant routers. Figure 6: The graph of adjacencies with TE-compliant routers.
8. TE LSAs - Packet network 8. TE LSAs for packet network
The OSPFv2 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.
LSA types 9 through 11 are defined in [OPAQUE]. LSA types 9 through 11 are defined in [OPAQUE].
Each LSA type has a unique flooding scope. Opaque LSA types Each LSA type has a unique flooding scope. Opaque LSA types
9 through 11 are general purpose LSAs, with flooding 9 through 11 are general purpose LSAs, with flooding
scope set to link-local, area-local and AS-wide (except stub scope set to link-local, area-local and AS-wide (except stub
areas) respectively. areas) respectively.
In the following subsections, we define new LSAs for traffic In the following subsections, we define new LSAs for traffic
engineering (TE) use. The Values for the new TE LSA types are engineering (TE) use. The Values for the new TE LSA types are
assigned such that the high bit of the LSA-type octet is set assigned such that the high bit of the LSA-type octet is set
to 1. The new TE LSAs are largely modeled after the existing to 1. The new TE LSAs are largely modeled after the existing
LSAs for content format and have a unique flooding scope. LSAs for content format and have a unique flooding scope.
TE-router LSA is defined to advertise TE characteristics of TE-router LSA is defined to advertise TE characteristics of
an OSPF-TE router and all the TE-links attached to the an OSPF-xTE router and all the TE-links attached to the
router. TE-incremental-Link-Update LSA is defined to router. TE-incremental-Link-Update LSA is defined to
advertise incremental updates to the metrics of a TE link. advertise incremental updates to the metrics of a TE link.
Flooding scope for both these LSAs is restricted to the Flooding scope for both these LSAs is restricted to an area.
TE nodes in the area.
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. details of an area to external areas.
skipping to change at page 19, line 25 skipping to change at page 19, line 34
advertise AS external network reachability and pre-engineered advertise AS external network reachability and pre-engineered
TE circuits respectively. While flooding scope for both these TE circuits respectively. While flooding scope for both these
LSAs can be the entire AS, flooding scope for the LSAs can be the entire AS, flooding scope for the
pre-engineered TE circuit LSA may optionally be restricted to pre-engineered TE circuit LSA may optionally be restricted to
just the TE topology within an area. just the TE topology within an area.
8.1. TE-Router LSA (0x81) 8.1. TE-Router LSA (0x81)
The TE-router LSA (0x81) is modeled after the router LSA and has the The TE-router LSA (0x81) is modeled after the router LSA and has the
same flooding scope as the router-LSA. However, the scope is same flooding scope as the router-LSA. However, the scope is
restricted to only the OSPF-TE nodes within the area. The TE-router restricted to only the OSPF-xTE nodes within the area. The TE-router
LSA describes the TE metrics of the router as well as the TE-links 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 described in the following sub-sections. and Link-TE TLVs are each described in the following sub-sections.
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 20, line 26 skipping to change at page 20, line 35
| 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.
8.1.1. Router-TE flags - TE capabilities of the router 8.1.1. Router-TE flags - TE capabilities of the router
The following flags are used to describe the TE capabilities of an The following flags are used to describe the TE capabilities of an
OSPF-TE router. The remaining bits of the 32-bit word are reserved OSPF-xTE router. The remaining bits of the 32-bit word are reserved
for future use. for future use.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L|L|P| | | | |L|S|C| |L|L|P| | | | |L|S|C|
|S|E|S| | | | |S|I|S| |S|E|S| | | | |S|I|S|
|R|R|C| | | | |P|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
skipping to change at page 21, line 39 skipping to change at page 21, line 48
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x8001 | Length = 6 | | Tag = 0x8001 | Length = 6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label depth | QOS | | | Label depth | QOS | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
'Label depth' is the depth of label stack the node is capable of 'Label depth' is the depth of label stack the node is capable of
processing on its ingress interfaces. An octet is used to represent 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 label depth. A default value of 1 is assumed when the TLV is not
listed. listed. Label depth is relevant when an LER has to pop off multiple
labels off the MPLS stack.
'QOS' is a single octet field that may be assigned '1' or '0'. Nodes '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 supporting QOS are able to interpret the EXP bits in the MPLS header
to prioritize multiple classes of traffic through the same LSP. to prioritize multiple classes of traffic through the same LSP.
8.1.2.2. TE-NODE-TLV-MPLS-SIG-PROTOCOLS 8.1.2.2. TE-NODE-TLV-MPLS-SIG-PROTOCOLS
MPLS signaling protocols TLV lists all the signaling protocol MPLS signaling protocols TLV lists all the signaling protocol
supported by the node. An octet is used to list each signaling supported by the node. An octet is used to list each signaling
protocol supported. protocol supported.
skipping to change at page 23, line 5 skipping to change at page 23, line 46
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x8003 | Length = 4(1 + (n+1)/2) | | Tag = 0x8003 | Length = 4(1 + (n+1)/2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSPF-1 | .... | | CSPF-1 | .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSPF-n | | | CSPF-n | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8.1.2.4. TE-NODE-TLV-NULL
When a TE-Router or a TE-link has multiple TLVs to describe the
metrics, the NULL TLV is used to terminate the TLV list.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x8888 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8.1.3. Link-TE flags - TE capabilities of a link 8.1.3. Link-TE flags - TE capabilities of a link
The following flags are used to describe the TE capabilities of a The following flags are used to describe the TE capabilities of a
link. The remaining bits of the 32-bit word are reserved for link. The remaining bits of the 32-bit word are reserved for
future use. future use.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|N|P| | | |D| |S|L|B|C| |T|N|P| | | |D| |S|L|B|C|
|E|T|K| | | |B| |R|U|W|O| |E|T|K| | | |B| |R|U|W|O|
| |E|T| | | |S| |L|G| |L| | |E|T| | | |S| |L|G| |L|
skipping to change at page 23, line 35 skipping to change at page 25, line 35
PKT - Indicates whether or not the link is capable of IP PKT - Indicates whether or not the link is capable of IP
packet processing. packet processing.
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 TE-LINK-TLV-SRLG follows. SRLG Bit - Shared Risk Link Group TLV TE-LINK-TLV-SRLG follows.
LUG bit - Link usage cost metric TLV TE-LINK-TLV-LUG follows. LUG bit - Link usage cost metric TLV TE-LINK-TLV-LUG follows.
BW bit - Link bandwidth TLV TE-LINK-TLV-BANDWIDTH follows. BW bit - One or more Link bandwidth TLVs follow
COL bit - Link Color TLV TE-LINK-TLV-COLOR follows. COL bit - Link Color TLV TE-LINK-TLV-COLOR follows.
8.1.4. Link-TE TLVs 8.1.4. Link-TE TLVs
8.1.4.1. TE-LINK-TLV-SRLG 8.1.4.1. TE-LINK-TLV-SRLG
The SRLG describes the list of Shared Risk Link Groups (SRLG) the The SRLG describes the list of Shared Risk Link Groups (SRLG) the
link belongs to. Two octets are used to list each SRLG. If the link link belongs to. Two octets are used to list each SRLG. If the link
belongs to 'n' SRLGs, the Length would be (4 + 4 * ((n+1)/2)) octets. belongs to 'n' SRLGs, the Length would be (4 + 4 * ((n+1)/2)) octets.
skipping to change at page 24, line 9 skipping to change at page 26, line 9
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0001 | Length = 4(1 + (n+1)/2) | | Tag = 0x0001 | Length = 4(1 + (n+1)/2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG-1 | .... | | SRLG-1 | .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG-n | | | SRLG-n | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8.1.4.2. TE-LINK-TLV-BANDWIDTH 8.1.4.2. TE-LINK-TLV-BANDWIDTH-MAX
The bandwidth TLV specifies maximum bandwidth, bandwidth available The bandwidth TLV specifies maximum bandwidth of the link as follows.
for TE use and reserved bandwidth as follows.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0002 | Length = 16 | | Tag = 0x0002 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Bandwidth | | Maximum Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth available for TE use |
Bandwidth is expressed in units of 32 bytes/sec (256 bits/sec).
A 32-bit field for bandwidth would permit specification not exceeding
1 tera-bits/sec.
'Maximum bandwidth' is be the maximum link capacity expressed in
bandwidth units. Portions or all of this bandwidth may be used for
TE use.
8.1.4.3. TE-LINK-TLV-BANDWIDTH-MAX-FOR-TE
The bandwidth TLV specifies maximum bandwidth available for TE use
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved Bandwidth | | Tag = 0x0003 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Bandwidth available for TE use |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bandwidth is expressed in units of 32 bytes/sec (256 bits/sec). Bandwidth is expressed in units of 32 bytes/sec (256 bits/sec).
A 32-bit field for bandwidth would permit specification not exceeding A 32-bit field for bandwidth would permit specification not exceeding
1 tera-bits/sec. 1 tera-bits/sec.
'Maximum bandwidth' is be the maximum link capacity expressed in 'Maximum bandwidth available for TE use' is the total reservable
bandwidth units. bandwidth on the link for use by all the TE circuit paths traversing
the link. The link is oversubscribed when this field is more than
the 'Maximum Bandwidth'. When the field is less than the
'Maximum Bandwidth', the remaining bandwidth on the link may
be used for non-TE traffic in a mixed network.
'Bandwidth available for TE use' is the maximum reservable bandwidth 8.1.4.4. TE-LINK-TLV-BANDWIDTH-TE
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 The bandwidth TLV specifies the bandwidth reserved for TE as follows.
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 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE Bandwidth subscribed |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bandwidth is expressed in units of 32 bytes/sec (256 bits/sec).
A 32-bit field for bandwidth would permit specification not exceeding
1 tera-bits/sec.
'TE Bandwidth subscribed' is the bandwidth that is currently
subscribed from of the link. 'TE Bandwidth subscribed' must be less
than the 'Maximum 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.5. TE-LINK-TLV-LUG
The link usage cost TLV specifies Bandwidth unit usage cost, The link usage cost TLV specifies Bandwidth unit usage cost,
TE circuit set-up cost, and any time constraints for setup and TE circuit set-up cost, and any time constraints for setup and
teardown of TE circuits on the link. teardown of TE circuits on the link.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0003 | Length = 28 | | Tag = 0x0005 | Length = 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth unit usage cost | | Bandwidth unit usage cost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE circuit set-up cost | | TE circuit set-up cost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE circuit set-up time constraint | | TE circuit set-up time constraint |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE circuit tear-down time constraint | | TE circuit tear-down time constraint |
| | | |
skipping to change at page 25, line 35 skipping to change at page 28, line 17
of January 1, 1970 UTC. A reserved value of 0 implies no circuit of January 1, 1970 UTC. A reserved value of 0 implies no circuit
setup time constraint. setup time constraint.
Circuit Teardown time constraint Circuit Teardown time constraint
This 64-bit number specifies the time at or before which all This 64-bit number specifies the time at or before which all
TE-circuit paths using the link must be torn down. The teardown TE-circuit paths using the link must be torn down. The teardown
time constraint is specified as the number of seconds from the time constraint is specified as the number of seconds from the
start of January 1 1970 UTC. A reserved value of 0 implies no start of January 1 1970 UTC. A reserved value of 0 implies no
circuit teardown time constraint. circuit teardown time constraint.
No. of TE Circuit paths 8.1.4.6. TE-LINK-TLV-COLOR
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 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 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 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 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 color. If the link belongs to 'n' number of colors, the Length
would be (4 + 4 * ((n+1)/2)) octets. would be (4 + 4 * ((n+1)/2)) octets.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x0004 | Length = 4(1 + (n+1)/2) | | Tag = 0x0006 | Length = 4(1 + (n+1)/2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Color-1 | .... | | Color-1 | .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Color-n | | | Color-n | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8.1.4.7. TE-LINK-TLV-NULL
When a TE-link has multiple TLVs to describe its metrics, the NULL
TLV is used to terminate the TLV list. The TE-LINK-TLV-NULL is same
as the TE-NODE-TLV-NULL described in section 8.1.2.4
8.2. TE-incremental-link-Update LSA (0x8d) 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 native OSPF network and a TE
network is that the latter may be subject to frequent real-time network is that the latter may be subject to frequent real-time
circuit pinning and is likely to undergo TE-state updates. Some circuit pinning and is likely to undergo TE-state updates. Some
links might undergo changes more frequently than others. Flooding links might undergo changes more frequently than others. Flooding
the network with TE-router LSAs at the aggregated speed of all the network with TE-router LSAs at the aggregated speed of all
link metric changes is simply not desirable. A smaller in size, link metric changes is simply not desirable. A smaller in size,
TE-incremental-link-update LSA is designed to advertise only the TE-incremental-link-update LSA is designed to advertise only the
incremental link updates. incremental link updates.
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 (not exceeding once every
MinLSInterval seconds). 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.
0 1 2 3 0 1 2 3
skipping to change at page 34, line 26 skipping to change at page 37, line 11
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. TE LSAs - Non-packet network 9. TE LSAs for non-packet network
A non-packet network would use all the TE LSAs described in the A non-packet network would use the TE LSAs described in the
previous section for a packet network, albeit with some variations. previous section for a packet network with some variations.
These variations are described in the following subsections. These variations are described in the following subsections.
TE-Router-Proxy LSA is defined to allow proxy advertisement for Two new LSAs, TE-Positional-ring-network LSA and
non-packet TE-nodes by an OSPF-TE router. TE-Router-Proxy LSA are defined for explicit use in
non-packet TE networks.
Readers may refer to [SONET-SDH] for a detailed description of
the terms used in the context of SONET/SDH TDM networks,
9.1. TE-Router LSA (0x81) 9.1. TE-Router LSA (0x81)
The following fields are used to describe each router link (i.e., The following fields are used to describe each router link (i.e.,
interface). Each router link is typed (see the below Type field). interface). Each router link is typed (see the below Type field).
The Type field indicates the kind of link being described. The Type field indicates the kind of link being described.
Type Type
A new link type "Positional-Ring Type" (value 5) is defined. A new link type "Positional-Ring Type" (value 5) is defined.
This is essentially a connection to a TDM-Ring. TDM ring network This is essentially a connection to a TDM-Ring. TDM ring network
skipping to change at page 36, line 16 skipping to change at page 39, line 4
type) switch capable. type) switch capable.
9.1.2. Link-TE options - TE capabilities of a TE-link 9.1.2. Link-TE options - TE capabilities of a TE-link
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|N|P|T|L|F|D| |S|L|B|C| |T|N|P|T|L|F|D| |S|L|B|C|
|E|T|K|D|S|S|B| |R|U|W|O| |E|T|K|D|S|S|B| |R|U|W|O|
| |E|T|M|C|C|S| |L|G|A|L| | |E|T|M|C|C|S| |L|G|A|L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|<---- Boolean TE flags ------->|<- TE flags pointing to TLVs ->| |<---- Boolean TE flags ------->|<- TE flags pointing to TLVs ->|
TDM, LSC, FSC bits TDM, LSC, FSC bits
- Same as defined for router TE options. - Same as defined for router TE options.
9.2. Changes to Network LSA 9.2. TE-Positional-ring-network LSA (0x82)
Network-LSA is the Type 2 LSA. With the exception of the following, Network LSA is adequate for packet TE networks. A new
no additional changes will be required to this LSA for TE TE-Positional-Ring-network-LSA is defined to represent type-5
compatibility. The LSA format and flooding scope remains unchanged. link networks, found in non-packet networks such as SONET/SDH
TDM rings. A type-5 ring is a collection of network elements
(NEs) forming a closed loop. Each NE is connected to two
adjacent NEs via a duplex connection to provide redundancy
in the ring. The sequence in which the NEs are placed on the
Ring is pertinent. The NE that provides the OSPF-xTE
functionality is termed the Gateway Network Element (GNE).
The GNE selection criteria is outside the scope of this
document. The GNE is also termed the Designated Router for
the ring.
A network-LSA is originated for each broadcast, NBMA and The TE-Positional-ring-network LSA (0x82) is modeled after the
Positional-Ring type network in the area which supports two or network LSA and has the same flooding scope as the network-LSA
more routers. The TE option is also required to be set while amongst the OSPF-xTE nodes within the area. Below is the format
propagating the TDM network LSA. of the TE-Positional-ring-network LSA. Unless specified
explicitly otherwise, the fields carry the same meaning as they
do in a network LSA. Only the differences are explained below.
TE-Positional-ring-network-LSA is originated for each
Positional-Ring type network in the area. The tuple of (Link
State ID, Network Mask) below uniquely represents a ring. The
TE option must be set in the Options flag while propagating
the LSA.
9.2.1. Positional-Ring type network LSA - New Network type for TDM-ring. 0 1 2 3
- Ring ID: (Network Address/Mask) 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
- No. of elements in the ring (a.k.a. ring neighbors) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Ring Bandwidth | LS age | Options | 0x82 |
- Ring Protection (UPSR/BLSR) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ID of individual nodes (Interface IP address) | Link State ID |
- Ring type (2-Fiber vs. 4-Fiber, SONET vs. SDH) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ring Type | Capacity Unit | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ring capacity |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Element Node Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Network LSA is required for SONET RING. Unlike the broadcast Link State ID
type, the sequence in which the Network Elements (NEs) are This is the IP interface address of the network's Gateway
placed on a RING-network is pertinent. The nodes in the ring Network Element, which is also the designated router.
must be described clock wise, assuming the Gateway Network
Element (GNE) as the starting element. Advertising Router
Router ID of the network's Designated Router.
Ring type
There are 8 types of SONET/SDH rings defined as follows.
1 - A Unidirectional Line Switched 2-fiber ring (2-fiber ULSR)
2 - A bi-directional Line switched 2-fiber ring (2-fiber BLSR)
3 - A Unidirectional Path Switched 2-fiber ring (2-fiber UPSR)
4 - A bi-directional Path switched 2-fiber ring (2-fiber BPSR)
5 - A Unidirectional Line Switched 4-fiber ring (4-fiber ULSR)
6 - A bi-directional Line switched 4-fiber ring (4-fiber BLSR)
7 - A Unidirectional Path Switched 4-fiber ring (4-fiber UPSR)
8 - A bi-directional Path switched 4-fiber ring (4-fiber BPSR)
Capacity unit
Two units are defined at this time as follows.
1 - Synchronous Transport Signal (STS), which is the basic
signal rate for SONET signals. The rate of an STS signal
is 51.84 Mbps
2 - Synchronous Transport Multiplexer(STM), which is the
basic signal rate for SDH signals. The rate of an STM
signal is 155.52 Mbps
Ring capacity
Ring capacity expressed in number of Capacity units.
Network Element Node Id
The Router ID of each of the routers in the positional-ring
network. The list must start with the designated router as
the first element. The Network Elements (NEs) must be listed
in strict clockwise order as they appear on the ring,
starting with the Gateway Network Element (GNE). The number
of NEs in the ring can be deduced from the LSA header's
length field.
9.3. 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
to do the advertisement for them. TE-router-Proxy LSA shall not be Element) to do the advertisement for them. TE-router-Proxy LSA
used to advertise Area Border Routers and/or AS border Routers. shall not be used to advertise Area Border Routers and/or AS border
Routers.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 0x8e | | LS age | Options | 0x8e |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID (Router ID of the TE Network Element) | | Link State ID (Router ID of the TE Network Element) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router | | Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 40, line 5 skipping to change at page 44, line 5
| | | | | |
+-----------------+ +-------------+ +-----------------+ +-----------------+ +-------------+ +-----------------+
|Pre-engineered TE| |AS External | |Pre-engineered TE| |Pre-engineered TE| |AS External | |Pre-engineered TE|
|circuit path(s) | |TE-Network | |circuit path(s) | |circuit path(s) | |TE-Network | |circuit path(s) |
|reachable from | |reachability | |reachable from | |reachable from | |reachability | |reachable from |
|ASBR-S1 | |from ASBR-S2 | |ASBR-S2 | |ASBR-S1 | |from ASBR-S2 | |ASBR-S2 |
+-----------------+ +-------------+ +-----------------+ +-----------------+ +-------------+ +-----------------+
Figure 9: Inter-Area Abstraction as viewed by Area-1 TE-routers Figure 9: Inter-Area Abstraction as viewed by Area-1 TE-routers
11. Changes to Data structures in OSPF-TE nodes 11. Changes to Data structures in OSPF-xTE 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 An OSPF-xTE router must be able to include the router-TE
TE capabilities (as specified in section 7.1) in the router data capabilities (as specified in section 8.1) in the router data
structure. Further, routers providing proxy service to other TE structure. OSPF-xTE 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 sets of Neighbors 11.2. Two sets of Neighbors
Two sets of neighbor data structures are required. TE-neighbors Two sets of neighbor data structures are required. TE-neighbors
set is used to advertise TE LSAs. Only the TE-nodes will be set is used to advertise TE LSAs. Only the TE-nodes will be
members of the TE-neighbor set. Native neighbors set will be used members of the TE-neighbor set. Native neighbors set will be used
to advertise native LSAs. All neighboring nodes supporting to advertise native LSAs. All neighboring nodes supporting
non-TE links are part of this set. As for flooding optimizations non-TE links are part of the Native neighbors set.
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.
in [FLOOD-OPT].
TePermitted TePermitted
If the value of the flag is TRUE, the interface may be If the value of the flag is TRUE, the interface may 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 IP packet networks, where data links may permit both TE and IP
packets. For FSC and LSC TE networks, this flag is set to packets. For FSC and LSC TE networks, this flag is set to
FALSE. FALSE.
IpTerminated FloodingPermitted
If the value of the flag is TRUE, the interface processes IP If the value of the flag is TRUE, the interface may be used
Packet data and hence may be used for OSPF data exchange. for OSPF and OSPF-xTE packet exchange to synchronize the
LSDB across all adjacent neighbors. This is TRUE by default
AdjacencySychRequired to all NonTePermitted interfaces that are enabled for OSPF.
If the value of the flag is TRUE, the interface may be used to However, it is possible to set this to FALSE
synchronize the LSDB across all adjacent neighbors. This is
TRUE by default to all IpTerminated interfaces that are
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 define any number of TLVS that describe
describe the link characteristics. 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 though 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
skipping to change at page 42, line 5 skipping to change at page 46, line 4
12.1. TE LSA type values 12.1. TE LSA type values
LSA type is an 8-bit field required by each LSA. TE LSA types LSA type is an 8-bit field required by each LSA. TE LSA types
will have the high bit set to 1. TE LSAs can range from 0x80 will have the high bit set to 1. TE LSAs can range from 0x80
through 0xFF. The following values are defined in sections through 0xFF. The following values are defined in sections
8.0 and 9.0. The remaining values are available for assignment 8.0 and 9.0. The remaining values are available for assignment
by the IANA with IETF Consensus [Ref 11]. by the IANA with IETF Consensus [Ref 11].
TE LSA Type Value TE LSA Type Value
_________________________________________ _________________________________________
TE-Router LSA 0x81 TE-Router LSA 0x81
TE-Positional-ring-network LSA 0x82
TE-Summary Network LSA 0x83 TE-Summary Network LSA 0x83
TE-Summary router LSA 0x84 TE-Summary router LSA 0x84
TE-AS-external LSAs 0x85 TE-AS-external LSAs 0x85
TE-Circuit-paths LSA 0x8C TE-Circuit-paths LSA 0x8C
TE-incremental-link-Update LSA 0x8d TE-incremental-link-Update LSA 0x8d
TE-Router-Proxy LSA 0x8e TE-Router-Proxy LSA 0x8e
12.2. TE TLV tag values 12.2. TE TLV tag values
TLV type is a 16-bit field required by each TE TLV. TLV type TLV type is a 16-bit field required by each TE TLV. TLV type
skipping to change at page 42, line 28 skipping to change at page 46, line 27
can range from 0x0001 through 0xFFFF. TLV type 0 is reserved can range from 0x0001 through 0xFFFF. TLV type 0 is reserved
and unassigned. The following TLV types are defined in sections and unassigned. The following TLV types are defined in sections
8.0 and 9.0. The remaining values are available for assignment 8.0 and 9.0. The remaining values are available for assignment
by the IANA with IETF Consensus [Ref 11]. by the IANA with IETF Consensus [Ref 11].
TE TLV Tag Reference Value TE TLV Tag Reference Value
Section Section
_________________________________________________________ _________________________________________________________
TE-LINK-TLV-SRLG Section 8.1.4.1 0x0001 TE-LINK-TLV-SRLG Section 8.1.4.1 0x0001
TE-LINK-TLV-BWA Section 8.1.4.2 0x0002 TE-LINK-TLV-BANDWIDTH-MAX Section 8.1.4.2 0x0002
TE-LINK-TLV-LUG Section 8.1.4.3 0x0003 TE-LINK-TLV-BANDWIDTH-MAX-FOR-TE Section 8.1.4.3 0x0003
TE-LINK-TLV-COLOR Section 8.1.4.4 0x0004 TE-LINK-TLV-BANDWIDTH-TE Section 8.1.4.4 0x0004
TE-LINK-TLV-LUG Section 8.1.4.5 0x0005
TE-LINK-TLV-COLOR Section 8.1.4.6 0x0006
TE-LINK-TLV-NULL Section 8.1.4.7 0x8888
TE-NODE-TLV-MPLS-SWITCHING Section 8.1.2.1 0x8001 TE-NODE-TLV-MPLS-SWITCHING Section 8.1.2.1 0x8001
TE-NODE-TLV-MPLS-SIG-PROTOCOLS Section 8.1.2.2 0x8002 TE-NODE-TLV-MPLS-SIG-PROTOCOLS Section 8.1.2.2 0x8002
TE-NODE-TLV-CSPF-ALG Section 8.1.2.3 0x8003 TE-NODE-TLV-CSPF-ALG Section 8.1.2.3 0x8003
TE-NODE-TLV-NULL Section 8.1.2.4 0x8888
13. Acknowledgements 13. Acknowledgements
The authors wish to specially thank Chitti Babu and his team The authors wish to specially thank Chitti Babu and his team
for verifying portions of the specification for a packet for verifying several portions of the specification in a
network. The authors also wish to thank Vishwas Manral, Riyad mixed packet network. The authors also wish to thank Vishwas
Hartani and Tricci So for their valuable comments and feedback Manral, Riyad Hartani and Tricci So for their valuable
on the draft. comments and feedback on the draft. Lastly, the authors wish
to thank Alex Zinin and Mike Shand for their draft (now
defunct) titled "Flooding optimizations in link state routing
protocols". The draft provided inspiration to the authors to
be sensitive to the high flooding rate, likely in TE networks.
14. Security Considerations 14. Security Considerations
Security considerations for the base OSPF protocol are covered Security considerations for the base OSPF protocol are covered
in [OSPF-v2] and [SEC-OSPF]. This memo does not create any new in [OSPF-v2] and [SEC-OSPF]. This memo does not create any new
security issues for the OSPF protocol. Security measures security issues for the OSPF protocol. Security measures
applied to the native OSPF (refer [SEC-OSPF]) are directly applied to the native OSPF (refer [SEC-OSPF]) are directly
applicable to the TE LSAs described in the document. Discussed applicable to the TE LSAs described in the document. Discussed
below are the security considerations in processing TE LSAs. below are the security considerations in processing TE LSAs.
Secure communication between OSPF-TE nodes has a number of Secure communication between OSPF-xTE nodes has a number of
components. Authorization, authentication, integrity and components. Authorization, authentication, integrity and
confidentiality. Authorization refers to whether a particular confidentiality. Authorization refers to whether a particular
OSPF-TE node is authorized to receive or propagate the TE LSAs OSPF-xTE node is authorized to receive or propagate the TE LSAs
to its neighbors. Failing the authorization process might to its neighbors. Failing the authorization process might
indicate a resource theft attempt or unauthorized resource indicate a resource theft attempt or unauthorized resource
advertisement. In either case, the OSPF-TE nodes should take advertisement. In either case, the OSPF-xTE nodes should take
proper measures to audit/log such attempts so as to alert the proper measures to audit/log such attempts so as to alert the
administrator to take necessary action. OSPF-TE nodes may refuse administrator to take necessary action. OSPF-xTE nodes may
to communicate with the neighboring nodes that fail to prompt refuse to communicate with the neighboring nodes that fail to
the required credentials. prompt the required credentials.
Authentication refers to confirming the identity of an originator Authentication refers to confirming the identity of an originator
for the datagrams received from the originator. Lack of strong for the datagrams received from the originator. Lack of strong
credentials for authentication of OSPF-TE LSAs can seriously credentials for authentication of OSPF-xTE LSAs can seriously
jeopardize the TE service rendered by the network. A consequence jeopardize the TE service rendered by the network. A consequence
of not authenticating a neighbor would be that an attacker could of not authenticating a neighbor would be that an attacker could
spoof the identity of a "legitimate" OSPF-TE node and manipulate spoof the identity of a "legitimate" OSPF-xTE node and manipulate
the state, and the TE database including the topology and the state, and the TE database including the topology and
metrics collected. This could potentially lead to metrics collected. This could potentially cause
denial-of-service on the TE network. Another consequence of not denial-of-service on the TE network. Another consequence of not
authenticating is that an attacker could pose as OSPF-TE neighbor authenticating is that an attacker could pose as OSPF-xTE
and respond in a manner that would divert TE data to the attacker. 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 Integrity is required to ensure that an OSPF-xTE message has not
been accidentally or maliciously altered or destroyed. The result been accidentally or maliciously altered or destroyed. The result
of a lack of data integrity enforcement in an untrusted environment of a lack of data integrity enforcement in an untrusted environment
could be that an imposter will alter the messages sent by a could be that an imposter will alter the messages sent by a
legitimate adjacent neighbor and bring the OSPF-TE on a node and legitimate adjacent neighbor and bring the OSPF-xTE on a node and
the whole network to a halt or cause a denial of service for the the whole network to a halt or cause a denial of service for the
TE circuit paths effected by the alteration. TE circuit paths effected by the alteration.
Confidentiality of MIDCOM messages ensure that the TE LSAs are Confidentiality of MIDCOM messages ensure that the TE LSAs are
accessible only to the authorized entities. When OSPF-TE is accessible only to the authorized entities. When OSPF-xTE is
deployed in an untrusted environment, lack of confidentiality will deployed in an untrusted environment, lack of confidentiality will
allow an intruder to perform traffic flow analysis and snoop the allow an intruder to perform traffic flow analysis and snoop the
TE control network to monitor the traffic metrics and the rate at TE control network to monitor the traffic metrics and the rate at
which circuit paths are being setup and torn-down. The intruder which circuit paths are being setup and torn-down. The intruder
could cannibalize a lesser secure OSPF-TE node and destroy or could cannibalize a lesser secure OSPF-xTE node and destroy or
compromise the state and TE-LDSB on the node. Needless to say, the 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 least secure OSPF-xTE will become the Achilles heel and make the
network vulnerable to security attacks. TE network vulnerable to security attacks.
15. Normative References 15. Normative References
[IETF-STD] Bradner, S., "Key words for use in RFCs to indicate [IETF-STD] Bradner, S., "Key words for use in RFCs to indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. 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 [RFC 2434] Narten, T. and H. Alvestrand, "Guidelines for
skipping to change at page 44, line 23 skipping to change at page 48, line 30
BCP 26, RFC 2434, October 1998. 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. [OSPF-v2] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
[SEC-OSPF] Murphy, S., Badger, M., and B. Wellington, "OSPF with [SEC-OSPF] Murphy, S., Badger, M., and B. Wellington, "OSPF with
Digital Signatures", RFC 2154, June 1997 Digital Signatures", RFC 2154, June 1997
[FLOOD-OPT] Zinin, A. and M. Shand, "Flooding Optimizations in 16. Informative References
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
Functional Description", work in progress,
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.
[MOSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584, [MOSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584,
skipping to change at page 45, line 9 skipping to change at page 49, line 9
Option", draft-ietf-ospf-nssa-update-11.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.
[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-09.txt> <draft-katz-yeung-ospf-traffic-09.txt>
[OPQLSA-GMPLS] Kompella, K., Y. Rekhter, A. Banerjee, J. Drake, [SONET-SDH] Ming-CHwan Chow, "Understanding SONET/SDH Standards
G. Bernstein, D. Fedyk, E. Mannie, D. Saha and and Applications" - A paperback or bound book,
V. Sharma, "OSPF Extensions in Support of Generalized Published by Andan publisher.
MPLS", <draft-ietf-ccamp-ospf-gmpls-extensions-09.txt>,
work in progress. [GMPLS-TE] P.A. Smith et. al, "Generalized MPLS - Signaling
Functional Description", work in progress,
draft-ietf-mpls-generalized-signaling-09.txt
Authors' Addresses Authors' Addresses
Pyda Srisuresh Pyda Srisuresh
Kuokoa Networks, Inc. Consultant
475 Potrero Avenue 849 Erie circle
Sunnyvale, CA 94085 Milpitas, CA 95035
U.S.A. U.S.A.
EMail: srisuresh@yahoo.com EMail: srisuresh@yahoo.com
Paul Joseph Paul Joseph
Force10 Networks Force10 Networks
1440 McCarthy Boulevard 1440 McCarthy Boulevard
Milpitas, CA 95035 Milpitas, CA 95035
U.S.A. U.S.A.
EMail: pjoseph@Force10Networks.com EMail: pjoseph@Force10Networks.com
 End of changes. 166 change blocks. 
453 lines changed or deleted 562 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/