Network Working Group                                       P. Srisuresh
INTERNET-DRAFT                                            Caymas Systems
Expires as of June 31, 2005
Request for Comments: XXXX                                    Consultant
Category:                                                      P. Joseph
                                                     Symbol Technologies
                                                       December 31, 2004
                                                      SiNett Corporation
                                                           November 2005


    OSPF-xTE: An experimental extension Experimental Extension to OSPF for Traffic Engineering
                <draft-srisuresh-ospf-te-07.txt>


                          Status of this This Memo


   By 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 of

   This memo defines an Experimental Protocol for the Internet Engineering
   Task Force (IETF), its areas,
   community.  It does not specify an Internet standard of any kind.
   Discussion and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.


   Internet-Drafts are draft documents valid suggestions for a maximum improvement are requested.
   Distribution of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It this memo is inappropriate 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.html unlimited.

Copyright Notice

   Copyright (C) The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html" Internet Society (2005).

Abstract

   This document defines OSPF-xTE, an experimental traffic engineering
   (TE) extension to the link-state routing protocol OSPF.  OSPF-xTE
   defines new TE LSAs Link 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 that Non-TE non-TE nodes in the AS are uneffected unaffected 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 as SONET/TDM and optical networks. 






Srisuresh & Joseph

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.




<author>                      Experimental                      [Page 1]
Internet-Draft

RFC XXXX           OSPF Experimental TE Extensions       December 2004 Traffic Engineering Extension      November 2005


   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 of traffic engineering ...........................3 Traffic Engineering ...............................3
   3. Terminology .................................................4 .....................................................5
      3.1. Native OSPF terms ......................................5 Terms ..........................................5
      3.2. OSPF-xTE terms .........................................5 .............................................6
   4. Motivations behind Behind the design Design of OSPF-xTE ...................8 .......................9
      4.1. Scalable design ........................................9 Design ............................................9
      4.2. Operable in mixed Mixed and peer networks ....................9 Peer Networks ........................9
      4.3. Efficient in flooding reach ............................9 Flooding Reach ................................9
      4.4. Ability to reserve TE-exclusive links .................10 Reserve TE-Exclusive Links .....................10
      4.5. Extendible design .....................................10 Extensible Design .........................................10
      4.6. Unified for packet Packet and non-packet networks ............10 Non-packet Networks ................10
      4.7. Networks benefiting Benefiting from the OSPF-xTE design ..........11 Design ..............11
   5. OSPF-xTE solution overview .................................12 .....................................12
      5.1. OSPF-xTE Solution .....................................12 .........................................12
      5.2. Assumptions ...........................................13 ...............................................13
   6. Strategy for Transition of Opaque LSAs to OSPF-xTE transition strategy ................14 .............14
   7. OSPF-xTE router adjacency - Router Adjacency -- TE topology discovery ..........14 Topology Discovery .............14
      7.1. The OSPF-xTE router adjacency .........................14 Router 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. The graph Graph of adjacencies ..............................16 Adjacencies ..................................16
   8. TE LSAs for packet network .................................18 .....................................17
      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.4. Link-TE TLVs .........................................23
      8.2. TE-incremental-link-Update TE-Incremental-Link-Update LSA (0x8d) .................27 .....................26
      8.3. TE-Circuit-paths TE-Circuit-Path LSA (0x8C) ...........................29 ................................28
      8.4. TE-Summary LSAs .......................................32 ...........................................31
         8.4.1. TE-Summary Network LSA (0x83) ........................31
         8.4.2. TE-Summary Router LSA (0x84) .........................32
      8.5. TE-AS-external LSAs (0x85) ............................34 ................................34
   9. TE LSAs for non-packet network .............................36
       9.1. TE-Router LSA (0x81) ..................................36 LSAs for Non-packetNnetwork .................................36
      9.1. TE-Router LSA (0x81) ......................................36
         9.1.1. Router-TE flags - TE capabilities of the router ......37



<author>                      Experimental                      [Page 2]

RFC XXXX           OSPF Traffic Engineering Extension      November 2005


         9.1.2. Link-TE Options: TE Capabilities of a TE Link ........38
      9.2. TE-Positional-ring-network TE-positional-ring-network LSA (0x82) .................38 .....................38
      9.3. TE-Router-Proxy LSA (0x8e) ............................40 ................................40
   10. Abstract topology representation Topology Representation with TE support ...........41 Support ..............41
   11. Changes to Data structures in OSPF-xTE routers .............43 nodes ..................43
      11.1. Changes to Router data structure .....................43 Data Structure .........................43
      11.2. Two set sets of Neighbors .................................43 ....................................43
      11.3. Changes to Interface data structure ..................43 Data Structure ......................43
   12. IANA Considerations ........................................44 ...........................................44
      12.1. TE LSA type values ...................................44 .......................................44
      12.2. TE TLV tag values ....................................45 ........................................45
   13. Acknowledgements ...........................................45 ..............................................45
   14. Security Considerations ....................................46 .......................................46
   15. Normative References .......................................47 ..........................................47
   16. Informative References .....................................47




Srisuresh & Joseph                                              [Page 2]
Internet-Draft       OSPF Experimental TE Extensions       December 2004



   17. Authors' Addresses .........................................48
   18. Full Copyright Statement ...................................48 ........................................47


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).  A stand-alone stand-
   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 for the packet networks alone may
   skip section 9.0.

2.  Principles of traffic engineering Traffic 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.
   Only the unicast circuit paths are considered in this section. Multicast section; multicast
   variations are outside the scope.

   A traffic engineered circuit path is uni-directional and may be
   identified by the tuple of tuple: (FEC, TE circuit parameters, 
   Origin Node/Link, Destination node/Link).


   Forwarding origin
   node/link, destination node/link).



<author>                      Experimental                      [Page 3]

RFC XXXX           OSPF Traffic Engineering Extension      November 2005


   A forwarding Equivalency Class (FEC) is a grouping of traffic that is
   forwarded in the same manner by a node. A  An FEC may be classified
   based on a number of criteria criteria, as follows. follows:
        a) Traffic traffic arriving on a specific interface,
        b) Traffic traffic arriving at a certain time of day,
        c) Traffic traffic 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) Traffic traffic in a certain priority class,
        e) Traffic traffic arriving on a specific set of TDM (STS) circuits on
           an interface, 




Srisuresh & Joseph                                              [Page 3]
Internet-Draft       OSPF Experimental TE Extensions       December 2004 or
        f) Traffic traffic arriving on a certain wavelength of an interface interface.

   Discerning traffic based on the FEC criteria is mandatory for Label
   Edge Routers (LERs).  The intermediate Label Switched Label-Switched Routers (LSRs)
   are transparent to the traffic content.  LSRs are merely only responsible
   for keeping maintaining the circuit in-tact for the circuit its lifetime.  This document will not
   address defining definition of FEC criteria,
   or the mapping of a 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 protection
           switching switching.

   TE metrics for a link may include the following.
        a) Available available bandwidth,
        b) Reliability reliability of the link,
        c) Color color assigned to the link,
        d) Cost cost of bandwidth usage on the link, and
        e) Membership to membership in a Shared Risk Shared-Risk Link Group (SRLG) (SRLG).

   A number of CSPF OSPF 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 path to be identifiable by their IP addresses.







<author>                      Experimental                      [Page 4]

RFC XXXX           OSPF Traffic Engineering Extension      November 2005


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-LDP signaling specific
   signaling-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.





Srisuresh & Joseph                                              [Page 4]
Internet-Draft       OSPF Experimental TE Extensions       December 2004



3.1.

3.1  Native OSPF terms


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 forwarding and but 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", and non-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 terms LSP "LSP" and TE "TE circuit path path"
       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 LSDB is contains 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



<author>                      Experimental                      [Page 5]

RFC XXXX           OSPF Traffic Engineering Extension      November 2005


       topology.


3.2.

3.2  OSPF-xTE terms


3.2.1.

   o  TE node

       A TE node


   TE-Node is a node in the traffic engineered engineering (TE) network.  A 
   TE-node
       TE node has a minimum of one TE-link TE 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




Srisuresh & Joseph                                              [Page 5]
Internet-Draft       OSPF Experimental TE Extensions       December 2004
       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 TE Link link is a network attachment point to a TE-node TE 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 a TE-node, TE node, only the links that
       take part in a traffic engineered traffic-engineered network are called the TE links.


3.2.3.

   o  TE circuit path

       A TE circuit path is a uni-directional data path, path that is defined
       by a list of TE nodes connected to each other through TE links.
       A TE circuit path is also often referred merely simply 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 a
   Traffic Engineered
       traffic-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) may be constituted consist of a combination of native and
       OSPF-xTE nodes. 


3.2.5.






<author>                      Experimental                      [Page 6]

RFC XXXX           OSPF Traffic Engineering Extension      November 2005


   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 connected TE-nodes TE nodes and TE-links TE links, for
       the purpose of setting up one or more TE circuit paths.
   The terms TE network, TE data network and TE topology are




Srisuresh & Joseph                                              [Page 6]
Internet-Draft       OSPF Experimental TE Extensions       December 2004  The
       terms "TE network", "TE data network", and "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 term packet 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 is TE-network a TE network in which the nodes switch
       non-packet entities such as an STS time slot, a slots, Lambda
   wavelength wavelengths,
       or simply an interface. interfaces.

       SONET/TDM and Fiber fiber cross-connect networks are examples of 
   non-packet-TE non-
       packet-TE networks.  Circuit emulation in these networks is
       accomplished by the switch fabric in the intermediary nodes
       (based on TDM time slot, fiber interface interface, 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 of
   packet-TE both packet-
       TE and non-TE networks combined. networks.  Traffic in the network is strictly
       datagram oriented - 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.




<author>                      Experimental                      [Page 7]

RFC XXXX           OSPF Traffic Engineering Extension      November 2005


   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.




Srisuresh & Joseph                                              [Page 7]
Internet-Draft       OSPF Experimental TE Extensions       December 2004




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 for an a data object in the form of form: Tag-Length-Value.
       All TLVs are assumed to be of the following format, unless
       specified otherwise.  The Tag and length Length are 16 bits wide each.
       The length Length 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, TE links links,
       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 a TE-node.
   
3.2.14. TE node.

   o  Link-TE TLVs (Link TLVs)

       TLVs used to describe the TE capabilities of a TE-link. TE link.




<author>                      Experimental                      [Page 8]

RFC XXXX           OSPF Traffic Engineering Extension      November 2005


4.  Motivations behind Behind the design Design of OSPF-xTE

   There are several motivations that led to the design of OSPF-xTE.
   OSPF-xTE is scalable, efficient efficient, 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.





Srisuresh & Joseph                                              [Page 8]
Internet-Draft       OSPF Experimental TE Extensions       December 2004



4.1.

4.1  Scalable design


   OSPF-xTE area level Design

   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 a OSPF-xTE OSPF-
   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.

4.2  Operable in mixed Mixed and peer networks Peer 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 of opaque Opaque 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.

4.3  Efficient in flooding reach Flooding Reach

   OSPF-xTE is able to identify the TE topology in a mixed network and will
   to limit the flooding of TE LSAs to just only the TE-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



<author>                      Experimental                      [Page 9]

RFC XXXX           OSPF Traffic Engineering Extension      November 2005


   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 advertise
   just only a subset of the metrics that are
   prone to rapid changes.

   The more frequent and wider the flooding frequency, flooding, the larger the number of
   retransmissions and acknowledgements.  The same




Srisuresh & Joseph                                              [Page 9]
Internet-Draft       OSPF Experimental TE Extensions       December 2004 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.

4.4  Ability to reserve TE-exclusive links Reserve 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 a TE-topology TE 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 isolate best-
   effort best-effort IP
   traffic from TE traffic on a link.  All links are subject to best-effort best-
   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 design

4.5  Extensible Design

   The OSPF-xTE design is based on the tried and tested tried-and-tested OSPF paradigm,
   and it inherits all the benefits of the OSPF, present and future. 
   TE-LSAs  TE
   LSAs are extendible, extensible, just as the native OSPF on which OSPF-xTE is founded. 


4.6.
   founded are extensible.

4.6  Unified for packet Packet and non-packet networks Non-packet Networks

   OSPF-xTE is usable within a packet network or a non-packet network or
   a combination peer network.




<author>                      Experimental                     [Page 10]

RFC XXXX           OSPF Traffic Engineering Extension      November 2005


   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 




Srisuresh & Joseph                                             [Page 10]
Internet-Draft       OSPF Experimental TE Extensions       December 2004 as non-packet-TE links)
   in the network.  OSPF-xTE meets this requirement.


4.7.

4.7  Networks benefiting Benefiting from the OSPF-xTE design Design

   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 support MPLS based MPLS-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 to offer offering MPLS in the entire AS.

       Not all routers will support TE extensions at the same time
       during the migration process.  Use of TE specific TE-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 offering Best-effort-IP best-effort-IP & TE services

       Providers choosing to offer both best-effort-IP and TE based
       packet services simultaneously on the same physically connected
       network will benefit from the OSPF-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 have up-to-date As-wide up-to-date, AS-wide, TE reachability
       knowledge.  This in turn will make TE circuit setup predictable
       and computationally bounded. 


4.7.4.

   o  Non-packet networks and Peer networks

       Vendors may also use OSPF-xTE for their non-packet TE networks.
       OSPF-xTE defines the following functions in support of non-packet



<author>                      Experimental                     [Page 11]

RFC XXXX           OSPF Traffic Engineering Extension      November 2005


       TE networks.
        (a) "Positional-Ring" type network LSA and LSAs.
        (b) Router Proxying - proxying -- allowing a router to advertise on behalf
              of other nodes (that are not Packet/OSPF capable).





Srisuresh & Joseph                                             [Page 11]
Internet-Draft       OSPF Experimental TE Extensions       December 2004 packet/OSPF-capable).

5.  OSPF-xTE solution overview


5.1.

5.1  OSPF-xTE Solution


   Locally scoped opaque

   Locally-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 along TE-topology. TE topology.

   An OSPF-xTE node will have the a native LSDB and the a TE-LSDB, 
   A while a
   native OSPF node will have just the a native LSDB.  Consider the following OSPF area
   area, constituted of OSPF-xTE and native OSPF routers. routers, shown in
   Figure 1.  Nodes RT1, RT2, RT3 RT3, 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.






























Srisuresh & Joseph


























<author>                      Experimental                     [Page 12]
Internet-Draft

RFC XXXX           OSPF Experimental TE Extensions       December 2004 Traffic Engineering Extension      November 2005


              +---+
              |   |--------------------------------------+
                    |RT6|\\
              |RT6|\                                    |
              +---+  \\  \                                  |
               ||      \\      \                                |
               ||        \\        \                              |
               ||          \\          \                            |
               ||          +---+                         |
               ||          |   |----------------+        |
               ||          |RT1|\\          |RT1|\              |        |
               ||          +---+  \\  \            |        |
               ||          //|      \\      \          |        |
               ||        //  |        \\        \        |        |
               ||      //    |          \\          \      |        |
              +---+  //      |            \\            \  +---+      |
              |RT2|//        |              \\|RT3|------+              \|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

             Figure 6: 1.  A (TE + native) OSPF network topology


5.2. Network 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's TE-database TE database to be synchronized within the area.
        Failing this, the OSPF router will not be in the TE calculations
        of other TE routers in the area.

        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. 





Srisuresh & Joseph




<author>                      Experimental                     [Page 13]
Internet-Draft

RFC XXXX           OSPF Experimental TE Extensions       December 2004



   2. Traffic Engineering Extension      November 2005


   (2)  OSPF-xTE nodes must advertise the link state of its TE-links.
      TE-links TE links.
        TE links are not obligated to support native IP traffic.  Hence,
        an OSPF-xTE node cannot be required to synchronize its link-state link-
        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 a TE-link TE link or a
        native-IP link or both.  For example, a link may be used for
        both TE and non-TE traffic, so as long as the link is 
      under-subscribed under
        subscribed in bandwidth for TE traffic - say, (for example, 50% of the
        link capacity is set aside for TE traffic. 


   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 Network Element(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-xTE transition strategy

   Below is a strategy to transition implementations currently using
   opaque
   Opaque 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 of opaque Opaque LSAs and native LSDB. 


   2.

   (2)  Use TE-Summary LSAs and TE-AS-external-LSAs TE-AS-external LSAs for inter-area 
      Communication. Make use of
        communication.  Use the TE-topology TE topology within an area to summarize
        the TE networks in the area and advertise the same to all TE-nodes TE
        nodes in the backbone.  The TE-ABRs (TE area backbone routers)
        on the backbone area will in-turn in turn advertise these summaries
        within their connected areas.

7.  OSPF-xTE router adjacency - Router Adjacency -- TE topology discovery Topology Discovery

   OSPF creates adjacencies between neighboring routers for the purpose
   of exchanging routing information. In the  The following subsections, we subsections
   describe the use of locally scoped locally-scoped Opaque LSA LSAs to discover OSPF-xTE
   neighboring routers.  The capability is used as the basis to build a
   TE topology.
   
7.1.

7.1  The OSPF-xTE router adjacency Router Adjacency

   OSPF uses the options field in the hello Hello packet to advertise optional




Srisuresh & Joseph                                             [Page 14]
Internet-Draft       OSPF Experimental TE Extensions       December 2004
   router capabilities [OSPF]. [OSPF-V2].  However, all the bits in this field
   have been allocated and there is no way to advertise OSPF-xTE



<author>                      Experimental                     [Page 14]

RFC XXXX           OSPF Traffic Engineering Extension      November 2005


   capability using the options field at this time.  This document
   proposes using 
   local scope opaque lsa local-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 options field 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 become TE-neighbors TE neighbors unless they share a
   common network link on which both routers advertise support for
   OSPF-xTE.  Routers that donot do not support OSPF-xTE may simply ignore the
   advertisement. 
   
7.2.

7.2  The Hello Protocol

   The Hello Protocol protocol 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.

   For NBMA non-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.

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 its Router 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 as designated router.


7.4. 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




Srisuresh & Joseph                                             [Page 15]
Internet-Draft       OSPF Experimental TE Extensions       December 2004 Backup Designated
   Router for the network.  Once again, TE-compliance must be weighed in
   conjunction with router priority in electing the backup designated router. 


7.5. Backup Designated
   Router.



<author>                      Experimental                     [Page 15]

RFC XXXX           OSPF Traffic Engineering Extension      November 2005


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, as  As stated in item
   2 of section 5.2, a basic assertion 
   by of 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 to run the send
   OSPF-xTE messages over a TE-link TE link that is configured not to permit reject non-TE
   traffic.  However, the control network must be setup set up such that a
   minimum of one path exists between any two OSPF or OSPF-xTE routers
   within the network network, 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 not effect affect the native nodes
   that coexist with the OSPF-xTE nodes.

   The control traffic for a TE network (i.e., TE LSA advertisement) is
   likely to be higher than that of a native OSPF network.  This is
   because the TE metrics may vary with each TE circuit setup and the
   corresponding state change must be advertised at the earliest, not
   exceeding the MinLSInterval of 5 seconds.  To minimize advertising
   repetitive content, OSPF-xTE defines a new TE-incremental-Link-update
   LSA (section 8.2) that would advertise just the TLVs that changed for
   a link.


   A new

   The OSPFIGP-TE well-known multicast address 224.0.0.24 may be used has been
   assigned by IANA for the exchange of TE compliant TE-compliant database
   descriptors during database synchronization.
   
7.6.

7.6  The graph Graph of adjacencies Adjacencies

   If two routers have multiple networks in common, they may have
   multiple adjacencies between them.  The adjacency may be one of




Srisuresh & Joseph                                             [Page 16]
Internet-Draft       OSPF Experimental TE Extensions       December 2004 two
   types - native OSPF adjacency and TE adjacency.  OSPF-xTE routers
   will form both types of adjacency.

   Two types of adjacency graphs are possible possible, depending on whether a
   Designated Router is elected for the network.  On physical 
   point-to-point point-to-
   point networks, point-to-multipoint networks, Point-to-Multipoint networks and
   Virtual virtual links,
   neighboring routers become adjacent whenever they can communicate



<author>                      Experimental                     [Page 16]

RFC XXXX           OSPF Traffic Engineering Extension      November 2005


   directly.  The adjacency can be one of either (a) TE-compliant or (b)
   native.  In contrast, on broadcast and NBMA networks the designated
   router and the backup designated router may maintain two sets of
   adjacency.  The remaining routers will form either TE-compliant or
   native adjacency.

   In the 
   Broadcast broadcast network below, in Figure 2, routers RT7 and RT3 are chosen
   as the
   designated Designated and backup routers Backup Designated Routers, respectively.
   Routers RT3, RT4 and RT7 are TE-compliant. TE-compliant, but RT5 and RT6 are not. So,
   So RT4 will have TE-compliant adjacency with the designated and
   backup
   routers. routers, while RT5 and RT6 will only have native adjacency
   with the
   designated Designated and backup routers.


































Srisuresh & Joseph                                             [Page 17]
Internet-Draft       OSPF Experimental TE Extensions       December 2004 Backup Designated Routers.


                Network                          Adjacency

         +---+            +---+
         |RT1|------------|RT2|            o--------------------o            o-----------------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)

         Figure 6: The graph of adjacencies with TE-compliant routers. 2.  Two Adjacency Graphs with TE-Compliant Routers

8.  TE LSAs for packet network

   The OSPFv2 protocol, as of now, protocol currently has a total of 11 LSA types.  LSA types
   1 through 5 are defined in [OSPF-v2].  LSA types 6, 7 7, and 8 are
   defined in [MOSPF], [NSSA] [NSSA], and [BGP-OSPF] [BGP-OSPF], respectively.  LSA types



<author>                      Experimental                     [Page 17]

RFC XXXX           OSPF Traffic Engineering Extension      November 2005


   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-local area-local, and AS-wide (except stub areas) respectively.

   In the following subsections, we define new LSAs for traffic
   engineering (TE) use.  The Values values for the new TE LSA types are




Srisuresh & Joseph                                             [Page 18]
Internet-Draft       OSPF Experimental TE Extensions       December 2004
   assigned such that with the high bit of the LSA-type octet is set 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 an OSPF-xTE OSPF-
   xTE router and all the TE-links TE links attached to the router. TE-incremental-Link-Update  TE-
   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 and Area Border Routers
   (along with router TE characteristics) to external areas.  Flooding Scope
   scope of the TE-Summary LSAs is the TE topology in the entire AS less
   the non-backbone area for which the 
   the advertising router is an ABR.
   Just as with native OSPF summary LSAs, the TE-summary TE-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 TE circuits circuits,
   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.

8.1  TE-Router LSA (0x81)

   The TE-router LSA (0x81) is modeled after the router LSA and has the
   same flooding scope as the router-LSA. router LSA.  However, the scope is
   restricted to only the OSPF-xTE nodes within the area.  The TE-router TE router
   LSA describes the TE metrics of the router as well as the TE-links TE 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.








<author>                      Experimental                     [Page 18]

RFC XXXX           OSPF Traffic Engineering Extension      November 2005


        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                        |




Srisuresh & Joseph                                             [Page 19]
Internet-Draft       OSPF Experimental TE Extensions       December 2004
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         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.

8.1.1  Router-TE flags - flags: TE capabilities Capabilities of the router Router

   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 ->|




<author>                      Experimental                     [Page 19]

RFC XXXX           OSPF Traffic Engineering Extension      November 2005


       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 have the LER




Srisuresh & Joseph                                             [Page 20]
Internet-Draft       OSPF Experimental TE Extensions       December 2004 capability. When  Also setting the E bit is also set, that
                 indicates an AS Boundary router with LER capability. When
                 Setting the B bit is
           also set, that indicates an area border router with
                 LER capability.

       Bit PSC - Indicates the node is Packet 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 MPLS Signaling protocol support Signaling-protocol-support TLV 
           TE-NODE-TLV-MPLS-SIG-PROTOCOLS TE-NODE-TLV-
                 MPLS-SIG-PROTOCOLS follows.

       BIT CSPF - A CSPF algorithm support TLV TE-NODE-TLV-CSPF-ALG
                 follows.



8.1.2.

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                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Label depth   |  QOS          |                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   '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 pop off multiple
   labels off the MPLS stack.


   'QOS' is a single octet field that may be assigned '1' or '0'. Nodes

   supporting QOS are able to interpret the EXP bits in the MPLS header
   to prioritize multiple classes of traffic through the same LSP.





Srisuresh & Joseph





<author>                      Experimental                     [Page 21]
Internet-Draft 20]

RFC XXXX           OSPF Experimental TE Extensions       December 2004



8.1.2.2. Traffic Engineering Extension      November 2005


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 as 2 2, and LDP as 3.
   These are the only permitted signaling protocols at this time.
       
8.1.2.3.

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.

8.1.2.4  TE-NODE-TLV-NULL

   When a TE-Router or a TE-link TE link has multiple TLVs to describe the
   metrics, the NULL TLV is used to terminate the TLV list.






<author>                      Experimental                     [Page 21]

RFC XXXX           OSPF Traffic Engineering Extension      November 2005


        0                   1                   2                   3




Srisuresh & Joseph                                             [Page 22]
Internet-Draft       OSPF Experimental TE Extensions       December 2004
        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                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
















































Srisuresh & Joseph                                             [Page 23]
Internet-Draft       OSPF Experimental TE Extensions       December 2004



8.1.3.


8.1.3   Link-TE flags - flags: TE capabilities Capabilities of a link Link

   The following flags are used to describe the TE capabilities of a
   link.  The remaining bits of the 32-bit word are reserved for future
   use.

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |T|N|P| | | |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 not Database database synchronization is
                  permitted on this link.


       SRLG

       Bit SRLG - Shared Risk Link Group TLV TE-LINK-TLV-SRLG follows.

       Bit LUG  bit  - Link usage cost metric Usage Cost Metric TLV TE-LINK-TLV-LUG follows.

       Bit BW   bit   - One or more Link bandwidth Bandwidth TLVs follow

       Bit COL bit  - Link Color TLV TE-LINK-TLV-COLOR follows.
        
8.1.4.










<author>                      Experimental                     [Page 22]

RFC XXXX           OSPF Traffic Engineering Extension      November 2005


8.1.4  Link-TE TLVs


8.1.4.1.

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)   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Srisuresh & Joseph                                             [Page 24]
Internet-Draft       OSPF Experimental TE Extensions       December 2004
       |                    SRLG-1     |      ....                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                    SRLG-n     |                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
8.1.4.2.

8.1.4.2  TE-LINK-TLV-BANDWIDTH-MAX

   The bandwidth Bandwidth TLV specifies the maximum bandwidth of the link link, 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 1
   tera-bits/sec.


   'Maximum bandwidth'

   Maximum Bandwidth is be  the maximum link capacity expressed in
   bandwidth units.  Portions or all of this bandwidth may be used for
   TE use.


8.1.4.3.

8.1.4.3  TE-LINK-TLV-BANDWIDTH-MAX-FOR-TE

   The bandwidth Bandwidth TLV specifies the maximum bandwidth available for TE use
   use, as follows.







<author>                      Experimental                     [Page 23]

RFC XXXX           OSPF Traffic Engineering Extension      November 2005


        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 1
   tera-bits/sec.


   'Maximum bandwidth

   "Maximum Bandwidth available for TE use' 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.




Srisuresh & Joseph                                             [Page 25]
Internet-Draft       OSPF Experimental TE Extensions       December 2004




8.1.4.4.

8.1.4.4  TE-LINK-TLV-BANDWIDTH-TE

   The bandwidth Bandwidth 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 1
   tera-bits/sec.


   'TE

   "TE Bandwidth subscribed' subscribed" is the bandwidth that is currently
   subscribed from of the link. 'TE "TE Bandwidth subscribed' subscribed" must be less
   than the 'Maximum "Maximum bandwidth available for TE use'. use".  New TE circuit
   paths are able to claim no more than the difference between the two
   bandwidths for reservation.


8.1.4.5.

8.1.4.5  TE-LINK-TLV-LUG

   The link usage cost TLV specifies Bandwidth bandwidth unit usage cost, TE
   circuit set-up cost, and any time constraints for setup and teardown
   of TE circuits on the link.





<author>                      Experimental                     [Page 24]

RFC XXXX           OSPF Traffic Engineering Extension      November 2005


        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




Srisuresh & Joseph                                             [Page 26]
Internet-Draft       OSPF Experimental TE Extensions       December 2004

       This 64-bit number specifies the time at or after which a
       TE-circuit TE-
       circuit path may be set up on the link.  The set-up time
       constraint is specified as the number of seconds from the start
       of January 1, 1970 UTC.  A reserved value of 0 implies no circuit
       setup time constraint.

   Circuit Teardown time constraint

       This 64-bit number specifies the time at or before which all
       TE-circuit TE-
       circuit paths using the link must be torn down.  The teardown
       time constraint is specified as the number of seconds from the
       start of January 1 1970 UTC.  A reserved value of 0 implies no
       circuit teardown time constraint.


8.1.4.6.

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 a TE-link TE link meeting certain
   criteria.  The color TLV can be used to specify one or more colors
   assigned to the link as follows.  Two octets are used to list each
   color.  If the link belongs to 'n' number of colors, the Length would
   be (4 + 4 * ((n+1)/2)) octets.











<author>                      Experimental                     [Page 25]

RFC XXXX           OSPF Traffic Engineering Extension      November 2005


        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.

8.1.4.7  TE-LINK-TLV-NULL

   When a TE-link TE link has multiple TLVs to describe its metrics, the NULL
   TLV is used to terminate the TLV list.  The TE-LINK-TLV-NULL is same
   as the TE-NODE-TLV-NULL described in section 8.1.2.4


8.2. TE-incremental-link-Update

8.2  TE-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 in size,




Srisuresh & Joseph                                             [Page 27]
Internet-Draft       OSPF Experimental TE Extensions       December 2004



   TE-incremental-link-update size TE-
   incremental-link-update LSA is designed to advertise only the
   incremental link updates. 


   TE-incremental-link-Update

   A TE-incremental-link-update LSA will be advertised as frequently as
   the link state is changed (not exceeding once every MinLSInterval
   seconds).  The TE-link TE link sequence is largely the advertisement of a
   sub-portion of router LSA.  The sequence number on this will be
   incremented with the TE-router LSA's sequence as the basis.  When an
   updated TE-router LSA is advertised within 30 minutes of the previous
   advertisement, the updated TE-router LSA will assume a sequence no.
   number that is larger than the most frequently updated of its links.

   Below is the format of the TE-incremental-link-update LSA.














<author>                      Experimental                     [Page 26]

RFC XXXX           OSPF Traffic Engineering Extension      November 2005


        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 specified as
       as for
       Link ID ID, for a link within the router-LSA. router LSA.

   Link Data

       This specifies the router ID the link belongs to.  In majority of




Srisuresh & Joseph                                             [Page 28]
Internet-Draft       OSPF Experimental TE Extensions       December 2004
       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 a router-proxy-LSA proxy router LSA was used to advertise the TE-router-LSA TE-
       router LSA of a SONET/TDM node. 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 the 
       incremental-link-update-LSA incremental-link-update LSA belongs to helps receiving
       nodes in finding the exact match for the LSA in their database.

       The tuple of (LS Type, LSA ID, Advertising router) uniquely identify
       identifies the LSA and replace replaces LSAs of the same tuple with an



<author>                      Experimental                     [Page 27]

RFC XXXX           OSPF Traffic Engineering Extension      November 2005


       older sequence number.  However, there is an exception to this
       rule in the context of TE-link-update LSA. TE-Link update  TE-Link-update LSA
       will initially assume the sequence number of the TE-router LSA it
       belongs to.  Further, when a new TE-router LSA update with a
       larger sequence number is advertised, the newer sequence number
       is assumed by al all the link LSAs.

8.3. TE-Circuit-path TE-Circuit-Path LSA (0x8C)

   TE-Circuit-path LSA may be used to advertise the availability of
   pre-engineered TE circuit path(s) originating from any router in the
   network.  The flooding scope may be Area wide area-wide or AS wide. AS-wide.







































<author>                      Experimental                     [Page 28]

RFC XXXX           OSPF Traffic Engineering Extension      November 2005


        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             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)|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Srisuresh & Joseph                                             [Page 29]
Internet-Draft       OSPF Experimental TE Extensions       December 2004
       |                 Circuit Teardown time cont...                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Circuit Teardown time cont..  |  No. of TE circuit paths 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                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              ...                              |


   Link State ID

       The ID of the far-end router or the far-end Link-ID link-ID to which the
       TE circuit path(s) is being advertised.

   TE-circuit-path(s) flags



<author>                      Experimental                     [Page 29]

RFC XXXX           OSPF Traffic Engineering Extension      November 2005


       Bit G - When set, the flooding scope is set to be AS wide. AS-wide.
               Otherwise, the flooding scope is set to be area 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 Link state State ID is an Area area 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 that Setup-time setup time of the circuit
               path follows.

       Bit T - When set, this indicates that teardown-time teardown time of the
               circuit path follows.

       CktType - This 4-bit field specifies the Circuit circuit type of the
               Forward Equivalency Class (FC).




Srisuresh & Joseph                                             [Page 30]
Internet-Draft       OSPF Experimental TE Extensions       December 2004 (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.

   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 the TE-circuit TE 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 January 
       1 1,
       1970 UTC.

   Circuit Teardown time (Optional)

       This 64-bit number specifies the time at which the TE-circuit TE circuit
       path may be torn down.  This field is specified only when the 
       T-bit 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



<author>                      Experimental                     [Page 30]

RFC XXXX           OSPF Traffic Engineering Extension      November 2005


       1970 UTC.

   No.  of TE Circuit paths Paths

       This specifies the number of pre-engineered TE circuit paths
       between the advertising router and the router specified in the 
       link state
       Link State ID.

   Circuit-TE ID

       This is the ID of the far-end router for a given TE-circuit TE circuit path
       segment.

   Circuit-TE Data

       This is the virtual link identifier on the near-end router for a
       given TE-circuit TE 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) list pairs lists the
       end-point nodes and links in the LSA as a series.

   Circuit-TE flags

       This lists the Zero zero or more TE-link TLVs that all member elements
       of the LSP meet.






Srisuresh & Joseph                                             [Page 31]
Internet-Draft       OSPF Experimental TE Extensions       December 2004



8.4.

8.4  TE-Summary LSAs

   TE-Summary LSAs


    TE-Summary-LSAs are the Type 0x83 and 0x84 LSAs.  These LSAs are
   originated by area border routers. TE-Summary-network-LSA  A TE-Summary-network LSA (0x83)
   describes the  reachability of TE networks in a non-backbone area,
   advertised by the Area Border Router.  A Type 0x84 
    summary-LSA summary LSA
   describes the reachability of Area 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.

8.4.1  TE-Summary Network LSA (0x83)


    TE-summary

   A 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 native summary Summary LSA.




<author>                      Experimental                     [Page 31]

RFC XXXX           OSPF Traffic Engineering Extension      November 2005


   The scope of flooding for a TE-summary TE-Summary network LSA is AS wide, AS-wide, with
   the exception of the originating area and the stub areas.  The
    area border router 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-summary a TE-Summary network LSA does
   not advertise summary costs to reach networks within an area.  This
   is because TE parameters are not necessarily additive or
    comparative. comparable.
   The parameters can be varied in their expression.  For example, a TE-summary
   TE-Summary network LSA will not summarize a network whose links do
   not fall under an SRLG (Shared-Risk Link Group).  This way, the TE-summary TE-
   Summary LSA merely advertises the reachability of TE networks within
   an area.  The specific circuit paths can be computed by the BDRs. ABR.
   Pre-engineered circuit paths are advertised using TE-Circuit-path LSA (refer section
   LSAs(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)            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Srisuresh & Joseph                                             [Page 32]
Internet-Draft       OSPF Experimental TE Extensions       December 2004
       |                     LS sequence number                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         LS checksum           |             length            L ength            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Network Mask                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Area-ID                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



8.4.2.

8.4.2  TE-Summary router Router LSA (0x84)


    TE-summary

    A TE-Summary router LSA may be used to advertise the availability of
    Area Border Routers (ABRs) and AS Border Routers (ASBRs) that are
    TE capable.
    TE-capable.  The TE-summary TE-Summary router LSAs are originated by the Area
    Border Routers.  The scope of flooding for the TE-summary TE-Summary router LSA
    is the non-backbone area the advertising ABR belongs to.










<author>                      Experimental                     [Page 32]

RFC XXXX           OSPF Traffic Engineering Extension      November 2005


        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           |             length             Length            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    0      |E|B|      0        |       No. of Areas            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Area-ID                                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       ...                                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   Router-TE flags                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   Router-TE TLVs                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     ....                                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Link State ID

       The ID of the Area border router or the AS border router whose TE
       capability is being advertised. 




Srisuresh & Joseph                                             [Page 33]
Internet-Draft       OSPF Experimental TE Extensions       December 2004

   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 border router 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



<author>                      Experimental                     [Page 33]

RFC XXXX           OSPF Traffic Engineering Extension      November 2005


       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  (TE

       TE capabilities of the link-state-ID router) 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.

8.5  TE-AS-external LSAs (0x85)


   TE-AS-external-LSAs

   TE-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
   is AS wide, AS-wide, with the exception of stub areas.























<author>                      Experimental                     [Page 34]

RFC XXXX           OSPF Traffic Engineering Extension      November 2005


        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     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Srisuresh & Joseph                                             [Page 34]
Internet-Draft       OSPF Experimental TE Extensions       December 2004
       |                        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 specific 
        TE-node TE
        node or TE-link TE 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



<author>                      Experimental                     [Page 35]

RFC XXXX           OSPF Traffic Engineering Extension      November 2005


            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).





Srisuresh & Joseph                                             [Page 35]
Internet-Draft       OSPF Experimental TE Extensions       December 2004

   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 for non-packet network Non-packetNnetwork

   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.

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 ring characteristics. I.e., characteristics, for example, 2-fiber vs
        .  4-fiber ring and UPSR vs BLSR protected UPSR- vs. BLSR-protected ring.





<author>                      Experimental                     [Page 36]

RFC XXXX           OSPF Traffic Engineering Extension      November 2005


               Type   Description
               __________________________________________________
               1      Point-to-point connection to another router
               2      Connection to a transit network
               3      Connection to a stub network
               4      Virtual link
               5      Positional-Ring Type. 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




Srisuresh & Joseph                                             [Page 36]
Internet-Draft       OSPF Experimental TE Extensions       December 2004 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 - TE capabilities of the router

   Flags specific to non-packet TE-nodes TE nodes are described below.

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |L|L|P|T|L|F|                                           |S|S|S|C|
       |S|E|S|D|S|S|                                           |T|E|I|S|
       |R|R|C|M|C|C|                                           |A|L|G|P|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |<---- Boolean TE flags ------->|<- TE flags pointing to TLVs ->|


       Bit TDM - Indicates the node is TDM circuit switch capable.

       Bit LSC - Indicates the node is capable of Lambda switch Capable. switching.

       Bit FSC - Indicates the node is Fiber capable of fiber-switching (can



<author>                      Experimental                     [Page 37]

RFC XXXX           OSPF Traffic Engineering Extension      November 2005


           also be a non-fiber link
           type) switch capable.


9.1.2. type).

9.1.2  Link-TE options - Options: TE capabilities Capabilities of a TE-link TE Link

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |T|N|P|T|L|F|D|                                         |S|L|B|C|
       |E|T|K|D|S|S|B|                                         |R|U|W|O|
       | |E|T|M|C|C|S|                                         |L|G|A|L|
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |<---- Boolean TE flags ------->|<- TE flags pointing to TLVs ->|






Srisuresh & Joseph                                             [Page 37]
Internet-Draft       OSPF Experimental TE Extensions       December 2004



       TDM, LSC, FSC bits - Same as defined for router TE options.


9.2. TE-Positional-ring-network

9.2  TE-positional-ring-network LSA (0x82)

   Network LSA is adequate for packet TE networks.  A new
   TE-Positional-Ring-network-LSA TE-
   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.

   The TE-Positional-ring-network TE-positional-ring-network LSA (0x82) is modeled after the
   network LSA and has the same flooding scope as the network-LSA network LSA
   amongst the OSPF-xTE nodes within the area.  Below is the format of
   the TE-Positional-ring-network TE-Positional-Ring-network LSA.  Unless specified explicitly
   otherwise, the fields carry the same meaning as they do in a network
   LSA.  Only the differences are explained below.  
   TE-Positional-ring-network-LSA

   A TE-positional-ring-network LSA is originated for each
   Positional-Ring Positional-
   Ring type network in the area.  The tuple of (Link State ID, Network
   Mask) below uniquely represents a ring.  The TE option must be set in
   the Options flag while propagating the LSA.












<author>                      Experimental                     [Page 38]

RFC XXXX           OSPF Traffic Engineering Extension      November 2005


        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               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Srisuresh & Joseph                                             [Page 38]
Internet-Draft       OSPF Experimental TE Extensions       December 2004
       |                           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 - A bi-directional Line switched 2-fiber ring (2-fiber BLSR)
        3 - A Unidirectional Path Switched 2-fiber ring (2-fiber UPSR)
        4 - A bi-directional Path switched 2-fiber ring (2-fiber BPSR)
        5 - A Unidirectional Line Switched 4-fiber ring (4-fiber ULSR)
        6 - A bi-directional Line switched 4-fiber ring (4-fiber BLSR)
        7 - A Unidirectional Path Switched 4-fiber ring (4-fiber UPSR)
        8 - A bi-directional Path switched 4-fiber ring (4-fiber BPSR)

   Capacity unit Unit

        Two units are defined at this time currently defined, as follows.



<author>                      Experimental                     [Page 39]

RFC XXXX           OSPF Traffic Engineering Extension      November 2005


        1 - Synchronous Transport Signal (STS), which is the basic
            signal rate for SONET signals.  The rate of an STS signal is
            51.84 Mbps

        2 - Synchronous Transport Multiplexer(STM), which is the basic
            signal rate for SDH signals.  The rate of an STM signal is
            155.52 Mbps

   Ring capacity

        Ring capacity expressed in number of Capacity units. 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




Srisuresh & Joseph                                             [Page 39]
Internet-Draft       OSPF Experimental TE Extensions       December 2004 length field.   
 
9.3.

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 trusted 
   TE-router TE-
   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/SDH 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
   advertise Area Border Routers and/or AS border 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         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



<author>                      Experimental                     [Page 40]

RFC XXXX           OSPF Traffic Engineering Extension      November 2005


       |  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                             |




Srisuresh & Joseph                                             [Page 40]
Internet-Draft       OSPF Experimental TE Extensions       December 2004 ID                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Link Data                             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              ...                              |

10.  Abstract topology representation Topology Representation with TE support Support

   Below, we consider a TE network composed of three OSPF areas - 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 a pre-engineered pre-
   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 and ASBR-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.
   





























Srisuresh & Joseph













<author>                      Experimental                     [Page 41]
Internet-Draft

RFC XXXX           OSPF Experimental TE Extensions       December 2004 Traffic Engineering Extension      November 2005


                          +-------+
                          |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          |
          +-----------------+   +-------------+   +-----------------+


       Figure 9: 3: Inter-Area Abstraction as viewed by Area-1 TE-routers





Srisuresh & Joseph




<author>                      Experimental                     [Page 42]
Internet-Draft

RFC XXXX           OSPF Experimental TE Extensions       December 2004 Traffic Engineering Extension      November 2005


11. Changes to Data structures in OSPF-xTE nodes


11.1.

11.1  Changes to Router data structure Data 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.

11.2  Two sets of Neighbors

   Two sets of neighbor data structures are required. TE-neighbors set
   is used to advertise TE LSAs. Only the TE-nodes TE 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.

11.3  Changes to Interface data structure Data 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




Srisuresh & Joseph







<author>                      Experimental                     [Page 43]
Internet-Draft

RFC XXXX           OSPF Experimental TE Extensions       December 2004 Traffic Engineering Extension      November 2005


   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".
       The Positional-ring Positional-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 Considerations


   This document proposes that TE LSA types and TE TLVs be
   maintained by the IANA.

   The document IANA has also proposes an OSPFIGP-TE assigned multicast address be assigned by the IANA 224.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 assign

   TE LSA types and TE TLVs. 



12.1. TLVs will be maintained by the IANA, using the
   following criteria.

12.1  TE LSA type 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].













<author>                      Experimental                     [Page 44]

RFC XXXX           OSPF Traffic Engineering Extension      November 2005


      TE LSA Type                        Value
      _________________________________________





Srisuresh & Joseph                                             [Page 44]
Internet-Draft       OSPF Experimental TE Extensions       December 2004
      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.

12.2  TE TLV tag values

   TLV type is a 16-bit field required by each TE TLV.  TLV type shall
   be unique across the router and link TLVs.  A TLV type can range from
   0x0001 through 0xFFFF.  TLV type 0 is reserved and unassigned.  The
   following TLV types are defined in sections 8.0 and 9.0.  The
   remaining values are available for assignment by the IANA with IETF
   Consensus [Ref 11]. [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, Riyad Hartani and Tricci
   So for their valuable comments and feedback on the draft.  Lastly,
   the authors wish to thank Alex Zinin and Mike Shand for their draft
   (now defunct) titled "Flooding optimizations in link state routing
   protocols".  The draft provided inspiration to the authors to be
   sensitive to the high flooding rate, likely in TE networks. 




Srisuresh & Joseph




<author>                      Experimental                     [Page 45]
Internet-Draft

RFC XXXX           OSPF Experimental TE Extensions       December 2004 Traffic Engineering Extension      November 2005


14. Security Considerations

   Security considerations for the base OSPF protocol are covered in
   [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 particular
   OSPF-xTE OSPF-
   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 of MIDCOM messages ensure 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




Srisuresh & Joseph                                             [Page 46]
Internet-Draft       OSPF Experimental TE Extensions       December 2004 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 and TE-LDSB on the node.  Needless to say, the least secure



<author>                      Experimental                     [Page 46]

RFC XXXX           OSPF Traffic Engineering Extension      November 2005


   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., and H. Alvestrand, "Guidelines for
              writing an IANA Considerations Section in RFCs",
              BCP 26, R. Callon,
              "Multiprotocol Label Switching Architecture", RFC 2434, 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 Over 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., Shen, N., Aggarwal, R., Schaffer, S., and
              Vasseur, JP., "Extensions to OSPF for advertising 
              optional router capabilities", 
              draft-ietf-ospf-cap-04.txt (work Advertising Optional
              Router XCapabilities", Work in progress)


16. Informative References


   [RSVP-TE]  Awduche, D., L. Berger, D. Gan, Progress, May 2005.

   [RFC2434]  Narten, T. Li, V. Srinivasan, and G. Swallow, "RSVP-TE: Extensions to RSVP H. Alvestrand, "Guidelines for LSP
              Tunnels", Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 3209, IETF, December 2001 2434,
              October 1998.

16. Informative References

   [BGP-OSPF] Ferguson, D., "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]  L. Berger, "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, "The OSPF NSSA Not-So-Stubby Area (NSSA) Option",
              RFC 3101, January 2003





Srisuresh & Joseph                                             [Page 47]
Internet-Draft       OSPF Experimental TE Extensions       December 2004

   [OPAQUE]   Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July



<author>                      Experimental                     [Page 47]

RFC XXXX           OSPF Traffic Engineering Extension      November 2005


              1998.

   [OPQLSA-TE] Katz, D., D. Yeung Yeung, 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, IETF, December 2001.

   [SONET-SDH] Ming-CHwan Ming-Chwan Chow, "Understanding SONET/SDH Standards and
              Applications" - A paperback or bound book, Published by
              Andan publisher.


   [GMPLS-TE]  L. Berger, "Generalized Multi Protocol Label
              Switching (GMPLS) Signaling Functional Description",
              RFC 3471, January 2003



17.


Authors' Addresses

   Pyda Srisuresh
   Caymas Systems, Inc.
   1179-A North McDowell Blvd.
   Petaluma,
   Consultant
   20027 Pacifica Drive
   Cupertino, CA 94954 95014
   U.S.A.
   EMail: srisuresh@yahoo.com

   Paul Joseph
   Symbol Technologies
   SiNett Corporation
   640 West California Avenue, Suite 200
   Sunnyvale, CA 94086
   U.S.A.
   EMail:



18. pjoawph24@hotmail.com






















<author>                      Experimental                     [Page 48]

RFC XXXX           OSPF Traffic Engineering Extension      November 2005


Full Copyright Statement

   Copyright (C) The Internet Society (2004). (2005).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, 78 and at www.rfc-editor.org/copyright.html, and
   except as set forth therein, the authors retain all their rights." 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 INTERNET SOCIETY 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.







<author>                      Experimental                     [Page 49]