idnits 2.17.00 (12 Aug 2021) /tmp/idnits44749/draft-jacquenet-fwd-pib-00.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There is 1 instance of lines with non-ascii characters in the document. 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 is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. 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 (August 2004) is 6481 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-isis-traffic has been published as RFC 3784 ** Obsolete normative reference: RFC 3291 (ref. '15') (Obsoleted by RFC 4001) ** Obsolete normative reference: RFC 2401 (ref. '17') (Obsoleted by RFC 4301) Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 2 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-fwd-pib-00.txt France Telecom 5 Category: Experimental February 2004 6 Expires August 2004 8 An IP Forwarding 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 forwarding policy by network devices. Instances 34 of such classes reside in a virtual information store, which is 35 called the IP Forwarding Policy Information Base (PIB). The 36 corresponding IP forwarding policy provisioning data are intended for 37 use by a COPS-PR TE Client-Type, and they complement the PRC classes 38 that have been defined in the Framework PIB. 40 Table of Contents 42 1. Introduction...............................................2 43 2. Conventions used in this document..........................3 44 3. PIB Overview...............................................3 45 4. The IP Forwarding Policy Information Base..................4 46 5. Security Considerations....................................9 47 6. References.................................................9 48 7. Acknowledgments...........................................10 49 8. Authors' Addresses........................................10 50 9. Full Copyright Statement..................................11 52 1. Introduction 54 The deployment of value-added IP services over the Internet has 55 become one of the most competing challenges for service providers, as 56 well as a complex technical issue. 58 Within the context of network resource provisioning and allocation, 59 the Common Open Policy Service protocol (COPS, [2]) and its usage for 60 the support of Policy Provisioning ([3]) is one of the most promising 61 candidate protocols that should help service providers in dynamically 62 enforcing IP routing and traffic engineering policies. 64 An IP routing/TE policy consists in appropriately provisioning and 65 allocating/de-allocating the switching and the transmission resources 66 of an IP network (i.e. the routers and the links that connect these 67 routers, respectively), according to e.g. rate, one-way delay, inter- 68 packet delay variation, etc.) that have been possibly negotiated 69 between the customers and the service providers, and according to (a 70 set of)routing metrics, which can also reflect the network 71 conditions. 73 Thus, the enforcement of IP routing/TE policies yields the need for 74 an introduction of a high level of automation for the dynamic 75 provisioning of the configuration data that will be taken into 76 account by the routers to select the appropriate IP routes. 78 Within the context of this document, the actual enforcement of an IP 79 forwarding policy is primarily based upon the activation of both 80 intra- and inter-domain dynamic routing protocols that will be 81 activated by the routers to select, install, maintain and possibly 82 withdraw IP routes. 84 Such routes have been selected so that they comply as much as 85 possible with the aforementioned QoS requirements and/or specific 86 routing constraints, possibly depending on the type of traffic that 87 will be conveyed along these routes. 89 It is therefore necessary to provide the route selection processes 90 with the information that will depict the routing policies that are 91 to be enforced within a domain and, whenever appropriate, the 92 aforementioned constraints and metrics, given the dynamic routing 93 protocols actually support traffic engineering capabilities for the 94 calculation and the selection of such routes. 96 Some of these capabilities are currently being specified in [4] and 97 [5] for the OSPF (Open Shortest Path First) and the IS-IS 98 (Intermediate System to Intermediate System routing protocol, [6]) 99 interior routing protocols respectively, while there is a comparable 100 effort for the BGP4 (Border Gateway Protocol, version 4) protocol, as 101 described in [7], for example. 103 To provide the route selection processes with the aforementioned 104 information, one possibility is to use the COPS-PR protocol, together 105 with a collection of policy provisioning data that will be stored in 106 a virtual information store, called a Policy Information Base. 108 This draft describes a collection of Policy Rule Classes that will be 109 stored and dynamically maintained in an IP forwarding PIB. The "rule" 110 and "role" concepts, which have been defined in [8], are adopted by 111 this document to distribute the IP routing policy provisioning data 112 over the COPS-PR protocol. 114 The corresponding IP forwarding policy provisioning data are intended 115 for use by a COPS-PR TE Client-Type ([9]), and they complement the 116 PRC classes that have been defined in the Framework PIB ([10]). 118 This document is organized as follows: 120 - Section 3 provides an overview of the organization of the IP 121 forwarding PIB, 123 - Section 4 provides a description of the PRC classes of the IP 124 forwarding PIB, according to the semantics of the Structure of 125 Policy Provisioning Information (SPPI, [11]). 127 2. Conventions used in this document 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in RFC 2119 [12]. 133 3. PIB Overview 135 The dynamic enforcement of an IP forwarding policy relies upon the 136 activation of intra- and inter-domain routing protocols that will 137 have the ability to take into account configuration information for 138 the computation and the selection of routes, which will comply as 139 much as possible with the constraints and requirements that MAY have 140 been contractually defined between customers and service providers. 142 This document specifies an IP forwarding PIB that mainly aims at 143 storing and maintaining the information related to the IP routes that 144 have been installed in the routers' Forwarding Information Bases, so 145 that service providers maintain and update the adequate knowledge of 146 the network's resources availability, from an IP routing perspective. 148 As such, this PIB has been designed so that it SHOULD be gracefully 149 complemented by PIB modules that will reflect the IGP- and BGP- 150 inferred routing policies to be enforced, in terms of cost metrics' 151 values to be assigned and updated whenever needed. 153 Also, the accounting PIB module which is described in [13] aims at 154 providing the most accurate feedback (to service providers) on how 155 efficient the enforcement of a given IP forwarding policy (as 156 specified in this document) actually is. 158 The choice of this PIB organization is basically twofold: 160 - Make the PIB implementation simple, 162 - Provide the appropriate granularity of policy provisioning data 163 that will be manipulated according to the requirements and 164 technical choices of service providers. 166 Therefore, the IP forwarding PIB is currently organized into the 167 following provisioning classes: 169 1. The Forwarding Classes (ipFwdClasses): the information 170 contained in these classes is meant to provide a detailed 171 description of the IP routes as they have been selected by the 172 routers of a given domain, 174 2. The Statistics Classes (ipFwdStatsClasses): the information 175 contained in these classes is meant to provide statistics on 176 the use of the IP routes currently depicted in the IP 177 forwarding PIB. 179 4. The IP Forwarding Policy Information Base 181 IP-FWD-PIB PIB-DEFINITIONS ::= BEGIN 183 IMPORTS 184 Unsigned32, Integer32, MODULE-IDENTITY, 185 MODULE-COMPLIANCE, OBJECT-TYPE, OBJECT-GROUP 186 FROM COPS-PR-SPPI 187 InstanceId, ReferenceId, Prid, TagId 188 FROM COPS-PR-SPPI-TC 189 InetAddress, InetAddressType 190 FROM INET-ADDRESS-MIB 191 Count, TEXTUAL-CONVENTION 192 FROM ACCT-FR-PIB-TC 193 TruthValue, TEXTUAL-CONVENTION 194 FROM SNMPv2-TC 195 RoleCombination, PrcIdentifier 196 FROM FRAMEWORK-ROLE-PIB 197 SnmpAdminString 198 FROM SNMP-FRAMEWORK-MIB; 200 ipFwdPib MODULE-IDENTITY 202 SUBJECT-CATEGORIES { tbd } -- TE client-type to be 203 -- assigned by IANA 204 LAST-UPDATED "200301220900Z" 205 ORGANIZATION "France Telecom" 206 CONTACT-INFO " 207 Mohamed Boucadair 208 France Telecom R & D 209 42, rue des Coutures 210 BP 6243 211 14066 CAEN CEDEX 04 212 France 213 Phone: +33 2 31 75 92 31 214 E-Mail: mohamed.boucadair@francetelecom.com" 215 DESCRIPTION 216 "The PIB module containing a set of policy rule classes 217 that describe the IP routes that have been computed by 218 means of routing/TE policy enforcement, as well as 219 route traffic statistics." 220 REVISION "200402041000Z" 221 DESCRIPTION 222 "Initial version." 224 ::= { pib tbd } -- tbd to be assigned by IANA 226 ipFwdClasses OBJECT IDENTIFIER ::= { ipFwdPib 1 } 227 ipFwdStatsClasses OBJECT IDENTIFIER ::= { ipFwdPib 2 } 229 -- 230 -- Forwarding classes. The information contained in these classes 231 -- is meant to provide a detailed description of the available IP 232 -- routes. One table has been specified so far, but there is room 233 -- for depicting different kinds of routes, like MPLS (MultiProtocol 234 -- Label Switching, ([14]) LSP (Label switched Paths) paths. 235 -- 236 -- 237 -- 239 -- 240 -- The ipFwdTable 241 -- 243 ipFwdTable OBJECT-TYPE 245 SYNTAX SEQUENCE OF ipRouteEntry 246 PIB-ACCESS notify 247 STATUS current 248 DESCRIPTION 249 "This table describes the IP routes that are installed 250 in the forwarding tables of the routers." 252 ::= { ipFwdClasses 1 } 254 ipRouteEntry OBJECT-TYPE 256 SYNTAX ipRouteEntry 257 STATUS current 258 DESCRIPTION 259 "A particular route to a particular destination." 261 PIB-INDEX { ipRoutePrid } 262 UNIQUENESS { ipRouteDest, 263 ipRouteMask, 264 ipRoutePhbId, 265 ipRouteNextHopAddress 266 ipRouteNextHopMask 267 ipRouteIfIndex } 269 ::= { ipFwdTable 1 } 271 ipRouteEntry ::= SEQUENCE { 272 ipRoutePrid InstanceId, 273 ipRouteDestAddrType InetAddressType, 274 ipRouteDest InetAddress, 275 ipRouteMask Unsigned32, 276 ipRouteNextHopAddrType InetAddressType, 277 ipRouteNextHopAddress InetAddress, 278 ipRouteNextHopMask Unsigned32, 279 ipRoutePhbId Integer32, 280 ipRouteOrigin Integer32, 281 ipRouteIfIndex Unsigned32 282 } 284 ipRoutePrid OBJECT-TYPE 286 SYNTAX InstanceId 287 STATUS current 288 DESCRIPTION 289 "An integer index that uniquely identifies this route 290 entry among all the route entries." 292 ::= { ipRouteEntry 1 } 294 ipRouteDestAddrType OBJECT-TYPE 296 SYNTAX InetAddressType 297 STATUS current 298 DESCRIPTION 299 "The address type enumeration value ([15]) used to 300 specify the type of a route's destination IP address." 302 ::= { ipRouteEntry 2 } 304 ipRouteDest OBJECT-TYPE 306 SYNTAX InetAddress 307 STATUS current 308 DESCRIPTION 309 "The IP address to match against the packet's 310 destination address." 312 ::= { ipRouteEntry 3 } 314 ipRouteMask OBJECT-TYPE 316 SYNTAX Unsigned32 (0..128) 317 STATUS current 318 DESCRIPTION 319 "Indicates the length of a mask for the matching of the 320 destination IP address. Masks are constructed by 321 setting bits in sequence from the most-significant bit 322 downwards for ipRouteMask bits length. All other bits 323 in the mask, up to the number needed to fill the length 324 of the address ipRouteDest are cleared to zero. A zero 325 bit in the mask then means that the corresponding bit 326 in the address always matches." 328 ::= { ipRouteEntry 4 } 330 ipRouteNextHopAddrType OBJECT-TYPE 332 SYNTAX InetAddressType 333 STATUS current 334 DESCRIPTION 335 "The address type enumeration value used to specify the 336 type of the next hop's IP address." 338 ::= { ipRouteEntry 5 } 340 ipRouteNextHopAddress OBJECT-TYPE 342 SYNTAX InetAddress 343 STATUS current 344 DESCRIPTION 345 "On remote routes, the address of the next router en 346 route; Otherwise, 0.0.0.0." 348 ::= { ipRouteEntry 6 } 350 ipRouteNextHopMask OBJECT-TYPE 352 SYNTAX Unsigned32 (0..128) 353 STATUS current 354 DESCRIPTION 355 "Indicates the length of a mask for the matching of the 356 next hop's IP address. Masks are constructed by setting 357 bits in sequence from the most-significant bit 358 downwards for ipRouteNextHopMask bits length. All other 359 bits in the mask, up to the number needed to fill the 360 length of the address ipRouteNextHop are cleared to 361 zero. A zero bit in the mask then means that the 362 corresponding bit in the address always matches." 364 ::= { ipRouteEntry 7 } 366 ipRoutePhbId OBJECT-TYPE 368 SYNTAX Integer32 (-1 | 0..63) 369 STATUS current 370 DESCRIPTION 371 "The binary encoding that uniquely identifies a Per Hop 372 Behaviour (PHB, [16]) or a set of PHBs associated to 373 the DiffServ Code Point (DSCP) marking of the IP 374 datagrams that will be conveyed along this route. A 375 value of -1 indicates that a specific PHB ID value has 376 not been defined, and thus, all PHB ID values are 377 considered a match." 379 ::= { ipRouteEntry 8 } 381 ipRouteOriginOBJECT-TYPE 383 SYNTAX INTEGER { 384 OSPF (0) 385 IS-IS (1) 386 BGP (2) 387 STATIC (3) 388 OTHER (4) 389 } 390 STATUS current 391 DESCRIPTION 392 "The value indicates the origin of the route. Either 393 the route has been computed by OSPF, by IS-IS, 394 announced by BGP4, is static, or else." 396 ::= { ipRouteEntry 9 } 398 ipRouteIfIndex OBJECT-TYPE 400 SYNTAX Unsigned32 (0..65535) 401 STATUS current 402 DESCRIPTION 403 "The ifIndex value that identifies the local interface 404 through which the next hop of this route is 405 accessible." 407 ::= { ipRouteEntry 10 } 409 -- 410 -- Route statistics classes. The information contained 411 -- in the yet-to-be defined tables aim at reporting statistics about 412 -- COPS control traffic, route traffic and potential errors. The 413 -- next version of the draft will provide a first table that will be 414 -- based upon the use of the "count" clause. 415 -- 416 -- 418 END 420 5. Security Considerations 422 The traffic engineering policy provisioning data as they are 423 described in this PIB will be used for configuring the appropriate 424 network elements that will be involved in the dynamic enforcement of 425 the corresponding routing and traffic engineering policies, by means 426 of a COPS-PR communication that will convey this information. 428 The function of dynamically provisioning network elements with such 429 configuration information implies that only an authorized COPS-PR 430 communication takes place. 432 From this perspective, this draft does not introduce any additional 433 security issues other than those that have been identified in the 434 COPS-PR specification, and it is therefore recommended that the IPSec 435 ([17]) protocol suite be used to secure the above-mentioned 436 authorized communication. 438 6. References 439 [ 440 [1] Bradner,] S., "The Internet Standards Process -- Revision 3", 441 BCP 9, RFC 2026, October 1996. 442 [2] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja R., Sastry 443 A., "The COPS (Common Open Policy Service) Protocol", RFC 2748, 444 Proposed Standard, January 2000. 445 [3] Ho Chan, K., Durham, D., Gai, S., Herzog, S., McLoghrie, K., 446 Reichmeyer, F., Seligson, J., Smith, A., Yavatkar, R., "COPS Usage 447 for Policy Provisioning (COPS-PR)", RFC 3084, March 2001. 448 [4] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering 449 Extensions to OSPF", RFC 3630, September 2003. 450 [5] Smit, H., Li, T., "IS-IS Extensions for Traffic Engineering", 451 draft-ietf-isis-traffic-05.txt, Work in Progress, August 2003. 452 [6] ISO/IEC 10589, "Intermediate System to Intermediate System, 453 Intra-Domain Routing Exchange Protocol for use in Conjunction with 454 the Protocol for Providing the Connectionless-mode Network Service 455 (ISO 8473)", June 1992. 456 [7] Jacquenet, C., "The BGP QOS_NLRI Attribute", draft-jacquenet- 457 bgp-qos-00.txt, Work in Progress, February 2004. 458 [8] Moore, B. et al., "Policy Core Information Model -- Version 1 459 Specification", RFC 3060, February 2001. 460 [9] Jacquenet, C., "A COPS Client-Type for Traffic Engineering", 461 draft-jacquenet-cops-te-00.txt, Work in Progress, February 2004. 463 [10] Sahita, R., et al., "Framework Policy Information Base", RFC 464 3318, March 2003. 465 [11] McLoghrie, K., et al., "Structure of Policy Provisioning 466 Information (SPPI)", RFC 3159, August 2001. 467 [12] Bradner, S., "Key words for use in RFCs to Indicate Requirement 468 Levels", BCP 14, RFC 2119, March 1997 469 [13] Boucadair, M., "An IP TE PIB for Accounting purposes", draft- 470 boucadair-ipte-acct-pib-02.txt, Work in Progress, June 2003. 471 [14] Rosen, E., et al., "Multiprotocol Label Switching Architecture", 472 RFC 3031, January 2001. 473 [15] Daniele, M., Haberman, B., Routhier, S., Schoenwaelder, J., 474 "Textual Conventions for Internet Network Addresses", RFC 3291, 475 May 2002. 476 [16] Black, D., Brim, S., Carpenter, B., Le Faucheur, F., "Per Hop 477 Behaviour Identification Codes", RFC 3140, June 2001. 478 [17] Kent, S., Atkinson, R., "Security Architecture for the Internet 479 Protocol", RFC 2401, November 1998. 481 7. Acknowledgments 483 Part of this work is funded by the European Commission, within the 484 context of the MESCAL (Management of End-to-End Quality of Service 485 Across the Internet At Large, http://www.mescal.org) project, which 486 is itself part of the IST (Information Society Technologies) research 487 program. 489 The authors would also like to thank all the partners of the MESCAL 490 project for the fruitful discussions that have been conducted so far 491 within the context of the traffic engineering specification effort of 492 the project. 494 8. Authors' Addresses 496 Mohamed Boucadair 497 France Telecom R & D 498 DMI/SIR 499 42, rue des Coutures 500 BP 6243 501 14066 Caen Cedex 4 502 France 503 Phone: +33 2 31 75 92 31 504 Email: mohamed.boucadair@francetelecom.com 506 Christian Jacquenet 507 France Telecom 508 3, avenue François Château 509 CS 36901 510 35069 Rennes CEDEX 511 France 512 Phone: +33 2 99 87 63 31 513 Email: christian.jacquenet@francetelecom.com 515 9. Full Copyright Statement 517 Copyright (C) The Internet Society (2004). All Rights Reserved. 519 This document and translations of it may be copied and furnished to 520 others, and derivative works that comment on or otherwise explain it 521 or assist its implementation may be prepared, coed, published and 522 distributed, in whole or in part, without restriction of any kind, 523 provided that the above copyright notice and this paragraph are 524 included on all such copies and derivative works. However, this 525 document itself may not be modified in any way, such as by removing 526 the copyright notice or references to the Internet Society or other 527 Internet organizations, except as needed for the purpose of 528 developing Internet standards in which case the procedures for 529 copyrights defined in the Internet Standards process must be 530 followed, or as required to translate it into languages other than 531 English. 533 The limited permissions granted above are perpetual and will not be 534 revoked by the Internet Society or its successors or assigns. 536 This document and the information contained herein is provided on an 537 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 538 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 539 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 540 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 541 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.