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
                    <draft-jacquenet-ip-te-pib-00.txt>


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]