Network Working Group S. Giacalone INTERNET-DRAFT Predictive Systems Expiration Date: September 2001 Filename: draft-giacalone-te-optical-next-02.txt March 2001 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 traffic engineering extensions to OSPFv3 [2]. This set of extensions is termed Network Engineering eXTensions for OSPFv3, or NEXT. 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 is specifically designed to support the MPLS control plane, and does not intend to alter native packet routing. Since NEXT inter-operates with OSPFv3, it is essentially network protocol independent. Therefore, when used with OSPFv3, NEXT and MPLS can support advanced services without limiting networks to IPv4. Please send comments to ospf@discuss.microsoft.com. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Expires September 2001 [Page 1] Internet Draft NEXT for OSPFv3 March, 2001 Table of Contents 1 Overview ............................................ 2 Basic Functionality ................................. 2.1 Protected Wavelength Routing ...................... 2.2 Limiting Resource Consumption ..................... 2.2.1 Controlling Implementations ..................... 2.2.2 Separating data into LSAs ....................... 2.2.3 Control Channels ................................ 2.2.4 Edge Operation . ................................ 2.3 Maintaining Network Stability ..................... 2.4 Topology and Computation .......................... 2.5 NEXT Time and Origination Parameters .............. NEXT LSA Formats ...................................... Overview NEXT TLVs .................................... Depiction of the NEXT TLV hierarchy ................... NEXT-LSA TLVs ......................................... 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 ................................. Shared Risk Group Level-2 TLV ......................... Administrative Metric Level-2 TLV ..................... Bandwidth Level-2 TLV ................................. Resource Class/Color Level-2 TLV ...................... NEXT-Interface TLV Related Level-3 TLVs ............... Data Control Channel (DCC) level-3 TLV ................ NEXT-Node Related level-2 TLVs ........................ 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 ................ The NEXT-Dynamic-Node Level-1 TLV ..................... NEXT-Dynamic-Interface TLV Related level-2 TLVs ....... Unreserved Bandwidth Level-2 TLV ...................... Delay Average Level-2 TLV ............................. Reliability Level-2 TLV ............................... Available Spectra Level-2 TLV ......................... NEXT-Dynamic-Node related level-2 TLVs ................ System Error Level-2 TLV .............................. 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 .............................. Expires September 2001 [Page 2] Internet Draft NEXT for OSPFv3 March, 2001 1 Overview This document details extensions to OSPFv3 [2] called NEXT. NEXT can be used to provide granular traffic engineering capabilities to OSPFv3 devices. To accomplish this, NEXT provides interface, link, and device capability and state information to other protocols. The intent of NEXT is to enable the selection of shortest paths through networks based on sets of advanced criteria. While NEXT builds on functionality presented in other works, it adds new features, presents new 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 the provisioning of advanced MPLS services for non IPv4 networks. NEXT supports intra-area and inter-area routing. 2 Basic Functionality NEXT adds new LSAs to OSPFv3, and as (generally) conceived with other OSPFv3 LSAs, NEXT LSAs will be encapsulated in IPv6 packets. 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. Topological views of a network derived from NEXT may not be synchronized with the regular OSPFv3 routed topology. 2.1 Protected Wavelength Routing NEXT supports the reservation of alternate standby paths to a specific destination. Protected path setup is support is provided by the Shared Risk Link Group TLV (described elsewhere). 2.2 Limiting Resource Consumption This memo includes several recommendations for reducing NEXT related resource consumption. 2.2.1 Controlling Implementations Expires September 2001 [Page 3] Internet Draft NEXT for OSPFv3 March, 2001 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 with this specification. These TLVs are specified elsewhere in this memo. Network operators must determine which TLVs are needed, balancing the benefits of NEXT data against resource consumption. Obviously, only critical TLVs should be enabled. Therefor, this memo assumes that network operators will only enable a subset of all TLVs available in an implementation. 2.2.2 Separating data into LSAs NEXT splits dynamically changing TLVs, such as averages, into separate LSAs from more static TLVs, such as color, in order to reduce the amount aggregate TLV data transmitted. 2.2.3 Control Channels To minimize the amount of data injected into a network, NEXT supports the assignment of control channels. This functionality is implemented by the DCC level-3 TLV, and the Total and Available Spectra level-2 TLVs, described elsewhere in this memo. 2.2.4 Edge Operation In order to reduce the memory and processing requirements of interior 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, in some cases, only edge devices require additional resources for these purposes. However, all devices running NEXT must originate and forward NEXT LSAs 2.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 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 data to set up explicit routes should be very diligent in tearing down and Expires September 2001 [Page 4] Internet Draft NEXT for OSPFv3 March, 2001 rebuilding paths. Once a resource-reserved path is set up, NEXT path metric changes should not automatically cause existing 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 only through commands designed to trigger this action. This rule applies to any TLV which polls device or interface counters which can be manually reset. Special care must be taken with the general origination intervals of several NEXT TLVs, including those based on counters or dynamic states. The state polling intervals NEXT uses to build TLV metrics must be manually configurable. All counter based TLVs must default to a 5 minute counter polling average. Additionally, [10] describes methods for smoothing the variance between differing metrics. Using this technique, it may be possible to limit oscillations. 2.4 Topology and Computation Although network topology computation is outside the scope of this memo, note that it would be beneficial if outside protocols can build separate, modified singular, or composite (totally singular) views of the network using the data presented by NEXT. Separate topological views result from utilizing NEXT to build separate "best paths" based on one NEXT state parameter. Alternatively, NEXT may be used to modify the normal topology process, building (complex) composite metrics, thereby modifying the normal singular view of the network. Lastly, NEXT LSA data may be used to build singular topologies based on sets of state and capability data. In this case, a single best path would be computed based on the links which support the highest number of requested parameters and capabilities, and the best metrics for all the requested states. Note that this functionality implies that all metrics are inspected and treated equally by the traffic engineering mechanism, unless configured otherwise. An example of this type of mechanism can be found in [10]. NEXT implementations must permit direct access to NEXT LSAs and databases. 2.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 September 2001 [Page 5] Internet Draft NEXT for OSPFv3 March, 2001 Refer to the section entitled limiting resource consumption for more information regarding resource consumption issues. 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. Enabling NEXT parameters may result in LSA re-origination. 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 as in [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: Expires September 2001 [Page 6] Internet Draft NEXT for OSPFv3 March, 2001 -The NEXT-LSA: The NEXT-LSA carries data that is likely to be somewhat static. For example, this LSA might carry data pertaining to administrative metrics, which tend not to change frequently. -The NEXT-Dynamic-LSA: The NEXT-Dynamic-LSA carries data that is likely to change frequently. 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 nodal state and capability. All NEXT LSAs will be identified using unallocated 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. All options field allocations are TBD. Specialized use of NEXT LSA ID fields is TBD. Until such specifications are made, NEXT LSA ID fields carry the same meaning as the intra-area-prefix LSA [2]. Overview of 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. Both NEXT LSAs, the NEXT-LSA and the NEXT-Dynamic-LSA, utilize the same TLV architecture. The NEXT TLV architecture follows the common triplet format: 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 Expires September 2001 [Page 7] Internet Draft NEXT for OSPFv3 March, 2001 zero. TLVs must be padded to a four-byte alignment, however, 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 be 32-bit aligned. Unrecognized TLV types must be ignored. All TLVs types between 1 and 9, and above 131000 are reserved for future use. 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. In order to facilitate changes, base NEXT TLVs must be assigned with types at intervals of five. All other undefined TLV type codes are reserved for future assignment. All reserved fields are currently not utilized and must be set to zero. NEXT level-1 TLVs 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. Level-3 TLVs must conform to the same architectural and operative constraints as other TLVs. Note level-3 TLVs may also, in turn, carry further nested TLVs. The number of TLVs subordinate to a higher level TLV may vary, but it must be possible for a single sub-level (lower than level-1) 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. Disabled TLVs should not be sent. Note that NEXT LSAs DO NOT define the same sub-level TLVs. Implementations of NEXT must allow TLV values to be manually overridden. Several TLVs must not be re-originated when router event counters are cleared. These TLVs must only be re-originated via commands designed to trigger this action. Special care must be taken with the general origination intervals of several TLVs. Sub-level TLVs will be ordered as appropriate. There may be instances when certain TLVs must be ordered in a specific fashion. Depiction of the NEXT TLV hierarchy +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ | NEXT-LSA | | NEXT-Dynamic-LSA | +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ | | -------- ------- Expires September 2001 [Page 8] Internet Draft NEXT for OSPFv3 March, 2001 | | | | | +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ | | |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-LSA TLVs This section specifies TLVs which are only used with the NEXT-LSA. The NEXT-LSA incorporates TLVs which convey generally static information. NEXT-LSA level-1 TLVs NEXT-LSA Level-1 TLVs follow the OSPFv3 LSA header of an 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 support is TBD. Expires September 2001 [Page 9] Internet Draft NEXT for OSPFv3 March, 2001 The NEXT-Interface level-1 TLV The NEXT-Interface level-1 TLV granularly describes a single network device interface. The NEXT-interface TLV contains core values and a set of nested level-2 TLVs. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Level2 TLVs | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ As in [2], 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. 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. Note that under future specification it may be possible to use the reserved space in the base NEXT-Interface TLV to identify technologies or protocols. The remainder of the NEXT-interface TLV is comprised of level-2 TLVs. The NEXT-Node level-1 TLV A NEXT-Node TLV describes a system which is running OSPFv3 and NEXT. While the NEXT-Node TLV may contain basic values, it will contain a set of nested level-2 TLVs. Expires September 2001 [Page 10] Internet Draft NEXT for OSPFv3 March, 2001 Only a single NEXT-Node TLV may be carried in an LSA. The NEXT-Node TLV can be utilized to view OSPFv3 network entities (i.e. routers) as devices with inherent states, separate from, but similar to the way that links have been viewed traditionally. Note that while NEXT-node TLVs are intended to add separate but specific device information to the network topology, their information may also be used as "macro" TLVs, adjusting the value of interface TLVs. In this case, the Nodal TLVs can be viewed as extended interface TLVs. 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 in the NEXT-LSA. NEXT currently defines the following level-2 TLVs for the Level-1 NEXT-Interface TLV: Type Description --------------------------------------------------- 10 Link Type 15 Shared Risk Link Group 20 Administrative Metric 25 Bandwidth 30 Resource class/color 400-435 Reserved for IPv6 CoS (TBD) Link Type level-2 TLV The Link Type TLV identifies access characteristics of an 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 (10) | length | Expires September 2001 [Page 11] Internet Draft NEXT for OSPFv3 March, 2001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The following values a currently defined for the link type attribute of this TLV: Type Description --------------------------------------------------- 10 Point-to-point 15 Multiaccess 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. 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 (15) | 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 Expires September 2001 [Page 12] Internet Draft NEXT for OSPFv3 March, 2001 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 (25) | 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 (30) | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Resource Class/Color Mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NEXT-interface TLV related level-3 TLVs NEXT Level-3 TLVs follow (and are part of) level-2 in NEXT-interface level 2 TLVs. NEXT currently defines the following level-3 TLVs for NEXT-interface Level-2 TLVs: Expires September 2001 [Page 13] Internet Draft NEXT for OSPFv3 March, 2001 Type Description Associated Level-2 TLV --------------------------------------------------- 10 Data Control Channel Link Type Data Control Channel (DCC) level-3 TLV The DCC TLV identifies 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. The second usage is useful when non OSPF channels have differing states and capabilities. The DCC interface will be identified by the physical interface ID derived from the referenced router links LSA. When the NEXT-Interface TLV is used to represent channels or lambdas with differing state and capabilities interface index must be used for identification. 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- 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. NEXT-Node TLV related level-2 TLVs NEXT-Node Level-2 TLVs follow (and are part of) NEXT-Node level-1 TLVs in the NEXT-LSA. NEXT currently defines the following level-2 TLVs for the NEXT-Node Level-1 TLV in the NEXT-LSA: Type Description --------------------------------------------------- Expires September 2001 [Page 14] Internet Draft NEXT for OSPFv3 March, 2001 10 System Resource class/color System Resource class/color level-2 TLV 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 (10) | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Resource Class/Color Mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NEXT-Dynamic-LSA Related TLVs 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 in the NEXT-Dynamic-LSA. NEXT currently defines the Expires September 2001 [Page 15] Internet Draft NEXT for OSPFv3 March, 2001 following level-2 TLVs for the Level-1 Interface TLV when viewed in the NEXT-Dynamic-LSA: Type Description --------------------------------------------------- 10 Unreserved Bandwidth 15 Delay Average 20 Reliability 25 Available Spectra 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 control channel representing a conglomeration of non OSPF channels, as specified by the Link Type TLV, the unreserved bandwidth should be the sum of the unused bandwidths of all channels on all the links being represented 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 (10) | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unreserved Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 Expires September 2001 [Page 16] Internet Draft NEXT for OSPFv3 March, 2001 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 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. Generation of this TLV to influence network topology may be governed by mechanisms such as [13]. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reliability Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 Expires September 2001 [Page 17] Internet Draft NEXT for OSPFv3 March, 2001 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. Wavelength is specified in nanometers, and describes the starting or smallest wavelength for the channel. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |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 in the NEXT-Dynamic-LSA. 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 Error 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: Expires September 2001 [Page 18] Internet Draft NEXT for OSPFv3 March, 2001 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | System Error ID | Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 Author acknowledges the following individuals: -Alex Zinin, Cisco Systems 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 Expires September 2001 [Page 19] Internet Draft NEXT for OSPFv3 March, 2001 [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 for Internet Traffic Engineering", July 2000. [13] Giacalone, S., "OSPFv2 Metric Auto-Decay" Work in Progress, August 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 Expires September 2001 [Page 20] Internet Draft NEXT for OSPFv3 March, 2001 -The NEXT-Dynamic-LSA -The NEXT-Dynamic-Interface level-1 TLV -NEXT-Dynamic-Interface level-2 TLVs -Unreserved Bandwidth -Interface Delay Average -The NEXT-Dynamic-Node level-1 TLV -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 Expires September 2001 [Page 21] Internet Draft NEXT for OSPFv3 March, 2001 Copyright (C) The Internet Society (2001). 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 September 2001 [Page 22]