Network Working Group Qingming Ma INTERNET DRAFT Heidi Ou Expiration: August 2001 Cisco Systems February 2001 Using Two Octets for Bandwidth Values in OSPF and ISIS extensions for Traffic Engineering Status of this Memo 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. 1. Abstract In OSPF and ISIS extensions for support of traffic engineering, sub- TLVs with values of link bandwidth are advertised. Currently a bandwidth value is denoted by a 4-byte IEEE floating number. This draft proposes a simple way to use two octets to represent a bandwidth value used in traffic engineering sub-TLVs. Ma & Ou [Page 1] INTERNET DRAFT February 2001 Expires August 2001 2. Introduction Traffic Engineering requires routing protocols to advertise link bandwidth information. Current OSPF extensions [1] for traffic engineering advertise a per-link LSA with payload of one or more nested Type/Length/Value (TLV). In [1], nine sub-TLVs are mandatory, of which the following three sub-TLVs are used for link bandwidth: sub-type | bytes | values ------------------------------------------------------- 6 | 4 | Maximum BW 7 | 4 | Maximum Reservable BW 8 | 32 | Unreserved BW for eight priorities. Similar ISIS extensions are also proposed in [7]. In both cases of extensions, a bandwidth sub-TLV is represented by an IEEE floating point number in terms of bytes/second. More recent proposals [2,3,4,5,6] require more sub-TLVs to be supported. Using IEEE floating point gives the range of bandwidth value that is significantly larger than that a four-byte integer can give. An four-byte integer can only represent a bandwidth value up to (2^32 - 1), which is about 4GB/s and is clearly insufficient for a link with capacity above OC192. In addition to high processing overhead associated floating point arithmetic, one problem with using IEEE floating point numbers for bandwidth values is that a router processor may not support IEEE floating point. In such a cases either the bandwidth values in floating point numbers is converted into four-byte integers, or the router processor has to emulate the floating point arithmetic. In the former case, a large bandwidth value may overflow into zero. In the later case, 128 bits may be needed to represent the integer part of an IEEE floating point number, which can consume a significant amount of processing cycles. Furthermore, such a router need to collect link bandwidth statistics (mostly likely using four-byte integers) and convert them into a IEEE floating point representation when set the sub-TLVs for the LSA. In practice, the bandwidth values being advertised need not be as precise as that can be represented by an IEEE floating point number [8]. In the cases when two bandwidth values are very close, it does not matter for the purpose of traffic engineering which link should be selected. Other criteria in path selection may weight more. For example, if one link is of bandwidth 512.788 MB/s and the other 512.102 MB/s, which link to use may make little difference from traffic engineering perspective. Other path selecting criteria, such as number of hops, may be used to decide which link to use. In other words, given two bandwidth values, what it matters is the difference between the first few most significant digits. On the other hand, it is difficult to have accurate bandwidth values, since these bandwidth values are typically collected over a time Ma & Ou [Page 2] INTERNET DRAFT February 2001 Expires August 2001 interval (perhaps, an exponential average over the time interval). While these values are flooded within the network, the actual bandwidth values may have been changed. Thus, it is almost impossible to know precisely link bandwidth values than the link capacity. Approximative bandwidth values are sufficient. In this draft, we propose a way to use two octets to represent a bandwidth value in sub-TLVs for the traffic engineering LSA, which we believe is sufficient for the purpose of traffic engineering. One advantage to use this representation is low processing overhead, especially for a router processor that does not support IEEE floating point. Using this representation, there is no need to deal with floating point numbers. Another advantage to use this representation is that the size of sub-TLVs for traffic engineering are significantly reduced. Considering the fact that more bandwidth sub- TLVs may be defined, such as support for Diff-Serv-aware traffic engineering and link bundling, this size reduction can be more significant. As a result of the size reduction, more sub-TLVs can be defined. This helps the situation, such as ISIS where the total size of all sub-TLVs is limited to 244 bytes. Also, smaller sub-TLV size implies that less number of packets need to be sent for flooding link state information and less packet fragmentation for LSAs is needed. 3. Representing bandwidth value in two Octets We propose to use two octets to represent a bandwidth value: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | a | b | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ It represents the number BW = (a, b) = a X 2^b. The a is like the mantissa and b like the exp in an IEEE floating point number. The range of the number is 0 <= a < 1024 0 <= b < 64 0 <= BW < 2^73 (about 8 * 10^21) Thus the maximal value can be as large as 8,000,000,000 TB/s, which should be sufficient to represent link bandwidth value for today and future networks. Given an integer, it may be coded in multiple ways. For example, the value 1024 can be represented as (512, 1), (256, 2), (128, 3), and so on. We call a representation that is with the minimum b the normal representation. In the case that a value can not be represented precisely, we need to decide if it should be round up or round down to the closest number which can be represented. For instance, 1025 can be round up to (513, 1) or round down to (512, 1). Which Ma & Ou [Page 3] INTERNET DRAFT February 2001 Expires August 2001 representation to use depends on whether we want to over-engineer the network or not. It is easy to compare two bandwidth values BW1 = (a1, b1) and BW2 = (a2, b2) in normal representation: BW1 < BW2 iff (b1 < b2) or (b1 == b2 && a1 < a2) Other arithmetic operators, such as addition, subtraction, and multiplication can be defined accordingly. We propose to use this new representation for all or part of sub-TLVs in OSPF and ISIS entension for traffic engineering. There are two possible ways to pursue this. One way is to incorporate this representation in the existing drafts for OSPF and ISIS entensions. The other way is to define new sub-TLV types, to ensure backward compatability. 4. Changes in OSPF extensions A number of OSPF extensions have been proposed for traffic engineering. 4.1 Generic OSPF entensions for traffic engineering We start with the basic extensions defined in [1]. There are three new sub-TLVs are defined: sub-type | bytes | values -------------------------------------------------------- 6 | 4 | Maximum BW 7 | 4 | Maximum Reservable BW 8 | 32 | Unreserved BW for eight priorities. We propose to define two new sub-TLVs to replace these: sub-type | bytes | values --------------------------------------------------------------- TBD1 | 4 | Maximum BW for the first two octets | | Maximum Reservable BW for other two octets TBD2 | 16 | Unreserved BW for eight priorities. The actual sub-type numbers TBD1 and TBD2 are to be decided. 4.2 Link bundling and GMPLS extensions In [2, 3], a new sub-TLV with type 13 is added: Ma & Ou [Page 4] INTERNET DRAFT February 2001 Expires August 2001 sub-type | bytes | values --------------------------------------------------------- 13 | 32 | Maximum LSP BW (carried per-priority) This one can also be replaced by a new sub-type with the length of value 16. sub-type | bytes | values --------------------------------------------------------- TBD | 16 | Maximum LSP BW (carried per-priority) 4.3 Diff-Serv aware traffic engineering extensions In [5], OSPF extensions for support of Diff-Serv-aware MPLS traffic engineering are proposed, three new optional Sub-TLVs are defined: sub-type | bytes | values -------------------------------------------------- TBD1 | 32 | Unreserved BW for Class-Type 1 TBD2 | 32 | Unreserved BW for Class-Type 2 TBD3 | 32 | Unreserved BW for Class-Type 3 These three sub-TLVs can be encoded as sub-type | bytes | values -------------------------------------------------- TBD1+ | 16 | Unreserved BW for Class-Type 1 TBD2+ | 16 | Unreserved BW for Class-Type 2 TBD3+ | 16 | Unreserved BW for Class-Type 3 5. Changes in ISIS extensions This section discuss a number of ISIS extensions that have been proposed for traffic engineering. 5.1 Generic ISIS entensions for traffic engineering We start with the basic extensions defined in [7]. In the extended IS reachability TLV, three sub-TLVs are defined: sub-type | bytes | values -------------------------------------------------------- 9 | 4 | Maximum BW 10 | 4 | Maximum Reservable BW 11 | 32 | Unreserved BW for eight priorities. We propose to define two new sub-TLVs to replace these: Ma & Ou [Page 5] INTERNET DRAFT February 2001 Expires August 2001 sub-type | bytes | values ------------------------------------------------------------- TBD1 | 4 | Maximum BW for the first two octets | | Maximum Reservable BW for other two octets TBD2 | 16 | Unreserved BW for eight priorities. The actual sub-type numbers TBD1 and TBD2 are to be decided. 5.2 GMPLS extensions In [4], the extended reachability TLV contains a sub-TLV with sub- type 12: sub-type | bytes | values --------------------------------------------------------- 12 | 32 | Maximum LSP BW (carried per-priority) This one can also be replaced by a new sub-type with the length of value 16. sub-type | bytes | values --------------------------------------------------------- TBD | 16 | Maximum LSP BW (carried per-priority) 5.3 Diff-Serv aware traffic engineering extensions In [6], the extended reachability TLV contains (optional) three sub- TLVs whose sub-types are to be defined: sub-type | bytes | values -------------------------------------------------- TBD1 | 32 | Unreserved BW for Class-Type 1 TBD2 | 32 | Unreserved BW for Class-Type 2 TBD3 | 32 | Unreserved BW for Class-Type 3 These three sub-TLVs can be encoded as sub-type | bytes | values -------------------------------------------------- TBD1+ | 16 | Unreserved BW for Class-Type 1 TBD2+ | 16 | Unreserved BW for Class-Type 2 TBD3+ | 16 | Unreserved BW for Class-Type 3 6. References [1] Katz, D. and Yeung, D., "Traffic Engineering Extension to OSPF" draft-katz-yeung-ospf-traffic-03.txt Ma & Ou [Page 6] INTERNET DRAFT February 2001 Expires August 2001 [2] Kompella, K., Tekhter, Y., and Berger, L., "Link Bundling in MPLS Traffic Engineering", draft-kompella-mpls-bundle-04.txt [3] Kompella, K. et al, "OSPF Extensions in Support of Generalized MPLS" draft-kompella-ospf-gmpls-extensions-00.txt [4] Kompella, K. et al, "ISIS Extensions in Support of Generalized MPLS" draft-kompella-isis-gmpls-extensions-01.txt [5] Le Faucheur, F. et al, "Extension to OSPF for support of Diff-Serv-aware MPLS Traffic Engineering", draft-lefaucheur-diff-te-ospf-00.txt [6] Le Faucheur, F. et al, "Extension to ISIS for support of Diff-Serv-aware MPLS Traffic Engineering", draft-lefaucheur-diff-te-isis-00.txt [7] Li, T. and Smit, H., "IS-IS extensions for Traffic Engineering", draft-ietf-isis-traffic-02.txt [8] Ma, Q., "Quality-of-Service Routing in Integrated Service Networks" Ph.D. Dissertation, Carnegie Mellon University, 1997 7. Editors' Address Qingming Ma Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 e-mail: qma@cisco.com Heidi Ou Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 e-mail: hou@cisco.com Ma & Ou [Page 7]