Network Working Group M. Boucadair Internet Draft C. Jacquenet Document: draft-jacquenet-ip-te-pib-02.txt France Telecom R&D Category: Experimental June 2002 Expires December 2002 An IP Traffic Engineering Policy Information Base Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026 [1]. 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 draft specifies a set of Policy Rule Classes (PRC) for the enforcement of an IP traffic engineering policy by COPS-PR ([2])- capable routers. Instances of such classes reside in a virtual information store, which is called the IP Traffic Engineering Policy Information Base (IP TE PIB). The corresponding IP TE policy provisioning data are intended for use by the COPS-PR IP TE Client- Type([3]), and they complement the PRC classes that have been defined in the Framework PIB ([4]). Table of Contents 1. Introduction................................................2 2. Conventions used in this document...........................3 3. Changes since the previous version..........................3 4. Scalability considerations..................................3 4.1. A tentative metric taxonomy.................................4 4.2. Reporting the enforcement of an IP traffic engineering policy....................................................4 5. PIB Overview................................................5 Jacquenet et al. Experimental - Expires Dec. 2002 [Page 1] Internet Draft An IP Traffic Engineering PIB June 2002 6. The IP Traffic Engineering Policy Information Base..........6 7. Security Considerations....................................26 8. References.................................................27 9. Acknowledgments............................................28 10. Authors' Addresses.........................................28 1. Introduction The deployment of value-added IP services over the Internet has become one of the most competing challenges for service providers, as well as a complex technical issue. Within the context of network resource provisioning and allocation, the COPS protocol and its usage for the support of Policy Provisioning is one of the ongoing specification efforts of the Resource Allocation Protocol (rap) Working Group of the IETF that should help service providers in dynamically enforcing IP Traffic Engineering (IP TE) policies. An IP traffic engineering policy consists in appropriately provisioning, and allocating/de-allocating, the switching and the transmission resources of an IP network (i.e. the routers and the links that connect these routers, respectively), according to Quality of Service (QoS) requirements (e.g. rate, one-way delay, inter-packet delay variation, etc.) that have been expressed by the customers who can access such resources within the context of a given service subscription procedure ([5]). Thus, the enforcement of an IP traffic engineering policy yields the introduction of a high level of automation for the dynamic provisioning of the configuration data that will be taken into account by the routers to select the appropriate IP routes. Within the context of this document, the actual enforcement of an IP traffic engineering policy is primarily based upon the activation of both intra- and inter-domain dynamic routing protocols (e.g. [6], [7]) that will be activated in the network to select, install, maintain and possibly withdraw routes that will comply with the above-mentioned QoS requirements and/or specific routing constraints, depending on the type of traffic that will be conveyed along these traffic engineered routes. It is therefore necessary to provide the route selection processes with the information that will reflect these QoS requirements, given the dynamic routing protocols support traffic engineering capabilities for the computation of such routes. Some of these capabilities are currently being specified in [8] and [9] for the OSPF (Open Shortest Path First, [6]) and the IS-IS (Intermediate System to Intermediate System routing protocol, [10]) interior routing protocols respectively, while there is a comparable Jacquenet et al. Experimental - Expires Dec. 2002 [Page 2] Internet Draft An IP Traffic Engineering PIB June 2002 effort for the BGP4 (Border Gateway Protocol, version 4) protocol, as described in [11], for example. To provide the route selection processes with the aforementioned information, one possibility is to use the COPS-PR protocol, together with a collection of policy provisioning data that will be stored in a virtual information store, called a Policy Information Base. This draft describes a collection of Policy Rule Classes that will be stored and dynamically maintained in the IP TE PIB. The "rule" and "role" concepts, which have been defined in [12], are adopted by this document to distribute the IP traffic engineering policy provisioning data over the COPS-PR protocol. This document is organized as follows: - Section 4 introduces some considerations about the scalability of such a dynamic provisioning scheme, - Section 5 provides an overview of the organization of the IP TE PIB, - Section 6 provides a description of the PRC classes of the IP TE PIB, according to the semantics of the Structure of Policy Provisioning Information (SPPI, [13]). 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [14]. 3. Changes since the previous version - The PIB has been slightly reorganized to introduce an additional table for IS-IS-related policy provisioning data according to [9], - The introduction has been slightly reworded, - The references section has been updated. 4. Scalability considerations The usage of the COPS-PR protocol for the dynamic enforcement of an IP traffic engineering policy raises some scalability issues, as far as the volume of configuration information that will be exchanged not only between the routers themselves (because of the OSPF machinery for example), but also between the PEP (Policy Enforcement Point) components embedded in the routers and the PDP (Policy Decision Point) they communicate with is concerned. Jacquenet et al. Experimental - Expires Dec. 2002 [Page 3] Internet Draft An IP Traffic Engineering PIB June 2002 While the concern strictly related to the design of a routing policy is outside the scope of this document, the dynamic provisioning of metric values as well as the reports related to the actual enforcement of decisions taken by the PDP, deserve some elaboration. 4.1. A tentative metric taxonomy The metrics that will be taken into account by the Shortest Path First (SPF) algorithms for IP TE route calculation can be classified into two basic categories: 1. Metrics assigned on a long-term basis, which basically consist of the "usual" cost metrics, like those defined in [5]. These metrics are those that are assigned on a (logical) interface basis, and they aim at reflecting the link quality the corresponding interface is attached to, 2. Metrics assigned on a (very) short term basis, which MAY consist of the following information: - The available bandwidth, (e.g. based upon the information provided by SNMP (Simple Network Management Protocol, [15]) counters like ifInOctets and ifOutOctets), - The amount of bandwidth that can be reserved, - The amount of reserved bandwidth. While "long term" metric values should not change frequently by definition, the "short term" metric values MAY vary like the ongoing usage of the resources of the network. Therefore, the dynamic computation of "short term" metric values SHOULD remain in the magnitude of the corresponding SPF computation, since newly assigned values yield the spontaneous generation of LSU (Link State Update, [5]) messages. Thus, the traffic generated by the IP traffic engineering provisioning data SHOULD be minimized according to pre-computation engineering recommendations like those described in [16]. 4.2. Reporting the enforcement of an IP traffic engineering policy Likewise, the actual enforcement of policy decisions implies the activation of a reporting mechanism, as described in the COPS-PR specification. From this perspective, this draft assumes that the corresponding reports sent by the PEP components of the routers towards the PDP SHOULD include the traffic engineered routes that have been computed by the routers, at least for network planning purposes: the service subscription requests will be negotiated according to the knowledge of the network resources that are actually available, and this information includes the routes that could very well service the aforementioned requirements, without any extra computation. Jacquenet et al. Experimental - Expires Dec. 2002 [Page 4] Internet Draft An IP Traffic Engineering PIB June 2002 Therefore, the traffic generated by the notification reports of the installed routes SHOULD remain in the magnitude of the route announcement procedures of the IP routing protocols machineries (like OSPF), and it is assumed that the volume of the corresponding COPS-PR traffic is also highly dependent on the pre-computation engineering recommendations that have been mentioned in the above section 3.1. In other words, this draft assumes that it is mainly the responsibility of a network operator to enforce an IP traffic engineering policy that should raise scalability issues (raised by design), NOT the choice of activating the COPS-PR protocol as a means to convey the corresponding IP TE provisioning data. Nevertheless, it is obviously one of the most important concerns of the ongoing specification and development effort that is partly reflected by this draft. In particular, it is the intention of the authors of this draft to later submit a publication that will aim at depicting the simulation results obtained through the validation of this COPS-PR architecture for the dynamic enforcement of an IP traffic engineering policy within the context of an operational service provider's environment. 5. PIB Overview The dynamic enforcement of an IP traffic engineering policy relies on the activation of intra- and inter-domain routing protocols that will have the ability to take into account traffic engineering-related information for the computation and the selection of routes, which will comply as much as possible with the QoS requirements that have been contractually defined between customers and service providers. This traffic engineering-related information is basically composed of metric values that will aim at reflecting an IP TE policy, as well as the result of the enforcement of such a policy, so that customers and providers can check anytime that the IP service is provisioned with the appropriate (and contractual) levels of quality (which can be expressed in terms of service availability, for example). Therefore, the IP TE PIB mainly aims at: - Storing and maintaining the configuration information that will be used by the routers to compute and select the routes that will comply with a collection of QoS requirements, such as the one-way maximum transit delay, or the maximum inter-packet delay variation, - Storing and maintaining the information related to the traffic engineered routes that have been installed in the routers' Forwarding Information Bases, so that the service providers have the permanent knowledge of the network's resources availability. Jacquenet et al. Experimental - Expires Dec. 2002 [Page 5] Internet Draft An IP Traffic Engineering PIB June 2002 From this perspective, the IP TE PIB is currently organized into the following provisioning classes: 1. The Forwarding Classes (ipTeFwClasses): the information contained in these classes is meant to provide a detailed description of the traffic-engineered routes. Only one table is defined at the current stage of this draft: the IP TE Route table which describes the information related to TE routes that have been installed by the routers in their FIBs, 2. The Metrics Classes (ipTeMetricsClasses): the information stored in the tables of this class is meant to provide a description of the metric values that will be taken into account by intra- and inter-domain routing protocols for the computation and the selection of traffic-engineered routes. So far, two groups have been identified: the first group is based upon the traffic engineering extensions of intra-domain routing protocols, the second group is related to QoS-related information that can be conveyed in BGP-4 messages, 3. The Statistics Classes (ipTeStatsClasses): the information contained in these classes is meant to provide statistic on the enforcement of the TE policies. 6. The IP Traffic Engineering Policy Information Base IP-TE-PIB PIB-DEFINITIONS ::= BEGIN IMPORTS Unsigned32, Integer32, MODULE-IDENTITY, MODULE-COMPLIANCE, OBJECT-TYPE, OBJECT-GROUP FROM COPS-PR-SPPI InstanceId, ReferenceId, Prid, TagId FROM COPS-PR-SPPI-TC InetAddress, InetAddressType FROM INET-ADDRESS-MIB Count, TEXTUAL-CONVENTION FROM ACCT-FR-PIB-TC TruthValue, TEXTUAL-CONVENTION FROM SNMPv2-TC RoleCombination, PrcIdentifier FROM FRAMEWORK-ROLE-PIB SnmpAdminString FROM SNMP-FRAMEWORK-MIB; ipTePib MODULE-IDENTITY SUBJECT-CATEGORIES { tbd } -- IP TE client-type to be -- assigned by IANA LAST-UPDATED "200106180900Z" ORGANIZATION "France Telecom" Jacquenet et al. Experimental - Expires Dec. 2002 [Page 6] Internet Draft An IP Traffic Engineering PIB June 2002 CONTACT-INFO " Christian Jacquenet France Telecom R & D 42, rue des Coutures BP 6243 14066 CAEN CEDEX 04 France Phone: +33 2 31 75 94 28 E-Mail: christian.jacquenet@francetelecom.com" DESCRIPTION "The PIB module containing a set of policy rule classes that describe IP Traffic Engineering policies to be enforced within and between domains." REVISION "200111061600Z" DESCRIPTION "Initial version." ::= { pib tbd } -- tbd to be assigned by IANA ipTeFwdClasses OBJECT IDENTIFIER ::= { ipTePib 1 } ipTeMetricsClasses OBJECT IDENTIFIER ::= { ipTePib 2 } ipTeStatsClasses OBJECT IDENTIFIER ::= { ipTePib 3 } -- -- Forwarding classes. The information contained in these classes -- is meant to provide a detailed description of the traffic -- engineered routes. One table has been specified so far, but there -- is room for depicting specific kinds of routes, like MPLS LSP -- paths, for example. -- -- -- -- The ipTeRouteTable -- ipTeRouteTable OBJECT-TYPE SYNTAX SEQUENCE OF ipTeRouteEntry PIB-ACCESS notify STATUS current DESCRIPTION "This table describes the traffic engineered routes that are installed in the forwarding tables of the routers." ::= { ipTeFwdClasses 1 } ipTeRouteEntry OBJECT-TYPE SYNTAX ipTeRouteEntry Jacquenet et al. Experimental - Expires Dec. 2002 [Page 7] Internet Draft An IP Traffic Engineering PIB June 2002 STATUS current DESCRIPTION "A particular traffic engineered route to a particular destination." PIB-INDEX { ipTeRoutePrid } UNIQUENESS { ipTeRouteDest, ipTeRouteMask, ipTeRoutePhbId, ipTeRouteNextHopAddress ipTeRouteNextHopMask ipTeRouteIfIndex } ::= { ipTeRouteTable 1 } ipTeRouteEntry ::= SEQUENCE { ipTeRoutePrid InstanceId, ipTeRouteDestAddrType InetAddressType, ipTeRouteDest InetAddress, ipTeRouteMask Unsigned32, ipTeRouteNextHopAddrType InetAddressType, ipTeRouteNextHopAddress InetAddress, ipTeRouteNextHopMask Unsigned32, ipTeRoutePhbId Integer32, ipTeRouteOrigin Integer32, ipTeRouteIfIndex Unsigned32 } ipTeRoutePrid OBJECT-TYPE SYNTAX InstanceId STATUS current DESCRIPTION "An integer index that uniquely identifies this route entry among all the route entries." ::= { ipTeRouteEntry 1 } ipTeRouteDestAddrType OBJECT-TYPE SYNTAX InetAddressType STATUS current DESCRIPTION "The address type enumeration value ([17]) used to specify the type of a route's destination IP address." ::= { ipTeRouteEntry 2 } ipTeRouteDest OBJECT-TYPE SYNTAX InetAddress STATUS current Jacquenet et al. Experimental - Expires Dec. 2002 [Page 8] Internet Draft An IP Traffic Engineering PIB June 2002 DESCRIPTION "The IP address to match against the packet's destination address." ::= { ipTeRouteEntry 3 } ipTeRouteMask OBJECT-TYPE SYNTAX Unsigned32 (0..128) STATUS current DESCRIPTION "Indicates the length of a mask for the matching of the destination IP address. Masks are constructed by setting bits in sequence from the most-significant bit downwards for ipTeRouteMask bits length. All other bits in the mask, up to the number needed to fill the length of the address ipTeRouteDest are cleared to zero. A zero bit in the mask then means that the corresponding bit in the address always matches."" ::= { ipTeRouteEntry 4 } ipTeRouteNextHopAddrType OBJECT-TYPE SYNTAX InetAddressType STATUS current DESCRIPTION "The address type enumeration value used to specify the type of the next hop's IP address." ::= { ipTeRouteEntry 5 } ipTeRouteNextHopAddress OBJECT-TYPE SYNTAX InetAddress STATUS current DESCRIPTION "On remote routes, the address of the next router en route; Otherwise, 0.0.0.0." ::= { ipTeRouteEntry 6 } ipTeRouteNextHopMask OBJECT-TYPE SYNTAX Unsigned32 (0..128) STATUS current DESCRIPTION "Indicates the length of a mask for the matching of the next hop's IP address. Masks are constructed by setting bits in sequence from the most-significant bit downwards for ipTeRouteNextHopMask bits length. All other bits in the mask, up to the number needed to fill Jacquenet et al. Experimental - Expires Dec. 2002 [Page 9] Internet Draft An IP Traffic Engineering PIB June 2002 the length of the address ipTeRouteNextHop are cleared to zero. A zero bit in the mask then means that the corresponding bit in the address always matches." ::= { ipTeRouteEntry 7 } ipTeRoutePhbId OBJECT-TYPE SYNTAX Integer32 (-1 | 0..63) STATUS current DESCRIPTION "The binary encoding that uniquely identifies a Per Hop Behaviour (PHB, [18]) or a set of PHBs associated to the DiffServ Code Point (DSCP, [15]) marking of the IP datagrams that will be conveyed along this traffic engineered route. A value of -1 indicates that a specific PHB ID value has not been defined, and thus, all PHB ID values are considered a match." ::= { ipTeRouteEntry 8 } ipTeRouteOrigin OBJECT-TYPE SYNTAX INTEGER { OSPF (0) IS-IS (1) BGP (2) STATIC (3) OTHER (4) } STATUS current DESCRIPTION "The value indicates the origin of the route. Either the route has been computed by OSPF, by IS-IS, announced by BGP4, is static, or else." ::= { ipTeRouteEntry 9 } ipTeRouteIfIndex OBJECT-TYPE SYNTAX Unsigned32 (0..65535) STATUS current DESCRIPTION "The ifIndex value that identifies the local interface through which the next hop of this route is accessible." ::= { ipTeRouteEntry 10 } -- -- -- Traffic engineering metrics classes. Jacquenet et al. Experimental - Expires Dec. 2002 [Page 10] Internet Draft An IP Traffic Engineering PIB June 2002 -- -- The information stored in the following tables is meant to provide -- the description of the metric values that will be taken into -- account by intra- and inter-domain routing protocols for the -- computation and the selection of traffic-engineered routes. So -- far, two tables have been identified: one which is based upon the -- traffic engineering extensions of OSPF, the other which is based -- upon the contents of a specific BGP4 attribute. -- -- igpTeGroup OBJECT IDENTIFIER ::= { ipTeMetricsClasses 1 } bgpTeGroup OBJECT IDENTIFIER ::= { ipTeMetricsClasses 2 } -- -- The ospfTeMetricsTable -- ospfTeMetricsTable OBJECT-TYPE SYNTAX SEQUENCE OF ospfTeMetricsEntry PIB-ACCESS install-notify STATUS current DESCRIPTION "This class describes the link and traffic engineering metrics that will be used by OSPF for TE route calculation purposes." ::= { igpTeGroup 1 } ospfTeMetricsEntry OBJECT-TYPE SYNTAX ospfTeMetricsEntry STATUS current DESCRIPTION "The collection of OSPF metrics assigned to the router on a per interface and per DSCP basis." PIB-INDEX { ospfTeMetricsPrid } UNIQUENESS { ospfTeMetricsLinkMetricValue, ospfTeMetricsDscpValue, ospfTeMetricSubTlvLinkType, ospfTeMetricSubTlvLinkId, ospfTeMetricSubTlvLocalIfAddress, ospfTeMetricSubTlvRemoteIfAddress, ospfTeMetricSubTlvTeMetric, ospfTeMetricSubTlvMaxBandwidth, ospfTeMetricSubTlvMaxRsvBandwidth, ospfTeMetricSubTlvUnRsvBandwidth, ospfTeMetricIfIndex } ::= { ospfTeMetricsTable 1 } Jacquenet et al. Experimental - Expires Dec. 2002 [Page 11] Internet Draft An IP Traffic Engineering PIB June 2002 ospfTeMetricsEntry ::= SEQUENCE { ospfTeMetricsPrid InstanceId, ospfTeMetricsIfMetricValue Unsigned32, ospfTeMetricsDscpValue Integer32, ospfTeMetricsTopTlvAddressType InetAddressType, ospfTeMetricsTopTlvRouterAddress InetAddress, ospfTeMetricsTopTlvRouterAddrMask Unsigned32, ospfTeMetricsSubTlvLinkType Unsigned32, ospfTeMetricsSubTlvLinkIdAddressType InetAddressType, ospfTeMetricsSubTlvLinkId InetAddress, ospfTeMetricsSubTlvLinkIdMask Unsigned32, ospfTeMetricsSubTlvLocalIfAddressType InetAddressType, ospfTeMetricsSubTlvLocalIfAddress InetAddress, ospfTeMetricsSubTlvLocalIfAddrMask Unsigned32, ospfTeMetricsSubTlvRemoteIfAddressType InetAddressType, ospfTeMetricsSubTlvRemoteIfAddress InetAddress, ospfTeMetricsSubTlvRemoteIfAddrMask Unsigned32, ospfTeMetricsSubTlvTeMetric Unsigned32, ospfTeMetricsSubTlvMaxBandwidth Unsigned32, ospfTeMetricsSubTlvMaxRsvBandwidth Unsigned32, ospfTeMetricsSubTlvUnrsvBandwidth Unsigned32, ospfTeMetricsSubTlvResourceClass Unsigned32, ospfTeMetricsIfIndex Unsigned32 } ospfTeMetricsPrid OBJECT-TYPE SYNTAX InstanceId STATUS current DESCRIPTION "An integer index that uniquely identifies this instance of the ospfTeMetrics class." ::= { ospfTeMetricsEntry 1 } ospfTeMetricsIfMetricValue OBJECT-TYPE SYNTAX Unsigned32 (1..65535) STATUS current DESCRIPTION "The link metric assigned on a per-DSCP and per-interface basis, as defined in this instance of the ospfTeMetricsTable." ::= { ospfTeMetricsEntry 2 } ospfTeMetricsDscpValue OBJECT-TYPE SYNTAX Integer32 (-1 | 0..63) STATUS current DESCRIPTION Jacquenet et al. Experimental - Expires Dec. 2002 [Page 12] Internet Draft An IP Traffic Engineering PIB June 2002 "The DSCP value associated to the link metric value, as defined in the ospfTeMetricsIfMetricValue object. A value of -1 indicates that a specific DSCP value has not been defined and thus all DSCP values are considered a match." ::= { ospfTeMetricsEntry 3 } ospfTeMetricsTopTlvAddressType OBJECT-TYPE SYNTAX InetAddressType STATUS current DESCRIPTION "The address type enumeration value used to specify the IP address of the advertising router. This IP address is always reachable, and is typically implemented as a "loopback" address." ::= { ospfTeMetricsEntry 4 } ospfTeMetricsTopTlvRouterAddress OBJECT-TYPE SYNTAX InetAddress STATUS current DESCRIPTION "The IP address (typically a "loopback" address) of the advertising router." ::= { ospfTeMetricsEntry 5 } ospfTeMetricsTopTlvRouterAddrMask OBJECT-TYPE SYNTAX Unsigned32 (0..128) STATUS current DESCRIPTION "Indicates the length of a mask for the matching of the advertising router's IP address. Masks are constructed by setting bits in sequence from the most-significant bit downwards for ospfTeMetricsTopTlvRouterAddrMask bits length. All other bits in the mask, up to the number needed to fill the length of the address ospfTeMetricsTopTlvRouterAddress are cleared to zero. A zero bit in the mask then means that the corresponding bit in the address always matches." ::= { ospfTeMetricsEntry 6 } ospfTeMetricsSubTlvLinkType OBJECT-TYPE SYNTAX INTEGER { Point-to-Point (1) Multiaccess (2) } STATUS current Jacquenet et al. Experimental - Expires Dec. 2002 [Page 13] Internet Draft An IP Traffic Engineering PIB June 2002 DESCRIPTION "The type of the link, either point-to-point or multi- access, as defined in [8]." ::= { ospfTeMetricsEntry 7 } ospfTeMetricsSubTlvLinkIdAddressType OBJECT-TYPE SYNTAX InetAddressType STATUS current DESCRIPTION "The address type enumeration value used to identify the other end of the link, described as an IP address." ::= { ospfTeMetricsEntry 8 } ospfTeMetricsSubTlvLinkId OBJECT-TYPE SYNTAX InetAddress STATUS current DESCRIPTION "The identification of the other end of the link, described as an IP address." ::= { ospfTeMetricsEntry 9 } ospfTeMetricsSubTlvLinkMask OBJECT-TYPE SYNTAX Unsigned32 (0..128) STATUS current DESCRIPTION "Indicates the length of a mask for the matching of the other end of the link, described as an IP address. Masks are constructed by setting bits in sequence from the most- significant bit downwards for ospfTeMetricsSubTlvLinkMask bits length. All other bits in the mask, up to the number needed to fill the length of the address ospfTeMetricsSubTlvLinkId are cleared to zero. A zero bit in the mask then means that the corresponding bit in the address always matches." ::= { ospfTeMetricsEntry 10 } ospfTeMetricsSubTlvLocalIfAddressType OBJECT-TYPE SYNTAX InetAddressType STATUS current DESCRIPTION "The address type enumeration value used to specify the IP address of the interface corresponding to this instance of the ospfTeMetricsSubTlvLinkType object." Jacquenet et al. Experimental - Expires Dec. 2002 [Page 14] Internet Draft An IP Traffic Engineering PIB June 2002 ::= { ospfTeMetricsEntry 11 } ospfTeMetricsSubTlvLocalIfAddress OBJECT-TYPE SYNTAX InetAddress STATUS current DESCRIPTION "Specifies the IP address of the interface of the advertising router which is connected to the link described as an instance of the ospfTeMetricsSubTlvLinkType object." ::= { ospfTeMetricsEntry 12 } ospfTeMetricsSubTlvLocalIfAddrMask OBJECT-TYPE SYNTAX Unsigned32 (0..128) STATUS current DESCRIPTION "Indicates the length of a mask for the matching of the IP address of the interface corresponding to this instance of the ospfTeMetricsSubTlvLinkType object. Masks are constructed by setting bits in sequence from the most- significant bit downwards for ospfTeMetricsSubTlvLocalIfAddrMask bits length. All other bits in the mask, up to the number needed to fill the length of the address ospfTeMetricsSubTlvLocalIfAddress are cleared to zero. A zero bit in the mask then means that the corresponding bit in the address always matches." ::= { ospfTeMetricsEntry 13 } ospfTeMetricsSubTlvRemoteIfAddressType OBJECT-TYPE SYNTAX InetAddressType STATUS current DESCRIPTION "The address type enumeration value used to specify the IP address(es) of the neighbour's interface corresponding to this instance of the ospfTeMetricsSubTlvLinkType object." ::= { ospfTeMetricsEntry 14 } ospfTeMetricSubTlvRemoteIfAddress OBJECT-TYPE SYNTAX InetAddress STATUS current DESCRIPTION "Specifies the IP address of the neighbour's interface that is attached to this instance of the ospfTeMetricsSubTlvLinkType object." Jacquenet et al. Experimental - Expires Dec. 2002 [Page 15] Internet Draft An IP Traffic Engineering PIB June 2002 ::= { ospfTeMetricsEntry 15 } ospfTeMetricSubTlvRemoteIfAddrMask OBJECT-TYPE SYNTAX Unsigned32 (0..128) STATUS current DESCRIPTION "Indicates the length of a mask for the matching of the IP address of the neighbor's interface corresponding to this instance of the ospfTeMetricsSubTlvLinkType object. Masks are constructed by setting bits in sequence from the most- significant bit downwards for ospfTeMetricSubTlvRemoteIfAddrMaskbits length. All other bits in the mask, up to the number needed to fill the length of the address ospfTeMetricSubTlvRemoteIfAddress are cleared to zero. A zero bit in the mask then means that the corresponding bit in the address always matches." ::= { ospfTeMetricsEntry 16 } ospfTeMetricSubTlvTeMetric OBJECT-TYPE SYNTAX Unsigned32 (1..65535) STATUS current DESCRIPTION "The link metric that has been assigned for traffic engineering purposes. This metric may be different from the ospfTeMetricsLinkMetricValue object of the ospfTeMetrics class." ::= { ospfTeMetricsEntry 17 } ospfTeMetricSubTlvBandwidthType OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) UNITS "bytes per second" STATUS current DESCRIPTION "Specifies the maximum bandwidth that can be used on this instance of the ospfTeMetricsSubTlvLinkType object in this direction (from the advertising router), expressed in bytes per second." ::= { ospfpTeMetricsEntry 18 } ospfTeMetricSubTlvMaxRsvBandwidth OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) UNITS "bytes per second" STATUS current DESCRIPTION Jacquenet et al. Experimental - Expires Dec. 2002 [Page 16] Internet Draft An IP Traffic Engineering PIB June 2002 "Specifies the maximum bandwidth that may be reserved on this instance of the ospfTeMetricsSubTlvLinkType object in this direction (from the advertising router), expressed in bytes per second." ::= { ospfTeMetricsEntry 19 } ospfTeMetricSubTlvUnrsvBandwidth OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) UNITS "bytes per second" STATUS current DESCRIPTION "Specifies the amount of bandwidth that has not been reserved on this instance of the ospfTeMetricsSubTlvLinkType object in this direction yet (from the advertising router), expressed in bytes per second." ::= { ospfTeMetricsEntry 20 } ospfTeMetricSubTlvResourceClass OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) STATUS current DESCRIPTION "Specifies administrative group membership for the link in terms of a bit mask." ::= { ospfTeMetricsEntry 21 } ospfTeMetricIfIndex OBJECT-TYPE SYNTAX Unsigned32 (0..65535) STATUS current DESCRIPTION "The ifIndex value that identifies the local interface that has been assigned a (set of) metrics." ::= { ospfTeMetricsEntry 22 } -- -- The isisTeMetricsTable -- isisTeMetricsTable OBJECT-TYPE SYNTAX SEQUENCE OF isisTeMetricsEntry PIB-ACCESS install-notify STATUS current DESCRIPTION Jacquenet et al. Experimental - Expires Dec. 2002 [Page 17] Internet Draft An IP Traffic Engineering PIB June 2002 "This class describes the link and traffic engineering metrics that will be used by IS-IS for TE route computation purposes." ::= { igpTeGroup 2 } isisTeMetricsEntry OBJECT-TYPE SYNTAX isisTeMetricsEntry STATUS current DESCRIPTION "The collection of IS-IS metrics assigned to the router on a per interface basis." PIB-INDEX { isisTeMetricsPrid } UNIQUENESS { isisTeMetricsSubTlvIfAddr, isisTeMetricsSubTlvNbrAddr, isisTeMetricSubTlvTeMetric, isisTeMetricsSubTlvMaxLinkBwth, isisTeMetricsSubTlvMaxRsvLinkBwth, isisTeMetricsPriority, isisTeMetricsSubTlvUnRsvBwth, isisTeMetricsIfIndex } ::= { isisTeMetricsTable 1 } isisTeMetricsEntry ::= SEQUENCE { isisTeMetricsPrid InstanceId, isisTeMetricsTlvTeRouterID InetAddress, isisTeMetricsSubTlvIfAddrType InetAddressType, isisTeMetricsSubTlvIfAddr InetAddress, isisTeMetricsSubTlvIfAddrMask Unsigned32, isisTeMetricsSubTlvNbrAddType InetAddressType, isisTeMetricsSubTlvNbrAddr InetAddress, isisTeMetricsSubTlvNbrMask Unsigned32, isisTeMetricsSubTlvTeMetric Unsigned32, isisTeMetricsSubTlvMaxLinkBwth Unsigned32, isisTeMetricsSubTlvMaxRsvLinkBwth Unsigned32, isisTeMetricsPriority Integer32, isisTeMetricsSubTlvUnRsvBwth Unsigned32, isisTeMetricsIfIndex Unsigned32 } isisTeMetricsPrid OBJECT-TYPE SYNTAX InstanceId STATUS current DESCRIPTION "An integer index that uniquely identifies this instance of the isisTeMetrics class." Jacquenet et al. Experimental - Expires Dec. 2002 [Page 18] Internet Draft An IP Traffic Engineering PIB June 2002 ::= { isisTeMetricsEntry 1 } isisTeMetricsTlvTeRouterID OBJECT-TYPE SYNTAX InetAddress STATUS current DESCRIPTION "Specifies the router ID." ::= { isisTeMetricsEntry 2 } isisTeMetricsSubTlvIfAddrType OBJECT-TYPE SYNTAX InetAddressType STATUS current DESCRIPTION "The address type enumeration value used to specify the type of the interface IP address." ::= { isisTeMetricsEntry 3 } isisTeMetricsSubTlvIfAddr OBJECT-TYPE SYNTAX InetAddress STATUS current DESCRIPTION "Specifies the IP address of the interface." ::= { isisTeMetricsEntry 4 } isisTeMetricsSubTlvIfAddrMask OBJECT-TYPE SYNTAX Unsigned32 (0..128) STATUS current DESCRIPTION "Indicates the length of a mask for the matching of the IP address of the neighbouring router. Masks are constructed by setting bits in sequence from the most significant bit downwards for isisTeMetricsSubTlvIfAddrMask bits length. All other bits in the mask, up to the number needed to fill the length of the address isisTeMetricsSubTlvIfAddr are cleared to zero. A zero bit in the mask then means that the corresponding bit in the address always matches." ::= { isisTeMetricsEntry 5 } isisTeMetricsSubTlvNbrAddrType OBJECT-TYPE SYNTAX InetAddressType STATUS current DESCRIPTION Jacquenet et al. Experimental - Expires Dec. 2002 [Page 19] Internet Draft An IP Traffic Engineering PIB June 2002 "The address type enumeration value used to specify the type of the neighbouring router's IP address." ::= { isisTeMetricsEntry 6 } isisTeMetricsSubTlvNbrAddr OBJECT-TYPE SYNTAX InetAddress STATUS current DESCRIPTION "Specifies the IP address of the neighbouring router on the link the corresponding interface (defined by the ifIndex) is attached to." ::= { isisTeMetricsEntry 7 } isisTeMetricsSubTlvNbrMask OBJECT-TYPE SYNTAX Unsigned32 (0..128) STATUS current DESCRIPTION "Indicates the length of a mask for the matching of the IP address of the neighbouring router. Masks are constructed by setting bits in sequence from the most significant bit downwards for isisTeMetricsSubTlvNbrMask bits length. All other bits in the mask, up to the number needed to fill the length of the address isisTeMetricsSubTlvNbrAddr are cleared to zero. A zero bit in the mask then means that the corresponding bit in the address always matches." ::= { isisTeMetricsEntry 8 } isisTeMetricsSubTlvTeMetric OBJECT-TYPE SYNTAX Unsigned32 (1..65535) STATUS current DESCRIPTION "The traffic engineering default metric is used to present a differently weighted topology to TE-based SPF computations." ::= { isisTeMetricsEntry 9 } isisTeMetricsSubTlvMaxLinkBwth OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) UNITS "bytes per second" STATUS current DESCRIPTION "This metric specifies the maximum bandwidth that can be used on this link in this direction." ::= { isisTeMetricsEntry 10 } Jacquenet et al. Experimental - Expires Dec. 2002 [Page 20] Internet Draft An IP Traffic Engineering PIB June 2002 isisTeMetricsSubTlvMaxRsvLinkBwth OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) UNITS "bytes per second" STATUS current DESCRIPTION "Specifies the maximum bandwidth that may be reserved on this link in this direction, expressed in bytes per second." ::= { isisTeMetricsEntry 11 } isisTeMetricsPriority OBJECT-TYPE SYNTAX Integer32 (0..7) STATUS current DESCRIPTION "Specifies one of the eight priority levels, possible values ranging from 0 and 7." ::= { isisTeMetricsEntry 12} isisTeMetricsSubTlvUnRsvBwth OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) UNITS "bytes per second" STATUS current DESCRIPTION "Specifies the amount of bandwidth that has not been reserved on this link in this direction and having the priority isisTeMetricsPriority, expressed in bytes per second." ::= { isisTeMetricsEntry 13 } isisTeMetricsIfIndex OBJECT-TYPE SYNTAX Unsigned32 (0..65535) STATUS current DESCRIPTION "The ifIndex value that uniquely identifies the interface that has been assigned a (set of) metrics." ::= { isisTeMetricsEntry 14 } -- -- The bgpTeTable -- bgpTeTable OBJECT-TYPE Jacquenet et al. Experimental - Expires Dec. 2002 [Page 21] Internet Draft An IP Traffic Engineering PIB June 2002 SYNTAX SEQUENCE OF bgpTeEntry PIB-ACCESS install-notify STATUS current DESCRIPTION "This class describes the QoS information that MAY be conveyed in BGP4 UPDATE messages for the purpose of enforcing an inter-domain traffic engineering policy." ::= { bgpTeGroup 1 } bgpTeEntry OBJECT-TYPE SYNTAX bgpTeEntry STATUS current DESCRIPTION "The collection of QoS information to be exchanged by BGP peers, as far as the announcement of traffic engineered routes between domains is concerned." PIB-INDEX { bgpTePrid } UNIQUENESS { bgpTeNlriAddress, bgpTeNextHopAddress, bgpTeReservedRate, bgpTeAvailableRate, bgpTeLossRate, bgpTePhbId, bgpTeMinOneWayDelay, bgpTeMaxOneWayDelay, bgpTeAverageOneWayDelay, bgpTeInterPacketDelay } ::= { bgpTeTable 1 } bgpTeEntry ::= SEQUENCE { bgpTePrid InstanceId, bgpTeNlriAddressType InetAddressType, bgpTeNlriAddress InetAddress, bgpTeNlriAddressMask Unsigned32, bgpTeNextHopAddressType InetAddressType, bgpTeNextHopAddress InetAddress, bgpTeNextHopMask Unsigned32, bgpTeReservedRate Unsigned32, bgpTeAvailableRate Unsigned32, bgpTeLossRate Unsigned32, bgpTePhbId Integer32, bgpTeMinOneWayDelay Unsigned32, bgpTeMaxOneWayDelay Unsigned32, bgpTeAverageOneWayDelay Unsigned32, bgpTeInterPacketDelay Unsigned32 } Jacquenet et al. Experimental - Expires Dec. 2002 [Page 22] Internet Draft An IP Traffic Engineering PIB June 2002 bgpTePrid OBJECT-TYPE SYNTAX InstanceId STATUS current DESCRIPTION "An integer index that uniquely identifies this instance of the bgpTeTable class." ::= { bgpTeEntry 1 } bgpTeNlriAddressType OBJECT-TYPE SYNTAX InetAddressType STATUS current DESCRIPTION "The address type enumeration value used to specify the type of a route's destination IP address." ::= { bgpTeEntry 2 } bgpTeNlriAddress OBJECT-TYPE SYNTAX InetAddress STATUS current DESCRIPTION "The IP address to match against the NLRI field of the QOS_NLRI attribute of the BGP4 UPDATE message." ::= { bgpTeEntry 3 } bgpTeNlriAddressMask OBJECT-TYPE SYNTAX Unsigned32 (0..128) STATUS current DESCRIPTION "Indicates the length of a mask for the matching of the NLRI field of the QOS_NLRI attribute of the BGP4 UPDATE message. Masks are constructed by setting bits in sequence from the most-significant bit downwards for bgpTeNlriMask bits length. All other bits in the mask, up to the number needed to fill the length of the address bgpTeNlri are cleared to zero. A zero bit in the mask then means that the corresponding bit in the address always matches."" ::= { bgpTeEntry 4 } bgpTeNextHopAddressType OBJECT-TYPE SYNTAX InetAddressType STATUS current DESCRIPTION Jacquenet et al. Experimental - Expires Dec. 2002 [Page 23] Internet Draft An IP Traffic Engineering PIB June 2002 "The address type enumeration value used to specify the type of the next hop's IP address." ::= { bgpTeEntry 5 } bgpTeNextHopAddress OBJECT-TYPE SYNTAX InetAddress STATUS current DESCRIPTION "On remote routes, the address of the next router en route; Otherwise, 0.0.0.0." ::= { bgpTeEntry 6 } bgpTeNextHopMask OBJECT-TYPE SYNTAX Unsigned32 (0..128) STATUS current DESCRIPTION "Indicates the length of a mask for the matching of the next hop's IP address. Masks are constructed by setting bits in sequence from the most-significant bit downwards for bgpTeNextHopMask bits length. All other bits in the mask, up to the number needed to fill the length of the address bgpTeNextHopAddress are cleared to zero. A zero bit in the mask then means that the corresponding bit in the address always matches." ::= { bgpTeEntry 7 } bgpTeReservedRate OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) UNITS "kilobits per second" STATUS current DESCRIPTION "Specifies the reserved rate that cannot be used on this instance of the bgpTeNlriAddress object in this direction (from the advertising BGP peer), expressed in kilobits per second." ::= { bgpTeEntry 8 } bgpTeAvailableRate OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) UNITS "kilobits per second" STATUS current DESCRIPTION "Specifies the available rate that may be reserved on this instance of the bgpTeNlriAddress object in this direction Jacquenet et al. Experimental - Expires Dec. 2002 [Page 24] Internet Draft An IP Traffic Engineering PIB June 2002 (from the advertising BGP peer), expressed in kilobits per second." ::= { bgpTeEntry 9 } bgpTeLossRate OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) STATUS current DESCRIPTION "Specifies the packet loss ratio that has been observed on this route instantiated by the bgpTeNlriAddress object." ::= { bgpTeEntry 10 } bgpTePhbId OBJECT-TYPE SYNTAX Integer32 (-1 | 0..63) STATUS current DESCRIPTION "The binary encoding that uniquely identifies a Per Hop Behaviour (PHB) or a set of PHBs associated to the DiffServ Code Point marking of the IP datagrams that are to be conveyed along this traffic engineered route. A value of -1 indicates that a specific PHB ID value has not been defined, and thus, all PHB ID values are considered a match." ::= { bgpTeEntry 11 } bgpTeMinOneWayDelay OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) UNITS "milliseconds" STATUS current DESCRIPTION "Specifies the minimum one-way delay that has been observed on this route instantiated by the bgpTeNlriAddress object, expressed in milliseconds." ::= { bgpTeEntry 12 } bgpTeMaxOneWayDelay OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) UNITS "milliseconds" STATUS current DESCRIPTION "Specifies the maximum one-way delay that has been observed on this route instantiated by the bgpTeNlriAddress object, expressed in milliseconds." Jacquenet et al. Experimental - Expires Dec. 2002 [Page 25] Internet Draft An IP Traffic Engineering PIB June 2002 ::= { bgpTeEntry 13 } bgpTeAverageOneWayDelay OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) UNITS "milliseconds" STATUS current DESCRIPTION "Specifies the average one-way delay that has been observed on this route instantiated by the bgpTeNlriAddress object, expressed in milliseconds." ::= { bgpTeEntry 14 } bgpTeInterPacketDelay OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) UNITS "milliseconds" STATUS current DESCRIPTION "Specifies the inter-packet delay variation that has been observed on this route instantiated by the bgpTeNlriAddress object." ::= { bgpTeEntry 15 } -- -- Traffic engineering statistics classes. The information contained -- in the yet-to-be defined tables aim at reporting statistics about -- COPS control traffic, engineered traffic and potential errors. The -- next version of the draft will provide a first table that will be -- based upon the use of the "count" clause. -- -- END 7. Security Considerations The traffic engineering policy provisioning data as they are described in this PIB will be used for configuring the appropriate network elements that will be involved in the dynamic enforcement of these traffic engineering policies, by means of a COPS-PR communication that will convey this information. The function of dynamically provisioning network elements with such configuration information implies that only an authorized COPS-PR communication take place. From this perspective, this draft does not introduce any additional security issues other than those that have been identified in the COPS-PR specification, and it is therefore recommended that the IPSec Jacquenet et al. Experimental - Expires Dec. 2002 [Page 26] Internet Draft An IP Traffic Engineering PIB June 2002 ([19]) protocol suite be used to secure the above-mentioned authorized communication. 8. References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] Ho Chan, K., Durham, D., Gai, S., Herzog, S., McLoghrie, K., Reichmeyer, F., Seligson, J., Smith, A., Yavatkar, R., "COPS Usage for Policy Provisioning (COPS-PR)", RFC 3084, March 2001. [3] Jacquenet, C., "A COPS Client-Type for IP Traffic Engineering", draft-jacquenet-ip-te-cops-03.txt, Work in Progress, June 2002. [4] Fine, M., et al., "Framework Policy Information Base", draft- ietf-rap-frameworkpib-07.txt, Work in Progress, January 2002. [5] Goderis, D., T'Joens, Y., Jacquenet, C., Memenios, G., Pavlou, G., Egan, R., Griffin, D., Georgatsos, P., Georgiadis, L., "Specification of a Service Level Specification (SLS) Template", draft-tequila-sls-02.txt, Work in Progress, February 2002. Check http://www.ist-tequila.org for additional information. [6] Moy J.,"OSPF Version 2", RFC 2328, April 1998. [7] Rekhter Y., Li T., "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995. [8] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering Extensions to OSPF", draft-katz-yeung-ospf-traffic-06.txt, Work in Progress, October 2001. [9] Smit, H., Li, T., "IS-IS Extensions for Traffic Engineering", draft-ietf-isis-traffic-04.txt, Work in Progress, August 2001. [10] ISO/IEC 10589, "Intermediate System to Intermediate System, Intra-Domain Routing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)", June 1992. [11] Jacquenet, C., "Providing Quality of Service Indication by the BGP-4 Protocol: the QOS_NLRI Attribute", draft-jacquenet-qos- nrli-04.txt, Work in Progress, March 2002. [12] Moore, B. et al., "Policy Core Information Model -- Version 1 Specification", RFC 3060, February 2001. [13] McLoghrie, K., et al., "Structure of Policy Provisioning Information (SPPI)", RFC 3159, August 2001. [14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [15] Case, J., et al., "A Simple Network Management Protocol", RFC 1157, May 1990. [16] Guerin, R., et al., "QoS Routing Mechanisms and OSPF Extensions", RFC 2676, August 1999. [17] Daniele, M., Haberman, B., Routhier, S., Schoenwaelder, J., "Textual Conventions for Internet Network Addresses", RFC 3291, May 2002. [18] Black, D., Brim, S., Carpenter, B., Le Faucheur, F., "Per Hop Behaviour Identification Codes", RFC 3140, June 2001. Jacquenet et al. Experimental - Expires Dec. 2002 [Page 27] Internet Draft An IP Traffic Engineering PIB June 2002 [19] Kent, S., Atkinson, R., "Security Architecture for the Internet Protocol", RFC 2401, November 1998. 9. Acknowledgments Part of this work is funded by the European Commission, within the context of the TEQUILA (Traffic Engineering for Quality of Service in the Internet At Large Scale, [5]) project, which is itself part of the IST (Information Society Technologies) research program. The author would also like to thank all the partners of the TEQUILA project for the fruitful discussions that have been conducted so far within the context of the traffic engineering specification effort of the project. 10. Authors' Addresses Mohamed Boucadair, Christian Jacquenet France Telecom R & D DMI/SIR 42, rue des Coutures BP 6243 14066 Caen Cedex 4 France Phone: +33 2 31 75 94 28 Email: {mohamed.boucadair, christian.jacquenet}@rd.francetelecom.com Full Copyright Statement Copyright (C) The Internet Society (2002). 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 its implementation may be prepared, coed, 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. Jacquenet et al. Experimental - Expires Dec. 2002 [Page 28] Internet Draft An IP Traffic Engineering PIB June 2002 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. Jacquenet et al. Experimental - Expires Dec. 2002 [Page 29]