Internet Draft Network Working Group S. Giacalone INTERNET-DRAFT Predictive Systems Expiration Date: February 2001 Filename: draft-giacalone-te-optical-next-01.txt August 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 enables OSPFv3 to discern and advertise holistic state and capability data. NEXT may be used to build and present complex "best network paths" to outside protocols such as CR-LDP and RSVP-TE. NEXT may also be used to support other (perhaps unforeseen) advanced topological and administrative processes. NEXT is specifically designed to support Traffic Engineering and Optical Routing while providing new features and functionality. Note that NEXT does not intend to alter native packet routing. Since NEXT inter-operates with OSPFv3, it is essentially network protocol independent. Therefor, when used with OSPFv3, NEXT can support advanced services without limiting networks to IPv4. Please send comments to ospf@discuss.microsoft.com. Expires February 2001 [Page 1] Internet Draft NEXT for OSPFv3 August, 2000 Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Table of Contents 1 Overview ............................................ 2 Terminology ......................................... 3 Basic Functionality ................................. 3.1 Protected Wavelength Routing ...................... 3.2 Limiting Resource Consumption ..................... 3.2.1 Controlling Implementations ..................... 3.2.2 Separating data into LSAs ....................... 3.2.3 Balancing Benefits and Utilization .............. 3.2.4 Control Channels ................................ 3.2.5 Edge-Mode Operation ............................. 3.2.6 Path Calculation on Demand ...................... 3.3 Maintaining Network Stability ..................... 3.4 Topology and Computation .......................... 3.5 NEXT Time and Origination Parameters .............. NEXT LSA Formats ...................................... NEXT TLVs ............................................. Level-1 TLV Interaction ............................... NEXT level-2 and level-3 TLVs ......................... Depiction of the NEXT TLV hierarchy ................... NEXT Level-3 TLVs ..................................... TLVs for the NEXT-LSA ................................. NEXT-LSA level-1 TLVs ................................. The NEXT-Interface level-1 TLV ........................ The Next-Node level-1 TLV ............................. NEXT-Interface TLV 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 ................................. 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 ........................ Total Spectra Level-2 TLV ............................. NEXT-Interface TLV Related Level-3 TLVs ............... Data Control Channel (DCC) level-3 TLV ................ Link Subtype Level-3 TLV .............................. NEXT-Node Related level-2 TLVs ........................ Device Technology Fault Tolerance (DTFT) Level-2 TLV .. System Resource Class/Color Level-2 TLV ............... NEXT-Dynamic-LSA Related TLVs ......................... NEXT-Dynamic-LSA level-1 TLVs ......................... The NEXT-Dynamic-Interface Level-1 TLV ................ Expires February 2001 [Page 2] Internet Draft NEXT for OSPFv3 August, 2000 The NEXT-Dynamic-Node Level-1 TLV ..................... NEXT-Dynamic-Interface TLV Related level-2 TLVs ....... 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 ............................... Outbound Queue Depth Level-2 TLV ...................... Inbound Queue Depth Level-2 TLV ....................... Available Spectra Level-2 TLV ......................... NEXT-Dynamic-Node related level-2 TLVs ................ System Utilization & Average Level-2 TLV .............. System Delay Average Level-2 TLV ...................... System Error Level-2 TLV .............................. NEXT Delay Calculation ................................ Issues To Be Decided (TBD) ............................ Acknowledgements ...................................... References ............................................ A Compatibility ....................................... A.1 NEXT operation with resource class/color and COS .. A.2 Basic Compatibility Criteria ...................... A.3 Unnumbered Links .................................. B NEXT State and the end-to-end argument .............. Security Considerations ............................... Authors' Addresses .................................... Full Copyright Statement .............................. 1 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 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. NEXT aims to provide unified support to both Traffic Engineering and Lambda switching protocols. 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. Since it operates with OSPFv3, which is essentially network protocol independent, NEXT can be used to enable all networks to become extensively self aware. NEXT's independence from IP may be used to support the domain (all routed) IP optical model. Although, NEXT focuses on traffic engineering (TE) [3,4], Multi Protocol lambda Switching (MPLmS) [5,6], and Protection Wavelength Expires February 2001 [Page 3] Internet Draft NEXT for OSPFv3 August, 2000 Routing it is specifically intended to support changing requirements and technologies in the future. A core philosophical premise of NEXT is that it may effect the core topology building process of OSPFv3, or it 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. NEXT supports advanced intra-area and inter-area routing. 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. 2 Terminology -Link State Database (LSDB): In NEXT, this represents the collection of NEXT LSAs. -Topology: Depending on the mode in which NEXT is operating, the topology is a data structure representing the OSPF router's view of the network. There may be a single NEXT LSDB supporting a single OSPF topology, or there may be many of each. For example, if a composite view of the network is desired, there is no reason to have more than a single OSPF topology. However, when it's desirable to view the network as subsets of, for example least delay and also highest bandwidth paths, there may be a single NEXT LSDB, but multiple topologies. These NEXT modes, composite and shadow, are detailed elsewhere in this document. 3 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. The TLV is the most basic component of NEXT. 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 February 2001 [Page 4] Internet Draft NEXT for OSPFv3 August, 2000 NEXT's TLVs convey information to describe the OSPFv3 network's 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. NEXT network topology/s may not be synchronized with the regular OSPFv3 routed topology. The information provided by NEXT LSAs and TLVs may be used to build channels, lightpaths, 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. 3.1 Protected Wavelength Routing NEXT allows the reservation of alternate standby paths to a specific destination. This function may be necessary in Lambda routing and MPLmS network to insure that redundant lightpath bandwidth is available in the event of a network reconvergence. Protected Wavelength Routing is supported by the Shared Risk Link Group TLV (described elsewhere). Using this TLV, it's possible to determine, select and or reserve paths which are physically separate, and share no single point of failure in the network. 3.2 Limiting Resource Consumption This memo outlines several methods by which the impact NEXT has on network resources can be minimized. 3.2.1 Controlling Implementations To minimize memory and processing requirements, implementations do not need to support more than 8 NEXT sub-level (level 2 and 3) TLVs at one time. Supporting more than this number at one time is optional. Additionally, there is a minimalistic set of NEXT TLVs required for interoperability and compatibility. These TLVs are specified elsewhere in this memo. 3.2.2 Separating data into LSAs Next splits dynamic TLVs (like averages) into separate LSAs, so that less aggregate TLV data needs to be retransmitted when network changes occur. 3.2.3 Balancing Benefits and Utilization Expires February 2001 [Page 5] Internet Draft NEXT for OSPFv3 August, 2000 Network operators must determine which TLVs are needed, balancing the benefits of next data against resource consumption. Only critical TLVs should be enabled. NEXT assumes that network operators only enable a subset of all TLVs in an implementation. 3.2.4 Control Channels To minimize the amount of data injected into a network, NEXT fully supports the assignment of a single lambda (or portion thereof) as a control channel. This control channel runs OSPF/NEXT, and represents lamdbas residing on the fiber which don't need to run OSPF/NEXT. This functionality is implemented by the DCC level-3 TLV, and the Total and Available Spectra level-2 TLVs, described elsewhere in this memo. 3.2.5 Edge-Mode Operation Edge-mode NEXT operation can dramatically reduce the memory and processing requirements of interior (UNI/NNI) routing devices. When NEXT is being used to provide data for building explicit paths (such as E-LSPs or lightpaths) only edge devices need to store NEXT LSAs and (possibly) compute topology. Therefor, only edge devices need additional resources for these purposes. Note that all devices running NEXT must originate and forward NEXT LSAs 3.2.6 Path calculation on demand NEXT implementations may (if desired) calculate topology when needed by other protocols, thus reducing processing overhead. 3.3 Maintaining Network Stability NEXT does not intend to alter packet-by-packet (native OSPF) routing. NEXT provides additional data to other protocols for uses outside the scope of this memo. Therefor, routing oscillations caused by NEXT are limited to the protocols that use NEXT data (for example CR-LDP). Normal traffic follows normal OSPFv3 routing when NEXT is in use. NEXT best topology data may be used by outside protocols to route resource reservation requests, or set up explicit network paths. Careful design and implementation of outside protocols will increase network stability. For example, outside protocols using NEXT best data to set up explicit routes should be very diligent in tearing down and rebuilding existing paths. Once a resource-reserved path is set up, general NEXT path metric changes should not automatically cause existing reserved paths to change. NEXT defines 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. This applies to any TLV Expires February 2001 [Page 6] Internet Draft NEXT for OSPFv3 August, 2000 which polls device or interface counters which can be manually reset. For example, the reliability TLV, which polls interface error counters, must not be resent when those counters are rest. Special care must be taken with the general origination intervals of several TLVs, including those based on counters (like errors) or truly dynamic states (like delay). Polling intervals must be manually configurable. All counter based TLVs will default to a 5 minute counter polling average. Additionally, [10] describes a methods for smoothing the variance between differing metrics. Using this technique, it may be possible to limit oscillations. 3.4 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 topological views if the network based on some, or all, of it's state parameters. This mode of NEXT operation is termed "shadow mode" Alternatively, NEXT may be used to modify the normal topology process, building dense (complex) composite metrics, in a mode called NEXT "composite mode". 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. To calculate topological views of the network, NEXT uses the metric computation presented in [10]. Although one intent of NEXT is to provide best-paths based on complex state and capability data, directly access to the NEXT LSAs database/s must be permitted. 3.5 NEXT Time and Origination Parameters Normally, routers will originate NEXT LSAs as contents change, and whenever otherwise required by OSPF (an LSA refresh, for example)[3]. Expires February 2001 [Page 7] Internet Draft NEXT for OSPFv3 August, 2000 There are, however, several issues regarding resource consumption. For more information, please refer to the section entitled limiting resource consumption. Upon reception of a changed NEXT LSA, routers should update their NEXT database/s. TLVs not enabled MUST not be added to LSAs or nested within other TLVs. NEXT LSA Formats 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 new OSPFv3 LSAs, including: -The NEXT-LSA. The NEXT-LSA carries data that is more likely to be somewhat static. For example, administrative metrics, which once assigned tend not to change frequently. Expires February 2001 [Page 8] Internet Draft NEXT for OSPFv3 August, 2000 -The NEXT-Dynamic-LSA. The NEXT-Dynamic-LSA carries data that is likely to change often. For example, the NEXT-Dynamic-LSA will carry information such as average state data, which will tend to change every polling interval. NEXT splits static and dynamic data into separate LSAs in order to reduce protocol overhead. Both LSAs carry data which pertains to interface and node state and capability. All NEXT LSAs will be defined with the allocation unused LS-type [2] bit space. 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] 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. Both NEXT LSAs, the NEXT-LSA and the NEXT-Dynamic-LSA, use the same TLV architecture. 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 Expires February 2001 [Page 9] Internet Draft NEXT for OSPFv3 August, 2000 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. 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. Level-1 TLV Interaction As the level-1 TLVs don't, by themselves, carry state and capability data, there doesn't appear to be interaction issues between level-1 TLVs. NEXT level-2 and level-3 TLVs 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 level-3 TLVs. The number of TLVs subordinate to a a higher level TLV may vary, but it must be possible for a single de TLV to be sent. The specific number of TLVs related to a higher Level TLV should permit optimum network convergence. Unnecessary TLVs should not be sent. NEXT LSAs (the NEXT-LSA and the NEXT-Dynamic-LSA) DO NOT define the same level-2 TLVs. 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). Sub TLVs will be ordered as appropriate, and there may be instances when certain TLVs must be ordered in a specific fashion. Depiction of the NEXT TLV hierarchy Expires February 2001 [Page 10] Internet Draft NEXT for OSPFv3 August, 2000 +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ | NEXT-LSA | | NEXT-Dynamic-LSA | +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ | | -------- ------- | | | | | +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ | | |NEXT-Node level 1 TLV| |NEXT-Node level 1 TLV| | | +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ | | | | | +-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+ | NEXT-Interface | | | | NEXT-Interface | | level-1 TLV | | | | level-1 TLV | +-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+ | | | | | +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ | | | Static Nodal | | Dynamic Nodal | | | | level-2 TLVs | | level-2 TLVs | | | +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ | | | | | +-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+ | Static Interface | | | | Dynamic Interface | | level-2 TLVs | | | | level-2 TLV | +-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ | | | Static Nodal | | Dynamic Nodal | | | | level-3 TLVs | | level-3 TLVs | | | |(related to specific | |(related to specific | | | | level-2 TLVs) | | level-2 TLVs) | | | +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ | Static Interface | | Dynamic Interface | | level-3 TLVs | | level-2 TLV | |(related to specific | |(related to specific | | level-2 TLVs) | | level-2 TLVs) | +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ 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. Expires February 2001 [Page 11] Internet Draft NEXT for OSPFv3 August, 2000 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). Implementations of NEXT must allow values to be manually overridden TLVs for the NEXT-LSA This section provides information regarding TLVs which are only used with the NEXT-LSA. NEXT-LSA related TLVs provide state and capability data which is more static in nature. NEXT-LSA level-1 TLVs Level-1 TLVs follow the OSPFv3 LSA header in the NEXT-LSA. NEXT currently defines the following level-1 TLVs for the NEXT-LSA: Type Description --------------------------------------------------- 10 The NEXT-interface TLV 15 The NEXT-node TLV 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 device interface in the network. The NEXT-interface TLV contains basic values and a set of nested level-2 TLVs. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Expires February 2001 [Page 12] Internet Draft NEXT for OSPFv3 August, 2000 | Type (10) | length (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Referenced LS type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Referenced Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Referenced Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Level2 TLVs | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The combined values of 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]. 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. 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 a topology. Note that the possibility of using nodal states in topological computation was previously not possible. This usage of Node TLVs is called "nodal" mode. Expires February 2001 [Page 13] Internet Draft NEXT for OSPFv3 August, 2000 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. This usage of Node TLVs is called "macro" mode. Using NEXT-Node TLVs in nodal mode 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, this approach (the nodal approach) is likely to be somewhat complex. Using NEXT-Node TLVs in macro mode as an interface 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 | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The remainder of the NEXT-interface TLV is comprised of level-2 TLVs. 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 in the NEXT-LSA: Type Description --------------------------------------------------- 10 Link type 15 Link Media 20 Shared Risk Link Group 25 Administrative Metric 30 Bandwidth 35 Resource class/color 40 MTU-Interleave 45 Dilation 50 Rate Shape 55 Congestion Control 60 Total Spectra 400 Reserved for IPv6 CoS 1(TBD) 405 Reserved for IPv6 CoS 2(TBD) 410 Reserved for IPv6 CoS 2(TBD) Expires February 2001 [Page 14] Internet Draft NEXT for OSPFv3 August, 2000 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) 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]. 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 Expires February 2001 [Page 15] Internet Draft NEXT for OSPFv3 August, 2000 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 indicate 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]. 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 Expires February 2001 [Page 16] Internet Draft NEXT for OSPFv3 August, 2000 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (30) | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Resource Class/Color level-2 TLV The Resource Class/Color sub-TLV specifies administrative group 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 (35) | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Expires February 2001 [Page 17] Internet Draft NEXT for OSPFv3 August, 2000 | 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 (40) | 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (45) | 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 50. Expires February 2001 [Page 18] Internet Draft NEXT for OSPFv3 August, 2000 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 (55) | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|B| | | | | | | 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 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. Wavelength is specified in nanometers. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |potential channel wavelength 1 |potential channel wavelength 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . | . . . | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Expires February 2001 [Page 19] Internet Draft NEXT for OSPFv3 August, 2000 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 Data Control Channel Link Type 15 Link subtype Link Type Data Control Channel (DCC) level-3 TLV The Link subtype TLV identifies this interface as a data control channel. An interface sending this TLV is representing other, non OSPF interfaces in OSPF. Furthermore, this TLV specifies whether other TLVs will represent all non OSPF interfaces on this fiber as a single unit, or if all other TLVs in the parent NEXT-Interface level- 1 TLV refer to a specific non OSPF channel (lambda). The second usage is useful when non OSPF channels (lambdas) on a fiber have differing states and capabilities. The DCC interface will be identified by the physical interface ID derived from the referenced router links LSA. Therefor, this TLV can support non OSPF channels on the local link, as well as those that are on separate links in the same device. When the NEXT-Interface TLV is used to represent channels or lambdas with differing state and capabilities it's necessary to list the non OSPF channel or lambda by interface index. Because interface ID is used in the DCC TLV, NEXT allows control channels to operate on physically separate links from data channels. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|B| | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Non OSPF Interface Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The A bit when set, indicates that the parent NEXT-Interface TLV represents a DCC, and that the values of all other TLVs in the NEXT- Expires February 2001 [Page 20] Internet Draft NEXT for OSPFv3 August, 2000 Interface level-1 TLV refer to a conglomeration of the non OSPF channels or lambdas. The B bit when set, indicates that the parent NEXT-Interface TLV represents a DCC, and that the values of all other TLVs are a represent a SINGLE non OSPF channel or lambda. This non OSPF channel or lambda is referenced by Non OSPF Interface Index. 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) 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 (15) | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Detailed descriptions of types and TLV architecture is as in [6], except for the following: 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-Node TLV related level-2 TLVs Expires February 2001 [Page 21] Internet Draft NEXT for OSPFv3 August, 2000 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 in the NEXT-LSA: Type Description --------------------------------------------------- 10 Device technology fault tolerance 15 System Resource class/color NEXT-Node Level-2 TLV Descriptions 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 (10) | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | DTFT | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ System Resource class/color The System Resource Class/Color sub-TLV specifies administrative group membership for this system as a whole, in terms of a bit mask. A system that is a member of multiple groups will have multiple bits set [3]. This TLV overrides the system resource class/color assigned to any interface. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Resource Class/Color Mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NEXT-Dynamic-LSA Related TLVs Expires February 2001 [Page 22] Internet Draft NEXT for OSPFv3 August, 2000 This section provides information regarding TLVs which are only used with the NEXT-Dynamic-LSA. NEXT-Dynamic-LSA related TLVs provide state and capability data which is likely to change frequently. NEXT-Dynamic-LSA level-1 TLVs Level-1 TLVs follow the OSPFv3 LSA header. NEXT currently defines the following level-1 TLVs: Type Description --------------------------------------------------- 10 The NEXT-Dynamic-Interface TLV 15 The NEXT-Dynamic-Node TLV The NEXT-Dynamic-Interface Level-1 TLV The specifications of the NEXT-Dynamic-Interface TLV are the same as those for the NEXT-Interface TLV (from the NEXT-LSA). The NEXT-Dynamic-Node Level-1 TLV The specifications of the NEXT-Dynamic-Node TLV are the same as those for the NEXT-Interface TLV (from the NEXT-LSA). NEXT-Dynamic-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 Interface TLV when viewed in the NEXT-Dynamic-LSA: Type Description --------------------------------------------------- 10 Maximum Reservable Bandwidth 15 Unreserved Bandwidth 20 Interface Utilization Average 25 Interface Delay Average 30 Delay Variation Average 35 Reliability 40 Outbound Queue Depth 45 Inbound Queue Depth 50 Available Spectra 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 Expires February 2001 [Page 23] Internet Draft NEXT for OSPFv3 August, 2000 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 (10) | 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (15) | 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 Expires February 2001 [Page 24] Internet Draft NEXT for OSPFv3 August, 2000 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 (20) | 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 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 (25) | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Polling Average | Delay Average | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Expires February 2001 [Page 25] Internet Draft NEXT for OSPFv3 August, 2000 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 (30) | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Polling Average | Min. Delay Average | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max. Delay Average | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reliability level-2 TLV The Reliability TLV specifies perceived interface reliability. This TLV may provide a decay metric. 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. Expires February 2001 [Page 26] Internet Draft NEXT for OSPFv3 August, 2000 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 (35) | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Polling Average | Loss | LTFT | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Loss | +-+-+-+-+-+-+-+ Outbound Queue Depth level-2 TLV The Outbound Queue Depth TLV specifies average outbound 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 (40) | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Queue | Queue Depth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Expires February 2001 [Page 27] Internet Draft NEXT for OSPFv3 August, 2000 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Inbound Queue Depth level-2 TLV The Inbound Queue Depth TLV specifies average inbound 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 (45) | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Queue | Queue Depth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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. Wavelength is specified in nanometers. 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 | Expires February 2001 [Page 28] Internet Draft NEXT for OSPFv3 August, 2000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |potential channel wavelength 1 |potential channel wavelength 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . | . . . | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NEXT-Dynamic-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 when contained in the NEXT-Dynamic-LSA: Type Description --------------------------------------------------- 10 System Utilization & Average 15 System Delay Average 20 System Error 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Expires February 2001 [Page 29] Internet Draft NEXT for OSPFv3 August, 2000 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 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ System Error Level-2 TLV The System Error TLV specifies the occurrence of a critical system event, allowing that state to be injected into topology. 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 Expires February 2001 [Page 30] Internet Draft NEXT for OSPFv3 August, 2000 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | System Error ID | Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 it's 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 TLV hierarchies. -Inter area and External support -OSPFv3 Options field assignments -IPv6 COS TLVs -Interoperation between level-2 TLVs, and between level-1 and level-2 TLVs. -Additional optical capabilities and state data -Diff-Serv support -Virtual Link Support -Increase bounds and half-lives Expires February 2001 [Page 31] Internet Draft NEXT for OSPFv3 August, 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. The Authors acknowledge the following individuals: -Alex Zinin, Cisco Systems 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. [9] Carpenter, B. "Architectural Principles of the Internet", RFC 1958, June 1996 [10] Giacalone, S., "Scored Fair Metric Calculation", Work in Progress, July 2000. [11] Christian, B., Davies, B., Tse, H., "Operational measurements for traffic engineering", July 2000 [12] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., "A Framework Expires February 2001 [Page 32] Internet Draft NEXT for OSPFv3 August, 2000 for Internet Traffic Engineering", July 2000. 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. If NEXT is used to build composite metrics, the premise for path selection may change greatly, as NEXT provides an abundance of new information. A.1 NEXT operation with resource class/color and COS When enabled, NEXT advertises data for each class/color and/or COS on a per interface/node basis. Put simply, each class/color and/or COS can be viewed as another instance of an interface or node. A.2 Basic Compatibility Criteria To be compatible with this memo, NEXT implementations must support the following minimum set of NEXT specifications: -The NEXT-LSA -The NEXT Interface Level-1 TLV -NEXT Interface Level-2 TLVs -Link type -Link Media -Shared Risk Link Group -Administrative Metric -Bandwidth -Resource class/color -The NEXT Node Level-1 TLV -NEXT Node Level-2 TLVs -System Resource class/color -The NEXT-Dynamic-LSA -The NEXT-Dynamic-Interface level-1 TLV -NEXT-Dynamic-Interface level-2 TLVs -Maximum Reservable Bandwidth -Unreserved Bandwidth -Interface Utilization Average -Interface Delay Average -Reliability -The NEXT-Dynamic-Node level-1 TLV Expires February 2001 [Page 33] Internet Draft NEXT for OSPFv3 August, 2000 -NEXT-Dynamic-Node level-2 TLVs -System Error A.3 Unnumbered Links Since OSPFv3 separates network topology data and addressing information advertisement, NEXT can operate on unnumbered links with no additional implications. OSPFv3 refers to interfaces using network protocol independent identifiers. B NEXT State and the end-to-end argument It appears that the end-to-end argument [9] does not apply to NEXT as it is not an end-to-end protocol. Furthermore, [9] specifies "that the network maintains some state information: routes, QoS guarantees that it makes, session information where that is used in header compression, compression histories for data compression, and the like." Fortunately, NEXT operates in the areas of routing, switching, and QoS and it therefor operates within this specification. While NEXT provides abundant state information to other intermediate protocols (for example, MPLS) it makes efforts to minimize unneeded information advertisement, and therefor complies with [9] in that the volume of state data be minimized. C Security Considerations NEXT does not appear to provide risk in addition to that already present in OSPF. D Authors' Addresses Spencer Giacalone Predictive Systems, Inc. 25a Vreeland Road Florham Park, NJ 07932 Phone: +1 (973) 301-5695 EMail: spencer.giacalone@predictive.com E 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 Expires February 2001 [Page 34] Internet Draft NEXT for OSPFv3 August, 2000 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 February 2001 [Page 35]