Internet Draft Network Working Group S. Giacalone INTERNET-DRAFT Predictive Systems Expiration Date: January 2001 Filename: draft-giacalone-te-optical-next-00.txt July 2000 Network Engineering Extensions (NEXT) for OSPFv3 This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It 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/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This memo defines extensions to OSPFv3 [2] to provide support for Network Engineering. This set of extensions is termed Network Engineering eXTensions for OSPFv3, or NEXT. The term network engineering was chosen to impart NEXT's wide scope of functionality. NEXT is intended to provide holistic and extremely rich state information to OSPFv3 routers. Using this information, various advanced topological and administrative decisions can be made. Please send comments to ospf@discuss.microsoft.com. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Table of Contents Overview .............................................. Basic Functionality ................................... Basic NEXT LSA Format ................................. Topology and Computation .............................. NEXT Time Parameters .................................. Expires January 2001 [Page 1] Internet Draft NEXT for OSPFv3 July, 2000 NEXT TLVs ............................................. NEXT Level-1 TLVs ..................................... The NEXT-Interface level-1 TLV ........................ The Next-Node level-1 TLV ............................. NEXT Level-2 TLVs ..................................... Level-2 TLV Interaction ............................... NEXT-Interface Related Level-2 TLVs ................... Link Type Level-2 TLV ................................. Link Media Level-2 TLV ................................ Shared Risk Group Level-2 TLV ......................... Administrative Metric Level-2 TLV ..................... Bandwidth Level-2 TLV ................................. Maximum Reservable Bandwidth Level-2 TLV .............. Unreserved Bandwidth Level-2 TLV ...................... Interface Utilization Average Level-2 TLV ............. Delay Average Level-2 TLV ............................. Delay Variation Average Level-2 TLV ................... Reliability Level-2 TLV ............................... Resource Class/Color Level-2 TLV ...................... MTU-Interleave Level-2 TLV ............................ Dilation Level-2 TLV .................................. Rate Shape Level-2 TLV ................................ Congestion Control Level-2 TLV ........................ Outbound Queue Type Depth Level-2 TLV ................. Inbound Queue Type Depth Level-2 TLV .................. Total Spectra Level-2 TLV ............................. Available Spectra Level-2 TLV ......................... NEXT-Node Related level-2 TLVs ........................ System Utilization & Average Level-2 TLV .............. System Delay Average Level-2 TLV ...................... Device Technology Fault Tolerance (DTFT) Level-2 TLV .. System Resource Class/Color Level-2 TLV ............... System Error Level-2 TLV .............................. NEXT Level-3 TLVs ..................................... NEXT-Interface TLV Related Level-3 TLVs ............... Link Subtype Level-3 TLV .............................. NEXT Delay Calculation ................................ Issues To Be Decided (TBD) ............................ Acknowledgements ...................................... References ............................................ Compatibility ......................................... Security Considerations ............................... Authors' Addresses .................................... Full Copyright Statement .............................. Overview This document details extensions to OSPFv3 [2] called NEXT. NEXT can be used to add very granular network engineering capabilities to OSPFv3 networks. To accomplish this, NEXT provides a wealth of Expires January 2001 [Page 2] Internet Draft NEXT for OSPFv3 July, 2000 interface, link, and device capability and state information to OSPFv3, or other protocols. The intent of NEXT is to enable the selection of shortest paths through networks based on sets of advanced network state criteria. Using NEXT, advanced policy decisions can be made, and traffic can be routed or switch traffic with varying qualities of service. NEXT can also assist in building complex fault tolerant networks. NEXT may effect the core topology building process of OSPFv3, or may be used to build separate "shadow" topologies. In the former, NEXT can be used a basis to make sophisticated decisions within OSPFv3. In the later, OSPFv3/NEXT can serve to build repositories of detailed information to enhance supplementary protocols. Since NEXT operates with and depends on OSPFv3, which is essentially network protocol independent, NEXT can be used to enable all networks to become extensively self aware. While NEXT builds on functionality presented in other works, it adds many new features, presents new philosophical possibilities, and is intended for use with OSPFv3. NEXT focuses on traffic engineering (TE) [3,4] and Multi Protocol lambda Switching (MPLmS) [5,6], but is specifically intended to support changing requirements and technologies in the future. It is hoped that NEXT will become a focal point for the distribution of advanced network information, enhancing OSPFv3 (and other protocols) while enabling complex deterministic services to be implemented. Note that in addition to allowing existing QOS protocols, such as RSVP, to provide new types of QoS, NEXT can enhance these protocols, by reducing the possibility of "crank-back". Extensions to other protocols to make use of NEXT information may be needed. Basic Functionality To provide network engineering functionality, NEXT adds new LSAs to OSPFv3. As (generally) conceived with other OSPFv3 LSAs, NEXT LSAs will be encapsulated in IPv6 packets. As with other protocols and technologies, NEXT is based on a hierarchical series of type/length/value (TLV) triplets which reside in NEXT OSPFv3 LSAs. NEXT TLVs may carry sub-TLVs, each conveying more specific data. The ability of TLVs to hierarchically nest other TLVs is described in terms of levels, Level-1 being the first, or highest TLV level. Expires January 2001 [Page 3] Internet Draft NEXT for OSPFv3 July, 2000 NEXTs' TLVs convey information to describe the OSPFv3 networks' resource state for the purpose of manipulating data forwarding. That is, NEXT provides information pertaining to current and potential network operation to allow administrative control of the way data traverses the network. The NEXT network topology may not be synchronized with the regular OSPFv3 routed topology. The information provided by NEXT LSAs and TLVs may be used to build channels, light paths, MPLS LSPs, RSVP reservations, a combination of these, or for other purposes. Note that NEXT can be used to make protocols like RSVP more deterministic as resources for path requests would be known in advance, and avoidance of "crank back" would be possible. Basic NEXT LSA Format NEXT LSAs follow the basic OSPFv3 packet and LSA header constructs. Each NEXT LSA is contained within a standard OSPFv3 packet header [2]: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version # | Type | Packet length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Area ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Instance ID | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Additionally, each NEXT LSA begins with the standard OSPFv3 LSA Header [2]: 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 | LS type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NEXT defines a new LSA, termed the NEXT-LSA, which will be defined with the allocation unused LS-type [2] bit space. Expires January 2001 [Page 4] Internet Draft NEXT for OSPFv3 July, 2000 NEXT follows the same rules for LSA origination, flooding, and reception as those presented in [2] Within the LS type of each NEXT LSA header, the U bit must be set to 1 (store and flood). The flooding scope bits S1 and S2 must be set to 0 and 1 (Area Scope) respectively. Options field allocation in NEXT LSAs on the LSAs it references is TBD. Special use of NEXT LSA ID fields to impart meaning are TBD. Until that time, the LSA ID field carries the same meaning as the intra- area-prefix LSA [2] Topology and Computation Whether NEXT LSAs result in a separate topological views of the OSPFv3 network, a modified singular view, or a composite (totally singular)view is TBD. For example, NEXT may result in separate topology tables (or databases)for some, or all, of it's state parameters. Alternatively, NEXT may be used to modify the normal topology process, building dense (complex) composite metrics. Although NEXT LSA data may be used to provide enhanced composite metric data for path selection, implementations of NEXT must be capable of providing separate and distinct sets of topology data. For example, NEXT must be able to differentiate between paths that offer low delay, high bandwidth, or low loss. The specification of recommended and required NEXT TLV state sets (combinations) for conformance and use in building separate topologies is TBD. NEXT Time Parameters Unless specified, routers shall originate NEXT LSAs as contents change, and whenever otherwise required by OSPF (an LSA refresh, for example)[3]. There are, however, several TLVs which must not be re-originated when router event counters are cleared. Re-origination of these TLVs must occur only via manual command when counters are cleared. Special care must be taken with the general origination intervals of several TLVs, including those that are based on counters (like errors) or truly dynamic states (like delay). These TLVs must permit statistical samples (used to build TLV values) to be adjusted. Expires January 2001 [Page 5] Internet Draft NEXT for OSPFv3 July, 2000 Upon reception of a changed NEXT LSA, routers should update their NEXT database/s. When building separate topologies, no SPF or other route calculations are necessary [3]. NEXT TLVs As noted earlier, the actual payload of each next LSA is comprised of a nested series of TLVs. The first layer of TLVs are referred to as level-1 TLVs, the following level as level-2, and so on. The use of TLVs enables NEXT to provide modularity and therefor versatility and extensibility. The basic NEXT TLV architecture is : 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ As in [3], the length field defines the TLV's value length field in bytes. A TLV with no value field would have a corresponding length of zero. TLVs must be padded to a four-byte alignment and padding is not included in the length field. For example, a three byte value would have a length of three, but the total size of the TLV would be eight bytes). All Nested TLVs must also be 32-bit aligned. Unrecognized TLV types must be ignored. TLVs not enabled should not be added to LSAs or other TLVs. TLVs with unchanged values should not be sent. All TLVs types between 1 and 9, and above 131000 are reserved for NEXT protocol extensions. All TLV types between 400 and 6000 are reserved for protocol specific functions. All TLV types between 16384 and 32767 are reserved for vendor-specific extensions. Base NEXT TLVs must be assigned with types at intervals of five. All other undefined TLV type codes are reserved for future assignment. TLVs values will be assigned to allow changes to be easily made. All reserved fields are currently not utilized and should be set to zero. NEXT level-1 TLVs Level-1 TLVs follow the OSPFv3 LSA header. NEXT currently defines the following level-1 TLVs: Type Description --------------------------------------------------- 10 The NEXT-interface TLV 15 The NEXT-node TLV Expires January 2001 [Page 6] Internet Draft NEXT for OSPFv3 July, 2000 Inter area and external path handling is TBD. It may be possible to support this by using referencing [2] or by adding a new level-1 TLV. The NEXT-Interface level-1 TLV Each NEXT-Interface TLV granularly describes a single interface in the over all network topology. The NEXT-interface TLV contains basic values and a set of nested level-2 TLVs. Sub TLVs may be ordered as appropriate. Note that an interface may be a physical or virtual link, or some type of composite as in WDM. The number of NEXT-interface TLVs carried in each LSA may vary, but it must be possible for a single NEXT-interface TLV to be sent. The specific number of NEXT-interface TLVs contained in an LSA should permit optimum network convergence. For example, unnecessary TLVs should not be sent. All device interfaces may be described by multiple TLVs residing in a single LSA if warranted. The base values contained in the NEXT-interface level-1 TLV are extremely similar to parts of the Intra-Area-Prefix LSA [2]. The architecture of the NEXT-interface TLV is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (10) | length (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Referenced LS type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Referenced Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Referenced Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Referenced Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Level2 TLVs | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The combined values of Referenced Interface ID, Referenced LS type, Referenced Link State ID, and Referenced Advertising Router Identify the router-LSA or network-LSA and interface which NEXT-interface information should be associated with. If Referenced LS type is 1, the prefixes are associated with a router-LSA, Referenced Link State ID should be 0 and Referenced Advertising Router should be the originating router's Router ID. If Referenced LS type is 2, the prefixes are associated with a network-LSA, Referenced Link State ID should be the Interface ID of the link's Designated Router and Referenced Advertising Router should be the Designated Router's Router ID [2]. Expires January 2001 [Page 7] Internet Draft NEXT for OSPFv3 July, 2000 By utilizing LSA referencing [2], the NEXT-interface LSA does not need to advertise neighboring routers and/or links to determine and identify redundant topologies. A possible use for the reserved space in the base NEXT-Interface LSA data is as a vector (identifier) for technologies or protocols. The remainder of the NEXT-interface TLV is comprised of level-2 TLVs. The NEXT-Node level-1 TLV Each NEXT-Node TLV granularly describes a system which is running OSPFv3 and NEXT. The NEXT-Node TLV may contain basic value/s, but it will contain a set of nested level-2 TLVs. Sub TLVs may be ordered as appropriate. Only a single NEXT-Node TLV may be carried in an LSA. Unnecessary and/or disabled TLVs should not be sent. The NEXT-Node TLV can be utilized to view OSPFv3 network entities (i.e. routers) as devices with inherent states, similar to the way that links have been viewed traditionally. For example, NEXT-Node TLVs may be used to inject router CPU or environmental state data into an SPF topology or database. Note that the possibility of using nodal states in topological computation was previously not possible. To the Contrary, NEXT-Node TLVs may be used as "macro" TLVs, adjusting the value all TLVs of a certain type. In this case, the Nodal TLVs can be viewed as extended interface TLVs. Using NEXT-Node TLVs to describe the interior state of devices is very topologically significant, as it presents a new set of pseudo paths through the OSPFv3 network. However, the nodal approach is likely to be somewhat complex. Using NEXT-Node TLVs as "macro" TLV adjustment mechanism is simple, however, this approach leads to the complex possibility of the representation all NEXT-Interface TLVs in Node-TLVs becoming desirable. The architecture of the NEXT-Node TLV is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (15) | length (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Level2 TLVs | | ... | Expires January 2001 [Page 8] Internet Draft NEXT for OSPFv3 July, 2000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The remainder of the NEXT-interface TLV is comprised of level-2 TLVs. NEXT Level-2 TLVs As noted earlier, each level-1 TLV may carry nested level-2 TLVs, each conveying more specific data. Level-2 TLVs must conform the same architectural and operative constraints as level-1 TLVs. Note level-2 TLVs may, in turn, carry further nested TLVs. The number of Level-2 TLVs subordinate to a Level-1 TLV may vary, but it must be possible for a single de TLV to be sent. The specific number of Level-2 TLVs related to a Level-1 TLV should permit optimum network convergence. Unnecessary TLVs should not be sent. Implementations of NEXT must allow values to be manually overridden. There are several TLVs which must not be re-originated when router event counters are cleared. These TLVs must be re-originated via commands designed to trigger this action. Special care must be taken with the general origination intervals of several TLVs. These TLVs include those that are based on counters (like errors) or truly dynamic states (like delay). Level-2 TLV Interaction Procedure for implementing precedence (topological importance) between NEXT TLVs is TBD. Logical solutions are predetermined TLV precedence, predetermined precedence with local adjustment, the and the reuse of type field bits to advertise transitive (and configured) precedence. NEXT-Interface TLV Related level-2 TLVs NEXT Interface Level-2 TLVs follow (and are part of) NEXT level-1 Interface TLVs. NEXT currently defines the following level-2 TLVs for the Level-1 NEXT-Interface TLV: Type Description --------------------------------------------------- 10 Link type 15 Link Media 20 Shared Risk Link Group 25 Administrative Metric 30 Bandwidth 35 Maximum Reservable Bandwidth 40 Unreserved Bandwidth Expires January 2001 [Page 9] Internet Draft NEXT for OSPFv3 July, 2000 45 Interface Utilization Average 50 Interface Delay Average 55 Delay Variation Average 60 Reliability 65 Resource class/color 70 MTU-Interleave 75 Dilation 80 Rate Shape 85 Congestion Control 90 Outbound Queue Type Depth 95 Inbound Queue Type Depth 100 Total Spectra 105 Available Spectra 400 Reserved for IPv6 CoS 1(TBD) 405 Reserved for IPv6 CoS 2(TBD) 410 Reserved for IPv6 CoS 2(TBD) 415 Reserved for IPv6 CoS 2(TBD) 420 Reserved for IPv6 CoS 2(TBD) 425 Reserved for IPv6 CoS 2(TBD) 430 Reserved for IPv6 CoS 2(TBD) 435 Reserved for IPv6 CoS 2(TBD) NEXT-Interface Level-2 TLV Descriptions Link Type level-2 TLV The Link Type TLV identifies access characteristics of an interface. The following values a currently defined for this TLV: Type Description --------------------------------------------------- 10 Point-to-point 15 Multiaccess This TLV appears as: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (10) | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Link Media Level-2 TLV As in [6], the link media TLV represents the bit encoding format and the bit transmission rate of the interface. Generally, this TLV will be used to list supported transport methods within the same routing construct, as currently may occur in the optical domain [6]. Expires January 2001 [Page 10] Internet Draft NEXT for OSPFv3 July, 2000 As defined in [6] the value of the link media TLV is listed by a 16 bit media type field. The second field defines the lowest priority at which that media type is available as in [6], but is 16 bits in length. The following values for the media type field of this TLV are as in [6]: Type Description ---------------------------------------------------OC- SONET 1 <= <= 3072 3072 + OC- SDH 1 <= <= 3072 6144 + OC- Clear 1 <= <= 3072 9217 DS0 DS0 9218 DS1 DS1 9219 E1 E1 9220 DS2 DS2 9221 E2 E2 9222 DS3 DS3 9223 E3 E3 9224 J3 J3 9225 DS4 DS4 9226 E4 E4 9227 J4 J4 9228 1Gbps GigE 9229 10Gbps 10GigE This TLV appears as: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (15) | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Type (variable) | Priority (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Shared Risk Link Group Level-2 TLV As in [6], the Shared Risk Link Group (SRLG) TLV permits the advertisement and bonding of links to SRLGs. SRLGs are configured to indicated the use of share resources whose failure may affect all links in the set [6]. A link may belong to multiple SRLGs. Thus the SRLG TLV describes a list of SRLGs that the link belongs to. An SRLG is identified by a 32 bit number that is unique within an IGP domain [6]. Expires January 2001 [Page 11] Internet Draft NEXT for OSPFv3 July, 2000 The value in the SRLG TLV is an unordered list of 32 bit numbers that are the SRLGs that the link belongs to [6]. This TLV appears as: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (20) | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRLG | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRLG... | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Administrative Metric level-2 TLV The Administrative Metric TLV specifies a supplemental interface metric for network engineering purposes. This metric may be different than the standard OSPF link metric, and should be considered with greater significance. The default value should be zero (the lowest metric). This TLV appears as: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (25) | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Administrative Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Bandwidth level-2 TLV The Bandwidth Level-TLV specifies the overall (Total) outbound interface bandwidth in IEEE floating point format. Whether this metric should be automatically computed is TBD. To provide uniform and eased network administration, the value of this TLV is specified in kiloBITS per second. When an OSPFv3 link is a MPLmS control channel as specified by Type TLVs, the bandwidth should be the sum of the bandwidths of all lambdas of all the fibers in the IP link at that priority level [6]. This TLV appears as: 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 Expires January 2001 [Page 12] Internet Draft NEXT for OSPFv3 July, 2000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (30) | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Maximum Reservable Bandwidth level-2 TLV The Bandwidth Level-TLV specifies the outbound interface bandwidth that may be reserved, in IEEE floating point format. To provide uniform and eased network administration, the value of this TLV is specified in KiloBITs per second. When an OSPFv3 link is a MPLmS control channel as specified by Type TLVs, the reservable bandwidth should be the sum of the bandwidths of all lambdas of all the fibers in the IP link at that priority level allocated for reservation [6]. This TLV appears as: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (35) | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reservable Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Unreserved Bandwidth level-2 TLV The Unreserved Bandwidth level-2 TLV specifies the outbound interface bandwidth not yet reserved in IEEE floating point format. Data pertaining to class levels is TBD, however iterative issuance of unreserved bandwidth TLVs per class may be possible by re-allocating reserved bit space. The sum of each must be less than or equal to the maximum reservable bandwidth. To provide uniform and eased network administration, the value of this TLV is specified in KiloBITs per second. When an OSPFv3 link is a MPLmS control channel as specified by Type TLVs, the unreserved bandwidth should be the sum of the unused bandwidths of all lambdas of all the fibers in the IP link at that priority level allocated for reservation but not yet allocated [6]. This TLV appears as: 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 Expires January 2001 [Page 13] Internet Draft NEXT for OSPFv3 July, 2000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (40) | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unreserved Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Interface Utilization Average level-2 TLV The Interface Utilization Average TLV specifies the outbound interface utilization. The Utilization Average may be useful in situations where no reservations have been made, when reservations have been made but do not behave as expected, or when reservation is not configured. A possible use of the Utilization Average TLV would be soft (deterministic) over subscription. The utilization average should be calculated automatically. To balance TLV granularity with LSA origination rates, the utilization average should be determine via an adjustable polling cycle. This TLV lists the current average in the polling average field. This TLV should not be re-issued specifically due changes in the polling average. Special care must be taken to insure that the received rate of LSAs generated due to the Interface Utilization Average level-2 TLV is sustainable. To provide uniform and eased network administration, the value of this TLV is specified in KiloBITs per second. This TLV appears as: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (45) | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Polling Average | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Utilization | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Delay Average level-2 TLV The Delay Average TLV specifies the overall average (mean) outbound delay in milliseconds. The Delay Average may be useful in situations where path selection must be dependant on latency. This TLV may be utilized when, for example the network contains slow or congested links, or when traffic shaping is enabled. It would be beneficial to calculate the delay automatically. A method for determining delay is TBD, although one is presented in this document. Without an automatic Expires January 2001 [Page 14] Internet Draft NEXT for OSPFv3 July, 2000 system for determining delay, it is possible to use a manual value. Any automatic delay calculation system must balance granularity with LSA origination rates; the delay average should be determined via an adjustable polling cycle. Special care must be taken to insure that the received rate of LSAs generated due to this level-2 TLV is sustainable. This TLV should not be re-issued specifically due changes in the polling average. This TLV appears as: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (50) | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Polling Average | Delay Average | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Delay Variation Average level-2 TLV The Delay Variation average TLV specifies the average minimum and maximum outbound delay in milliseconds. The delay variation average may be useful in situations where path selection must be dependant on jitter. It would be beneficial to calculate the interface delay variation automatically, however a method for accomplishing this is TBD. It may be possible to use the minimum and maximum rates using the delay mechanism introduced in this memo. Until an automatic method is specified, a possible solution is to use a manual value. Any automatic delay variation calculation system must balance granularity with LSA origination rates; the delay variation average should be determined via an adjustable polling cycle. Special care must be taken to insure that the received rate of LSAs generated due to this level-2 TLV is sustainable. This TLV should not be re-issued specifically due changes in the polling average. This TLV appears as: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (55) | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Polling Average | Min. Delay Average | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max. Delay Average | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Expires January 2001 [Page 15] Internet Draft NEXT for OSPFv3 July, 2000 Reliability level-2 TLV The Reliability TLV specifies perceived interface reliability. This TLV may be useful in situations where path selection must be dependant on: -Loss -Link technology fault tolerance (LTFT) -Errors Loss regards output loss rates. It would be beneficial to calculate loss automatically; an obvious solution being to parse output drop counters. For brevity, loss rates will be mapped to pre-determined values. A table mapping loss and values is TBD. LTFT regards the fault tolerance of the link technology. For example, SONET may be more fault tolerant that Frame Relay, which is more fault tolerant than T1. It would be beneficial to calculate LTFT automatically, based on interface type. Specifications of types and LTFT values are TBD. Errors regards error event rates on an interface. Note that unless input errors are measured this value may not properly represent link state. A list of error counters that should be parsed is TBD. All interface error rates should be combined into a composite value, which will then be mapped to pre-determined threshold values. A table mapping errors and values is TBD. The rate at which this TLV, and therefor an LSA is generated must specifically be adjustable. Special care must be taken to insure that the received rate of LSAs generated is sustainable. This TLV should not be re-issued specifically due changes in the polling average. This TLV appears as: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (60) | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Polling Average | Loss | LTFT | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Loss | +-+-+-+-+-+-+-+ Resource Class/Color level-2 TLV The Resource Class/Color sub-TLV specifies administrative group Expires January 2001 [Page 16] Internet Draft NEXT for OSPFv3 July, 2000 membership for this link, in terms of a bit mask. A link that is a member of multiple groups will have multiple bits set [3]. This TLV appears as: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (65) | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Resource Class/Color Mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MTU-Interleave Level-2 TLV The MTU-Interleave TLV specifies the maximum output transmission unit for the interface. This TLV may be useful in networks where abnormal MTUs are present, as in the case of packet interleaving, often used in multi-service networks. The value of this TLV is specified in the number of BYTEs that comprise the MTU. This TLV appears as: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (70) | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Bytes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Dilation level-2 TLV The Dilation TLV permits the specification of protocol overhead values for an interface. This TLV may be useful in for calculating true interface bandwidths. For example, an ATM/SONET interface may have more average associated protocol overhead than a POS interface, etc. This TLV may also be useful in networks that implement tunneling and/or trunking. The value of this TLV is specified in KiloBITs per second. This value should be determined by referring to a table listing percentage of bandwidth used for protocol overhead per protocol "stack". A table listing these values is TBD. This TLV may adjust bandwidth TLVs, or present data for separate topological computation. This TLV appears as: 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 Expires January 2001 [Page 17] Internet Draft NEXT for OSPFv3 July, 2000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (75) | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Dilation | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rate Shape level-2 TLV The Rate Shape TLV specifies the presence of a shaping (policing or smoothing) mechanism outbound from the interface. The specifics of this TLV are TBD. The type of this TLV is 80. Congestion Control level-2 TLV The congestion control TLV specifies the presence of a congestion control/avoidance mechanism (e.g. RED) INBOUND to the interface. This TLV may be expanded to address bit rate variable (e.g. deficit queuing) and class (e.g. class-based RED). The Following bits provide information regarding presence of a congestion control/avoidance mechanism: Bit Description --------------------------------------------------- A RED B Class Based RED This TLV appears as: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (85) | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|B| | | | | | | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Outbound Queue Type Depth level-2 TLV The Outbound Queue Type Depth TLV specifies the presence of a queues on a class basis, as well as average queue depth. This TLV may be used to find paths through a network which can prioritize traffic. Any automatic queue depth calculation system must balance granularity with LSA origination rates; the delay variation average should be determined via an adjustable polling cycle. Special care must be taken to insure that the received rate of LSAs generated due to this TLV is sustainable. This TLV should not be re-issued specifically due changes in the polling average. Expires January 2001 [Page 18] Internet Draft NEXT for OSPFv3 July, 2000 The Queue Depth value is measured in BYTEs. This TLV appears as: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (90) | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Queue | Class | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Queue Depth | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Inbound Queue Type Depth level-2 TLV The Inbound Queue Type Depth TLV specifies the presence of a queues on a class basis, as well as average queue depth. This TLV may be used to find paths through a network which can prioritize traffic. Any automatic queue depth calculation system must balance granularity with LSA origination rates; the delay variation average should be determined via an adjustable polling cycle. Special care must be taken to insure that the received rate of LSAs generated due to this TLV is sustainable. This TLV should not be re-issued specifically due changes in the polling average. The Queue Depth value is measured in BYTEs. This TLV appears as: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (95) | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Queue | Class | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Queue Depth | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Total Spectra level-2 TLV The Total Spectra TLV specifies the total number of lambdas that can be injected into the link by the device originating this LSA. Additionally, this TLV lists the range/s of the wavelengths that can be used. This TLV might be used in conjunction with interfaces that specify the use control channels (i.e. links running OSPFv3 on a Expires January 2001 [Page 19] Internet Draft NEXT for OSPFv3 July, 2000 single connection, but layer 2 lambda switching on others). The specification of a control channel is perform in a separate TLV. The Total Spectra TLV can provide potential wavelength state information in MPLmS networks. This TLV appears as: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (100) | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | wavelength range | potential lambdas | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Available Spectra level-2 TLV The available Spectra TLV specifies the number of lambdas that can are unused and available on this interface. Additionally, this TLV includes the wavelength range that is available. This TLV might be used in conjunction with interfaces that specify the use control channels (i.e. links running OSPFv3 on a single connection, but layer 2 lambda switching on others). The specification of a control channel is perform in a separate TLV. This TLV can provide potential wavelength state information in MPLmS networks. This TLV appears as: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (105) | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | wavelength range | available lambdas | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NEXT-Node related level-2 TLVs NEXT-Node Level-2 TLVs follow (and are part of) NEXT-Node level-1 TLVs. NEXT currently defines the following level-2 TLVs for the NEXT- Node Level-1 TLV: Type Description --------------------------------------------------- Expires January 2001 [Page 20] Internet Draft NEXT for OSPFv3 July, 2000 10 System Utilization & Average 15 System Delay Average 20 Device technology fault tolerance 25 System Resource class/color 30 System Error NEXT-Node Level-2 TLV Descriptions System Utilization & Average Level-2 TLV The System Utilization Average TLV specifies the system oriented utilization. The specific parameters that would be described in this TLV are TBD, however, possibilities include CPU utilization and chassis subscription. Utilization averages should be calculated automatically when possible. To balance TLV granularity with LSA origination rates, the utilization average should be determined via an adjustable polling cycle. This TLV lists the current average in the polling average field. This TLV should not be re-issued specifically due changes in the polling average. Special care must be taken to insure that the received rate of LSAs generated due to this level-2 TLV is sustainable. This TLV appears as: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (10) | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Polling Average | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TBD Parameter | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . | | TBD Parameter | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ System Delay Average Level-2 TLV The System Delay Average TLV specifies the overall average (mean) device delay in milliseconds. The Delay Average may be useful in situations where path selection must be dependant on latency. It would be beneficial to calculate the delay automatically, although manual specification may be necessary. A method for determining delay is TBD, although one is presented in this document. Any automatic delay calculation system must balance granularity with LSA origination rates; the delay average should be determine via an Expires January 2001 [Page 21] Internet Draft NEXT for OSPFv3 July, 2000 adjustable polling cycle. Special care must be taken to insure that the received rate of LSAs generated due to this level-2 TLV is sustainable. This TLV should not be re-issued specifically due changes in the polling average. This TLV appears as: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (15) | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Polling Average | Delay Average | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Device Technology Fault Tolerance (DTFT) Level-2 TLV The DTFT TLV specifies the fault tolerance of the device. For example, a device with fully redundant components is more redundant than one without. It would be beneficial to calculate DTFT automatically, perhaps based on a table of generic chassis types. Specifications of types and DTFT values are TBD. This TLV appears as: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (20) | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | DTFT | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ System Resource class/color The System Resource Class/Color sub-TLV specifies administrative group membership for this link, in terms of a bit mask. A system that is a member of multiple groups will have multiple bits set [3]. This TLV appears as: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (25) | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Resource Class/Color Mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Expires January 2001 [Page 22] Internet Draft NEXT for OSPFv3 July, 2000 System Error Level-2 TLV The System Error TLV specifies the occurrence of a critical system event. This TLV would be useful in situations where it would be beneficial to select paths around compromised components. For example, this TLV might allow paths to avoid a device with a failed cooling system. It would be beneficial to send this TLV automatically. It may be possible to send this TLV when system error SNMP traps are sent. To accomplish this, a table listing general types of system errors and values could be used to install value in this TLV. Thereafter, the value in the TLV could be used to devalue other states and metrics, or it could be used to effect topology directly. Any automatic system for issuing this TLV must limit LSA origination rates. Special care must be taken to insure that the received rate of LSAs generated due to this level-2 TLV is sustainable. This TLV should not be re-issued specifically due changes in the polling average. This TLV appears as: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (30) | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | System Error ID | Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NEXT Level-3 TLVs As noted, each level-2 TLV may carry nested level-3 TLVs, which convey more specific data. Level-3 TLVs must conform to the same architectural and operative constraints as other TLVs. Note level-3 TLVs may, in turn, carry further nested TLVs. The number of Level-3 TLVs subordinate to a Level-2 TLV may vary, but it must be possible for a single de TLV to be sent. The specific number of Level-3 TLVs related to a Level-2 TLV should permit optimum network convergence. Unnecessary TLVs should not be sent. Implementations of NEXT must allow values to be manually overridden. There are several TLVs which must not be re-originated when router event counters are cleared. These TLVs must be re-originated via commands designed to trigger this action. Expires January 2001 [Page 23] Internet Draft NEXT for OSPFv3 July, 2000 Special care must be taken with the general origination intervals of several TLVs. These TLVs include those that are based on counters (like errors) or truly dynamic states (like delay). Implementations of NEXT must allow values to be manually overridden. NEXT-interface TLV related level-3 TLVs NEXT Level-3 TLVs follow (and are part of) NEXT level-2 TLVs. NEXT currently defines the following level-3 TLVs for NEXT-interface Level-2 TLVs: Type Description Associated Level-2 TLV --------------------------------------------------- 10 Link subtype Link Type NEXT-interface TLV related level-3 TLV Descriptions Link Subtype level-3 TLV The Link subtype TLV identifies access characteristics and capabilities of the interface. It is subordinate to the NEXT- Interface Level-2 Link Type TLV. As based in [6] NEXT currently defines the following values for the type field of this TLV: Type Description --------------------------------------------------- 11 Packet-Switch Capable-1 (PSC-1) 12 Packet-Switch Capable-2 (PSC-2) 13 Packet-Switch Capable-3 (PSC-3) 14 Packet-Switch Capable-4 (PSC-4) 195 Data Control Channel (DCC) 200 Time-Division-Multiplex Capable (TDM) 210 Lambda-Switch Capable (LSC) 220 Fiber-Switch Capable (FSC) 240 Forwarding Adjacency PSC (FA-PSC) 245 Forwarding Adjacency TDM (FA-TDM) 250 Forwarding Adjacency LSC (FA-LSC) This TLV appears as: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (10) | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Expires January 2001 [Page 24] Internet Draft NEXT for OSPFv3 July, 2000 Detailed descriptions of types are as in [6], except for DCC. DCC indicates that the interface or Lambda can and will be used by OSPFv3, and perhaps Lambda signaling [5]. It indicates that information presented by NEXT may be a composite of other connections, which do not operate at the network layer. This type may have some functional similarities to type LSC. NEXT Delay Calculation There are several methods for calculating interface (and link delays) in NEXT. One logical solution is for routers operating with a higher RID to "poll" other routers at some interval. If the routers have synchronized internal clocks then the polling router might build a packet which includes time stamp. When the target router receives this packet, it can compare the time stamp with its' own clock. Additionally, the target router would "flip" the network addresses and send the exact (unchanged) packet back to the polling router. The polling router could compare the time stamp with its now incremented internal clock to find the differential. Next, the router might divide the time differential equally to find the one-way delay. For added accuracy serialization and estimated processing times might be factored. The polling packet described might be implemented as an OSPFv3 LSA with link Local scope, or extending this principle, OSPFv3's hello packet might be modified to support time stamp polling. It may be beneficial to measure delay (using the polling method) for each class of service supported. Note that the use of special CPU time allocations or queuing for OSPFv3 packet processing should be taken into account. For time synchronization, OSPFv3 NEXT routers polling for delay might also use NTP. Issues To Be Decided (TBD) -Best practices for allocating TLV types should be considered. This must include implementation ease, and TLV hierarchies. -Inter area and External area support -OSPFv3 Options -IPv6 COS TLVs -All other specific issues TBD Expires January 2001 [Page 25] Internet Draft NEXT for OSPFv3 July, 2000 6 Acknowledgements This document is based on "Traffic Engineering Extensions to OSPF" by Katz, D., Yeung, D, and "Extensions to IS-IS/OSPF and RSVP in support of MPL(ambda)S" by Kompella, K., Rekhter, Y., Awduche, D., Hannan, A., Hjalmtysson, G., Lawrence, J., Okamoto, S., Basak, D., Bernstein, G., Drake, J., Margalit, N., and Stern, E. 7 References [1] Moy, J., "OSPF Version 2", RFC 2328, April 1998 [2] Coltun, R., Moy, J., "OSPF for IPv6" RFC 2740, December 1999 [3] Katz, D., Yeung, D, "Traffic Engineering Extensions to OSPF", internet Draft, April 2000 [4] Awduche, D., et al, "Requirements for Traffic Engineering Over MPLS, work in progress. [5] Luciani, J., Rajagopalan, B., Awduche, D., Cain, B., Jamoussi, B., " IP over Optical Networks - A Framework", work in progress. [6] Kompella, K., Rekhter, Y., Awduche, D., Hannan, A., Hjalmtysson, G., Lawrence, J., Okamoto, S., Basak, D., Bernstein, G., Drake, J., Margalit, N., Stern, E., "Extensions to IS-IS/OSPF and RSVP in support of MPL(ambda)S", work in progress. [7] Baker, F., and Coltun, R., "OSPF Version 2 Management Information Base", RFC 1850, Cisco Systems, FORE Systems, November 1995. [8] Moy, J., "Multicast Extensions to OSPF", RFC 1584, Proteon, Inc., September 1993. A Compatibility Since NEXT uses new LSA/s, routers not running NEXT will simply ignore and flood its' messages. Additionally, NEXT uses OSPFv3 flooding scopes to limit its' LSAs effect to areas of the network. When a only subset of the devices in a network run NEXT, it should still be possible to benefit from its use. When routers run NEXT and are building separate topological databases OSPFv3 will, generally, operate as when not running NEXT. Expires January 2001 [Page 26] Internet Draft NEXT for OSPFv3 July, 2000 If NEXT is used to build composite metrics, the premise for path selection may change greatly, as NEXT provides an abundance of new information. B Security Considerations NEXT does not appear to provide risk in addition to that already present in OSPF. C Authors' Addresses Spencer Giacalone Predictive Systems, Inc. 25a Vreeland Road Florham Park, NJ 07932 Phone: +1 (973) 301-5695 EMail: spencer.giacalone@predictive.com D Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Expires January 2001 [Page 27]