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