idnits 2.17.1 draft-jacquenet-ip-te-pib-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 42 characters in excess of 72. ** The abstract seems to contain references ([2], [3], [4]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 2002) is 7803 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-jacquenet-ip-te-cops-03 == Outdated reference: A later version (-09) exists of draft-ietf-rap-frameworkpib-07 == Outdated reference: A later version (-03) exists of draft-tequila-sls-02 ** Obsolete normative reference: RFC 1771 (ref. '7') (Obsoleted by RFC 4271) == Outdated reference: A later version (-10) exists of draft-katz-yeung-ospf-traffic-06 == Outdated reference: A later version (-05) exists of draft-ietf-isis-traffic-04 -- No information found for draft-jacquenet-qos-nrli - is the name correct? ** Obsolete normative reference: RFC 3291 (ref. '17') (Obsoleted by RFC 4001) ** Obsolete normative reference: RFC 2401 (ref. '19') (Obsoleted by RFC 4301) Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Boucadair 3 Internet Draft C. Jacquenet 4 Document: draft-jacquenet-ip-te-pib-02.txt France Telecom R&D 5 Category: Experimental June 2002 6 Expires December 2002 8 An IP Traffic Engineering Policy Information Base 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC 2026 [1]. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress". 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This draft specifies a set of Policy Rule Classes (PRC) for the 33 enforcement of an IP traffic engineering policy by COPS-PR ([2])- 34 capable routers. Instances of such classes reside in a virtual 35 information store, which is called the IP Traffic Engineering Policy 36 Information Base (IP TE PIB). The corresponding IP TE policy 37 provisioning data are intended for use by the COPS-PR IP TE Client- 38 Type([3]), and they complement the PRC classes that have been defined 39 in the Framework PIB ([4]). 41 Table of Contents 43 1. Introduction................................................2 44 2. Conventions used in this document...........................3 45 3. Changes since the previous version..........................3 46 4. Scalability considerations..................................3 47 4.1. A tentative metric taxonomy.................................4 48 4.2. Reporting the enforcement of an IP traffic engineering 49 policy....................................................4 50 5. PIB Overview................................................5 51 6. The IP Traffic Engineering Policy Information Base..........6 52 7. Security Considerations....................................26 53 8. References.................................................27 54 9. Acknowledgments............................................28 55 10. Authors' Addresses.........................................28 57 1. Introduction 59 The deployment of value-added IP services over the Internet has 60 become one of the most competing challenges for service providers, as 61 well as a complex technical issue. 63 Within the context of network resource provisioning and allocation, 64 the COPS protocol and its usage for the support of Policy 65 Provisioning is one of the ongoing specification efforts of the 66 Resource Allocation Protocol (rap) Working Group of the IETF that 67 should help service providers in dynamically enforcing IP Traffic 68 Engineering (IP TE) policies. 70 An IP traffic engineering policy consists in appropriately 71 provisioning, and allocating/de-allocating, the switching and the 72 transmission resources of an IP network (i.e. the routers and the 73 links that connect these routers, respectively), according to Quality 74 of Service (QoS) requirements (e.g. rate, one-way delay, inter-packet 75 delay variation, etc.) that have been expressed by the customers who 76 can access such resources within the context of a given service 77 subscription procedure ([5]). 79 Thus, the enforcement of an IP traffic engineering policy yields the 80 introduction of a high level of automation for the dynamic 81 provisioning of the configuration data that will be taken into 82 account by the routers to select the appropriate IP routes. 84 Within the context of this document, the actual enforcement of an IP 85 traffic engineering policy is primarily based upon the activation of 86 both intra- and inter-domain dynamic routing protocols (e.g. [6], 87 [7]) that will be activated in the network to select, install, 88 maintain and possibly withdraw routes that will comply with the 89 above-mentioned QoS requirements and/or specific routing constraints, 90 depending on the type of traffic that will be conveyed along these 91 traffic engineered routes. 93 It is therefore necessary to provide the route selection processes 94 with the information that will reflect these QoS requirements, given 95 the dynamic routing protocols support traffic engineering 96 capabilities for the computation of such routes. 98 Some of these capabilities are currently being specified in [8] and 99 [9] for the OSPF (Open Shortest Path First, [6]) and the IS-IS 100 (Intermediate System to Intermediate System routing protocol, [10]) 101 interior routing protocols respectively, while there is a comparable 102 effort for the BGP4 (Border Gateway Protocol, version 4) protocol, as 103 described in [11], for example. 105 To provide the route selection processes with the aforementioned 106 information, one possibility is to use the COPS-PR protocol, together 107 with a collection of policy provisioning data that will be stored in 108 a virtual information store, called a Policy Information Base. 110 This draft describes a collection of Policy Rule Classes that will be 111 stored and dynamically maintained in the IP TE PIB. The "rule" and 112 "role" concepts, which have been defined in [12], are adopted by this 113 document to distribute the IP traffic engineering policy provisioning 114 data over the COPS-PR protocol. 116 This document is organized as follows: 118 - Section 4 introduces some considerations about the scalability of 119 such a dynamic provisioning scheme, 121 - Section 5 provides an overview of the organization of the IP TE 122 PIB, 124 - Section 6 provides a description of the PRC classes of the IP TE 125 PIB, according to the semantics of the Structure of Policy 126 Provisioning Information (SPPI, [13]). 128 2. Conventions used in this document 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in RFC 2119 [14]. 134 3. Changes since the previous version 136 - The PIB has been slightly reorganized to introduce an additional 137 table for IS-IS-related policy provisioning data according to [9], 139 - The introduction has been slightly reworded, 141 - The references section has been updated. 143 4. Scalability considerations 145 The usage of the COPS-PR protocol for the dynamic enforcement of an 146 IP traffic engineering policy raises some scalability issues, as far 147 as the volume of configuration information that will be exchanged not 148 only between the routers themselves (because of the OSPF machinery 149 for example), but also between the PEP (Policy Enforcement Point) 150 components embedded in the routers and the PDP (Policy Decision 151 Point) they communicate with is concerned. 153 While the concern strictly related to the design of a routing policy 154 is outside the scope of this document, the dynamic provisioning of 155 metric values as well as the reports related to the actual 156 enforcement of decisions taken by the PDP, deserve some elaboration. 158 4.1. A tentative metric taxonomy 160 The metrics that will be taken into account by the Shortest Path 161 First (SPF) algorithms for IP TE route calculation can be classified 162 into two basic categories: 164 1. Metrics assigned on a long-term basis, which basically consist 165 of the "usual" cost metrics, like those defined in [5]. These 166 metrics are those that are assigned on a (logical) interface 167 basis, and they aim at reflecting the link quality the 168 corresponding interface is attached to, 170 2. Metrics assigned on a (very) short term basis, which MAY consist 171 of the following information: 173 - The available bandwidth, (e.g. based upon the information 174 provided by SNMP (Simple Network Management Protocol, [15]) 175 counters like ifInOctets and ifOutOctets), 176 - The amount of bandwidth that can be reserved, 177 - The amount of reserved bandwidth. 179 While "long term" metric values should not change frequently by 180 definition, the "short term" metric values MAY vary like the ongoing 181 usage of the resources of the network. 183 Therefore, the dynamic computation of "short term" metric values 184 SHOULD remain in the magnitude of the corresponding SPF computation, 185 since newly assigned values yield the spontaneous generation of LSU 186 (Link State Update, [5]) messages. Thus, the traffic generated by the 187 IP traffic engineering provisioning data SHOULD be minimized 188 according to pre-computation engineering recommendations like those 189 described in [16]. 191 4.2. Reporting the enforcement of an IP traffic engineering policy 193 Likewise, the actual enforcement of policy decisions implies the 194 activation of a reporting mechanism, as described in the COPS-PR 195 specification. 197 From this perspective, this draft assumes that the corresponding 198 reports sent by the PEP components of the routers towards the PDP 199 SHOULD include the traffic engineered routes that have been computed 200 by the routers, at least for network planning purposes: the service 201 subscription requests will be negotiated according to the knowledge 202 of the network resources that are actually available, and this 203 information includes the routes that could very well service the 204 aforementioned requirements, without any extra computation. 206 Therefore, the traffic generated by the notification reports of the 207 installed routes SHOULD remain in the magnitude of the route 208 announcement procedures of the IP routing protocols machineries (like 209 OSPF), and it is assumed that the volume of the corresponding COPS-PR 210 traffic is also highly dependent on the pre-computation engineering 211 recommendations that have been mentioned in the above section 3.1. 213 In other words, this draft assumes that it is mainly the 214 responsibility of a network operator to enforce an IP traffic 215 engineering policy that should raise scalability issues (raised by 216 design), NOT the choice of activating the COPS-PR protocol as a means 217 to convey the corresponding IP TE provisioning data. 219 Nevertheless, it is obviously one of the most important concerns of 220 the ongoing specification and development effort that is partly 221 reflected by this draft. In particular, it is the intention of the 222 authors of this draft to later submit a publication that will aim at 223 depicting the simulation results obtained through the validation of 224 this COPS-PR architecture for the dynamic enforcement of an IP 225 traffic engineering policy within the context of an operational 226 service provider's environment. 228 5. PIB Overview 230 The dynamic enforcement of an IP traffic engineering policy relies on 231 the activation of intra- and inter-domain routing protocols that will 232 have the ability to take into account traffic engineering-related 233 information for the computation and the selection of routes, which 234 will comply as much as possible with the QoS requirements that have 235 been contractually defined between customers and service providers. 237 This traffic engineering-related information is basically composed of 238 metric values that will aim at reflecting an IP TE policy, as well as 239 the result of the enforcement of such a policy, so that customers and 240 providers can check anytime that the IP service is provisioned with 241 the appropriate (and contractual) levels of quality (which can be 242 expressed in terms of service availability, for example). 244 Therefore, the IP TE PIB mainly aims at: 246 - Storing and maintaining the configuration information that will be 247 used by the routers to compute and select the routes that will 248 comply with a collection of QoS requirements, such as the one-way 249 maximum transit delay, or the maximum inter-packet delay 250 variation, 252 - Storing and maintaining the information related to the traffic 253 engineered routes that have been installed in the routers' 254 Forwarding Information Bases, so that the service providers have 255 the permanent knowledge of the network's resources availability. 257 From this perspective, the IP TE PIB is currently organized into the 258 following provisioning classes: 260 1. The Forwarding Classes (ipTeFwClasses): the information 261 contained in these classes is meant to provide a detailed 262 description of the traffic-engineered routes. Only one table is 263 defined at the current stage of this draft: the IP TE Route 264 table which describes the information related to TE routes that 265 have been installed by the routers in their FIBs, 267 2. The Metrics Classes (ipTeMetricsClasses): the information 268 stored in the tables of this class is meant to provide a 269 description of the metric values that will be taken into 270 account by intra- and inter-domain routing protocols for the 271 computation and the selection of traffic-engineered routes. So 272 far, two groups have been identified: the first group is based 273 upon the traffic engineering extensions of intra-domain routing 274 protocols, the second group is related to QoS-related 275 information that can be conveyed in BGP-4 messages, 277 3. The Statistics Classes (ipTeStatsClasses): the information 278 contained in these classes is meant to provide statistic on the 279 enforcement of the TE policies. 281 6. The IP Traffic Engineering Policy Information Base 283 IP-TE-PIB PIB-DEFINITIONS ::= BEGIN 285 IMPORTS 286 Unsigned32, Integer32, MODULE-IDENTITY, 287 MODULE-COMPLIANCE, OBJECT-TYPE, OBJECT-GROUP 288 FROM COPS-PR-SPPI 289 InstanceId, ReferenceId, Prid, TagId 290 FROM COPS-PR-SPPI-TC 291 InetAddress, InetAddressType 292 FROM INET-ADDRESS-MIB 293 Count, TEXTUAL-CONVENTION 294 FROM ACCT-FR-PIB-TC 295 TruthValue, TEXTUAL-CONVENTION 296 FROM SNMPv2-TC 297 RoleCombination, PrcIdentifier 298 FROM FRAMEWORK-ROLE-PIB 299 SnmpAdminString 300 FROM SNMP-FRAMEWORK-MIB; 302 ipTePib MODULE-IDENTITY 304 SUBJECT-CATEGORIES { tbd } -- IP TE client-type to be 305 -- assigned by IANA 306 LAST-UPDATED "200106180900Z" 307 ORGANIZATION "France Telecom" 308 CONTACT-INFO " 309 Christian Jacquenet 310 France Telecom R & D 311 42, rue des Coutures 312 BP 6243 313 14066 CAEN CEDEX 04 314 France 315 Phone: +33 2 31 75 94 28 316 E-Mail: christian.jacquenet@francetelecom.com" 317 DESCRIPTION 318 "The PIB module containing a set of policy rule classes 319 that describe IP Traffic Engineering policies to be 320 enforced within and between domains." 321 REVISION "200111061600Z" 322 DESCRIPTION 323 "Initial version." 325 ::= { pib tbd } -- tbd to be assigned by IANA 327 ipTeFwdClasses OBJECT IDENTIFIER ::= { ipTePib 1 } 328 ipTeMetricsClasses OBJECT IDENTIFIER ::= { ipTePib 2 } 329 ipTeStatsClasses OBJECT IDENTIFIER ::= { ipTePib 3 } 331 -- 332 -- Forwarding classes. The information contained in these classes 333 -- is meant to provide a detailed description of the traffic 334 -- engineered routes. One table has been specified so far, but there 335 -- is room for depicting specific kinds of routes, like MPLS LSP 336 -- paths, for example. 337 -- 338 -- 340 -- 341 -- The ipTeRouteTable 342 -- 344 ipTeRouteTable OBJECT-TYPE 346 SYNTAX SEQUENCE OF ipTeRouteEntry 347 PIB-ACCESS notify 348 STATUS current 349 DESCRIPTION 350 "This table describes the traffic engineered routes 351 that are installed in the forwarding tables of the 352 routers." 354 ::= { ipTeFwdClasses 1 } 356 ipTeRouteEntry OBJECT-TYPE 358 SYNTAX ipTeRouteEntry 359 STATUS current 360 DESCRIPTION 361 "A particular traffic engineered route to a particular 362 destination." 364 PIB-INDEX { ipTeRoutePrid } 365 UNIQUENESS { ipTeRouteDest, 366 ipTeRouteMask, 367 ipTeRoutePhbId, 368 ipTeRouteNextHopAddress 369 ipTeRouteNextHopMask 370 ipTeRouteIfIndex } 372 ::= { ipTeRouteTable 1 } 374 ipTeRouteEntry ::= SEQUENCE { 375 ipTeRoutePrid InstanceId, 376 ipTeRouteDestAddrType InetAddressType, 377 ipTeRouteDest InetAddress, 378 ipTeRouteMask Unsigned32, 379 ipTeRouteNextHopAddrType InetAddressType, 380 ipTeRouteNextHopAddress InetAddress, 381 ipTeRouteNextHopMask Unsigned32, 382 ipTeRoutePhbId Integer32, 383 ipTeRouteOrigin Integer32, 384 ipTeRouteIfIndex Unsigned32 385 } 387 ipTeRoutePrid OBJECT-TYPE 389 SYNTAX InstanceId 390 STATUS current 391 DESCRIPTION 392 "An integer index that uniquely identifies this route 393 entry among all the route entries." 395 ::= { ipTeRouteEntry 1 } 397 ipTeRouteDestAddrType OBJECT-TYPE 399 SYNTAX InetAddressType 400 STATUS current 401 DESCRIPTION 402 "The address type enumeration value ([17]) used to 403 specify the type of a route's destination IP address." 405 ::= { ipTeRouteEntry 2 } 407 ipTeRouteDest OBJECT-TYPE 409 SYNTAX InetAddress 410 STATUS current 411 DESCRIPTION 412 "The IP address to match against the packet's 413 destination address." 415 ::= { ipTeRouteEntry 3 } 417 ipTeRouteMask OBJECT-TYPE 419 SYNTAX Unsigned32 (0..128) 420 STATUS current 421 DESCRIPTION 422 "Indicates the length of a mask for the matching of the 423 destination IP address. Masks are constructed by 424 setting bits in sequence from the most-significant bit 425 downwards for ipTeRouteMask bits length. All other bits 426 in the mask, up to the number needed to fill the length 427 of the address ipTeRouteDest are cleared to zero. A 428 zero bit in the mask then means that the corresponding 429 bit in the address always matches."" 431 ::= { ipTeRouteEntry 4 } 433 ipTeRouteNextHopAddrType OBJECT-TYPE 435 SYNTAX InetAddressType 436 STATUS current 437 DESCRIPTION 438 "The address type enumeration value used to specify the 439 type of the next hop's IP address." 441 ::= { ipTeRouteEntry 5 } 443 ipTeRouteNextHopAddress OBJECT-TYPE 445 SYNTAX InetAddress 446 STATUS current 447 DESCRIPTION 448 "On remote routes, the address of the next router en 449 route; Otherwise, 0.0.0.0." 451 ::= { ipTeRouteEntry 6 } 453 ipTeRouteNextHopMask OBJECT-TYPE 455 SYNTAX Unsigned32 (0..128) 456 STATUS current 457 DESCRIPTION 458 "Indicates the length of a mask for the matching of the 459 next hop's IP address. Masks are constructed by setting 460 bits in sequence from the most-significant bit 461 downwards for ipTeRouteNextHopMask bits length. All 462 other bits in the mask, up to the number needed to fill 463 the length of the address ipTeRouteNextHop are cleared 464 to zero. A zero bit in the mask then means that the 465 corresponding bit in the address always matches." 467 ::= { ipTeRouteEntry 7 } 469 ipTeRoutePhbId OBJECT-TYPE 471 SYNTAX Integer32 (-1 | 0..63) 472 STATUS current 473 DESCRIPTION 474 "The binary encoding that uniquely identifies a Per Hop 475 Behaviour (PHB, [18]) or a set of PHBs associated to 476 the DiffServ Code Point (DSCP, [15]) marking of the IP 477 datagrams that will be conveyed along this traffic 478 engineered route. A value of -1 indicates that a 479 specific PHB ID value has not been defined, and thus, 480 all PHB ID values are considered a match." 482 ::= { ipTeRouteEntry 8 } 484 ipTeRouteOrigin OBJECT-TYPE 486 SYNTAX INTEGER { 487 OSPF (0) 488 IS-IS (1) 489 BGP (2) 490 STATIC (3) 491 OTHER (4) 492 } 493 STATUS current 494 DESCRIPTION 495 "The value indicates the origin of the route. Either 496 the route has been computed by OSPF, by IS-IS, 497 announced by BGP4, is static, or else." 499 ::= { ipTeRouteEntry 9 } 501 ipTeRouteIfIndex OBJECT-TYPE 503 SYNTAX Unsigned32 (0..65535) 504 STATUS current 505 DESCRIPTION 506 "The ifIndex value that identifies the local interface 507 through which the next hop of this route is 508 accessible." 510 ::= { ipTeRouteEntry 10 } 512 -- 513 -- 514 -- Traffic engineering metrics classes. 516 -- 517 -- The information stored in the following tables is meant to provide 518 -- the description of the metric values that will be taken into 519 -- account by intra- and inter-domain routing protocols for the 520 -- computation and the selection of traffic-engineered routes. So 521 -- far, two tables have been identified: one which is based upon the 522 -- traffic engineering extensions of OSPF, the other which is based 523 -- upon the contents of a specific BGP4 attribute. 524 -- 525 -- 526 igpTeGroup OBJECT IDENTIFIER ::= { ipTeMetricsClasses 1 } 527 bgpTeGroup OBJECT IDENTIFIER ::= { ipTeMetricsClasses 2 } 529 -- 530 -- The ospfTeMetricsTable 531 -- 533 ospfTeMetricsTable OBJECT-TYPE 535 SYNTAX SEQUENCE OF ospfTeMetricsEntry 536 PIB-ACCESS install-notify 537 STATUS current 538 DESCRIPTION 539 "This class describes the link and traffic engineering 540 metrics that will be used by OSPF for TE route 541 calculation purposes." 543 ::= { igpTeGroup 1 } 545 ospfTeMetricsEntry OBJECT-TYPE 547 SYNTAX ospfTeMetricsEntry 548 STATUS current 549 DESCRIPTION 550 "The collection of OSPF metrics assigned to the router 551 on a per interface and per DSCP basis." 553 PIB-INDEX { ospfTeMetricsPrid } 554 UNIQUENESS { ospfTeMetricsLinkMetricValue, 555 ospfTeMetricsDscpValue, 556 ospfTeMetricSubTlvLinkType, 557 ospfTeMetricSubTlvLinkId, 558 ospfTeMetricSubTlvLocalIfAddress, 559 ospfTeMetricSubTlvRemoteIfAddress, 560 ospfTeMetricSubTlvTeMetric, 561 ospfTeMetricSubTlvMaxBandwidth, 562 ospfTeMetricSubTlvMaxRsvBandwidth, 563 ospfTeMetricSubTlvUnRsvBandwidth, 564 ospfTeMetricIfIndex } 566 ::= { ospfTeMetricsTable 1 } 568 ospfTeMetricsEntry ::= SEQUENCE { 570 ospfTeMetricsPrid InstanceId, 571 ospfTeMetricsIfMetricValue Unsigned32, 572 ospfTeMetricsDscpValue Integer32, 573 ospfTeMetricsTopTlvAddressType InetAddressType, 574 ospfTeMetricsTopTlvRouterAddress InetAddress, 575 ospfTeMetricsTopTlvRouterAddrMask Unsigned32, 576 ospfTeMetricsSubTlvLinkType Unsigned32, 577 ospfTeMetricsSubTlvLinkIdAddressType InetAddressType, 578 ospfTeMetricsSubTlvLinkId InetAddress, 579 ospfTeMetricsSubTlvLinkIdMask Unsigned32, 580 ospfTeMetricsSubTlvLocalIfAddressType InetAddressType, 581 ospfTeMetricsSubTlvLocalIfAddress InetAddress, 582 ospfTeMetricsSubTlvLocalIfAddrMask Unsigned32, 583 ospfTeMetricsSubTlvRemoteIfAddressType InetAddressType, 584 ospfTeMetricsSubTlvRemoteIfAddress InetAddress, 585 ospfTeMetricsSubTlvRemoteIfAddrMask Unsigned32, 586 ospfTeMetricsSubTlvTeMetric Unsigned32, 587 ospfTeMetricsSubTlvMaxBandwidth Unsigned32, 588 ospfTeMetricsSubTlvMaxRsvBandwidth Unsigned32, 589 ospfTeMetricsSubTlvUnrsvBandwidth Unsigned32, 590 ospfTeMetricsSubTlvResourceClass Unsigned32, 591 ospfTeMetricsIfIndex Unsigned32 592 } 594 ospfTeMetricsPrid OBJECT-TYPE 596 SYNTAX InstanceId 597 STATUS current 598 DESCRIPTION 599 "An integer index that uniquely identifies this instance of 600 the ospfTeMetrics class." 602 ::= { ospfTeMetricsEntry 1 } 604 ospfTeMetricsIfMetricValue OBJECT-TYPE 606 SYNTAX Unsigned32 (1..65535) 607 STATUS current 608 DESCRIPTION 609 "The link metric assigned on a per-DSCP and per-interface 610 basis, as defined in this instance of the 611 ospfTeMetricsTable." 613 ::= { ospfTeMetricsEntry 2 } 615 ospfTeMetricsDscpValue OBJECT-TYPE 617 SYNTAX Integer32 (-1 | 0..63) 618 STATUS current 619 DESCRIPTION 620 "The DSCP value associated to the link metric value, as 621 defined in the ospfTeMetricsIfMetricValue object. A value of 622 -1 indicates that a specific DSCP value has not been defined 623 and thus all DSCP values are considered a match." 625 ::= { ospfTeMetricsEntry 3 } 627 ospfTeMetricsTopTlvAddressType OBJECT-TYPE 629 SYNTAX InetAddressType 630 STATUS current 631 DESCRIPTION 632 "The address type enumeration value used to specify the IP 633 address of the advertising router. This IP address is always 634 reachable, and is typically implemented as a "loopback" 635 address." 637 ::= { ospfTeMetricsEntry 4 } 639 ospfTeMetricsTopTlvRouterAddress OBJECT-TYPE 641 SYNTAX InetAddress 642 STATUS current 643 DESCRIPTION 644 "The IP address (typically a "loopback" address) of the 645 advertising router." 647 ::= { ospfTeMetricsEntry 5 } 649 ospfTeMetricsTopTlvRouterAddrMask OBJECT-TYPE 651 SYNTAX Unsigned32 (0..128) 652 STATUS current 653 DESCRIPTION 654 "Indicates the length of a mask for the matching of the 655 advertising router's IP address. Masks are constructed by 656 setting bits in sequence from the most-significant bit 657 downwards for ospfTeMetricsTopTlvRouterAddrMask bits length. 658 All other bits in the mask, up to the number needed to fill 659 the length of the address ospfTeMetricsTopTlvRouterAddress 660 are cleared to zero. A zero bit in the mask then means that 661 the corresponding bit in the address always matches." 663 ::= { ospfTeMetricsEntry 6 } 665 ospfTeMetricsSubTlvLinkType OBJECT-TYPE 667 SYNTAX INTEGER { 668 Point-to-Point (1) 669 Multiaccess (2) 670 } 671 STATUS current 672 DESCRIPTION 673 "The type of the link, either point-to-point or multi- 674 access, as defined in [8]." 676 ::= { ospfTeMetricsEntry 7 } 678 ospfTeMetricsSubTlvLinkIdAddressType OBJECT-TYPE 680 SYNTAX InetAddressType 681 STATUS current 682 DESCRIPTION 683 "The address type enumeration value used to identify the 684 other end of the link, described as an IP address." 686 ::= { ospfTeMetricsEntry 8 } 688 ospfTeMetricsSubTlvLinkId OBJECT-TYPE 690 SYNTAX InetAddress 691 STATUS current 692 DESCRIPTION 693 "The identification of the other end of the link, described 694 as an IP address." 696 ::= { ospfTeMetricsEntry 9 } 698 ospfTeMetricsSubTlvLinkMask OBJECT-TYPE 700 SYNTAX Unsigned32 (0..128) 701 STATUS current 702 DESCRIPTION 703 "Indicates the length of a mask for the matching of the 704 other end of the link, described as an IP address. Masks 705 are constructed by setting bits in sequence from the most- 706 significant bit downwards for ospfTeMetricsSubTlvLinkMask 707 bits length. All other bits in the mask, up to the number 708 needed to fill the length of the address 709 ospfTeMetricsSubTlvLinkId are cleared to zero. A zero bit 710 in the mask then means that the corresponding bit in the 711 address always matches." 713 ::= { ospfTeMetricsEntry 10 } 715 ospfTeMetricsSubTlvLocalIfAddressType OBJECT-TYPE 717 SYNTAX InetAddressType 718 STATUS current 719 DESCRIPTION 720 "The address type enumeration value used to specify the IP 721 address of the interface corresponding to this instance of 722 the ospfTeMetricsSubTlvLinkType object." 724 ::= { ospfTeMetricsEntry 11 } 726 ospfTeMetricsSubTlvLocalIfAddress OBJECT-TYPE 728 SYNTAX InetAddress 729 STATUS current 730 DESCRIPTION 731 "Specifies the IP address of the interface of the 732 advertising router which is connected to the link described 733 as an instance of the ospfTeMetricsSubTlvLinkType object." 735 ::= { ospfTeMetricsEntry 12 } 737 ospfTeMetricsSubTlvLocalIfAddrMask OBJECT-TYPE 739 SYNTAX Unsigned32 (0..128) 740 STATUS current 741 DESCRIPTION 742 "Indicates the length of a mask for the matching of the IP 743 address of the interface corresponding to this instance of 744 the ospfTeMetricsSubTlvLinkType object. Masks are 745 constructed by setting bits in sequence from the most- 746 significant bit downwards for 747 ospfTeMetricsSubTlvLocalIfAddrMask bits length. All other 748 bits in the mask, up to the number needed to fill the length 749 of the address ospfTeMetricsSubTlvLocalIfAddress are cleared 750 to zero. A zero bit in the mask then means that the 751 corresponding bit in the address always matches." 753 ::= { ospfTeMetricsEntry 13 } 755 ospfTeMetricsSubTlvRemoteIfAddressType OBJECT-TYPE 757 SYNTAX InetAddressType 758 STATUS current 759 DESCRIPTION 760 "The address type enumeration value used to specify the IP 761 address(es) of the neighbour's interface corresponding to 762 this instance of the ospfTeMetricsSubTlvLinkType object." 764 ::= { ospfTeMetricsEntry 14 } 766 ospfTeMetricSubTlvRemoteIfAddress OBJECT-TYPE 768 SYNTAX InetAddress 769 STATUS current 770 DESCRIPTION 771 "Specifies the IP address of the neighbour's interface that 772 is attached to this instance of the 773 ospfTeMetricsSubTlvLinkType object." 775 ::= { ospfTeMetricsEntry 15 } 777 ospfTeMetricSubTlvRemoteIfAddrMask OBJECT-TYPE 779 SYNTAX Unsigned32 (0..128) 780 STATUS current 781 DESCRIPTION 782 "Indicates the length of a mask for the matching of the IP 783 address of the neighbor's interface corresponding to this 784 instance of the ospfTeMetricsSubTlvLinkType object. Masks 785 are constructed by setting bits in sequence from the most- 786 significant bit downwards for 787 ospfTeMetricSubTlvRemoteIfAddrMaskbits length. All other 788 bits in the mask, up to the number needed to fill the length 789 of the address ospfTeMetricSubTlvRemoteIfAddress are cleared 790 to zero. A zero bit in the mask then means that the 791 corresponding bit in the address always matches." 793 ::= { ospfTeMetricsEntry 16 } 795 ospfTeMetricSubTlvTeMetric OBJECT-TYPE 797 SYNTAX Unsigned32 (1..65535) 798 STATUS current 799 DESCRIPTION 800 "The link metric that has been assigned for traffic 801 engineering purposes. This metric may be different from the 802 ospfTeMetricsLinkMetricValue object of the ospfTeMetrics 803 class." 805 ::= { ospfTeMetricsEntry 17 } 807 ospfTeMetricSubTlvBandwidthType OBJECT-TYPE 809 SYNTAX Unsigned32 (0..4294967295) 810 UNITS "bytes per second" 811 STATUS current 812 DESCRIPTION 813 "Specifies the maximum bandwidth that can be used on this 814 instance of the ospfTeMetricsSubTlvLinkType object in this 815 direction (from the advertising router), expressed in bytes 816 per second." 818 ::= { ospfpTeMetricsEntry 18 } 820 ospfTeMetricSubTlvMaxRsvBandwidth OBJECT-TYPE 822 SYNTAX Unsigned32 (0..4294967295) 823 UNITS "bytes per second" 824 STATUS current 825 DESCRIPTION 826 "Specifies the maximum bandwidth that may be reserved on 827 this instance of the ospfTeMetricsSubTlvLinkType object in 828 this direction (from the advertising router), expressed in 829 bytes per second." 831 ::= { ospfTeMetricsEntry 19 } 833 ospfTeMetricSubTlvUnrsvBandwidth OBJECT-TYPE 835 SYNTAX Unsigned32 (0..4294967295) 836 UNITS "bytes per second" 837 STATUS current 838 DESCRIPTION 839 "Specifies the amount of bandwidth that has not been 840 reserved on this instance of the ospfTeMetricsSubTlvLinkType 841 object in this direction yet (from the advertising router), 842 expressed in bytes per second." 844 ::= { ospfTeMetricsEntry 20 } 846 ospfTeMetricSubTlvResourceClass OBJECT-TYPE 848 SYNTAX Unsigned32 (0..4294967295) 849 STATUS current 850 DESCRIPTION 851 "Specifies administrative group membership for the link in 852 terms of a bit mask." 854 ::= { ospfTeMetricsEntry 21 } 856 ospfTeMetricIfIndex OBJECT-TYPE 858 SYNTAX Unsigned32 (0..65535) 859 STATUS current 860 DESCRIPTION 861 "The ifIndex value that identifies the local interface that 862 has been assigned a (set of) metrics." 864 ::= { ospfTeMetricsEntry 22 } 866 -- 867 -- The isisTeMetricsTable 868 -- 870 isisTeMetricsTable OBJECT-TYPE 872 SYNTAX SEQUENCE OF isisTeMetricsEntry 873 PIB-ACCESS install-notify 874 STATUS current 875 DESCRIPTION 876 "This class describes the link and traffic engineering 877 metrics that will be used by IS-IS for TE route computation 878 purposes." 880 ::= { igpTeGroup 2 } 882 isisTeMetricsEntry OBJECT-TYPE 884 SYNTAX isisTeMetricsEntry 885 STATUS current 886 DESCRIPTION 887 "The collection of IS-IS metrics assigned to the router on a 888 per interface basis." 890 PIB-INDEX { isisTeMetricsPrid } 891 UNIQUENESS { 892 isisTeMetricsSubTlvIfAddr, 893 isisTeMetricsSubTlvNbrAddr, 894 isisTeMetricSubTlvTeMetric, 895 isisTeMetricsSubTlvMaxLinkBwth, 896 isisTeMetricsSubTlvMaxRsvLinkBwth, 897 isisTeMetricsPriority, 898 isisTeMetricsSubTlvUnRsvBwth, 899 isisTeMetricsIfIndex } 901 ::= { isisTeMetricsTable 1 } 903 isisTeMetricsEntry ::= SEQUENCE { 905 isisTeMetricsPrid InstanceId, 906 isisTeMetricsTlvTeRouterID InetAddress, 907 isisTeMetricsSubTlvIfAddrType InetAddressType, 908 isisTeMetricsSubTlvIfAddr InetAddress, 909 isisTeMetricsSubTlvIfAddrMask Unsigned32, 910 isisTeMetricsSubTlvNbrAddType InetAddressType, 911 isisTeMetricsSubTlvNbrAddr InetAddress, 912 isisTeMetricsSubTlvNbrMask Unsigned32, 913 isisTeMetricsSubTlvTeMetric Unsigned32, 914 isisTeMetricsSubTlvMaxLinkBwth Unsigned32, 915 isisTeMetricsSubTlvMaxRsvLinkBwth Unsigned32, 916 isisTeMetricsPriority Integer32, 917 isisTeMetricsSubTlvUnRsvBwth Unsigned32, 918 isisTeMetricsIfIndex Unsigned32 919 } 921 isisTeMetricsPrid OBJECT-TYPE 923 SYNTAX InstanceId 924 STATUS current 925 DESCRIPTION 926 "An integer index that uniquely identifies this instance of 927 the isisTeMetrics class." 929 ::= { isisTeMetricsEntry 1 } 931 isisTeMetricsTlvTeRouterID OBJECT-TYPE 933 SYNTAX InetAddress 934 STATUS current 935 DESCRIPTION 936 "Specifies the router ID." 938 ::= { isisTeMetricsEntry 2 } 940 isisTeMetricsSubTlvIfAddrType OBJECT-TYPE 942 SYNTAX InetAddressType 943 STATUS current 944 DESCRIPTION 945 "The address type enumeration value used to specify the type 946 of the interface IP address." 948 ::= { isisTeMetricsEntry 3 } 950 isisTeMetricsSubTlvIfAddr OBJECT-TYPE 952 SYNTAX InetAddress 953 STATUS current 954 DESCRIPTION 955 "Specifies the IP address of the interface." 957 ::= { isisTeMetricsEntry 4 } 959 isisTeMetricsSubTlvIfAddrMask OBJECT-TYPE 961 SYNTAX Unsigned32 (0..128) 962 STATUS current 963 DESCRIPTION 964 "Indicates the length of a mask for the matching of the IP 965 address of the neighbouring router. Masks are constructed by 966 setting bits in sequence from the most significant bit 967 downwards for isisTeMetricsSubTlvIfAddrMask bits length. All 968 other bits in the mask, up to the number needed to fill the 969 length of the address isisTeMetricsSubTlvIfAddr are cleared 970 to zero. A zero bit in the mask then means that the 971 corresponding bit in the address always matches." 973 ::= { isisTeMetricsEntry 5 } 975 isisTeMetricsSubTlvNbrAddrType OBJECT-TYPE 977 SYNTAX InetAddressType 978 STATUS current 979 DESCRIPTION 980 "The address type enumeration value used to specify the type 981 of the neighbouring router's IP address." 983 ::= { isisTeMetricsEntry 6 } 985 isisTeMetricsSubTlvNbrAddr OBJECT-TYPE 987 SYNTAX InetAddress 988 STATUS current 989 DESCRIPTION 990 "Specifies the IP address of the neighbouring router on the 991 link the corresponding interface (defined by the ifIndex) is 992 attached to." 994 ::= { isisTeMetricsEntry 7 } 996 isisTeMetricsSubTlvNbrMask OBJECT-TYPE 998 SYNTAX Unsigned32 (0..128) 999 STATUS current 1000 DESCRIPTION 1001 "Indicates the length of a mask for the matching of the IP 1002 address of the neighbouring router. Masks are constructed by 1003 setting bits in sequence from the most significant bit 1004 downwards for isisTeMetricsSubTlvNbrMask bits length. All 1005 other bits in the mask, up to the number needed to fill the 1006 length of the address isisTeMetricsSubTlvNbrAddr are cleared 1007 to zero. A zero bit in the mask then means that the 1008 corresponding bit in the address always matches." 1010 ::= { isisTeMetricsEntry 8 } 1012 isisTeMetricsSubTlvTeMetric OBJECT-TYPE 1014 SYNTAX Unsigned32 (1..65535) 1015 STATUS current 1016 DESCRIPTION 1017 "The traffic engineering default metric is used to present a 1018 differently weighted topology to TE-based SPF computations." 1020 ::= { isisTeMetricsEntry 9 } 1022 isisTeMetricsSubTlvMaxLinkBwth OBJECT-TYPE 1024 SYNTAX Unsigned32 (0..4294967295) 1025 UNITS "bytes per second" 1026 STATUS current 1027 DESCRIPTION 1028 "This metric specifies the maximum bandwidth that can be 1029 used on this link in this direction." 1031 ::= { isisTeMetricsEntry 10 } 1033 isisTeMetricsSubTlvMaxRsvLinkBwth OBJECT-TYPE 1035 SYNTAX Unsigned32 (0..4294967295) 1036 UNITS "bytes per second" 1037 STATUS current 1038 DESCRIPTION 1039 "Specifies the maximum bandwidth that may be reserved on 1040 this link in this direction, expressed in bytes per second." 1042 ::= { isisTeMetricsEntry 11 } 1044 isisTeMetricsPriority OBJECT-TYPE 1046 SYNTAX Integer32 (0..7) 1047 STATUS current 1048 DESCRIPTION 1049 "Specifies one of the eight priority levels, possible values 1050 ranging from 0 and 7." 1052 ::= { isisTeMetricsEntry 12} 1054 isisTeMetricsSubTlvUnRsvBwth OBJECT-TYPE 1056 SYNTAX Unsigned32 (0..4294967295) 1057 UNITS "bytes per second" 1058 STATUS current 1059 DESCRIPTION 1060 "Specifies the amount of bandwidth that has not been 1061 reserved on this link in this direction and having the 1062 priority isisTeMetricsPriority, expressed in bytes per 1063 second." 1065 ::= { isisTeMetricsEntry 13 } 1067 isisTeMetricsIfIndex OBJECT-TYPE 1069 SYNTAX Unsigned32 (0..65535) 1070 STATUS current 1071 DESCRIPTION 1072 "The ifIndex value that uniquely identifies the interface 1073 that has been assigned a (set of) metrics." 1075 ::= { isisTeMetricsEntry 14 } 1077 -- 1078 -- The bgpTeTable 1079 -- 1081 bgpTeTable OBJECT-TYPE 1082 SYNTAX SEQUENCE OF bgpTeEntry 1083 PIB-ACCESS install-notify 1084 STATUS current 1085 DESCRIPTION 1086 "This class describes the QoS information that MAY be 1087 conveyed in BGP4 UPDATE messages for the purpose of 1088 enforcing an inter-domain traffic engineering policy." 1090 ::= { bgpTeGroup 1 } 1092 bgpTeEntry OBJECT-TYPE 1094 SYNTAX bgpTeEntry 1095 STATUS current 1096 DESCRIPTION 1097 "The collection of QoS information to be exchanged by 1098 BGP peers, as far as the announcement of traffic 1099 engineered routes between domains is concerned." 1101 PIB-INDEX { bgpTePrid } 1102 UNIQUENESS { bgpTeNlriAddress, 1103 bgpTeNextHopAddress, 1104 bgpTeReservedRate, 1105 bgpTeAvailableRate, 1106 bgpTeLossRate, 1107 bgpTePhbId, 1108 bgpTeMinOneWayDelay, 1109 bgpTeMaxOneWayDelay, 1110 bgpTeAverageOneWayDelay, 1111 bgpTeInterPacketDelay } 1113 ::= { bgpTeTable 1 } 1115 bgpTeEntry ::= SEQUENCE { 1117 bgpTePrid InstanceId, 1118 bgpTeNlriAddressType InetAddressType, 1119 bgpTeNlriAddress InetAddress, 1120 bgpTeNlriAddressMask Unsigned32, 1121 bgpTeNextHopAddressType InetAddressType, 1122 bgpTeNextHopAddress InetAddress, 1123 bgpTeNextHopMask Unsigned32, 1124 bgpTeReservedRate Unsigned32, 1125 bgpTeAvailableRate Unsigned32, 1126 bgpTeLossRate Unsigned32, 1127 bgpTePhbId Integer32, 1128 bgpTeMinOneWayDelay Unsigned32, 1129 bgpTeMaxOneWayDelay Unsigned32, 1130 bgpTeAverageOneWayDelay Unsigned32, 1131 bgpTeInterPacketDelay Unsigned32 1132 } 1134 bgpTePrid OBJECT-TYPE 1136 SYNTAX InstanceId 1137 STATUS current 1138 DESCRIPTION 1139 "An integer index that uniquely identifies this instance of 1140 the bgpTeTable class." 1142 ::= { bgpTeEntry 1 } 1144 bgpTeNlriAddressType OBJECT-TYPE 1146 SYNTAX InetAddressType 1147 STATUS current 1148 DESCRIPTION 1149 "The address type enumeration value used to specify the 1150 type of a route's destination IP address." 1152 ::= { bgpTeEntry 2 } 1154 bgpTeNlriAddress OBJECT-TYPE 1156 SYNTAX InetAddress 1157 STATUS current 1158 DESCRIPTION 1159 "The IP address to match against the NLRI field of the 1160 QOS_NLRI attribute of the BGP4 UPDATE message." 1162 ::= { bgpTeEntry 3 } 1164 bgpTeNlriAddressMask OBJECT-TYPE 1166 SYNTAX Unsigned32 (0..128) 1167 STATUS current 1168 DESCRIPTION 1169 "Indicates the length of a mask for the matching of the 1170 NLRI field of the QOS_NLRI attribute of the BGP4 UPDATE 1171 message. Masks are constructed by setting bits in sequence 1172 from the most-significant bit downwards for bgpTeNlriMask 1173 bits length. All other bits in the mask, up to the number 1174 needed to fill the length of the address bgpTeNlri are 1175 cleared to zero. A zero bit in the mask then means that 1176 the corresponding bit in the address always matches."" 1178 ::= { bgpTeEntry 4 } 1180 bgpTeNextHopAddressType OBJECT-TYPE 1182 SYNTAX InetAddressType 1183 STATUS current 1184 DESCRIPTION 1185 "The address type enumeration value used to specify the 1186 type of the next hop's IP address." 1188 ::= { bgpTeEntry 5 } 1190 bgpTeNextHopAddress OBJECT-TYPE 1192 SYNTAX InetAddress 1193 STATUS current 1194 DESCRIPTION 1195 "On remote routes, the address of the next router en route; 1196 Otherwise, 0.0.0.0." 1198 ::= { bgpTeEntry 6 } 1200 bgpTeNextHopMask OBJECT-TYPE 1202 SYNTAX Unsigned32 (0..128) 1203 STATUS current 1204 DESCRIPTION 1205 "Indicates the length of a mask for the matching of the 1206 next hop's IP address. Masks are constructed by setting 1207 bits in sequence from the most-significant bit downwards 1208 for bgpTeNextHopMask bits length. All other bits in the 1209 mask, up to the number needed to fill the length of the 1210 address bgpTeNextHopAddress are cleared to zero. A zero 1211 bit in the mask then means that the corresponding bit in 1212 the address always matches." 1214 ::= { bgpTeEntry 7 } 1216 bgpTeReservedRate OBJECT-TYPE 1218 SYNTAX Unsigned32 (0..4294967295) 1219 UNITS "kilobits per second" 1220 STATUS current 1221 DESCRIPTION 1222 "Specifies the reserved rate that cannot be used on this 1223 instance of the bgpTeNlriAddress object in this direction 1224 (from the advertising BGP peer), expressed in kilobits per 1225 second." 1227 ::= { bgpTeEntry 8 } 1229 bgpTeAvailableRate OBJECT-TYPE 1231 SYNTAX Unsigned32 (0..4294967295) 1232 UNITS "kilobits per second" 1233 STATUS current 1234 DESCRIPTION 1235 "Specifies the available rate that may be reserved on this 1236 instance of the bgpTeNlriAddress object in this direction 1237 (from the advertising BGP peer), expressed in kilobits per 1238 second." 1240 ::= { bgpTeEntry 9 } 1242 bgpTeLossRate OBJECT-TYPE 1244 SYNTAX Unsigned32 (0..4294967295) 1245 STATUS current 1246 DESCRIPTION 1247 "Specifies the packet loss ratio that has been observed on 1248 this route instantiated by the bgpTeNlriAddress object." 1250 ::= { bgpTeEntry 10 } 1252 bgpTePhbId OBJECT-TYPE 1254 SYNTAX Integer32 (-1 | 0..63) 1255 STATUS current 1256 DESCRIPTION 1257 "The binary encoding that uniquely identifies a Per Hop 1258 Behaviour (PHB) or a set of PHBs associated to the DiffServ 1259 Code Point marking of the IP datagrams that are to be 1260 conveyed along this traffic engineered route. A value of -1 1261 indicates that a specific PHB ID value has not been 1262 defined, and thus, all PHB ID values are considered a 1263 match." 1265 ::= { bgpTeEntry 11 } 1267 bgpTeMinOneWayDelay OBJECT-TYPE 1269 SYNTAX Unsigned32 (0..4294967295) 1270 UNITS "milliseconds" 1271 STATUS current 1272 DESCRIPTION 1273 "Specifies the minimum one-way delay that has been observed 1274 on this route instantiated by the bgpTeNlriAddress object, 1275 expressed in milliseconds." 1277 ::= { bgpTeEntry 12 } 1279 bgpTeMaxOneWayDelay OBJECT-TYPE 1281 SYNTAX Unsigned32 (0..4294967295) 1282 UNITS "milliseconds" 1283 STATUS current 1284 DESCRIPTION 1285 "Specifies the maximum one-way delay that has been observed 1286 on this route instantiated by the bgpTeNlriAddress object, 1287 expressed in milliseconds." 1289 ::= { bgpTeEntry 13 } 1291 bgpTeAverageOneWayDelay OBJECT-TYPE 1293 SYNTAX Unsigned32 (0..4294967295) 1294 UNITS "milliseconds" 1295 STATUS current 1296 DESCRIPTION 1297 "Specifies the average one-way delay that has been observed 1298 on this route instantiated by the bgpTeNlriAddress object, 1299 expressed in milliseconds." 1301 ::= { bgpTeEntry 14 } 1303 bgpTeInterPacketDelay OBJECT-TYPE 1305 SYNTAX Unsigned32 (0..4294967295) 1306 UNITS "milliseconds" 1307 STATUS current 1308 DESCRIPTION 1309 "Specifies the inter-packet delay variation that has been 1310 observed on this route instantiated by the bgpTeNlriAddress 1311 object." 1313 ::= { bgpTeEntry 15 } 1315 -- 1316 -- Traffic engineering statistics classes. The information contained 1317 -- in the yet-to-be defined tables aim at reporting statistics about 1318 -- COPS control traffic, engineered traffic and potential errors. The 1319 -- next version of the draft will provide a first table that will be 1320 -- based upon the use of the "count" clause. 1321 -- 1322 -- 1324 END 1326 7. Security Considerations 1328 The traffic engineering policy provisioning data as they are 1329 described in this PIB will be used for configuring the appropriate 1330 network elements that will be involved in the dynamic enforcement of 1331 these traffic engineering policies, by means of a COPS-PR 1332 communication that will convey this information. 1334 The function of dynamically provisioning network elements with such 1335 configuration information implies that only an authorized COPS-PR 1336 communication take place. 1338 From this perspective, this draft does not introduce any additional 1339 security issues other than those that have been identified in the 1340 COPS-PR specification, and it is therefore recommended that the IPSec 1341 ([19]) protocol suite be used to secure the above-mentioned 1342 authorized communication. 1344 8. References 1346 [1] Bradner, S., "The Internet Standards Process -- Revision 3", 1347 BCP 9, RFC 2026, October 1996. 1348 [2] Ho Chan, K., Durham, D., Gai, S., Herzog, S., McLoghrie, K., 1349 Reichmeyer, F., Seligson, J., Smith, A., Yavatkar, R., "COPS 1350 Usage for Policy Provisioning (COPS-PR)", RFC 3084, March 2001. 1351 [3] Jacquenet, C., "A COPS Client-Type for IP Traffic Engineering", 1352 draft-jacquenet-ip-te-cops-03.txt, Work in Progress, June 2002. 1353 [4] Fine, M., et al., "Framework Policy Information Base", draft- 1354 ietf-rap-frameworkpib-07.txt, Work in Progress, January 2002. 1355 [5] Goderis, D., T'Joens, Y., Jacquenet, C., Memenios, G., Pavlou, 1356 G., Egan, R., Griffin, D., Georgatsos, P., Georgiadis, L., 1357 "Specification of a Service Level Specification (SLS) 1358 Template", draft-tequila-sls-02.txt, Work in Progress, February 1359 2002. Check http://www.ist-tequila.org for additional 1360 information. 1361 [6] Moy J.,"OSPF Version 2", RFC 2328, April 1998. 1362 [7] Rekhter Y., Li T., "A Border Gateway Protocol 4 (BGP-4)", RFC 1363 1771, March 1995. 1364 [8] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering 1365 Extensions to OSPF", draft-katz-yeung-ospf-traffic-06.txt, Work 1366 in Progress, October 2001. 1367 [9] Smit, H., Li, T., "IS-IS Extensions for Traffic Engineering", 1368 draft-ietf-isis-traffic-04.txt, Work in Progress, August 2001. 1369 [10] ISO/IEC 10589, "Intermediate System to Intermediate System, 1370 Intra-Domain Routing Exchange Protocol for use in Conjunction 1371 with the Protocol for Providing the Connectionless-mode Network 1372 Service (ISO 8473)", June 1992. 1373 [11] Jacquenet, C., "Providing Quality of Service Indication by the 1374 BGP-4 Protocol: the QOS_NLRI Attribute", draft-jacquenet-qos- 1375 nrli-04.txt, Work in Progress, March 2002. 1376 [12] Moore, B. et al., "Policy Core Information Model -- Version 1 1377 Specification", RFC 3060, February 2001. 1378 [13] McLoghrie, K., et al., "Structure of Policy Provisioning 1379 Information (SPPI)", RFC 3159, August 2001. 1380 [14] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1381 Levels", BCP 14, RFC 2119, March 1997 1382 [15] Case, J., et al., "A Simple Network Management Protocol", RFC 1383 1157, May 1990. 1384 [16] Guerin, R., et al., "QoS Routing Mechanisms and OSPF 1385 Extensions", RFC 2676, August 1999. 1386 [17] Daniele, M., Haberman, B., Routhier, S., Schoenwaelder, J., 1387 "Textual Conventions for Internet Network Addresses", RFC 3291, 1388 May 2002. 1389 [18] Black, D., Brim, S., Carpenter, B., Le Faucheur, F., "Per Hop 1390 Behaviour Identification Codes", RFC 3140, June 2001. 1392 [19] Kent, S., Atkinson, R., "Security Architecture for the Internet 1393 Protocol", RFC 2401, November 1998. 1395 9. Acknowledgments 1397 Part of this work is funded by the European Commission, within the 1398 context of the TEQUILA (Traffic Engineering for Quality of Service in 1399 the Internet At Large Scale, [5]) project, which is itself part of 1400 the IST (Information Society Technologies) research program. 1402 The author would also like to thank all the partners of the TEQUILA 1403 project for the fruitful discussions that have been conducted so far 1404 within the context of the traffic engineering specification effort of 1405 the project. 1407 10. Authors' Addresses 1409 Mohamed Boucadair, Christian Jacquenet 1410 France Telecom R & D 1411 DMI/SIR 1412 42, rue des Coutures 1413 BP 6243 1414 14066 Caen Cedex 4 1415 France 1416 Phone: +33 2 31 75 94 28 1417 Email: {mohamed.boucadair, christian.jacquenet}@rd.francetelecom.com 1419 Full Copyright Statement 1421 Copyright (C) The Internet Society (2002). All Rights Reserved. 1423 This document and translations of it may be copied and furnished to 1424 others, and derivative works that comment on or otherwise explain it 1425 or assist its implementation may be prepared, coed, published and 1426 distributed, in whole or in part, without restriction of any kind, 1427 provided that the above copyright notice and this paragraph are 1428 included on all such copies and derivative works. However, this 1429 document itself may not be modified in any way, such as by removing 1430 the copyright notice or references to the Internet Society or other 1431 Internet organizations, except as needed for the purpose of 1432 developing Internet standards in which case the procedures for 1433 copyrights defined in the Internet Standards process must be 1434 followed, or as required to translate it into languages other than 1435 English. 1437 The limited permissions granted above are perpetual and will not be 1438 revoked by the Internet Society or its successors or assigns. 1440 This document and the information contained herein is provided on an 1441 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1442 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1443 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1444 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1445 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.