Network Working Group C. Jacquenet Internet Draft France Telecom R&D Document: draft-jacquenet-ip-te-pib-00.txt June 2001 Category: Experimental Expires December 2001 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 will complement the PRC classes that have been defined in the Framework PIB ([4]). 1. Introduction The deployment of value-added IP services (like QoS (Quality of Service)-based IP Virtual Private Networks) over the Internet has become one of the most competing challenges for service providers, as well as a complex technical issue, as far as the appropriate provisioning and usage of the resources of the IP networks is concerned. Jacquenet Experimental - Expires December 2001 [Page 1] Internet Draft An IP Traffic Engineering PIB June 2001 From this standpoint, the COPS protocol and its usage for the support of Policy Provisioning ([2]) is one of the ongoing specification effort of the Resource Allocation Protocol (rap) Working Group of the IETF that should help service providers in dynamically enforcing an IP Traffic Engineering (IP TE) policy which happens to be one the key components to service customers according to the contents of the contractual agreements they have signed with their service provider(s). Indeed, the enforcement of an IP traffic engineering policy is based upon the use 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. As such, an IP traffic engineering policy (partly) 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]). 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 ([6], [7]) that will be activated in the network to appropriately 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 exactly reflect these QoS requirements, given the dynamic routing protocols support traffic engineering capabilities for the calculation and the selection of such routes. These capabilities are currently being specified in [8] and [9] for the OSPF (Open Shortest Path First, [5]) and the IS-IS (Intermediate System to Intermediate System routing protocol, [10]) interior routing protocols respectively, while there is an equivalent and ongoing specification effort for the BGP4 (Border Gateway Protocol, version 4) protocol, as described in [11], for example. To provide the route selection processes with the above-mentioned information, one possibility is to use the COPS protocol and its usage for policy provisioning, together with a collection of provisioning data that will be stored in a virtual information store, called a Policy Information Base. Jacquenet Experimental - Expires December 2001 [Page 2] Internet Draft An IP Traffic Engineering PIB June 2001 This draft describes a collection of Policy Rule Classes that are based upon the use of above-mentioned extensions to existing IP routing protocols - namely the OSPF and the BGP4 protocols, and which 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 3 introduces some considerations about the scalability of such a dynamic provisioning scheme, - Section 4 provides an overview of the organization of the IP TE PIB, - Section 5 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. Scalability considerations The usage of the COPS-PR protocol for the dynamic enforcement of an IP traffic engineering policy that would be based upon the use of traffic engineering extensions to IP routing protocols naturally raises the scalability issue, 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. 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 dynamic reports related to the actual enforcement of decisions taken by the PDP, deserve some elaboration. 3.1. A tentative metric taxonomy The metrics that will be taken into account by the SPF algorithms for IP TE route calculation can be classified into two basic categories: 1. Permanently assigned metrics, which basically consist of the "usual" cost metrics, as per [6]. These metrics are those that are assigned on a per (logical) interface basis, and they aim at reflecting the link quality the corresponding interface is Jacquenet Experimental - Expires December 2001 [Page 3] Internet Draft An IP Traffic Engineering PIB June 2001 attached to. Such metrics can also be derived on a per-DSCP basis, so that a given interface will be assigned different costs, depending on the value of the DS field, 2. Dynamically assigned metrics, which MAY consist of the following information: - The available bandwidth, (e.g. based upon the SNMP (Simple Network Management Protocol) variables like ifType, ifInOctets and ifOutOctets), - The amount of bandwidth that can be reserved, according to arithmetic calculation based upon the above-mentioned variables, for example, - The amount of reserved bandwidth, according to the information maintained in the PIB. While statically assigned metric values should not change frequently by definition (because they reflect the physical resources of the network as they are available, as well as the generic routing policy that has been defined by the network administrator to reflect how such resources will be used), the dynamically assigned metric values MAY vary like the ongoing usage of the resources of the network. Therefore, the static or dynamic computation of dynamically assigned metric values is in the magnitude of the corresponding SPF computation, since newly assigned values yield the spontaneous generation of LSU (Link State Update, [6]) messages. Hence, the IP traffic engineering provisioning data exchange SHOULD be minimized according to pre-computation engineering recommendations like those described in [15]. 3.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 above-mentioned requirements, without any extra computation (within the context of [5], for example). From this perspective, the report of the installed routes is in the magnitude of the route announcement procedures of the IP routing protocols machineries (like OSPF), and it is therefore 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. Jacquenet Experimental - Expires December 2001 [Page 4] Internet Draft An IP Traffic Engineering PIB June 2001 In other words, this draft assumes that it is mainly the responsibility of deploying an IP traffic engineering policy that should raise scalability issues, NOT the choice of activating the COPS-PR protocol as a means to convey the IP TE provisioning data that will reflect such a deployment. Nevertheless, it is obviously one of the most important concerns of the ongoing specification and development effort that is partly reflected by this draft, and which is further described in [5]. In particular, it is the intention of the author 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. 4. PIB Overview The dynamic enforcement of an IP traffic engineering policy is based upon the activation of intra- and inter-domain routing protocols that will have the ability to take into account traffic engineering- related information for the calculation 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 (as they have been depicted in [8] for the traffic engineering extensions to the OSPF protocol, for example) 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 automation (which can be expressed in terms of accessing the service, for example) and 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 calculate 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. From this perspective, the IP TE PIB is currently organized into the following provisioning classes: Jacquenet Experimental - Expires December 2001 [Page 5] Internet Draft An IP Traffic Engineering PIB June 2001 1. The OSPF TE Metrics Table: this class represents the collection of provisioning data that will reflect a specific intra-domain routing policy, in terms of TE metric value assignment, 2. The BGP TE Table: this class aims at depicting the BGP routes that have been announced by the routers with associated QoS information, 3. The IP TE Route Table: this class describes the information related to the traffic engineered routes that have been installed by the routers in their FIB bases, according to the traffic engineering policy they will have to enforce. 5. The IP Traffic Engineering Policy Information Base IP-TE-PIB PIB-DEFINITIONS ::= BEGIN IMPORTS Unsigned32, Integer32, MODULE-ENTITY, 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 CLIENT-TYPE { ipTe client-type } LAST-UPDATED "200118060900Z" ORGANIZATION "France Telecom" 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 Jacquenet Experimental - Expires December 2001 [Page 6] Internet Draft An IP Traffic Engineering PIB June 2001 "The PIB module containing a set of policy rule classes that describe IP Traffic Engineering policies to be enforced within and between domains." ::= { tbd } ipTeRouteTable OBJECT-IDENTIFIER ::= { ipTePib 1 } ospfTeMetricsTable OBJECT-IDENTIFIER ::= { ipTePib 2 } bgpTeTable OBJECT-IDENTIFIER ::= { ipTePib 3 } -- -- The ipTeRouteTable -- ipTeRouteTable OBJECT-TYPE SYNTAX SEQUENCE OF ipTeRouteEntry PIB-ACCESS notify STATUS current DESCRIPTION "This class describes the traffic engineered routes that are installed in the forwarding tables of the routers." ::= { ipTePib 1 } ipTeRouteEntry OBJECT-TYPE SYNTAX ipTeRouteEntry STATUS current DESCRIPTION "A particular traffic engineered route to a particular destination." PIB-INDEX { ipTeRoutePrid } UNIQUENESS { ipTeRouteDest, ipTeRouteMask, ipTeRoutePhbId, ipTeRouteNextHopAddress ipTeRouteNextHopMask } ::= { ipTeRouteTable 1 } ipTeRouteEntry ::= SEQUENCE { ipTeRoutePrid InstanceId, ipTeRouteDestAddrType InetAddressType, ipTeRouteDest InetAddress, ipTeRouteMask Unsigned32, ipTeRouteNextHopAddrType InetAddressType, ipTeRouteNextHopAddress InetAddress, ipTeRouteNextHopMask Unsigned32, ipTeRoutePhbId Integer32, Jacquenet Experimental - Expires December 2001 [Page 7] Internet Draft An IP Traffic Engineering PIB June 2001 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 ([16]) used to specify the type of a route's destination IP address." ::= { ipTeRouteEntry 2 } ipTeRouteDest OBJECT-TYPE SYNTAX InetAddress STATUS current 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 Jacquenet Experimental - Expires December 2001 [Page 8] Internet Draft An IP Traffic Engineering PIB June 2001 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 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, [17]) 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 { Jacquenet Experimental - Expires December 2001 [Page 9] Internet Draft An IP Traffic Engineering PIB June 2001 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 } -- -- 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." ::= { ipTePib 2 } 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, Jacquenet Experimental - Expires December 2001 [Page 10] Internet Draft An IP Traffic Engineering PIB June 2001 ospfTeMetricSubTlvLinkType, ospfTeMetricSubTlvLinkId, ospfTeMetricSubTlvLocalIfAddress, ospfTeMetricSubTlvRemoteIfAddress, ospfTeMetricSubTlvTeMetric, ospfTeMetricSubTlvMaxBandwidth, ospfTeMetricSubTlvMaxRsvBandwidth, ospfTeMetricSubTlvUnRsvBandwidth, ospfTeMetricIfIndex } ::= { ospfTeMetricsTable 1 } 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, 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 Jacquenet Experimental - Expires December 2001 [Page 11] Internet Draft An IP Traffic Engineering PIB June 2001 "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 "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 Jacquenet Experimental - Expires December 2001 [Page 12] Internet Draft An IP Traffic Engineering PIB June 2001 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) Multi-Link (2) } STATUS current 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." Jacquenet Experimental - Expires December 2001 [Page 13] Internet Draft An IP Traffic Engineering PIB June 2001 ::= { 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." ::= { 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." Jacquenet Experimental - Expires December 2001 [Page 14] Internet Draft An IP Traffic Engineering PIB June 2001 ::= { 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." ::= { 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) STATUS current DESCRIPTION "Specifies the maximum bandwidth that can be used on this instance of the ospfTeMetricsSubTlvLinkType object in this Jacquenet Experimental - Expires December 2001 [Page 15] Internet Draft An IP Traffic Engineering PIB June 2001 direction (from the advertising router), expressed in bytes per second." ::= { ospfpTeMetricsEntry 18 } ospfTeMetricSubTlvMaxRsvBandwidth OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) STATUS current DESCRIPTION "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) 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 } 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 21 } -- -- The bgpTeTable -- bgpTeTable OBJECT-TYPE 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." Jacquenet Experimental - Expires December 2001 [Page 16] Internet Draft An IP Traffic Engineering PIB June 2001 ::= { ipTePib 3 } 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 InetAddress, bgpTeNextHopAddressType InetAddressType, bgpTeNextHopAddress InetAddress, bgpTeNextHopMask InetAddress, bgpTeReservedRate Unsigned32, bgpTeAvailableRate Unsigned32, bgpTeLossRate Unsigned32, bgpTePhbId Integer32, bgpTeMinOneWayDelay Unsigned32, bgpTeMaxOneWayDelay Unsigned32, bgpTeAverageOneWayDelay Unsigned32, bgpTeInterPacketDelay Unsigned32 } bgpTePrid OBJECT-TYPE SYNTAX InstanceId STATUS current DESCRIPTION "An integer index that uniquely identifies this instance of the bgpTe class." Jacquenet Experimental - Expires December 2001 [Page 17] Internet Draft An IP Traffic Engineering PIB June 2001 ::= { bgpTeEntry 1 } bgpTeNlriAddressType OBJECT-TYPE SYNTAX InetAddressType STATUS current DESCRIPTION "The address type enumeration value ([18]) 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 "The address type enumeration value used to specify the type of the next hop's IP address." ::= { bgpTeEntry 5 } bgpTeNextHopAddress OBJECT-TYPE Jacquenet Experimental - Expires December 2001 [Page 18] Internet Draft An IP Traffic Engineering PIB June 2001 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) 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 bytes per second." ::= { bgpTeEntry 8 } bgpTeAvailableRate OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) STATUS current DESCRIPTION "Specifies the available rate that may be reserved on this instance of the bgpTeNlriAddress object in this direction (from the advertising BGP peer), expressed in bytes per second." ::= { bgpTeEntry 9 } bgpTeLossRate OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) STATUS current Jacquenet Experimental - Expires December 2001 [Page 19] Internet Draft An IP Traffic Engineering PIB June 2001 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, [19]) 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) 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) STATUS current DESCRIPTION "Specifies the maximum one-way delay that has been observed on this route instantiated by the bgpTeNlriAddress object, expressed in milliseconds." ::= { bgpTeEntry 13 } bgpTeAverageOneWayDelay OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) STATUS current DESCRIPTION "Specifies the average one-way delay that has been observed on this route instantiated by the bgpTeNlriAddress object, expressed in milliseconds." Jacquenet Experimental - Expires December 2001 [Page 20] Internet Draft An IP Traffic Engineering PIB June 2001 ::= { bgpTeEntry 14 } bgpTeInterPacketDelay OBJECT-TYPE SYNTAX Unsigned32 (0..4294967295) STATUS current DESCRIPTION "Specifies the inter-packet delay variation that has been observed on this route instantiated by the bgpTeNlriAddress object." ::= { bgpTeEntry 15 } END 6. 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 ([20]) protocol suite be used to secure the above-mentioned authorized communication. 7. 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-01.txt, Work in Progress, February 2001. [4] Fine, M., et al., "Framework Policy Information Base", draft- ietf-rap-frameworkpib-04.txt, Work in Progress, March 2001. [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-00.txt, Work in Progress, November 2000. Check http://www.ist-tequila.org for additional information. Jacquenet Experimental - Expires December 2001 [Page 21] Internet Draft An IP Traffic Engineering PIB June 2001 [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-04.txt, Work in Progress, February 2001. [9] Smit, H., Li, T., "IS-IS Extensions for Traffic Engineering", draft-ietf-isis-traffic-02.txt, Work in Progress, September 2000. [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-01.txt, Work in Progress, February 2001. [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)", draft-ietf-rap-sppi-07.txt, Work in Progress, May 2001. [14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [15] Guerin, R., et al., "QoS Routing Mechanisms and OSPF Extensions", RFC 2676, August 1999. [16] Daniele, M., Haberman, B., Routhier, S., Schoenwaelder, J., "Textual Conventions for Internet Network Addresses", RFC 2851, June 2000. [17] Black, D., Brim, S., Carpenter, B., Le Faucheur, F., "Per Hop Behaviour Identification Codes", draft-ietf-diffserv-2836bis- 02.txt, Work in Progress, May 2001. [18] Daniele, M., Haberman, B., Routhier, S., Schoenwaelder, J., "Textual Conventions for Internet Network Addresses", RFC 2851, June 2000. [19] Black, D., Brim, S., Carpenter, B., Le Faucheur, F., "Per Hop Behaviour Identification Codes", draft-ietf-diffserv-2836bis- 02.txt, Work in Progress, May 2001. [20] Kent, S., Atkinson, R., "Security Architecture for the Internet Protocol", RFC 2401, November 1998. 8. 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. Jacquenet Experimental - Expires December 2001 [Page 22] Internet Draft An IP Traffic Engineering PIB June 2001 9. Author's Addresses 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: christian.jacquenet@francetelecom.com Full Copyright Statement 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 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. 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 Experimental - Expires December 2001 [Page 23]