idnits 2.17.1 draft-jacquenet-ip-te-cops-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: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** 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? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' scope of this draft):' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 8. Security Considerations' ) ** 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.) (A line matching the expected section header was found, but with an unexpected indentation: ' 7. IANA Considerations' ) ** The document seems to lack an Authors' Addresses Section. ** There are 414 instances of too long lines in the document, the longest one being 15 characters in excess of 72. ** The abstract seems to contain references ([15], [2], [16], [3], [17], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [1], [14]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (November 2000) is 8562 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Missing reference section? '11' on line 598 looks like a reference -- Missing reference section? '2' on line 561 looks like a reference -- Missing reference section? '3' on line 565 looks like a reference -- Missing reference section? '4' on line 624 looks like a reference -- Missing reference section? '5' on line 576 looks like a reference -- Missing reference section? '6' on line 578 looks like a reference -- Missing reference section? '7' on line 581 looks like a reference -- Missing reference section? '8' on line 585 looks like a reference -- Missing reference section? '9' on line 589 looks like a reference -- Missing reference section? '10' on line 594 looks like a reference -- Missing reference section? '12' on line 601 looks like a reference -- Missing reference section? '13' on line 604 looks like a reference -- Missing reference section? '14' on line 608 looks like a reference -- Missing reference section? '15' on line 611 looks like a reference -- Missing reference section? '16' on line 614 looks like a reference -- Missing reference section? '17' on line 617 looks like a reference -- Missing reference section? '1' on line 558 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 0 warnings (==), 19 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Jacquenet 3 Internet Draft France Telecom R&D 4 Document: draft-jacquenet-ip-te-cops-00.txt November 2000 5 Category: Experimental 6 Expires: May 2001 8 A COPS client-type for IP traffic engineering 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 [11]. 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 COPS (Common Open Policy Service, [2])client- 33 type designed for the enforcement of IP Traffic Engineering (IP TE) 34 policies within IP networks. The usage of this IP TE COPS client-type 35 is based upon the activation of the COPS protocol for policy 36 provisioning purposes (COPS-PR, [3]). 38 1. Introduction 40 The deployment of value-added IP services (like quality-of-service- 41 based IP Virtual Private Networks) over the Internet has become one 42 of the most competing challenges for service providers, as well as a 43 complex technical issue, as far as the appropriate provisioning and 44 usage of the resources of the IP networks is concerned. 46 From this standpoint, the COPS protocol and its usage for the support 47 of Policy Provisioning is one of the ongoing specification effort of 48 the Resource Allocation Protocol (rap) Working Group of the IETF that 49 should help service providers in dynamically enforcing an IP Traffic 50 Engineering (IP TE) policy which appears to be one the key components 51 for the massive development of the above-mentioned IP services. 53 Indeed, an IP traffic engineering policy aims at appropriately 54 provisioning, allocating/de-allocating, and using the switching and 55 the transmission resources of an IP network (i.e. the routers and the 56 links that connect these routers, respectively), according to the 57 Quality of Service (QoS) requirements (e.g. bandwidth, delay, jitter, 58 etc.) expressed by the customers who can access such resources within 59 the context of a given service subscription procedure ([4]), among 60 other considerations (like network dimensioning and planning, for 61 example). 63 Within the context of this document, the actual enforcement of an IP 64 traffic engineering policy is primarily based upon the activation of 65 both intra- and inter-domain dynamic routing protocols ([5], [6]) 66 that will be activated in the network to appropriately select, 67 install, maintain and possibly withdraw routes that will comply with 68 the above-mentioned QoS requirements and/or specific routing 69 constraints, depending on the type of traffic that will be conveyed 70 along these routes. 72 It is therefore necessary to provide the route selection processes 73 with the information that will exactly reflect these QoS 74 requirements, given the dynamic routing protocols support traffic 75 engineering capabilities for the calculation and the selection of 76 such routes. These capabilities are currently being specified in [7] 77 and [8] for the OSPF (Open Shortest Path First, [5]) and the IS-IS 78 (Intermediate System to Intermediate System routing protocol, [9]) 79 interior routing protocols respectively, while there is an equivalent 80 and ongoing specification effort for the BGP4 (Border Gateway 81 Protocol, version 4) protocol, as described in [10], for example. 83 To provide the route selection processes with the above-mentioned 84 information, one possibility is to use the COPS protocol and its 85 usage for policy provisioning. To do so, a new COPS client-type is 86 specified, the "IP Traffic Engineering" (IP TE) client-type, and this 87 specification effort is the purpose of this draft. 89 This document is organized into the following sections: 91 - Section 3 introduces terminology as well as basic assumptions, 92 - Section 4 introduces the generic architecture, 93 - Section 5 defines the contents of the COPS messages that MUST 94 include the IP TE client-type specific information, 95 - Section 6 defines the usage of the IP TE client-type, including its 96 mode of operation with the PDP (Policy Decision Point, [11]) with 97 whom a COPS communication has been established, 98 - Finally, sections 7 and 8 introduce IANA and some security 99 considerations, respectively. 101 2. Conventions used in this document 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in RFC-2119 [12]. 107 3. Terminology considerations 109 The enforcement of an IP traffic engineering policy is based upon the 110 processing of the information that reflects the QoS requirements 111 expressed by a customer during a service subscription procedure. Such 112 a procedure can be gracefully based upon a Service Level 113 Specification (SLS) template that will be negotiated between the 114 customer and the provider, as described in [4]. From this standpoint, 115 such QoS requirements can be expressed in terms of bandwidth, delay, 116 jitter, DSCP (Diff-Serv Code Point, [13]) marking, or a combination 117 of these various parameters. 119 This information is called the "QoS-related" information within the 120 context of this draft. 122 Then, this QoS-related information must be taken into account by the 123 routing processes that will participate in the calculation, the 124 selection, the installation and the maintenance of the routes that 125 will comply with the above-mentioned QoS requirements. From this 126 perspective, the algorithms invoked by the routing processes will run 127 the route calculation algorithms that will take into account the cost 128 metrics (whose corresponding values can possibly be influenced by a 129 DSCP value) that have been assigned by the network administrators, 130 and that will somewhat reflect the QoS parameters that have been 131 valued in the above-mentioned SLS template ([7], [10]). 133 This metric-related information is called the "IP TE"-related 134 information within the context of this draft. 136 Thus, this draft makes a distinction between QoS-related information 137 and IP TE-related information, where: 139 - QoS-related information is conveyed in SLS (Service Level 140 Specification, [4]) templates, 142 - IP TE-related information is provided to routers (as a 143 configuration input), and is exchanged between routers so that they 144 calculate, select, install, maintain and possibly withdraw the routes 145 that will comply with the QoS parameters that have been valued in the 146 QoS-related information. 148 From this perspective, QoS-related information provides information 149 on the traffic to be forwarded in the network (such as source 150 address, destination address, protocol identification, DSCP marking, 151 etc.), whereas IP TE-related information provides information for the 152 routing processes that will indicate the routers of the network how 153 to forward the above-mentioned traffic, i.e. identify and use the IP 154 TE routes that will convey such traffic. 156 Furthermore, the actual enforcement of a given IP traffic engineering 157 policy implies that the routers MUST be provided with the IP TE- 158 related information to compute the corresponding IP TE routes, so 159 that they can calculate, select, install, maintain and possibly 160 withdraw the routes that will comply with the requirements expressed 161 in the above-mentioned QoS-related information. 163 Given these basic assumptions, this draft aims at specifying a COPS- 164 based IP-TE client-type that has the following characteristics: 166 - The IP-TE client-type is supported by the PEP (Policy Enforcement 167 Point, [11]) function that allows a router to enforce a collection of 168 policies (including an IP traffic engineering policy within the 169 context of this draft), thanks to a COPS-based communication that has 170 been established between the PEP and the PDP, 172 - The actual enforcement of an IP TE policy is based upon the IP TE- 173 related information that will be exchanged between the PEP and the 174 PDP, and that will be used by the router for selecting, installing, 175 maintaining and possibly withdrawing IP TE routes. 177 4. The generic model of an IP TE policy enforcement scheme 179 The use of the COPS protocol for IP TE policy provisioning together 180 with an IP TE client-type that is supported by the PEP embedded in 181 the IP routers which participate in the enforcement of the IP TE 182 policy, yields the generic model depicted in figure 1. 184 +----------------+ 185 | | 186 | IP Router | 187 | | 188 | +-----+ | COPS-PR +-----+ +-----------+ 189 | | PEP |<---|-------------->| PDP |<-->| IP TE PIB | 190 | +-----+ | +-----+ +-----------+ 191 | | | 192 | | | 193 | +-----+ | 194 | | LPDP| | 195 | +-----+ | 196 | | | 197 | | | 198 | /-------\ | 199 | | | | 200 | +-----+ +-----+| 201 | | RIB |.| RIB || 202 | +-----+ +-----+| 203 | | | | 204 | | | | 205 | \-------/ | 206 | | | 207 | +-----+ | 208 | | FIB | | 209 | +-----+ | 210 +----------------+ 211 _ 212 - Fig.1: generic model of an IP TE policy enforcement scheme - 214 According to figure 1, the routers embed the following and basic 215 components (among other capabilities which are clearly out of the 216 scope of this draft): 218 - A PEP capability, which supports the IP TE client-type. The IP TE 219 client-type is specified by the PEP to the PDP, and is unique for the 220 area covered by the IP traffic engineering policy, so that the PEP 221 can treat all the COPS client-types it supports as non-overlapping 222 and independent namespaces, 224 - A Local Policy Decision Point (LPDP, [11]), which corresponds to 225 the routing processes that have been activated in the router, 226 typically. Within the context of enforcing an IP traffic engineering 227 policy, the LPDP is expected to calculate and install the IP TE 228 routes that comply with the QoS requirements expressed in the IP TE- 229 related information that has been received by the PEP (see section 5 230 of this draft), 232 - Several instances of Routing Information Bases (RIB), according to 233 the different routing processes that have been activated - one can 234 easily assume the activation of at least one IGP (Interior Gateway 235 Protocol, like OSPF) and BGP4. From this standpoint, the above figure 236 does not make any specific assumption about the actual number of RIB 237 instances that can be supported by the router, since this is an 238 implementation specific issue, 240 - Conceptually one Forwarding Information Base (FIB), which will 241 store the routes that have been selected by the routing processes. 242 Again, this draft makes no assumption about the number of FIBs that 243 can be supported by a router (e.g. within the context of an IP VPN 244 (Virtual Private Network) service offering). 246 As suggested in [14], the enforcement of an IP traffic engineering 247 policy is based upon the use of an IP TE policy server (the PDP in 248 the above figure) that sends IP TE-related information to the PEP 249 capability embedded in the IP router. 251 The IP TE-related information is stored and maintained in the IP TE 252 Policy Information Base ([15]), which will be accessed by the PDP to 253 retrieve and update the IP TE-related information whenever necessary 254 (see section 5 of this draft). 256 The IP TE-related information is conveyed between the PDP and the PEP 257 thanks to the establishment of a COPS-PR connection between these two 258 entities. The COPS-PR protocol assumes a named data structure (the 259 PIB), so as to identify the type and purpose of the policy 260 information that is sent by the PDP to the PEP for the provisioning 261 of a given policy. 263 Within the context of this draft, the data structure of the PIB 264 refers to the IP traffic engineering policy that is therefore 265 described in the PIB as a specific PRovisioning Class (PRC, [3]), 266 namely the IP TE PRC. Furthermore, the IP TE PRC contains attributes 267 that actually describe the IP TE-related information that will be 268 sent by the PDP to the PEP. These attributes consist of the link and 269 traffic engineering metrics that will be manipulated by the routing 270 processes being activated in the routers to calculate the IP TE 271 routes for a given destination, among other characteristics. 273 The IP TE PRC is instantiated as multiple PRI (PRovisioning Instance) 274 instances, each of which being identified by PRovisioning Instance 275 iDentifier (PRID). A given PRI specifies the data content carried in 276 the IP TE client specific objects. An IP TE PRI typically contains a 277 value for each attribute that has been defined for the IP TE PRC. 279 Currently, the yet-to-be published [15] document has identified a 280 per-DSCP IP TE PRC instantiation scheme, because the DSCP value 281 conveyed in each IP datagram that will be processed by the routers 282 naturally yields the notion of "DSCP-based" routing. Such a routing 283 scheme aims at reflecting the IP traffic engineering policies that 284 have been defined by a service provider, assuming a restricted number 285 of DSCP-identified classes of service that will service the 286 customer's requirements. 288 This approach clearly yields the use of a single IP TE PRC (as part 289 of the generic PIB depicted in figure 1) per administrative domain, 290 i.e. it is assumed that each service provider will have the ability 291 to instantiate its own IP TE PRC, according to the routing policies 292 it has defined for forwarding the traffic within its domain, but also 293 outside of its domain, in terms of IGP metrics' values and BGP4 294 attribute values, among other things. 296 5. IP TE client-type specific information to be carried in COPS messages 298 This section describes the formalism that is specific to the use of 299 an IP TE client-type, given that only the COPS messages that require 300 an IP TE client-type specific definition are described in this 301 section, i.e. the other COPS messages to be exchanged between a PEP 302 that supports the IP TE client-type and a PDP, and which do not need 303 to carry IP TE client-type specific information are those described 304 in the corresponding [2] and [3] documents, without any further 305 elaboration. 307 It must be noted that, whatever the contents of the COPS messages 308 that MAY be exchanged between the PEP supporting the IP TE client- 309 type and the PDP, the actual calculation, selection, installation, 310 maintenance and possible withdrawal of IP TE routes in the router's 311 FIB is left to the LPDP embedded in the router. Nevertheless, the 312 information contained in the router's FIB MUST be consistent with the 313 information contained in the IP TE PIB: this is done thanks to the 314 synchronization features of the COPS machinery, as defined in [2]. 316 5.1. Client-type field of the Common Header of every COPS message 318 All of the IP TE client-type COPS messages MUST contain the COPS 319 Common Header with the 2-byte encoded Client-Type field valued with 320 the yet-to-be assigned IANA number (see section 7 of this draft) for 321 the IP TE client-type. 323 5.2. COPS Message Content 325 5.2.1. Request messages (REQ) 327 The REQ message is sent by the IP TE client-type to issue a 328 configuration request to the PDP, as specified in the COPS Context 329 Object. The REQ message includes the current configuration 330 information related to the enforcement of an IP traffic engineering 331 policy. Such configuration information is encoded according to the 332 ClientSI format that is defined for the Named ClientSI object of the 333 REQ message ([3]). 335 The configuration information is encoded as a collection of bindings 336 that associate a PRID object and an Encoded Provisioning Instance 337 Data (EPD, [3]). 339 Such information MAY consist of: 341 - The identification information of the router, e.g. the 342 identification information that is conveyed in OSPF LSA (Link State 343 Advertisement, [5]) Type 1 messages, which include the RouterID 344 information encoded as an IP address. The use of a loopback 345 interface's IP address is highly recommended for the instantiation of 346 the corresponding EPD, 348 - The link metric values that have been currently assigned to each 349 (physical/logical) interface of the router, as described in [5] for 350 example. Such values MAY vary with an associated DSCP value, i.e. the 351 link metric assigned to an interface is a function of the DSCP value 352 encoded in each IP datagram that this router may have to forward. For 353 example, a service provider may decide to assign higher values of the 354 link metric for the selection of the routes that will convey best 355 effort traffic characterized by the default DSCP value of 0x000000, 357 - The traffic engineering metric values that specify the link metric 358 values for traffic engineering purposes, as defined in [7], for 359 example. These values MAY be different from the above-mentioned link 360 metric values and they MAY also vary according to DSCP values: this 361 would indicate that the link is a member of one or several DSCP- 362 defined groups, 364 - The contents of each RIB maintained by the router, e.g. the LSDB 365 (Link State Data Base, [5]) and the Adj-RIB-Out, as defined in [6], 367 - The contents of the FIB maintained by the router. 369 5.2.2. Decision messages (DEC) 371 The DEC messages are used by the PDP to send IP TE policy 372 provisioning information to the IP TE client-type. DEC messages are 373 sent in response to a REQ message received from the PEP, or they can 374 be unsolicited, e.g. subsequent DEC messages can be sent at any time 375 after to supply the PEP with additional or updated IP TE policy 376 information without the solicited message flag set in the COPS 377 message header, since such messages correspond to unsolicited 378 decisions. 380 DEC messages typically consist of "install" and/or "remove" 381 decisions, and, when there is no Decision Flags set, the DEC message 382 includes the Named Decision Data (Provisioning) object. 384 Apart from the above-mentioned identification information, and 385 according to the kind of (PRID, EPD) bindings that MAY be processed 386 by the PEP (see section 5.2.1. of the draft), DEC messages MAY refer 387 to the following decision examples: 389 - Install (i.e. assign in this case) new link/traffic engineering 390 metric values each time a new interface is installed/created on the 391 router. These new values will obviously yield the generation of LSA 392 messages in the case of the activation of the OSPF protocol, and/or 393 the generation of BGP4 UPDATE messages (e.g. in the case of a new 394 instantiation of the MULTI_EXIT_DISC (MED, [6]) attribute). This will 395 in turn yield the calculation of (new) IP TE routes that MAY be 396 installed in the router's FIB, 398 - Modify already-assigned metric values, thanks to a remove/install 399 decision procedure (this may yield a modification of the router's FIB 400 as well, obviously). These DEC messages can be motivated by the 401 processing of newly accepted SLS requests among other contexts, 403 - Remove assigned metric values, i.e. the corresponding interfaces 404 may not be taken into consideration by the routing algorithms anymore 405 (or during a specific period of time, e.g. for maintenance purposes). 407 5.2.3. Report messages (RPT) 408 The Report message allow the PEP to indicate to the PDP that a 409 particular set of IP TE policy provisioning instances have been 410 successfully or unsuccessfully installed/removed. 412 When the PEP receives a DEC message from the PDP, it MUST send back a 413 RPT message towards the PDP. The RPT message will contain one of the 414 following Report-Type: 416 "Failure": notification of errors that occurred during the processing 417 of the (PRID, EPD) bindings contained in the DEC message. Such a 418 notification procedure can include a failure report in assigning an 419 updated value of a given metric for example, 421 "Success": notification of successful assignment of metric values, 422 and/or successful installation of IP TE routes in the router's FIB. 423 From this standpoint, there MAY be routes that will be installed in 424 the router's FIB without any explicit decision sent by the PDP to the 425 PEP w.r.t. the calculation/installation of the above-mentioned route: 426 this typically reflects a normal dynamic routing procedure, whenever 427 route advertisement messages are received by the router, including 428 messages related to a topology change. In any case (i.e. whatever the 429 effect that yielded the installation of a route in the router's FIB), 430 a RPT message MUST be sent by the PEP towards the PDP to notify such 431 an event, so that the IP TE PIB might be appropriately updated by the 432 PDP. 434 "Accounting": the accounting RPT message will carry statistical 435 information related to the traffic that will transit through the 436 router AND that will be forwarded by the router according to one of 437 the entries of the router's FIB. This statistical information MAY be 438 used by the PDP to possibly modify the metric values that have been 439 assigned when thresholds have been crossed: for example, if the RPT 440 message reports that x % of the available bandwidth associated to a 441 given interface have been reached, then the PDP may send an 442 unsolicited DEC message in return, so that potential bottlenecks be 443 avoided. 445 5.3. Backward compatibility issues 447 In the case where the IP network is composed of COPS-aware routers 448 (which embed a PEP capability that supports the IP TE client-type), 449 and of COPS-unaware routers, the activation of a link state routing 450 protocol (like OSPF) together with the reporting mechanism that has 451 been described in section 5.2.of this draft addresses the backward 452 compatibility issue. 454 Indeed, the flooding mechanism that is used by the OSPF protocol for 455 the propagation of the LSA messages assumes that, in particular, the 456 COPS-aware will receive these update messages. Upon receipt of such 457 messages, the PEP will have the ability to notify the PDP of the 458 corresponding changes (e.g. by using a "Success" report-type that 459 will reflect the installation of new routes in the router's FIB), so 460 that the IP TE PIB can be updated accordingly. 462 The same observation can be made within the context of the activation 463 of the BGP4 protocol, because of the iBGP full-mesh topology that is 464 required to allow the routers of a given domain to get a homogeneous 465 view of the "outside" world. 467 6. COPS-PR Usage of the IP TE client-type 469 After having opened a COPS connection with the PDP, the PEP sends a 470 REQ message to the PDP that will contain a Client Handle. The Client 471 Handle is used to identify a specific request state associated to the 472 IP TE client-type supported by the PEP. The REQ message will contain 473 a "Configuration Request" context object. 475 This REQ message will also carry the named client specific 476 information (including the (default) configuration information), as 477 described in section 5.2.1.of the draft. By "default" configuration 478 information, it must be understood the default values that can be 479 assigned to the different metrics considered in this document, 480 according to the bootstrap procedures of the routers, and to the 481 default values that have been instantiated in the IP TE PRC part of 482 the PIB. 484 The routes that have been installed in the router's FIB will be 485 conveyed in specific (PRID, EPD) bindings in the REQ message as well. 487 Upon receipt of the REQ message, the PDP will send back a DEC message 488 towards the PEP. This DEC message will carry IP TE Named Decision 489 Data object that will convey all the appropriate installation/removal 490 of (PRID, EPD), as described in section 5.2.2 of this draft. One of 491 the basic goals of this named Decision objects consist in making the 492 routers calculate and install the IP TE routes that will comply with 493 the requirements contained in the SLS templates that have been 494 accepted by the service provider, as well as enforce the IP traffic 495 engineering policy that is depicted by the above-mentioned metric 496 value assignment. 498 Upon receipt of a DEC message, the PEP and the IP TE client-type it 499 supports will (try to) enforce the corresponding IP TE decisions, by 500 making the LPDP (and its associated implementation specific Command 501 Line Interface, if necessary) install the named IP TE policy data 502 (e.g. assign a metric value to a recently-installed interface). 504 Then, the PEP will notify the PDP about the actual enforcement of the 505 named IP TE policy decision data, by sending the appropriate RPT 506 message back to the PDP. Depending on the report-type that will be 507 carried in the RPT message, the contents of the message MAY include: 509 - Successfully/unsuccessfully assigned new/updated metric values, 510 - Successfully installed routes from the router's FIB. Note that the 511 notion of "unsuccessfully installed" routes is meaningless, 513 - Successfully/unsuccessfully withdrawn routes from the router's FIB. 514 Route withdrawal is not only subject to the normal IGP and BGP4 515 procedures (thus yielding the generation of the corresponding 516 advertisement messages, like a BGP4 UPDATE message, for example), but 517 also subject to named IP TE policy decision data (carried in a 518 specific DEC message), like those data related to the lifetime of a 519 service: from this standpoint, an installed route may be valid ONLY 520 during the operating hours of a company, for example. 522 The RPT message MAY also carry the "Accounting" report-type, as 523 described in section 5.2.3.of this draft. 525 7. IANA Considerations 527 Section 5.1. of this draft has identified a need for the assignment 528 of a specific number that will uniquely identify the IP TE client- 529 type in every COPS message to be exchanged between a PEP and a PDP. 531 This value SHOULD be chosen in the range of 0x8000 - 0xFFFF,according 532 to a First Come First Served policy, as mentioned in both [2] and 533 [16]. 535 8. Security Considerations 537 This draft specifies a new client-type that will make use of the COPS 538 protocol for the provisioning and the enforcement of IP traffic 539 engineering policies within IP networks. As such, it introduces no 540 new security issues over the COPS protocol itself, or its usage for 541 policy provisioning. 543 Nevertheless, it is recommended that the IP-TE client-type 544 systematically uses the Message Integrity Object (Integrity) for the 545 authentication and the validation of every COPS message it may 546 exchange with the PDP with whom it has established a COPS 547 communication. The Message Integrity Object also prevents from replay 548 attacks. 550 In addition, the IP Security ([17]) protocol suite may be activated, 551 and the IPSec Authentication Header (AH) should be used for the 552 validation of the COPS connection, while the Encapsulated Security 553 Payload (ESP) may be used to provide both validation and secrecy, as 554 stated in [2]. 556 9. References 558 [1] Bradner, S.,"The Internet Standards Process -- Revision 3", BCP 559 9, RFC 2026, October 1996. 561 [2] Boyle J., Cohen R., Durham D., Herzog S., Raja R., Sastry A., 562 "The COPS (Common Open Policy Service) Protocol", RFC 2748, 563 Proposed Standard, January 2000. 565 [3] Ho Chan K., Durham D., Gai S., Herzog S., McLoghrie K., 566 Reichmeyer F., Seligson J., Smith A., Yavatkar R., "COPS Usage 567 for Policy Provisioning (COPS-PR)", draft-ietf-rap-pr-04.txt, 568 Work in Progress, August 2000. 570 [4] Goderis D., T'Joens Y., Jacquenet C., Memenios G., Pavlou G., 571 Egan R., Griffin D., Georgatsos P., Georgiadis L., 572 "Specification of a Service Level Specification (SLS) Template", 573 draft-tequila-sls-00.txt, Work in Progress, November 2000. Check 574 http://www.ist-tequila.org for additional information. 576 [5] Moy J.,"OSPF Version 2", RFC 2328, April 1998. 578 [6] Rekhter Y., Li T., "A Border Gateway Protocol 4 (BGP-4)", RFC 579 1771, March 1995. 581 [7] Katz D., Yeung D., "Traffic Engineering Extensions to OSPF", 582 draft-katz-yeung-ospf-traffic-02.txt, Work in Progress, October 583 2000. 585 [8] Smit H., Li T., "IS-IS Extensions for Traffic Engineering", 586 draft-ietf-isis-traffic-02.txt, Work in Progress, September 587 2000. 589 [9] ISO/IEC 10589, "Intermediate System to Intermediate System, 590 Intra-Domain Routing Exchange Protocol for use in Conjunction 591 with the Protocol for Providing the Connectionless-mode Network 592 Service (ISO 8473)", June 1992. 594 [10] Jacquenet C., "Providing Quality of Service Indication by the 595 BGP-4 Protocol: the QOS_NLRI Attribute", draft-jacquenet-qos- 596 nrli-00.txt, Work in Progress, July 2000. 598 [11] Yavatkar R., Pendarakis D., Guerin R., "A Framework for Policy- 599 Based Admission Control", RFC 2753, January 2000. 601 [12] Bradner, S., "Key words for use in RFCs to Indicate Requirement 602 Levels", BCP 14, RFC 2119, March 1997. 604 [13] Nichols K., Blake S., Baker F., Black D., "Definition of the 605 Differentiated Services Field (DS Field) in the IPv4 and IPv6 606 Headers", RFC 2474, December 1998. 608 [14] Apostopoulos G., Guerin R., Kamat S., Tripathi S. K., "Server 609 Based QOS Routing", Proceedings of the 1999 GLOBCOMM Conference. 611 [15] Jacquenet C., "An IP Traffic Engineering Policy Information 612 Base", Work in Progress, November 2000. 614 [16] Alvestrand H., Narten T., "Guidelines for Writing an IANA 615 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 617 [17] Atkinson R., "Security Architecture for the Internet Protocol", 618 RFC 2401, August 1998. 620 10. Acknowledgments 622 Part of this work is funded by the European Commission, within the 623 context of the TEQUILA (Traffic Engineering for Quality of Service in 624 the Internet At Large Scale, [4]) project, which is itself part of 625 the IST (Information Society Technologies) research program. 627 The author would also like to thank all the partners of the TEQUILA 628 project for the fruitful discussions that have been conducted so far 629 within the context of the traffic engineering specification effort of 630 the project. 632 11. Author's Addresses 634 Christian Jacquenet 635 France Telecom R & D 636 DMI/SIR 637 42, rue des Coutures 638 BP 6243 639 14066 CAEN Cedex 04 640 France 641 Phone: +33 2 31 75 94 28 642 Email: christian.jacquenet@francetelecom.fr 644 12. Full Copyright Statement 646 Copyright(C) The Internet Society (2000). All Rights Reserved. 648 This document and translations of it may be copied and furnished to 649 others, and derivative works that comment on or otherwise explain it 650 or assist its implementation may be prepared, copied, published and 651 distributed, in whole or in part, without restriction of any kind, 652 provided that the above copyright notice and this paragraph are 653 included on all such copies and derivative works. However, this 654 document itself may not be modified in any way, such as by removing 655 the copyright notice or references to the Internet Society or other 656 Internet organizations, except as needed for the purpose of 657 developing Internet standards in which case the procedures for 658 copyrights defined in the Internet Standards process must be 659 followed, or as required to translate it into languages other than 660 English. 662 The limited permissions granted above are perpetual and will not be 663 revoked by the Internet Society or its successors or assigns. 665 This document and the information contained herein is provided on an 666 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 667 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 668 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 669 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 670 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.