Network Working Group P. SrisureshINTERNET-DRAFT CaymasRequest for Comments: 4973 Kazeon SystemsExpires as of June 31, 2005Category: Experimental P. JosephSymbol Technologies December 31, 2004Consultant July 2007 OSPF-xTE:An experimental extensionExperimental Extension to OSPF for Traffic Engineering<draft-srisuresh-ospf-te-07.txt>Status ofthisThis MemoBy submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents ofThis memo defines an Experimental Protocol for the InternetEngineering Task Force (IETF), its areas,community. It does not specify an Internet standard of any kind. Discussion andits working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents validsuggestions fora maximumimprovement are requested. Distribution ofsix months and may be updated, replaced, or obsoleted by other documents at any time. Itthis memo isinappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.htmlunlimited. Copyright Notice Copyright (C) Thelist of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html"IETF Trust (2007). Abstract This document defines OSPF-xTE, an experimental traffic engineering (TE) extension to the link-state routing protocol OSPF. OSPF-xTE defines new TELSAsLink State Advertisements (LSAs) to disseminate TE metrics within an autonomous System (AS), which may consist of multiple areas.Further,When an AS consists of TE and non-TE nodes, OSPF-xTE ensures thatNon-TEnon-TE nodes in the AS areuneffectedunaffected by the TE LSAs. OSPF-xTE generates a stand-alone TE Link State Database (TE-LSDB), distinct from the native OSPF LSDB, for computation of TE circuit paths. OSPF-xTE is versatile and extendible to non-packet networks such asSONET/TDMSynchronous Optical Network (SONET) / Time Division Multiplexing (TDM) and optical networks. IESG Note The content of this RFC was at one time considered by the IETF, and therefore it may resemble a current IETF work in progress or a published IETF work. This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this RFC should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information. See RFC 3630 for the IETF consensus protocol for OSPF Traffic Engineering. The OSPF WG position at the time of publication is that although this proposal has some useful properties, the protocol in RFC 3630 is sufficient for the traffic engineering needs that have been identified so far, and the cost of migrating to this proposal exceeds its benefits. Table of Contents 1. Introduction................................................3....................................................3 2. Principles oftraffic engineering ...........................3Traffic Engineering ...............................3 3. Terminology.................................................4.....................................................5 3.1. Native OSPFterms ......................................5Terms ..........................................5 3.2. OSPF-xTEterms .........................................5Terms .............................................6 4. Motivations behind thedesignDesign of OSPF-xTE...................8.......................9 4.1. Scalabledesign ........................................9Design ............................................9 4.2. Operable inmixedMixed andpeer networks ....................9Peer Networks ........................9 4.3. Efficient inflooding reach ............................9Flooding Reach ................................9 4.4. Ability toreserve TE-exclusive links .................10Reserve TE-Exclusive Links .....................10 4.5.Extendible design .....................................10Extensible Design .........................................11 4.6. Unified forpacketPacket andnon-packet networks ............10Non-Packet Networks ................11 4.7. NetworksbenefitingBenefiting from the OSPF-xTEdesign ..........11Design ..............11 5. OSPF-xTEsolution overview .................................12Solution Overview .....................................12 5.1. OSPF-xTE Solution.....................................12.........................................12 5.2. Assumptions...........................................13...............................................13 6. Strategy for Transition of Opaque LSAs to OSPF-xTEtransition strategy ................14.............14 7. OSPF-xTErouter adjacency -Router Adjacency -- TEtopology discovery ..........14Topology Discovery .............14 7.1. The OSPF-xTErouter adjacency .........................14Router Adjacency .............................14 7.2. The Hello Protocol....................................15........................................15 7.3. The Designated Router.................................15.....................................15 7.4. The Backup Designated Router..........................15..............................15 7.5. Flooding and the Synchronization of Databases.........16.............16 7.6. ThegraphGraph ofadjacencies ..............................16Adjacencies ..................................16 8. TE LSAs forpacket network .................................18Packet Network .....................................18 8.1. TE-Router LSA (0x81)..................................19......................................18 8.1.1. Router-TE Flags: TE Capabilities of the Router .....19 8.1.2. Router-TE TLVs .....................................20 8.1.3. Link-TE Flags: TE Capabilities of a Link ...........22 8.1.4. Link-TE TLVs .......................................23 8.2.TE-incremental-link-UpdateTE-Incremental-Link-Update LSA (0x8d).................27.....................26 8.3.TE-Circuit-pathsTE-Circuit-Path LSA (0x8C)...........................29................................28 8.4. TE-Summary LSAs.......................................32...........................................31 8.4.1. TE-Summary Network LSA (0x83) ......................32 8.4.2. TE-Summary Router LSA (0x84) .......................33 8.5. TE-AS-external LSAs (0x85)............................34................................34 9. TE LSAs fornon-packet network .............................36Non-Packet Network .................................36 9.1. TE-Router LSA (0x81)..................................36......................................36 9.1.1. Router-TE flags - TE Capabilities of a Router ......37 9.1.2. Link-TE Options: TE Capabilities of a TE Link ......38 9.2.TE-Positional-ring-networkTE-positional-ring-network LSA (0x82).................38.....................38 9.3. TE-Router-Proxy LSA (0x8e)............................40................................40 10. Abstracttopology representationTopology Representation with TEsupport ...........41Support ..............42 11. Changes to DatastructuresStructures in OSPF-xTErouters .............43Nodes ..................44 11.1. Changes to Routerdata structure .....................43Data Structure .........................44 11.2. TwosetSets of Neighbors.................................43....................................44 11.3. Changes to Interfacedata structure ..................43Data Structure ......................44 12. IANA Considerations........................................44...........................................45 12.1. TE LSAtype values ...................................44Type Values .......................................45 12.2. TE TLVtag values ....................................45Tag Values ........................................46 13. Acknowledgements...........................................45..............................................46 14. Security Considerations....................................46.......................................47 15. Normative References.......................................47..........................................48 16. Informative References.....................................47 17. Authors' Addresses .........................................48 18. Full Copyright Statement ...................................48........................................48 1. Introduction This document defines OSPF-xTE, an experimental traffic engineering (TE) extension to the link-state routing protocol OSPF. The objective of OSPF-xTE is to discover TE network topology and disseminate TE metrics within an autonomous system (AS). Astand-alonestand- alone TE Link State Database (TE-LSDB), different from the native OSPF LSDB, is created to facilitate computation of TE circuit paths. Devising algorithms to compute TE circuit paths is not an objective of this document. OSPF-xTE is different from the Opaque-LSA-based approach outlined in [OPQLSA-TE]. Section 4 describes the motivations behind the design of OSPF-xTE. Section 6 outlines a transition path for those currently using [OPQLSA-TE] for intra-area and wish to extend this using OSPF-xTE across the AS. Readers interested in TE extensions forthepacket networks alone may skip section 9.0. 2. Principles oftraffic engineeringTraffic Engineering The objective of traffic engineering (TE) is to set up circuit path(s) between a pair of nodes or links and to forward traffic of a certain forwarding equivalency class (FEC) through the circuit path. Onlytheunicast circuit paths are considered in thissection. Multicastsection; multicast variations are outside the scope. A traffic engineered circuit path isuni-directionalunidirectional and may be identified by thetuple oftuple: (FEC, TE circuit parameters,Origin Node/Link, Destination node/Link). Forwarding Equivalency Classorigin node/link, destination node/link). A forwarding equivalency class (FEC) is a grouping of traffic that is forwarded in the same manner by a node.AAn FEC may be classified based on a number ofcriteriacriteria, asfollows.follows: a)Traffictraffic arriving on a specific interface, b)Traffictraffic arriving at a certain time of day, c)Traffictraffic meeting a certain packet based classification criteria (ex: based on a match of the fields in the IP and transport headers within a packet), d)Traffictraffic in a certain priority class, e)Traffictraffic arriving on a specific set of TDM(STS)(Synchronous Transport Signal (STS)) circuits on an interface, or f)Traffictraffic arriving on a certain wavelength of aninterfaceinterface. Discerning traffic based on the FEC criteria is mandatory for Label Edge Routers (LERs). The intermediateLabel SwitchedLabel-Switched Routers (LSRs) are transparent to the traffic content. LSRs aremerelyonly responsible forkeeping the circuit in-tact formaintaining the circuit for its lifetime. This document will not addressdefiningdefinition of FEC criteria,orthe mapping ofaan FEC to circuit, or the associated signaling to set up circuits. [MPLS-TE] and [GMPLS-TE] address the FEC criteria. [RSVP-TE] and [CR-LDP] address signaling protocols to set up circuits. This document is concerned with the collection of TE metrics for all the TE enforceable nodes and links within an autonomous system. TE metrics for a node may include the following. a) Ability to perform traffic prioritization, b) Ability to provision bandwidth on interfaces, c) Support for Constrained Shortest Path First (CSPF) algorithms, d) Support for certain TE-Circuit switch type, and e) Support for a certain type of automatic protectionswitchingswitching. TE metrics for a link may include the following. a)Availableavailable bandwidth, b)Reliabilityreliability of the link, c)Colorcolor assigned to the link, d)Costcost of bandwidth usage on the link, and e)Membership tomembership in a Shared Risk Link Group(SRLG)(SRLG). A number of CSPF (Constraint-based Shortest Path First) algorithms may be used to dynamically set up TE circuit paths in a TE network. OSPF-xTE mandates that the originating and the terminating entities of a TE circuit pathtobe identifiable bytheirIP addresses. 3. Terminology Definitions of the majority of the terms used in the context of the OSPF protocol may be found in [OSPF-V2]. MPLS and traffic engineering terms may be found in [MPLS-ARCH]. RSVP-TE and CR-LDPsignaling specificsignaling-specific terms may be found in [RSVP-TE] and[CR-LDP][CR-LDP], respectively. The following subsections describe the native OSPF terms and the OSPF-xTE terms used within this document. 3.1. Native OSPFterms 3.1.1.Terms o Native node (Non-TE node) A native or non-TE node is an OSPF router that is capable of IP packet forwardingandbut 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.o 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.o 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"Non-TE network", "native-OSPF network", andnon-TE topology"non-TE topology" are used synonymously throughout the document.3.1.4.o LSP LSP stands for"Label Switched"Label-Switched Path". An LSP is a TE circuit path in a packet network. The termsLSP"LSP" andTE"TE circuitpathpath" are used synonymously in the context of packet networks.3.1.5.o LSA LSA stands for OSPF "Link State Advertisement".3.1.6.o LSDB LSDB stands for"LSA"Link State Database". An LSDBiscontains a representation of the topology of a network. A native LSDB, constituted of native OSPF LSAs, represents the topology of a native IP network. The TE-LSDB, on the other hand, is constituted of TE LSAs and is a representation of the TE network topology. 3.2. OSPF-xTEterms 3.2.1.Terms o TE node A TE nodeTE-Nodeis a node in the trafficengineeredengineering (TE) network. ATE-nodeTE node has a minimum of oneTE-linkTE link attached to it. Associated with each TE node is a set of supported TE metrics. A TE node may also participate in a native IP network. In a SONET/TDM or photonic cross-connect network, a TE node is 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 themselves.3.2.2.o TE link A TELinklink is a network attachment point to aTE-nodeTE node and is intended for traffic engineering use. Associated with each TE link is a set of supported TE metrics. A TE link may also optionally carry native IP traffic. Of the various links attached to aTE-node,TE node, only the links that take part in atraffic engineeredtraffic-engineered network are calledtheTE links.3.2.3.o TE circuit path A TE circuit path is auni-directionalunidirectional datapath,path that is defined by a list of TE nodes connected to each other through TE links. A TE circuit path is also often referredmerelysimply as a circuit path or a circuit. For the purposes of OSPF-xTE, the originating and terminating entities of a TE circuit path must be identifiable by their IP addresses. As a general rule, all nodes and links party to aTraffic Engineeredtraffic-engineered network should be uniquely identifiable by an IP address.3.2.4.o OSPF-xTE node (OSPF-xTE router) An OSPF-xTE node is a TE node that runs the OSPF routing protocol and the OSPF-xTE extensions described in this document. An autonomous system (AS) maybe constitutedconsist of a combination of native and OSPF-xTE nodes.3.2.5.o TE Control network The IP network used by the OSPF-xTE nodes for OSPF-xTE communication is referred as the TE control network or simply the control network. The control network can be independent of the TE data network.3.2.6.o TE network (TE topology) A TE network is a network of connectedTE-nodesTE nodes andTE-linksTE links, for the purpose of setting up one or more TE circuit paths. The termsTE network, TE"TE network", "TE datanetworknetwork", andTE topology"TE topology" are used synonymously throughout the document.3.2.7.o Packet-TE network (Packet network) 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 packet with an MPLS header, followed by data octets. The intermediary node(s) of a circuit path in a packet-TE network perform MPLS label swapping to emulate the circuit. Unless specified otherwise, the termpacket network"packet network" is used throughout the document to refer to a packet-TE network.3.2.8.o Non-packet-TE network (Non-packet network) A non-packet-TE network isTE-networka TE network in which the nodes switch non-packet entities such asanSTS timeslot, aslots, Lambdawavelengthwavelengths, or simplyan interface.interfaces. SONET/TDM andFiberfiber cross-connect networks are examples ofnon-packet-TEnon- packet-TE networks. Circuit emulation in these networks is accomplished by the switch fabric in the intermediary nodes (based on TDM time slot, fiberinterfaceinterface, or Lambda). Unless specified otherwise, the term non-packet network is used throughout the document to refer a non-packet-TE network.3.2.9.o Mixed network A mixed network is a network that is constituted ofpacket-TEboth packet- TE and non-TEnetworks combined.networks. Traffic in the network is strictly datagramoriented -oriented, i.e., IP datagrams or MPLS packets. Routers in a mixed network may be TE or native nodes. OSPF-xTE is usable within a packet network or a mixed network.3.2.10.o Peer network A peer network is a network that is constituted of packet-TE and non-packet-TE networks combined. In a peer network, a TE node could potentially support TE links for the packet as well as non-packet data. OSPF-xTE is usable within a packet network or a non-packet network or a peer network, which is a combination of the two.3.2.11.o CSPF CSPF stands for "Constrained Shortest Path First". Given a TE LSDB and a set of constraints that must be satisfied to form a circuit path, there may be several CSPF algorithms to obtain a TE circuit path that meets the criteria.3.2.12.o TLV A TLV stands forana data object in theform ofform: Tag-Length-Value. All TLVs are assumed to be of the following format, unless specified otherwise. The Tag andlengthLength are 16 bits wide each. ThelengthLength includes the 4 octets required for Tag and Length specification. All TLVs described in this document are padded to 32-bit alignment. Any padding required for alignment will not be a part of the length field, however. TLVs are used to describe traffic engineering characteristics of the TE nodes, TElinkslinks, and TE circuit paths. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag | Length (4 or more) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+3.2.13.o Router-TE TLVs (Router TLVs) TLVs used to describe the TE capabilities of aTE-node. 3.2.14.TE node. o Link-TE TLVs (Link TLVs) TLVs used to describe the TE capabilities of aTE-link.TE link. 4. Motivations behind thedesignDesign of OSPF-xTE There are several motivations that led to the design of OSPF-xTE. OSPF-xTE is scalable,efficientefficient, and usable across a variety of network topologies. These motivations are explained in detail in the following subsections. The last subsection lists real-world network scenarios that benefit from the OSPF-xTE. 4.1. Scalabledesign OSPF-xTE area levelDesign In OSPF-xTE, an area-level abstraction provides the scaling required for the TE topology in a large autonomous system (AS). 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 aOSPF-xTEOSPF- xTE node in an area. [OPQLSA-TE], on the other hand, is designed for intra-area and is not scalable to AS-wide scope. 4.2. Operable inmixedMixed andpeer networksPeer Networks OSPF-xTE assumes that an AS may be constituted of coexisting TE and non-TE networks. OSPF-xTE dynamically discovers TE topology and the associated TE metrics of the nodes and links that form the TE network. As such, OSPF-xTE generates a stand-alone TE-LSDB that is fully representative of the TE network. Stand-alone TE-LSDB allows for speedy TE computations. [OPQLSA-TE] is designed for packet networks and is not suitable for mixes and peer networks. TE-LSDB in [OPQLSA-TE] is derived from the combination ofopaqueOpaque LSAs and native LSDB. Further, the TE-LSDB thus derived has no knowledge of the TE capabilities of the routers in the network. 4.3. Efficient inflooding reachFlooding Reach OSPF-xTE is able to identify the TE topology in a mixed network andwillto limit the flooding of TE LSAs tojustonly theTE-nodes.TE nodes. Non-TE nodes are not bombarded with TE LSAs. In a TE network, a subset of the TE metrics may be prone to rapid change, while others remain largely unchanged. Changes in TE metrics must be communicated at the earliest throughout the network to ensure that the TE-LSDB is up-to-date within the network. As a general rule, a TE network is likely to generate significantly more control traffic than a native network. The excess traffic is almost directly proportional to the rate at which TE circuits are set up and torn down within the TE network. The TE database synchronization should occur much quicker compared to the aggregate circuit set up and tear-down rates. OSPF-xTE defines TE-Incremental-Link-update LSA (section 8.2) to advertisejustonly a subset of the metrics that are prone to rapid changes. The more frequent and wider theflooding frequency,flooding, the larger the number of retransmissions and acknowledgements. The same information (needed or not) may reach a router through multiple links. Even if the router did not forward the information past the node, it would still have to send acknowledgements across all the various links on which the LSAs tried to converge. It is undesirable to flood non-TE nodes with TE information. 4.4. Ability toreserve TE-exclusive linksReserve TE-Exclusive Links OSPF-xTE draws a clear distinction between TE and non-TE links. A TE link may be configured to permit TE traffic alone, and not permit best-effort IP traffic on the link. This permits TE enforceability on the TE links. When links of aTE-topologyTE topology do not overlap the links of a native IP network, OSPF-xTE allows for virtual isolation of the two networks. Best-effort IP network and TE network often have different service requirements. Keeping the two networks physically isolated can be expensive. Combining the two networks into a single physically connected network will bring economies of scale, while service enforceability can be maintained individually for each of the TE and non-TE sections of the network. [OPQLSA-TE] does not support the ability to isolatebest- effortbest-effort IP traffic from TE traffic on a link. All links are subject tobest-effortbest- effort IP traffic. An OSPF router could potentially select a TE link to be its least cost link and inundate the link with best-effort IP traffic, thereby rendering the link unusable for TE purposes. 4.5.Extendible designExtensible Design The OSPF-xTE design is based on thetried and testedtried-and-tested OSPF paradigm, and it inherits all the benefits oftheOSPF, present and future.TE-LSAsTE LSAs areextendible,extensible, just as the native OSPF on which OSPF-xTE isfounded.founded are extensible. 4.6. Unified forpacketPacket andnon-packet networksNon-Packet Networks OSPF-xTE is usable within a packet network or a non-packet network or a combination peer network. Signaling protocols such as RSVP and LDP work the same across packet and non-packet networks. Signaling protocols merely need the TE characteristics of nodes and links so they can signal the nodes to formulate TE circuit paths. In a peer network, the underlying control protocol must be capable of providing a unified LSDB for all TE nodes (nodes with packet-TE links as well as non-packet-TE links) in the network. OSPF-xTE meets this requirement. 4.7. NetworksbenefitingBenefiting from the OSPF-xTEdesignDesign Below are examples of some real-world network scenarios that benefit from OSPF-xTE.4.7.1.o IP providers transitioning to provide TE services Providers needing to supportMPLS basedMPLS-based TE in their IP network may choose to transition gradually.Perhaps,They may add new TE links or convert existing links into TE links within an area first and progressively advance toofferoffering MPLS in the entire AS. Not all routers will support TE extensions at the same time during the migration process. Use ofTE specificTE-specific LSAs and their flooding to OSPF-xTE only nodes will allow the vendor to introduce MPLS TE without destabilizing the existing network. The native OSPF-LSDB will remain undisturbed while newer TE links are added to the network.4.7.2.o Providers offeringBest-effort-IPbest-effort-IP & TE services Providers choosing to offer both best-effort-IP and TE based packet services simultaneously on the same physically connected network will benefit from the OSPF-xTE design. By maintaining independent LSDBs for each type of service, TE links are not cannibalized in a mixed network.4.7.3.o Large TE networks The OSPF-xTE design is advantageous in large TE networks that 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 haveup-to-date As-wideup-to-date, AS-wide, TE reachability knowledge. This in turn will make TE circuit setup predictable and computationally bounded.4.7.4. Non-packet networkso Non-Packet Networks and PeernetworksNetworks Vendors may also use OSPF-xTE for their non-packet TE networks. OSPF-xTE defines the following functions in support of non-packet TE networks. (a) "Positional-Ring" type networkLSA andLSAs. (b) RouterProxying -proxying -- allowing a router to advertise on behalf of other nodes (that are notPacket/OSPF capable).packet/OSPF-capable). 5. OSPF-xTEsolution overviewSolution Overview 5.1. OSPF-xTE SolutionLocally scoped opaqueLocally-scoped Opaque LSA (type 9) is used to discovery the TE topology within a network. Section 7.1 describes in detail the use of type 9 Opaque LSA for TE topology discovery. TE LSAs are designed for use by the OSPF-xTE nodes. Section 8.0 describes the TE LSAs in detail. Changes required of the OSPF data structures to support OSPF-xTE are described in section 11.0. A new TE-neighbors data structure will be used to advertise TE LSAs alongTE-topology.TE topology. An OSPF-xTE node will havethea native LSDB andthea TE-LSDB,Awhile a native OSPF node will have justthea native LSDB. Consider thefollowingOSPFareaarea, constituted of OSPF-xTE and native OSPFrouters.routers, shown in Figure 1. Nodes RT1, RT2,RT3RT3, and RT6 are OSPF-xTE routers with TE and non-TE link attachments. Nodes RT4 and RT5 are native OSPF routers with no TE links. When the LSA database is synchronized, all nodes will share the same native LSDB. OSPF-xTE nodes alone will have the additional TE-LSDB. +---+ | |--------------------------------------+ |RT6|\\ | +---+ \\ | || \\ | || \\ | || \\ | || +---+ | || | |----------------+ | || |RT1|\\ | | || +---+ \\ | | || //| \\ | | || // | \\ | | || // | \\ | | +---+ // | \\ +---+ | |RT2|// | \\|RT3|------+ | |----------|----------------| | +---+ | +---+ | | | | | | +---+ +---+ |RT5|--------------|RT4| +---+ +---+ Legend: --Native(non-TE)Native (non-TE) network link |Native(non-TE)Native (non-TE) network link \\ TE network link || TE network link Figure6:1. A (TE + native) OSPFnetwork topologyNetwork Topology 5.2. Assumptions OSPF-xTE is an extension to the native OSPF protocol and does not mandate changes to the existing OSPF. OSPF-xTE design makes the following assumptions.1.(1) An OSPF-xTE node will need to establish router adjacency with at least one other OSPF-xTE node in the area in order for the router'sTE-databaseTE database to be synchronized within the area. Failing this, the OSPF router will not be in the TE calculations of other TE routers in the area. It is the responsibility of the network administrator(s) to ensure connectedness of the TE network. Otherwise, there can be disjoint TE topologies within a network.2.(2) OSPF-xTE nodes must advertise the link state of itsTE-links. TE-linksTE links. TE links are not obligated to support native IP traffic. Hence, an OSPF-xTE node cannot be required to synchronize itslink-statelink- state database with neighbors on all its links. The only requirement is to have the TE LSDB synchronized across all OSPF-xTE nodes in the area.3.(3) A link in a packet network may be designated as aTE-linkTE link or a native-IP link or both. For example, a link may be used for both TE and non-TE traffic,soas long as the link isunder-subscribedunder subscribed in bandwidth for TE traffic- say,(for example, 50% of the link capacity is set aside for TEtraffic. 4.traffic). (4) Non-packet TE sub-topologies must have a minimum of one node running OSPF-xTE protocol. For example, a SONET/SDH TDM ring must have a minimum of one Gateway NetworkElement(GNE)Element (GNE) running OSPF-xTE. The OSPF-xTE node will advertise on behalf of all the TE nodes in the ring. 6. Strategy for Transition of Opaque LSAs to OSPF-xTEtransition strategyBelow is a strategy to transition implementations currently usingopaqueOpaque LSAs ([OPQLSA-TE]) within an area to adapt OSPF-xTE in a gradual fashion across the AS.1.(1) Use [OPQLSA-TE] within an area. Derive TE topology within the area from the combination ofopaqueOpaque LSAs and native LSDB.2.(2) Use TE-Summary LSAs andTE-AS-external-LSAsTE-AS-external LSAs for inter-areaCommunication. Make use ofcommunication. Use theTE-topologyTE topology within an area to summarize the TE networks in the area and advertise the same to allTE-nodesTE nodes in the backbone. The TE-ABRs (TE area border routers) on the backbone area willin-turnin turn advertise these summaries within their connected areas. 7. OSPF-xTErouter adjacency -Router Adjacency -- TEtopology discoveryTopology Discovery OSPF creates adjacencies between neighboring routers for the purpose of exchanging routing information.In theThe followingsubsections, wesubsections describe the use oflocally scopedlocally-scoped OpaqueLSALSAs to discover OSPF-xTE neighboring routers. The capability is used as the basis to build a TE topology. 7.1. The OSPF-xTErouter adjacencyRouter Adjacency OSPF uses the options field in thehelloHello packet to advertise optional router capabilities[OSPF].[OSPF-V2]. However, all the bits in this field have been allocated and there is no way to advertise OSPF-xTE capability using the options field at this time. This document proposes usinglocal scope opaque lsalocal-scope Opaque LSA (OPAQUE-9 LSA) to advertise support for OSPF-xTE and establish OSPF-xTE adjacency. In order to exchange Opaque LSAs, the neighboring routers must have the O-bit (Opaque option bit) set in the optionsfield as a prerequisite.field. [OSPF-CAP] proposes a format for exchanging router capabilities via OPAQUE-9 LSA. Routers supporting OSPF-xTE will be required to set the "OSPF Experimental TE" bit within the "router capabilities" field. Two routers will not becomeTE-neighborsTE neighbors unless they share a common network link on which both routers advertise support for OSPF-xTE. Routers thatdonotdo not support OSPF-xTE may simply ignore the advertisement. 7.2. The Hello Protocol The HelloProtocolprotocol is primarily responsible for dynamically establishing and maintaining neighbor adjacencies. In a TE network, it is not required for all links and neighbors to establish adjacency using this protocol. OSPF-xTE router adjacency between two routers is established using the method described in the previous section. ForNBMAnon-broadcast multi-access (NBMA) and broadcast networks, the HELLO protocol is responsible for electing the Designated Router and the Backup Designated Router. Routers supporting the TE option shall be given a higher precedence for becoming a designated router over those that do not support TE. 7.3. The Designated Router When a router's non-TE link first becomes functional, it checks to see whether there is currently a Designated Router for the network. If there is one, it accepts that Designated Router, regardless of itsRouter Priority,router priority, so long as the current designated router is TE compliant. Otherwise, the router itself becomes Designated Router if it has the highest Router Priority on the network and is TE compliant. OSPF-xTE must be implemented on the most robust routers, as they become likely candidates to take on the role asdesignated router.Designated Router. 7.4. The Backup Designated Router The Backup Designated Router is also elected by the Hello Protocol. Each Hello Packet has a field that specifies the Backup Designated Router for the network. Once again, TE-compliance must be weighed in conjunction with router priority in electing thebackup designated router.Backup Designated Router. 7.5. Flooding and the Synchronization of Databases In OSPF, adjacent routers within an area are required to synchronize their databases. However, a more concise requirement is that all routers in an area must converge on the same LSDB.However, asAs stated in item 2 of section 5.2, a basic assertionbyof OSPF-xTE is that the links used by the OSPF-xTE control network for flooding must not be required to match the links used by the data network for real-time data forwarding. For instance, it should not be required torun thesend OSPF-xTE messages over aTE-linkTE link that is configurednottopermitreject non-TE traffic. However, the control network must besetupset up such that a minimum of one path exists between any two OSPF or OSPF-xTE routers within thenetworknetwork, for flooding purposes. This revised control network connectivity requirement does not jeopardize convergence of LSDB within an area. In a mixed network, where some of the neighbors are TE compliant and others are not, the designated OSPF-xTE router will exchange different sets of LSAs with its neighbors. TE LSAs are exchanged only with the TE neighbors. Native 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 noteffectaffect 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 newThe OSPFIGP-TE well-known multicast address 224.0.0.24may be usedhas been assigned by IANA for the exchange ofTE compliantTE-compliant database descriptors during database synchronization. 7.6. ThegraphGraph ofadjacenciesAdjacencies If two routers have multiple networks in common, they may have multiple adjacencies between them. The adjacency may be one of two types - native OSPF adjacency and TE adjacency. OSPF-xTE routers will form both types of adjacency. Two types of adjacency graphs arepossiblepossible, depending on whether a Designated Router is elected for the network. On physicalpoint-to-pointpoint-to- point networks, point-to-multipoint networks,Point-to-Multipoint networksandVirtualvirtual links, neighboring routers become adjacent whenever they can communicate directly. The adjacency can beone ofeither (a) TE-compliant or (b) native. In contrast, on broadcast and NBMA networks the designated router and the backup designated router may maintain two sets of adjacency. The remaining routers will form either TE-compliant or native adjacency. In theBroadcastbroadcast networkbelow,in Figure 2, routers RT7 and RT3 are chosen as thedesignatedDesignated andbackup routersBackup Designated Routers, respectively. Routers RT3, RT4 and RT7 areTE-compliant.TE-compliant, but RT5 and RT6 are not.So,So RT4 will have TE-compliant adjacency with the designated and backuprouters.routers, while RT5 and RT6 will only have native adjacency with thedesignatedDesignated andbackup routers.Backup Designated Routers. Network Adjacency +---+ +---+ |RT1|------------|RT2|o--------------------oo-----------------o +---+ N1 +---+ RT1 RT2 RT7 o::::: +---+ +---+ +---+ /| : |RT7| |RT3| |RT4| / | : +---+ +---+ +---+ / | : | | | / | : +-----------------------+ RT5o RT6o oRT4 N2 | |N2* *:; +---+ +---+ * *:; |RT5| |RT6| * *:; +---+ +---+ **: o:::::; o;;;;; RT3 Adjacency Legend: ----- Native adjacency (primary) ***** Native adjacency(Backup)(backup) ::::: TE-compliant adjacency (primary) ;;;;; TE-compliant adjacency(Backup)(backup) Figure6: The graph of adjacencies2. Two Adjacency Graphs withTE-compliant routers.TE-Compliant Routers 8. TE LSAs forpacket networkPacket Network The OSPFv2protocol, as of now,protocol currently has a total of 11 LSA types. LSA types 1 through 5 are defined in[OSPF-v2].[OSPF-V2]. LSA types 6,77, and 8 are defined in [MOSPF],[NSSA][NSSA], and[BGP-OSPF][BGP-OSPF], respectively. LSA types 9 through 11 are defined in [OPAQUE]. Each LSA type has a unique flooding scope. Opaque LSA types 9 through 11 are general purpose LSAs, with flooding scope set to link-local,area-localarea-local, and AS-wide (except stub areas) respectively. In the following subsections, we define new LSAs for traffic engineering (TE) use. TheValuesvalues for the new TE LSA types are assignedsuch thatwith the high bit of the LSA-type octetisset to 1. The new TE LSAs are largely modeled after the existing LSAs for content format and have a unique flooding scope. TE-router LSA is defined to advertise TE characteristics of anOSPF-xTEOSPF- xTE router and all theTE-linksTE links attached to the router.TE-incremental-Link-UpdateTE- incremental-Link-Update LSA is defined to advertise incremental updates to the metrics of a TE link. Flooding scope for both these LSAs is restricted to an area. TE-Summary network and router LSAs are defined to advertise the reachability of area-specific TE networks andArea Border Routersarea border routers (along with router TE characteristics) to external areas. FloodingScopescope of the TE-Summary LSAs is the TE topology in the entire AS less the non-backbone area for which thetheadvertising router is an ABR. Just as with native OSPF summary LSAs, theTE-summaryTE-Summary LSAs do not reveal the topological details of an area to external areas. TE-AS-external LSA and TE-Circuit-Path LSA are defined to advertise AS external network reachability and pre-engineered TEcircuitscircuits, respectively. While flooding scope for both these LSAs can be the entire AS, flooding scope for the pre-engineered TE circuit LSA may optionally be restricted to just the TE topology within an area. 8.1. TE-Router LSA (0x81) The TE-router LSA (0x81) is modeled after the router LSA and has the same flooding scope as therouter-LSA.router LSA. However, the scope is restricted to only the OSPF-xTE nodes within the area. TheTE-routerTE router LSA describes the TE metrics of the router as well as theTE-linksTE links attached to the router. Below is the format of the TE-router LSA. Unless specified explicitly otherwise, the fields carry the same meaning as they do in a router LSA. Only the differences are explained below. Router-TE flags, Router-TE TLVs, Link-TE options, and Link-TE TLVs are each described in the following sub-sections. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | 0x81 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 |V|E|B| 0 | Router-TE flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router-TE flags (contd.) | Router-TE TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .... | # of TE links | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | 0 | Link-TE flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link-TE flags (contd.) | Zero or more Link-TE TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | 8.1.1. Router-TEflags -Flags: TEcapabilitiesCapabilities of therouterRouter The following flags are used to describe the TE capabilities of an OSPF-xTE router. The remaining bits of the 32-bit word are reserved for future use. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L|L|P| | | | |L|S|C| |S|E|S| | | | |S|I|S| |R|R|C| | | | |P|G|P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |<---- Boolean TE flags ------->|<- TE flags pointing to TLVs ->| Bit LSR - When set, the router is considered to have LSR (Label- Switched Router) capability. Bit LER - When set, the router is considered to have LER capability. All MPLS border routers will be required to havetheLER capability.WhenSetting both the LER and Ebit is also set, thatbits indicates an AS Boundary router with LER capability.WhenSetting both the LER and Bbit is also set, thatbits indicates an area border router with LER capability. Bit PSC - Indicates the node isPacket Switch Capable.packet-switch capable. Bit LSP - An MPLS Label switch TLV TE-NODE-TLV-MPLS-SWITCHING follows. This is applicable only when the PSC flag is set. Bit SIG - An MPLSSignaling protocol supportSignaling-protocol-support TLVTE-NODE-TLV-MPLS-SIG-PROTOCOLSTE-NODE-TLV- MPLS-SIG-PROTOCOLS follows. BIT CSPF - A CSPF algorithm support TLV TE-NODE-TLV-CSPF-ALG follows. 8.1.2. Router-TE TLVs The following Router-TE TLVs are defined.8.1.2.4.8.1.2.1. TE-NODE-TLV-MPLS-SWITCHING MPLS switching TLV is applicable only for packet switched nodes. The TLV specifies the MPLS packet switching capabilities of the TE node. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x8001 | Length = 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LabeldepthDepth | QOS | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+'Label depth'Label Depth is the depth of label stack the node is capable of processing on its ingress interfaces. An octet is used to represent label depth. A default value of 1 is assumed when the TLV is not listed. Label depth is relevant when an LER has to popoffmultiple labels off the MPLS stack.'QOS'QOS is asingle octetsingle-octet field that may be assigned '1' or '0'. Nodes supporting QOS are able to interpret the EXP bits in the MPLS header to prioritize multiple classes of traffic through the same LSP. 8.1.2.2. TE-NODE-TLV-MPLS-SIG-PROTOCOLS MPLS signaling protocols TLV lists all the signaling protocol supported by the node. An octet is used to list each signaling protocol supported. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x8002 | Length = 5, 6 or 7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol-1 | ... | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ RSVP-TE protocol is represented as 1, CR-LDP as22, and LDP as 3. These are the only permitted signaling protocols at this time. 8.1.2.3. TE-NODE-TLV-CSPF-ALGORITHMS The CSPF algorithms TLV lists all the CSPF algorithm codes supported. Support for CSPF algorithms makes the node eligible to compute complete or partial circuit paths. Support for CSPF algorithms can also be beneficial in knowing whether or not a node is capable of expanding loose routes (in an MPLS signaling request) into a detailed circuit path. Two octets are used to list each CSPF algorithm code. The algorithm codes may be vendor defined and unique within an Autonomous System. If the node supports 'n' CSPF algorithms, the Length would be (4 + 4 * ((n+1)/2)) octets. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x8003 | Length = 4(1 + (n+1)/2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CSPF-1 | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CSPF-n | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8.1.2.4. TE-NODE-TLV-NULL When a TE-Router or aTE-linkTE 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-TEflags -Flags: TEcapabilitiesCapabilities of alinkLink The following flags are used to describe the TE capabilities of a link. The remaining bits of the 32-bit word are reserved for future use. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T|N|P| | | |D| |S|L|B|C| |E|T|K| | | |B| |R|U|W|O| | |E|T| | | |S| |L|G| |L| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |<---- Boolean TE flags ------->|<- TE flags pointing to TLVs ->| Bit TE - Indicates whether TE is permitted on the link. A link can be denied for TE use by setting the flag to 0. Bit NTE - Indicates whether non-TE traffic is permitted on the TE link. This flag is relevant only when the TE flag is set. Bit PKT - Indicates whether or not the link is capable of IP packet processing. Bit DBS - Indicates whether or notDatabasedatabase synchronization is permitted on this link.SRLGBit SRLG - Shared Risk Link Group TLV TE-LINK-TLV-SRLG follows. Bit LUGbit- Linkusage cost metricUsage Cost Metric TLV TE-LINK-TLV-LUG follows. Bit BWbit- One or more LinkbandwidthBandwidth TLVsfollowfollow. Bit COLbit- Link Color TLV TE-LINK-TLV-COLOR follows. 8.1.4. Link-TE TLVs 8.1.4.1. TE-LINK-TLV-SRLG The SRLG describes the list of Shared Risk Link Groups (SRLG) the 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. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0001 | Length = 4(1 + (n+1)/2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRLG-1 | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRLG-n | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+8.1.4.2.8.1.4.2 TE-LINK-TLV-BANDWIDTH-MAX ThebandwidthBandwidth TLV specifies the maximum bandwidth of thelinklink, as follows. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0002 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maximum Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Bandwidth is expressed in units of 32 bytes/sec (256 bits/sec). A 32-bit field for bandwidth would permit specification not exceeding 1tera-bits/sec. 'Maximum bandwidth'terabit/sec. Maximum Bandwidth isbethe 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 ThebandwidthBandwidth TLV specifies the maximum bandwidth available for TEuseuse, as follows. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0003 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maximum Bandwidth available for TE use | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Bandwidth is expressed in units of 32 bytes/sec (256 bits/sec). A 32-bit field for bandwidth would permit specification not exceeding 1tera-bits/sec. 'Maximum bandwidthterabit/sec. "Maximum Bandwidth available for TEuse'use" is the total reservable bandwidth on the link for use by all the TE circuit paths traversing the link. The link is oversubscribed when this field is more than the'Maximum Bandwidth'.Maximum Bandwidth. When the field is less than the'Maximum Bandwidth',Maximum Bandwidth, the remaining bandwidth on the link may be used for non-TE traffic in a mixed network. 8.1.4.4. TE-LINK-TLV-BANDWIDTH-TE ThebandwidthBandwidth TLV specifies the bandwidth reserved for TE as follows. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0004 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TE Bandwidth subscribed | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Bandwidth is expressed in units of 32 bytes/sec (256 bits/sec). A 32-bit field for bandwidth would permit specification not exceeding 1tera-bits/sec. 'TEterabit/sec. "TE Bandwidthsubscribed'subscribed" is the bandwidth that is currently subscribed from of the link.'TE"TE Bandwidthsubscribed'subscribed" must be less than the'Maximum"Maximum bandwidth available for TEuse'.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 specifiesBandwidthbandwidth unit usage cost, TE circuit set-up cost, and any time constraints for setup and teardown of TE circuits on the link. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0005 | Length = 28 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwidth unit usage cost | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TE circuit set-up cost | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TE circuit set-up time constraint | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TE circuit tear-down time constraint | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Circuit Setup time constraint This 64-bit number specifies the time at or after which aTE-circuitTE- circuit path may be set up on the link. The set-up time constraint is specified as the number of seconds from the start of January 1, 1970 UTC. A reserved value of 0 implies no circuit setup time constraint. Circuit Teardown time constraint This 64-bit number specifies the time at or before which allTE-circuitTE- circuit paths using the link must be torn down. The teardown time constraint is specified as the number of seconds from the start of January 1 1970 UTC. A reserved value of 0 implies no circuit teardown time constraint. 8.1.4.6. TE-LINK-TLV-COLOR The color TLV is similar to the SRLG TLV, in that an Autonomous System may choose to issue colors to aTE-linkTE link meeting certain criteria. The color TLV can be used to specify one or more colors assigned to the link as follows. Two octets are used to list each color. If the link belongs to 'n' number of colors, the Length would be (4 + 4 * ((n+1)/2)) octets. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0006 | Length = 4(1 + (n+1)/2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Color-1 | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Color-n | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8.1.4.7. TE-LINK-TLV-NULL When aTE-linkTE 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-UpdateTE-Incremental-Link-Update LSA (0x8d) A significant difference between a native OSPF network and a TE network is that the latter may be subject to frequent real-time circuit pinning and is likely to undergo TE-state updates. Some links might undergo changes more frequently than others. Flooding the network with TE-router LSAs at the aggregated speed of all link metric changes is simply not desirable. A smaller insize, TE-incremental-link-updatesize TE- incremental-link-update LSA is designed to advertise only the incremental link updates.TE-incremental-link-UpdateA TE-incremental-link-update LSA will be advertised as frequently as the link state is changed (not exceeding once every MinLSInterval seconds). TheTE-linkTE link sequence is largely the advertisement of a sub-portion of router LSA. The sequence number on this will be incremented with the TE-router LSA's sequence as the basis. When an updated TE-router LSA is advertised within 30 minutes of the previous advertisement, the updated TE-router LSA will assume a sequenceno.number that is larger than the most frequently updated of its links. Below is the format of the TE-incremental-link-update LSA. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | 0x8d | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID (same as Link ID) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | 0 | Link-TE options | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link-TE options | Zero or more Link-TE TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | # TOS | metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TOS | 0 | TOS metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Link State ID This would be exactly the same as would have been specifiedas asfor LinkIDID, for a link within therouter-LSA.router LSA. Link Data This specifies the router ID the link belongs to. In majority of cases, this would be same as the advertising router. This choice for Link Data is primarily to facilitate proxy advertisement for incremental link updates.Say,Suppose that arouter-proxy-LSAproxy router LSA was used to advertise theTE-router-LSATE- router LSA of a SONET/TDMnode. Say,node, and that the proxy router is now required to advertise incremental-link-update for the same SONET/TDM node. Specifying the actual router-ID to which the link in theincremental-link-update-LSAincremental-link-update LSA belongstohelps receiving nodes in finding the exact match for the LSA in their database. The tuple of (LS Type, LSA ID, Advertising router) uniquelyidentifyidentifies the LSA andreplacereplaces LSAs of the same tuple with an older sequence number. However, there is an exception to this rule in the context of TE-link-update LSA.TE-Link updateTE-Link-update LSA will initially assume the sequence number of the TE-router LSA it belongs to. Further, when a new TE-router LSA update with a larger sequence number is advertised, the newer sequence number is assumed byalall the link LSAs. 8.3.TE-Circuit-pathTE-Circuit-Path LSA (0x8C) TE-Circuit-path LSA (next page) may be used to advertise the availability of pre-engineered TE circuit path(s) originating from any router in the network. The flooding scope may beArea wide or AS wide. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | 0x84 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 |G|E|B|D|S|T|CktType| Circuit Duration (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Circuit Duration cont... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Circuit Duration cont.. | Circuit Setup time (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Circuit Setup time cont... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Circuit Setup time cont.. |Circuit Teardown time(Optional)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Circuit Teardown time cont... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Circuit Teardown time cont.. | No. of TE circuit paths | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Circuit-TE ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Circuit-TE Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | 0 | Circuit-TE flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Circuit-TE flags (contd.) | Zeroarea-wide ormore Circuit-TE TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Circuit-TE ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Circuit-TE Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... |AS-wide. Fields are as follows. Link State ID The ID of the far-end router or the far-endLink-IDlink-ID to which the TE circuit path(s) is being advertised. TE-circuit-path(s) flags Bit G - When set, the flooding scope is set to beAS wide.AS-wide. Otherwise, the flooding scope is set to bearea wide.area-wide. Bit E - When set, the advertised Link-State ID is an AS boundary router (E is for external). The advertising router and the Link State ID belong to the same area. Bit B - When set, the advertised LinkstateState ID is anAreaarea border router (B is for Border) Bit D - When set, this indicates that the duration of circuit path validity follows. Bit S - When set, this indicates thatSetup-timesetup time of the circuit path follows. Bit T - When set, this indicates thatteardown-timeteardown time of the circuit path follows. CktType - This 4-bit field specifies theCircuitcircuit type of the Forward Equivalency Class(FC).(FEC). 0x01 - Origin is Router, Destination is Router. 0x02 - Origin is Link, Destination is Link. 0x04 - Origin is Router, Destination is Link. 0x08 - Origin is Link, Destination is Router. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | 0x84 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 |G|E|B|D|S|T|CktType| Circuit Duration (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Circuit Duration cont... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Circuit Duration cont.. | Circuit Setup time (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Circuit Setup time cont... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Circuit Setup time cont.. |Circuit Teardown time(Optional)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Circuit Teardown time cont... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Circuit Teardown time cont.. | No. of TE Circuit Paths | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Circuit-TE ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Circuit-TE Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | 0 | Circuit-TE flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Circuit-TE flags (contd.) | Zero or more Circuit-TE TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Circuit-TE ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Circuit-TE Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | Circuit Duration (Optional) This 64-bit number specifies the seconds from the time of the LSA advertisement for which the pre-engineered circuit path will be valid. This field is specified only when the D-bit is set in the TE-circuit-path flags. Circuit Setup time (Optional) This 64-bit number specifies the time at which theTE-circuitTE circuit path may be set up. This field is specified only when the S-bit is set in the TE-circuit-path flags. The set-up time is specified as the number of seconds from the start of January11, 1970 UTC. Circuit Teardown time (Optional) This 64-bit number specifies the time at which theTE-circuitTE circuit path may be torn down. This field is specified only when the T-bit is set in the TE-circuit-path flags. The teardown time is specified as the number of seconds from the start of January 1 1970 UTC. No. of TE CircuitpathsPaths This specifies the number of pre-engineered TE circuit paths between the advertising router and the router specified in thelink stateLink State ID. Circuit-TE ID This is the ID of the far-end router for a givenTE-circuitTE circuit path segment. Circuit-TE Data This is the virtual link identifier on the near-end router for a givenTE-circuitTE circuit path segment. This can be a private interface or handle the near-end router uses to identify the virtual link. The sequence of(circuit-TE(Circuit-TE ID, Circuit-TE Data)listpairs lists the end-point nodes and links in the LSA as a series. Circuit-TE flags This lists theZerozero or more TE-link TLVs that all member elements of the LSP meet. 8.4. TE-Summary LSAsTE-Summary-LSAsTE-Summary LSAs aretheType 0x83 and 0x84 LSAs. These LSAs are originated by area border routers.TE-Summary-network-LSAA TE-Summary-network LSA (0x83) describes the reachability of TE networks in a non-backbone area, advertised by theArea Border Router.area border router. A Type 0x84summary-LSAsummary LSA describes the reachability ofArea Border Routersarea border routers and AS border routers and their TE capabilities. One of the benefits of having multiple areas within an AS is that frequent TE advertisements within the area do not impact outside the area. Only the TE abstractions befitting the external areas are advertised. 8.4.1. TE-Summary Network LSA (0x83)TE-summaryA TE-Summary network LSA may be used to advertise reachability of TE-networks accessible to areas external to the originating area. The content and the flooding scope of a TE-Summary LSA is different from that of a nativesummarySummary LSA. The scope of flooding for aTE-summaryTE-Summary network LSA isAS wide,AS-wide, with the exception of the originating area and the stub areas. The area border router for each non-backbone area is responsible for advertising the reachability of backbone networks into the area. Unlike a native-summary network LSA,TE-summarya TE-Summary network LSA does not advertise summary costs to reach networks within an area. This is because TE parameters are not necessarily additive orcomparative.comparable. The parameters can be varied in their expression. For example, aTE-summaryTE-Summary network LSA will not summarize a network whose links do not fall under an SRLG (Shared-Risk Link Group). This way, theTE-summaryTE- Summary LSA merely advertises the reachability of TE networks within an area. The specific circuit paths can be computed by theBDRs.ABR. Pre-engineered circuit paths are advertised using TE-Circuit-pathLSA (refer sectionLSAs(refer to Section 8.3). 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | 0x83 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID (IP Network Number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router (Area Border Router) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum |lengthLength | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Area-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8.4.2. TE-SummaryrouterRouter LSA (0x84)TE-summaryA TE-Summary router LSA may be used to advertise the availability ofArea Border Routersarea border routers (ABRs) andAS Border RoutersAS border routers (ASBRs) that areTE capable.TE-capable. TheTE-summaryTE-Summary router LSAs are originated by the Area Border Routers. The scope of flooding for theTE-summaryTE-Summary router LSA is the non-backbone area the advertising ABR belongs to. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | 0x84 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router (ABR) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum |lengthLength | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 |E|B| 0 | No. of Areas | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Area-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router-TE flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router-TE TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Link State ID The ID of theAreaarea border router or the AS border router whose TE capability is being advertised. Advertising Router The ABR that advertises its TE capabilities (and the OSPF areas it belongs to) or the TE capabilities of an ASBR within one of the areas for which the ABR is a borderrouter of.router. No. of Areas Specifies the number of OSPF areas the link state ID belongs to. Area-ID Specifies the OSPF area(s) the link state ID belongs to. When the link state ID is same as the advertising router ID, the Area-ID lists all the areas the ABR belongs to. In the case the link state ID is an ASBR, the Area-ID simply lists the area the ASBR belongs to. The advertising router is assumed to be the ABR from the same area the ASBR is located in. Summary-router-TE flags Bit E - When set, the advertised Link-State ID is an AS boundary router (E is for external). The advertising router and the Link State ID belong to the same area. Bit B - When set, the advertised Link state ID is an Area border router (B is for Border) Router-TE flags, Router-TE TLVs(TETE capabilities of the link-state-IDrouter)router. TE Flags and TE TLVs are as applicable to the ABR/ASBR specified in the link state ID. The semantics is same as specified in the Router-TE LSA. 8.5. TE-AS-external LSAs (0x85)TE-AS-external-LSAsTE-AS-external LSAs are the Type 0x85 LSAs. This is modeled after AS-external LSA format and flooding scope. TE-AS-external LSAs are originated by AS boundary routers with TE extensions, and describe the TE networks and pre-engineered circuit paths external to the AS. As with AS-external LSA, the flooding scope of the TE-AS-external LSA isAS wide,AS-wide, with the exception of stub areas. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | 0x85 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Forwarding address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | External Route Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | # of Virtual TE links | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link-TE flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link-TE TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TE-Forwarding address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | External Route TE Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | Network Mask The IP address mask for the advertised TE destination. For example, this can be used to specify access to a specificTE-nodeTE node orTE-linkTE link with an mask of 0xffffffff. This can also be used to specify access to an aggregated set of destinations using a different mask. ex: 0xff000000. Link-TE flags, Link-TE TLVs The TE attributes of this route. These fields are optional and are provided only when one or more pre-engineered circuits can be specified with the advertisement. Without these fields, the LSA will simply state TE reachability info. Forwarding address Data traffic for the advertised destination will be forwarded to 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., the responsible AS boundary router). External Route Tag A 32-bit field attached to each external route. This is not used by the OSPF protocol itself. It may be used to communicate information between AS boundary routers; the precise nature of such information is outside the scope of this specification. 9. TE LSAs fornon-packet networkNon-Packet Network A non-packet network would use the TE LSAs described in the previous section for a packet network with some variations. These variations are described in the following subsections. Two new LSAs, TE-Positional-ring-network LSA and TE-Router-Proxy LSA are defined for use in non-packet TE networks. Readers may refer to [SONET-SDH] for a detailed description of the terms used in the context of SONET/SDH TDM networks, 9.1. TE-Router LSA (0x81) The following fields are used to describe each router link (i.e., interface). Each router link is typed (see the below Type field). The Type field indicates the kind of link being described. Type A new link type "Positional-Ring Type" (value 5) is defined. This is essentially a connection to a TDM-Ring. TDM ring network is different from LAN/NBMA transit network in that nodes on the TDM ring do not necessarily have a terminating path between themselves.Secondly,Second, the order of links is important in determining the circuit path. Third, the protection switching and the number of fibers from a node going into a ring are determined by the ringcharacteristics. I.e.,characteristics, for example, 2-fibervsvs. 4-fiber ring andUPSR vs BLSR protected ring.Unidirectional Path Switched Ring (UPSR) vs. Bidirectional Line Switched Ring (BLSR). Type Description __________________________________________________ 1 Point-to-point connection to another router 2 Connection to a transit network 3 Connection to a stub network 4 Virtual link 5 Positional-RingType.type. Link ID Identifies the object that this router link connects to. Value depends on the link's Type. For a positional-ring type, the Link ID shall be IP Network/Subnet number just as the case with a broadcast transit network. The following table summarizes the updated Link ID values. Type Link ID ______________________________________ 1 Neighboring router's Router ID 2 IP address of Designated Router 3 IP network/subnet number 4 Neighboring router's Router ID 5 IP network/subnet number Link Data This depends on the link's Type field. For type-5 links, this specifies the router interface's IP address.9.1.1.9.1.1 Router-TE flags - TEcapabilitiesCapabilities ofthe routera Router Flags specific to non-packetTE-nodesTE nodes are described below. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L|L|P|T|L|F| |S|S|S|C| |S|E|S|D|S|S| |T|E|I|S| |R|R|C|M|C|C| |A|L|G|P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |<---- Boolean TE flags ------->|<- TE flags pointing to TLVs ->| Bit TDM - Indicates the node is TDM circuit switch capable. Bit LSC - Indicates the node is capable of Lambdaswitch Capable.switching. Bit FSC - Indicates the node isFibercapable of fiber-switching (can also be a non-fiber linktype) switch capable. 9.1.2.type). 9.1.2 Link-TEoptions -Options: TEcapabilitiesCapabilities of aTE-linkTE Link +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T|N|P|T|L|F|D| |S|L|B|C| |E|T|K|D|S|S|B| |R|U|W|O| | |E|T|M|C|C|S| |L|G|A|L| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |<---- Boolean TE flags ------->|<- TE flags pointing to TLVs ->| TDM, LSC, FSC bits - Same as defined for router TE options. 9.2.TE-Positional-ring-networkTE-positional-ring-network LSA (0x82) Network LSA is adequate for packet TE networks. A newTE-Positional-Ring-network-LSATE- positional-ring-network LSA is defined to represent type-5 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. TheTE-Positional-ring-networkTE-positional-ring-network LSA (0x82) is modeled after the network LSA and has the same flooding scope as thenetwork-LSAnetwork LSA amongst the OSPF-xTE nodes within the area. Below is the format of theTE-Positional-ring-networkTE-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-LSAA TE-positional-ring-network LSA is originated for eachPositional-RingPositional- 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. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | 0x82 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ring Type | Capacity Unit | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ring capacity | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Element Node Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | Link State ID This is the IP interface address of the network's Gateway Network Element, which is also the designated router. Advertising Router 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 - Abi-directionalBidirectional Line switched 2-fiber ring (2-fiber BLSR) 3 - A Unidirectional Path Switched 2-fiber ring (2-fiber UPSR) 4 - Abi-directionalBidirectional Path switched 2-fiber ring (2-fiber BPSR) 5 - A Unidirectional Line Switched 4-fiber ring (4-fiber ULSR) 6 - Abi-directionalBidirectional Line switched 4-fiber ring (4-fiber BLSR) 7 - A Unidirectional Path Switched 4-fiber ring (4-fiber UPSR) 8 - Abi-directionalBidirectional Path switched 4-fiber ring (4-fiber BPSR) CapacityunitUnit Two units aredefined at this timecurrently defined, 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 TransportMultiplexer(STM),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 Capacityunits.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) 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 trustedTE-routerTE- router Proxy. This is typically the scenario in a non-packet 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 such example would be the SONET/SDHADMAdd-Drop Multiplexer (ADM) nodes in a TDM ring. The nodes may principally depend upon the GNE (Gateway Network Element) to do the advertisement for them. TE-router-Proxy LSA shall not be used to advertiseArea Border Routersarea border routers and/or AS borderRouters.routers. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | 0x8e | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID (Router ID of the TE Network Element) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | Router-TE flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router-TE flags (contd.) | Router-TE TLVs | +---------------------------------------------------------------+ | .... | +---------------------------------------------------------------+ | .... | # of TE links | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | 0 | Link-TE options | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link-TE flags | Zero or more Link-TE TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | 10. Abstracttopology representationTopology Representation with TEsupportSupport Below, we consider a TE network composed of three OSPFareas -areas, Area-1, Area-2 and Area-3, attached together through the backbone area. Area-1 an has a single area border router, ABR-A1 and no ASBRs. Area-2 has an area border router ABR-A2 and an AS border router ASBR-S1. Area-3 has two area border routers ABR-A2 and ABR-A3 and an AS border router ASBR-S2. The following network also assumes apre-engineeredpre- engineered TE circuit path between ABR-A1 and ABR-A2; between ABR-A1 and ABR-A3; between ABR-A2 and ASBR-S1; and between ABR-A3 andASBR-S2.ASBR- S2. The following figure is an inter-area topology abstraction from the perspective of routers in Area-1. The abstraction illustrates reachability of TE networks and nodes within area to the external areas in the same AS and to the external ASes. The abstraction also illustrates pre-engineered TE circuit paths advertised by ABRs and ASBRs. +-------+ |Area-1 | +-------+ +-------------+ | |Reachable TE | +--------+ |networks in |-------| ABR-A1 | |backbone area| +--------+ +-------------+ | | | +--------------+ | +-----------------+ | | | +-----------------+ | +-----------------+ |Pre-engineered TE| +----------+ |Pre-engineered TE| |circuit path(s) | | Backbone | |circuit path(s) | |to ABR-A2 | | Area | |to ABR-A3 | +-----------------+ +----------+ +-----------------+ | | | | +----------+ | +--------------+ | +-----------+ | | | | +-----------+ |Reachable | +--------+ +--------+ |Reachable | |TE networks|------| ABR-A2 | | ABR-A3 |--|TE networks| |in Area A2 | +--------+ +--------+ |in Area A3 | +-----------+ | | | | | | +-----------+ +-------------+ | | +-----------------+ | +----------+ | | +-----------+ | | | +-----------+ +--------------+ | | | +--------------+ |Reachable | |Pre-engineered| | | | |Pre-engineered| |TE networks| |TE Ckt path(s)| +------+ +------+ |TE Ckt path(s)| |in Area A3 | |to ASBR-S1 | |Area-2| |Area-3| |to ASBR-S2 | +-----------+ +--------------+ +------+ +------+ +--------------+ | | | | | +--------+ | +-----------+ +-------------+ | | | | |AS external | +---------+ +---------+ |TE-network |----| ASBR-S1 | | ASBR-S2 | |reachability | +---------+ +---------+ |from ASBR-S1 | | | | +-------------+ +---+ +-------+ +-----------+ | | | +-----------------+ +-------------+ +-----------------+ |Pre-engineered TE| |AS External | |Pre-engineered TE| |circuit path(s) | |TE-Network | |circuit path(s) | |reachable from | |reachability | |reachable from | |ASBR-S1 | |from ASBR-S2 | |ASBR-S2 | +-----------------+ +-------------+ +-----------------+ Figure9:3: Inter-Area Abstraction as viewed by Area-1 TE-routers 11. Changes to DatastructuresStructures in OSPF-xTEnodesNodes 11.1. Changes to Routerdata structureData Structure An OSPF-xTE router must be able to include the router-TE capabilities (as specified in section 8.1) in the router data structure. OSPF-xTE routers providing proxy service to other TE routers must also track the router and associated interface data structures for all the TE client nodes for which the proxy service is being provided. Presumably, the interaction between the Proxy server and the proxy clients is out-of-band. 11.2. TwosetsSets of Neighbors Two sets of neighbor data structures are required. TE-neighbors set is used to advertise TE LSAs. Only theTE-nodesTE nodes will be members of the TE-neighbor set. Native neighbors set will be used to advertise native LSAs. All neighboring nodes supporting non-TE links are part of the Native neighbors set. 11.3. Changes to Interfacedata structureData Structure The following new fields are introduced to the interface data structure. TePermitted If the value of the flag is TRUE, the interface may be advertised as a TE-enabled interface. NonTePermitted If the value of the flag is TRUE, the interface permits non-TE traffic on the interface. Specifically, this is applicable to packet networks, where data links may permit both TE and IP packets. For FSC and LSC TE networks, this flag is set to FALSE. FloodingPermitted If the value of the flag is TRUE, the interface may be used for OSPF and OSPF-xTE packet exchange to synchronize the LSDB across all adjacent neighbors. This is TRUE by default to all NonTePermitted interfaces that are enabled for OSPF. However, it is possible to set this to FALSE for some of the interfaces. TE-TLVs Each interface may define any number of TLVS that describe the link characteristics. The following existing fields in Interface data structure will take on additional values to support TE extensions. Type The OSPF interface type can also be of type"Positional-RING"."Positional-Ring". ThePositional-ringPositional-Ring type is different from other types (such as broadcast and NBMA) in that the exact location of the nodes on the ring is relevant, even though they are all on the same ring. SONET ADM ring is a good example of this. Complete ring positional-ring description may be provided by the GNE on a ring as a TE-network LSA for the ring. List of Neighbors The list may be statically defined for an interface without requiring the use of Hello protocol. 12. IANA ConsiderationsThis document proposes that TE LSA types and TE TLVs be maintained by the IANA.Thedocument also proposes an OSPFIGP-TEIANA has assigned multicast addressbe assigned by the IANA224.0.0.24 to OSPFIGP-TE for the exchange of TE database descriptors.OSPFIGP-TE multicast address is suggested a value of 224.0.0.24 so as not to conflict with the recognized multicast address definitions, as defined in http://www.iana.org/assignments/multicast-addresses The following sub-section explains the criteria to be used by the IANA to assignTE LSA types and TETLVs.TLVs will be maintained by the IANA, using the following criteria. 12.1. TE LSAtype valuesType Values LSA type is an 8-bit field required by each LSA. TE LSA types will have the high bit set to 1. TE LSAs can range from 0x80 through 0xFF. The following values are defined in sections 8.0 and 9.0. The remaining values are available for assignment by the IANA with IETF Consensus[Ref 11].[RFC2434]. TE LSA Type Value _________________________________________ TE-Router LSA 0x81 TE-Positional-ring-network LSA 0x82 TE-Summary Network LSA 0x83 TE-Summary router LSA 0x84 TE-AS-external LSAs 0x85 TE-Circuit-paths LSA 0x8C TE-incremental-link-Update LSA 0x8d TE-Router-Proxy LSA 0x8e 12.2. TE TLVtag valuesTag Values TLV type is a 16-bit field required by each TE TLV. TLV type shall be unique across the router and link TLVs. A TLV type can range from 0x0001 through 0xFFFF. TLV type 0 is reserved and unassigned. The following TLV types are defined in sections 8.0 and 9.0. The remaining values are available for assignment by the IANA with IETF Consensus[Ref 11].[RFC2434]. TE TLV Tag Reference Value Section _________________________________________________________ TE-LINK-TLV-SRLG Section 8.1.4.1 0x0001 TE-LINK-TLV-BANDWIDTH-MAX Section 8.1.4.2 0x0002 TE-LINK-TLV-BANDWIDTH-MAX-FOR-TE Section 8.1.4.3 0x0003 TE-LINK-TLV-BANDWIDTH-TE Section 8.1.4.4 0x0004 TE-LINK-TLV-LUG Section 8.1.4.5 0x0005 TE-LINK-TLV-COLOR Section 8.1.4.6 0x0006 TE-LINK-TLV-NULL Section 8.1.4.7 0x8888 TE-NODE-TLV-MPLS-SWITCHING Section 8.1.2.1 0x8001 TE-NODE-TLV-MPLS-SIG-PROTOCOLS Section 8.1.2.2 0x8002 TE-NODE-TLV-CSPF-ALG Section 8.1.2.3 0x8003 TE-NODE-TLV-NULL Section 8.1.2.4 0x8888 13. Acknowledgements The authors wish to specially thank Chitti Babu and his team for implementing the protocol specified in a packet network and verifying several portions of the specification in a mixed packet network. The authors also wish to thank Vishwas Manral, RiyadHartaniHartani, and Tricci So for their valuable comments and feedback on thedraft.document. Lastly, the authors wish to thank Alex Zinin and Mike Shand for theirdraftdocument (now defunct) titled "Flooding optimizations in link state routing protocols". Thedraftdocument provided inspiration to the authors to be sensitive to the high flooding rate, likely in TE networks. 14. Security Considerations Security considerations for the base OSPF protocol are covered in[OSPF-v2][OSPF-V2] and [SEC-OSPF]. This memo does not create any new security issues for the OSPF protocol. Security measures applied to the native OSPF (refer [SEC-OSPF]) are directly applicable to the TE LSAs described in the document. Discussed below are the security considerations in processing TE LSAs. Secure communication between OSPF-xTE nodes has a number of components. Authorization, authentication, integrity and confidentiality. Authorization refers to whether a particularOSPF-xTEOSPF- xTE node is authorized to receive or propagate the TE LSAs to its neighbors. Failing the authorization process might indicate a resource theft attempt or unauthorized resource advertisement. In either case, the OSPF-xTE nodes should take proper measures to audit/log such attempts so as to alert the administrator to take necessary action. OSPF-xTE nodes may refuse to communicate with the neighboring nodes that fail to prompt the required credentials. Authentication refers to confirming the identity of an originator for the datagrams received from the originator. Lack of strong credentials for authentication of OSPF-xTE LSAs can seriously jeopardize the TE service rendered by the network. A consequence of not authenticating a neighbor would be that an attacker could spoof the identity of a "legitimate" OSPF-xTE node and manipulate the state, and the TE database including the topology and metrics collected. This could potentially cause denial-of-service on the TE network. Another consequence of not authenticating is that an attacker could pose as OSPF-xTE neighbor and respond in a manner that would divert TE data to the attacker. Integrity is required to ensure that an OSPF-xTE message has not been accidentally or maliciously altered or destroyed. The result of a lack of data integrity enforcement in an untrusted environment could be that an imposter will alter the messages sent by a legitimate adjacent neighbor and bring the OSPF-xTE on a node and the whole network to a halt or cause a denial of service for the TE circuit paths effected by the alteration. Confidentiality ofMIDCOMOSPF-xTE messagesensureensures that the TE LSAs are accessible only to the authorized entities. When OSPF-xTE is deployed in an untrusted environment, lack of confidentiality will allow an intruder to perform traffic flow analysis and snoop the TE control network to monitor the traffic metrics and the rate at which circuit paths are being setup and torn-down. The intruder could cannibalize a lesser secure OSPF-xTE node and destroy or compromise the state andTE-LDSBTE-LSDB on the node. Needless to say, the least secure OSPF-xTE will become the Achilles heel and make the TE network vulnerable to security attacks. 15. Normative References[IETF-STD] Bradner, S., "Key words for use in RFCs to indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC 1700] J. Reynolds and J. Postel, "Assigned Numbers", RFC 1700 [RFC 2434] Narten, T.[MPLS-ARCH] Rosen, E., Viswanathan, A., andH. Alvestrand, "Guidelines for writing an IANA Considerations Section in RFCs", BCP 26,R. Callon, "Multiprotocol Label Switching Architecture", RFC2434, October 1998.3031, Jaunary 2001. [MPLS-TE] Awduche, D.,et al,Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering OverMPLS,"MPLS", RFC 2702, September 1999.[OSPF-v2][OSPF-V2] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [SEC-OSPF] Murphy, S., Badger, M., and B. Wellington, "OSPF with Digital Signatures", RFC 2154, June 1997. [OSPF-CAP] Lindem, A., Ed., Shen, N., Vasseur, J., Aggarwal, R.,Schaffer, S.,andVasseur, JP.,S. Schaffer, "Extensions to OSPF foradvertising optional router capabilities", draft-ietf-ospf-cap-04.txt (workAdvertising Optional Router Capabilities", RFC 4970, July 2007. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section inprogress)RFCs", BCP 26, RFC 2434, October 1998. 16. Informative References[RSVP-TE] Awduche,[BGP-OSPF] Ferguson, D.,L. Berger, D. Gan, T. Li, V. Srinivasan, and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, IETF, December 2001"The OSPF External Attribute LSA", unpublished. [CR-LDP] Jamoussi,B. et al,B., Andersson, L., Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Heinanen, J., Kilty, T., and A. Malis, "Constraint-Based LSP Setup using LDP", RFC 3212, January 2002. [GMPLS-TE] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. [MOSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March 1994. [NSSA]P.Murphy, P., "The OSPFNSSANot-So-Stubby Area (NSSA) Option", RFC 3101, January20032003. [OPAQUE] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 1998. [OPQLSA-TE] Katz, D.,D. YeungYeung, D., and K. Kompella, "Traffic Engineering Extensions to OSPF", RFC 3630, September 2003. [RSVP-TE] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001. [SONET-SDH]Ming-CHwanChow, M.-C., "Understanding SONET/SDH Standards andApplications" - A paperback or bound book, Published byApplications", Holmdel, N.J.: Andanpublisher. [GMPLS-TE] L. Berger, "Generalized Multi Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003 17.Publisher, 1995. Authors' Addresses Pyda SrisureshCaymasKazeon Systems, Inc.1179-A North McDowell Blvd. Petaluma,1161 San Antonio Rd. Mountain View, CA9495494043 U.S.A. Phone: (408) 836-4773 EMail: srisuresh@yahoo.com Paul JosephSymbol TechnologiesConsultant 10100 Torre Avenue, # 121 Cupertino, CA 95014 U.S.A. Phone: (408) 777-8493 EMail:18.paul_95014@yahoo.com Full Copyright Statement Copyright (C) TheInternet Society (2004).IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP78,78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all theirrights."rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNETSOCIETYSOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.