TE Working Group Nabil Bitar Internet Draft Roshan Rao Expiration Date: December 2001 Karthik Muthukrishnan Lucent Technologies Inc. July 2001 Traffic Engineering Extensions to OSPF draft-bitar-rao-ospf-diffserv-mpls-01.txt Status 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 document describes extensions to the traffic engineering opaque LSA to mainly support differentiated services (Diffserv) and Multiprotocol Label Switching (MPLS). 1. Introduction In [1], a new OSPF Link State Advertisement (LSA), called the Traffic Engineering LSA (TE-LSA), was defined. This LSA advertises the link maximum and reservable bandwidth as well as the un-reservable bandwidth at each of 8 priority levels. This document defines new Link sub-TLV extensions to those defined in [1] in order to support differentiated services and MPLS. The need or requirements to provide such support in OSPF and IS-IS are discussed in detail in [2]. Differentiated services (Diffserv) enable the support of different per-hop behaviors (PHBs) [3] on a link. These per-hop behaviors enable packets passing through a link to get different forwarding treatment depending on the behavior aggregate to which they belong. Each behavior aggregate maps to a PHB. MPLS-aware switches/routers (LSRs), that implement the Diffserv extensions to Bitar, et. al Expires December 2001 [Page 1] MPLS [4], will be able to request and setup label-switched paths (LSPs) that carry different behavior aggregates. At routers, the label and/or EXP field of the top label in the shim header of a labeled packet indicates the behavior aggregate to which the labeled packet belongs. A Label Edge Router (LER) that initiates the setup of an LSP and requests certain PHB(s) to be applied to that LSP should be able to select a path through the network that is most likely to satisfy its traffic engineering requirement, including the requested PHB(s). This selection should be based on the state of the network, i.e. link support for PHBs, bandwidth per link or per Diffserv class etc. OSPF and IS-IS, as link state protocols, are perfectly suited to distribute such information in the network. This document proposes how encoding of such information can be done by extending the TE-LSA defined in [1]. Some extensions similar to those proposed in this document were proposed in [5]. However, this document defines the actual encoding of these extensions based on the PHBIDs defined in [6] as opposed to the class-type suggested in [5]. PHBIDs are used to identify Diffserv PHB/PHB-groups in a standard way. Additionally, the encoding proposed in this document can be looked at as defining the class type in [5] as a concatenation of PHBIDs. In addition to defining sub-TLVs that relay the link support for Diffserv, a new Link sub-TLV is defined to advertise the MPLS capability and the state of MPLS-related resources for that link. It is also proposed that the Maximum reservable Bandwdth Link sub-TLV defined in [1] be modified. This document does not discuss how the actual route selection for an LSP can be done. Route computation will be the subject of another discussion. 2. TLV format This document adopts the TLV format used in [1]. 3. Link TLV This document defines sub-TLVs to be encoded in the value field of the link TLV defined in [1]. The following sub-TLVs are defined: 1- Diffserv Available Bandwidth 2- Oversubscription 3- Diffserv Capability 4- Diffserv Max Delay 5- Link Propagation Delay 6- Priority Reserved Bandwidth 7- Link Capability/Resources All the sub-TLVs defined in this document are optional. However, a router must support all Diffserv TLVs or none. Each sub-TLV may occur only once. Unrecognized types are ignored but still flooded. A Modification to the the defnition of the Maximum Reservable Bandwidth sub-TLV defined in [1] is also proposed: Bitar, et. al Expires December 2001 [Page 2] 3.1 Diffserv Available Bandwidth The Diffserv Available Bandwidth sub-TLV is used to advertise the available bandwidth for each PHB/PHB group or set of PHB/PHB-groups configured on the advertised link from the advertising router direction. In the latter case, a set of PHB/PHB groups is allocated a sharable bandwidth chunk of the link. Each PHB or PHB group is identified by a 16-bit PHB identifier (PHBID) [6]. The absence of a PHBID from this sub-TLV can be interpreted to mean that the particular PHB group is not supported on that link unless it is advertised in the Diffserv capability TLV. Routing can take advantage of this information in selecting a path for an LSP that desires a particular PHB. The Diffserv available bandwidth sub-TLV type is TBD. Its value consists of a sequence of elements where each element has the following 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |#PHB=n | Oversubscription | Available Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Available bandwidth(cont.) | PHBID1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ---------- | PHBIDn | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Each PHBID field is encoded according to RFC 2836 [6]. The bandwidth value is encoded in IEEE floating point format and it is in units of bytes per second. The available bandwidth is what is available for reservation for the accompanying PHB, PHB group or set of PHBs/PHB-groups advertised in each element. In the latter case, it is assumed that a set of PHB/PHB groups advertised in one element are allocated the same bandwidth chunk and have the same oversubscription factor. Thus, allocating bandwidth X on the advertised link for any of the listed PHB/PHB groups in that element will decrease the available bandwidth for each of the PHB/PHB groups in this list by X. The sum of all advertised available bandwidths may exceed the actual link bandwidth as PHBs or PHB groups can be oversubscribed. The advertised available bandwidth factors in the over-subscription factor for a PHBID. The oversubscription factor is included separately as it could be used as a qualifier in selecting an LSP route (i.e. a route whose link oversubscription for a PHB does not exceed a certain value). The 10-bit over-subscription factor is encoded in percentage as an unsigned integer value with a maximum value of 1023. The number of elements advertised in each sub-TLV can be deduced from the sub-TLV length and the #PHB field(s). Each element has length (6 + n * 2) bytes, where 6 bytes account for the #PHB, oversubscription and the available bandwidth fields, and n is the number of PHBIDs advertised in that element. 3.2 Over-Subscription Bitar, et. al Expires December 2001 [Page 3] A Link TLV that includes the Over-Subscription sub-TLV MUST also include the Maximum Reservable Bandwidth sub-TLV as proposed to be defined in Section 3.8 and is correlated with it. The Over-Subscription sub-TLV type is TBD. It is encoded in percentage as a 16-bit integer value using the following 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Over-subscription factor | Reserved =0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Over-Subscription sub-TLV length is 4 bytes. 3.3 Diffserv Capability The Diffserv Capability sub-TLV type is TBD. It is used to advertise the PHB/PHB groups supported on a link. Its value consists of a sequence of PHBIDs as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PHBID1 | PHBID2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ------ | ------ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ------ | PHBIDn | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Remember that the TLV must be 4-byte aligned. Thus, if n is odd, the last 2 bytes will be padding bytes that are not included in the TLV length. The PHBID field is encoded according to RFC2836. The number of PHBIDs can be deduced from the length. If a PHBID is included in an element in the Diffserv Available Bandwidth sub-TLV, it does not need to be included in the Diffserv Capability sub-TLV. The Diffserv Capability sub-TLV is used when it is desirable to advertise the support for a PHB or a set of PHBs without advertising the bandwidth associated with them. 3.4 Maximum Delay It is sometimes desired to select a route for an LSP that satisfies a delay variation and/or delay requirement. These requirements can be imposed by the application(s) whose packets are to be transported in that LSP. An operator may want to configure a Diffserv PHB/PHB group that will be applied to such packets. Therefore, it becomes important to advertise the maximum delay associated with that PHB/PHB group at each link. When setting up an LSP with certain delay/delay variation requirement, this maximum delay can be used as a metric to select the LSP path. The Maximum delay advertised in this sub-TLV is only due to queuing delay. The delay variation is considered to be the same as maximum delay. Bitar, et. al Expires December 2001 [Page 4] The Maximum Delay TLV type is TBD. It is used to advertise the maximum queuing delay that can be encountered by a packet that belongs to a behavior aggregate corresponding to the associated PHBID. Its value consists of a sequence of 4-octet elements where each element has the following 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PHBID | Max Delay value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Max Delay value is specified as an unsigned-integer in units of microsecond. Thus, maximum delay can be 65536 microseconds. The length field in the sub-TLV will be equal to (4* number of advertised elements). 3.5 Link Propagation Delay The Link Propagation Delay sub-TLV type is TBD. The delay value is 4 octets encoded in the value field of the sub-TLV in IEEE floating point format. It is in units of microseconds. 3.6 Priority Reserved Bandwidth This sub-TLV advertises the reserved bandwidth at each of the eight priority levels specified in CR-LDP [7] and RSVP-TE [8]. An operator may configure PHB(s)/PHB groups to have fixed allocations of the bandwidth while allow others to share the remaining bandwidth or chunks of the bandwidth. In addition, an operator can configure certain priority levels but not all for certain PHB groups. In this latter case, it makes sense to advertise the reserved bandwidth for each of the configured priorities per PHB/PHB-group. When a set of PHB/PHB-groups is advertised to have a sharable bandwidth (i.e. as a set), the reserved bandwidth per priority level applies to the set not to individual PHBs/PHB-groups. This TLV type is TBD. Its value consists of a sequence of elements where each element has the following 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | #PHBID = n| Re| pri bit map | Reserved Bandwidth 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved Bandwidth 1 (cont.) | ------------ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ---------- | ------------- | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ---------- | Reserved Bandwidth k | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved Bandwidth k (cont) | PHBID1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | --------------- | PHBIDn | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Bitar, et. al Expires December 2001 [Page 5] The priority bit map (pri bit map) corresponds to the priority level with the most significant bit corresponding to priority 0 and the least significant bit corresponding to priority 7. If the bit is cleared, the corresponding priority level is not supported. If the bit is set, the corresponding priority level is supported. For those supported priority levels, the reserved bandwidth is listed in decreasing priority order (i.e. starting with 0 down to 7). The number of reserved bandwidth fields can be obtained by summing up the number of 1's in the bit map. 3.7 Link Capability/Resources The Link Capability/Resources sub-TLV type is TBD. Its value is a 32-bit map with the following defined bits: Bit 0 (most significant bit): corresponds to MPLS-specific resources on the link (e.g., out of labels, out of memory). It is set when a resource essential to the setup of an LSP is exhausted. Bit 31: set to 1 if the router supports RSVP-TE. It is clear otherwise. Bit 30: set to 1 if the router supports CR-LDP. It is clear otherwise. 3.8 Maximum Reservable Bandwidth According to [1], the Maximum Reservable Bandwidth sub-TLV (type-7) specifies the maximum bandwidth that may be reserved on this link in this direction, in IEEE floating point format. It is proposed that this sub-TLV advertise the maximum reservable bandwidth, including oversubscription, on the link excluding what is advertised in the Diffserv available bandwidth TLVs if any. 4. Elements of Procedure This document adopts the elements of procedures in [1] but proposes to eliminate the statement "No SPF or other route calculation are necessary" in [1]. Whether SPF or other routing computations are to be carried out upon reception of a type-10 LSA will depend on the router capabilities in supporting the TE extensions and its configuration, an implementation issue. Consistent routing behavior is probably better attained if all routers in a domain use the same criteria and algorithms for computing their routing tables. Routers shall reoriginate Traffic Engineering LSAs, other than normal refreshes, whenever there is a significant change in the advertised information that was previously advertised by these LSAs. 5. Security Considerations This document raises no new security issues for OSPF. Bitar, et. al Expires December 2001 [Page 6] 6. References [1] Katz, Dave and Yeung, Derek, "Traffic Engineering Extensions to OSPF," draft-katz-yeung-ospf-traffic-04.txt, February 2001. [2] Le Faucheur et. al., "Requirements for support of Diff-Serv-aware MPLS Traffic Engineering," draft-ietf-tewg-diff- te-reqts-00.txt," February 2001. [3] Blake, S. et. al., "An Architecture for Differentiated Services," RFC 2475, December 1998. [4] Le Faucheur et. al., "MPLS Support of Differentiated Services," draft-ietf-mpls-diff-ext-08.txt, February 2001. [5] Le Faucheur et. al., " Extensions to OSPF for support of Diff-Serv-aware MPLS Traffic Engineering," draft-ietf-ospf-diff- te-00.txt, February 2001. [6] Brim, S. et al, "Per Hop Behavior Identification Codes," RFC 2836, May 2000. [7] Jamoussi, B. et. al. "Constraint-Based LSP Setup using LDP," draft-ietf-mpls-cr-ldp-05.txt, February 2001. [8] Awduche, D. et al, "RSVP-TE: Extensions to RSVP for LSP Tunnels," draft-ietf-mpls-rsvp-lsp-tunnel-08.txt, February 2001. Authors' addresses: Nabil Bitar Lucent Technologies 1 Robbins Road, Westford, MA 01889 USA E-mail: nbitar@lucent.com Roshan Rao Lucent Technologies 1 Robbins Road, Westford, MA 01889 USA E-mail: rrao@lucent.com Karthik Muthukrishnan Lucent Technologies 1 Robbins Road, Westford, MA 01889 USA E-mail: mkarthik@lucent.com Bitar, et. al Expires December 2001 [Page 7]