idnits 2.17.1 draft-nitsan-cops-rsvp-proxy-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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages 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. ** The abstract seems to contain references ([NULL-SERV], [RSVP-PROXY], [COPS-RSVP], [COPS]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 205: '...s policy element MAY be sent in the Cl...' RFC 2119 keyword, line 237: '...s policy element MAY be sent in REQ me...' RFC 2119 keyword, line 275: '...s policy element MAY be sent in COPS R...' RFC 2119 keyword, line 307: '...bination objects MAY be present in the...' RFC 2119 keyword, line 342: '...B policy element MAY appear only once ...' (4 more instances...) 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 (October 1999) is 8952 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2205' is defined on line 471, but no explicit reference was found in the text == Unused Reference: 'RFC2210' is defined on line 476, but no explicit reference was found in the text == Unused Reference: 'RFC2474' is defined on line 479, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'RSVP-PROXY' -- Possible downref: Non-RFC (?) normative reference: ref. 'COPS' -- Possible downref: Non-RFC (?) normative reference: ref. 'COPS-RSVP' -- Possible downref: Normative reference to a draft: ref. 'COPS-PR' -- Possible downref: Non-RFC (?) normative reference: ref. 'DCLASS' -- Possible downref: Non-RFC (?) normative reference: ref. 'NULL-SERV' -- Possible downref: Non-RFC (?) normative reference: ref. 'PIB' Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Nitsan Elfassy 2 File: draft-nitsan-cops-rsvp-proxy-00.txt Dinesh Dutt 3 Expiration Date: April 2000 Cisco Systems 5 October 1999 7 COPS Extensions for RSVP Receiver Proxy Support 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- 25 Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Distribution of this memo is unlimited. 30 Copyright Notice 32 Copyright (C) The Internet Society (1998). All Rights Reserved. 34 Abstract 36 This document proposes an extension to [COPS-RSVP] and [COPS] 37 documents needed to support RSVP Receiver Proxy [RSVP-PROXY] and the 38 Null Service Type [NULL-SERV]. 40 Table of contents 42 1. Introduction ...................................................3 43 2. Functionality Required To Support RSVP Receiver Proxy...........3 44 2.1. Device Capabilities..........................................3 45 2.2. Role Combinations............................................4 46 2.3. Additional Decision Information..............................4 47 2.4. Path forwarding policy.......................................5 48 3. COPS Objects Used To Communicate The Additional Information.....5 49 4. Definitions of the New Objects..................................5 50 4.1. PEP Capabilities.............................................5 51 4.2. Role Combination.............................................7 52 5. Communicating Additional Decisions In DEC Message...............9 53 5.1. Policy Information to be included in the returned Resv.......9 54 6. Illustrative Example............................................9 55 7. Compatibility With Existing RSVP COPS Implementations..........10 56 7. References ....................................................11 57 8. Intellectual Property Considerations ..........................11 58 9. Author Information ............................................11 59 10. Full Copyright Statement .....................................12 61 Terminology 63 o RSVP: Resource ReSerVation Protocol. 65 o COPS: Common Open Policy Service. 67 o DSCP: DiffServ Code Point. 69 o Metering: the process of measuring the temporal properties (e.g., 70 rate) of a traffic stream selected by a classifier. The 71 instantaneous state of this process may be used to affect the 72 operation of a marker, shaper, or dropper, and/or may be used for 73 accounting and measurement purposes. 75 o Policing: the process of discarding packets (by a dropper) within 76 a traffic stream in accordance with the state of a corresponding 77 meter enforcing a traffic profile. 79 o Traffic conditioning: control functions performed to enforce 80 rules specified in a TCA, including metering, marking, shaping, 81 and policing. 83 o Microflow: A single instance of an application-to-application 84 flow of packets which is identified by source address, source 85 port, destination address, destination port and protocol id. 87 1. Introduction 89 RSVP Receiver Proxy [RSVP-PROXY] defines an extension to the RSVP 90 message processing mainly designed to operate in conjunction with the 91 Null Service Type [NULL-SERV]. Null Service type is a new service type 92 proposed for use with RSVP to support applications which cannot 93 quantify their resource requirements. The determination of resource 94 requirements for these applications is left to the discretion of the 95 network administrator. 97 The extension proposes that an intermediate router/switch receiving 98 an RSVP Path message terminate the Path message instead of forwarding 99 it all the way to the end destination. This router generates a proxy 100 Resv message and sends it upstream. This originated Resv follows the 101 same rules as any Resv message. 103 Existing COPS support for RSVP does not contain mechanisms to support 104 this new functionality proposed by RSVP Receiver Proxy. This document 105 proposes extensions to enable the use of COPS with RSVP Receiver 106 Proxy. 108 2. Functionality Required to support RSVP Receiver Proxy 110 This section describes the nature of the additional information that 111 needs to be exchanged between the PDP and the PEP to support RSVP 112 Receiver Proxy and the Null Service Type. 114 2.1. Device capabilities 116 RSVP requires that network nodes be capable of reserving resources to 117 support bandwidth allocation. These devices must also be capable of 118 enforcing the traffic to the specified bandwidth - specified via TSPEC 119 - such that they do not use more than their share of resources. 120 Traffic exceeding the specified TSPEC is dropped. The bandwidth 121 allocation and enforcement needs to be supported per each outgoing 122 interface. For example, a multicast flow going out two separate 123 interfaces, could have different resource requirements. 125 There are other capabilities such as marking that a device may or may 126 not support. In order for the PDP to inform a PEP to enforce a 127 decision, it would be useful for the PDP to know the capabilities of 128 the PEP. 130 The device capabilities of interest follow. 132 2.1.1. Support for RSVP Receiver Proxy 134 Current IntServ capable nodes do not support the additional 135 functionality specified by RSVP Receiver Proxy. Before the PDP can 136 send a decision which uses this functionality, it is necessary for the 137 PDP to know if the device supports it. 139 2.1.2. Support for Marking 141 This capability defines whether a node can mark packets and also the 142 manner in which it can mark, using DSCP or only IP Precedence. 144 2.1.3. Support for Resource Reservation and Enforcement 146 This defines the ability of a node to reserve resources and enforce 147 it. It also specifies whether the node can provide this functionality 148 per each outgoing interface or only per input interface. The 149 enforcement is accomplished using a meter and a policer. 151 2.2. Role Combinations 153 With the Null service type, the QoS assigned to a flow is upto the 154 discretion of the network administrator. The network administrator may 155 decide to use DiffServ to assign a QoS to the flow. The drafts related 156 to provisioning of QoS policy in a DiffServ environment ([COPS-PR], 157 [PIB]) specify that each interface has a set of roles associated with 158 it. A role is simply a string that is associated with an interface and 159 is used to group together interfaces that need to share a QoS 160 policy. Each interface can have many roles. A "role combination" is 161 an unordered set of roles. 163 Specifying the role combination associated with the ingress and egress 164 interface associated with the Path message provides for consistency 165 and compatbility with DiffServ policy. 167 2.3. Additional Decision Information 169 According to the new RSVP Receiver Proxy behavior, the RSVP Path 170 message is not forwarded further. The node terminating the Path will 171 instead originate the corresponding Resv message. This decision needs 172 to be communicated to the PEP for a Path message. 174 It is the PDP that decides what policy objects need to be in the Resv 175 message. The PDP needs to communicate these objects to the PEP. 177 3. COPS Objects Used To Communicate The Additional Information 179 The proposed extension defines new objects that are contained in the 180 existing COPS objects. The objects used are: 182 o Stateless Decision object 183 o Client SI Named object 184 o Policy Data object [POL-EXT] 185 o DCLASS object [DCLASS] 187 Further explanation is provided in the following sections. 189 4. Definitions of the New Objects 191 4.1. PEP Capabilities 193 This section defines the objects used to communicate the RSVP-related 194 device capabilities. 196 The container object used to communicate the Client capabilities is a 197 Policy Data Object. The capability information is implemented as 198 policy elements [POL-EXT]. 200 The definitions of the new policy elements follow. 202 4.1.1 RSVP_PROXY_SUPPORT policy element 204 This policy element indicates if the PEP supports RSVP Receiver 205 Proxy. This policy element MAY be sent in the Client Open message (in 206 a POLICY DATA object that itself is encapsulated in COPS ClientSI 207 Named object). 209 If the Client does not add the RSVP_PROXY_SUPPORT in the Client Open 210 message, the PDP assumes that the PEP does not support RSVP Receiver 211 Proxy. 213 +-------------+-------------+-------------+--------------------+ 214 | Length = 8 | P-Type = RSVP_PROXY_SUPPORT | 215 +------+------+-------------+-------------+--------------------+ 216 | Flags | /// Reserved /// | 217 +------+------+-------------+-------------+--------------------+ 219 Length: 16 bits 221 The overall length of the policy element, in octets. Equals 8. 223 P-Type: 16 bits 225 RSVP_PROXY_SUPPORT policy element, as registered with IANA. 227 flags: 16 bits 228 The currently supported flags are: 229 0x00 - RSVP Receiver Proxy not supported 230 0x01 - RSVP Receiver Proxy supported 232 4.1.2. POLICING_SUPPORT policy element definition 234 This policy element indicates if the device supports metering and 235 policing. 237 This policy element MAY be sent in REQ message or in the Client Open 238 message. In case of the REQ message, the object is carried in a Named 239 ClientSI Object following the Signaled ClientSI object that carries 240 the RSVP message objects. 242 If the Client Open or REQ message does not contain the 243 POLICING_SUPPORT policy element, the PDP assumes the PEP supports both 244 input and output policing (the PEP could be running older code which 245 does not define this object). 247 +-------------+-------------+-------------+--------------------+ 248 | Length = 8 | P-Type = POLICING_SUPPORT | 249 +------+------+-------------+-------------+--------------------+ 250 | Flags | /// reserved //// | 251 +------+------+-------------+-------------+--------------------+ 253 Length: 16 bits 255 The overall length of the policy element, in octets. Equals 8. 257 P-Type: 16 bits 259 POLICING_SUPPORT policy element, as registered with IANA. 261 flags: 16 bits 263 The currently supported flags are: 264 0x0 - No policing supported 265 0x1 - Only input-based policing 266 0x2 - Only output-based policing 267 0x3 - Both input and output-based policing 269 4.1.3. MARKING_SUPPORT policy element 271 This policy element indicates the marking capabilities of the PEP. 272 Marking is defined as setting the ToS byte of a packet based on some 273 defined rules. 275 This policy element MAY be sent in COPS REQ message or in the Client 276 Open message. When the Client-Open or REQ message does not contain 277 this element the PDP assumes the PEP has no marking capabilities. 279 +-------------+-------------+-------------+--------------------+ 280 | Length = 8 | P-Type = MARKING_SUPPORT | 281 +------+------+-------------+-------------+--------------------+ 282 | Flags | /// reserved //// | 283 +------+------+-------------+-------------+--------------------+ 285 Length: 16 bits 287 The overall length of the policy element, in octets. Equals 8. 289 P-Type: 16 bits 291 MARKING_SUPPORT policy element, as registered with IANA. 293 flags: 16 bits 295 The currently supported flags are: 296 0x0 - No Marking supported 297 0x1 - Only IP Precedence Marking 298 0x2 - DSCP based Marking 300 4.2. Role-Combination 302 As specified in section 2.2, it may also be useful add the 303 role-combinations assigned to the ingress and egress interfaces as 304 part of the information communicated to the PDP. Two new objects have 305 been defined to carry this information. 307 The role-combination objects MAY be present in the REQ Message. The 308 Named Client Specific Information Object (ClientSI Named) which 309 carries the POLICY-DATA object also carries the role combination 310 objects. 312 There are two role-combination objects defined, IN_ROLE_COMB and 313 OUT_ROLE_COMB. 315 4.2.1. In Interface Role-Combination policy element 317 The format of In Interface Role Combination policy element is as 318 follows: 320 +-------------+-------------+-------------+-------------+ 321 | Length (variable) | P-Type = IN_ROLE_COMB | 322 +------+------+-------------+-------------+-------------+ 323 | IN Role Combination | 324 +------+------+-------------+-------------+-------------+ 325 | ......... | 326 +------+------+-------------+-------------+-------------+ 327 Length: 16 bits 329 This is the overall length of the policy element, in octets. 330 If the length in octets does not fall on a 32-bit word boundary, 331 padding must be added to the end of the object so that it is 332 aligned to the next 32-bit boundary. 334 P-Type: 16 bits 336 IN_ROLE_COMB policy element, as registered with IANA. 338 IN Role Combination: Role Combination string. 340 Role Combination is a display string as defined in [PIB]. 342 IN_ROLE_COMB policy element MAY appear only once in the Policy Data 343 object. If this element is absent in the REQ message, the PDP can 344 assume a default IN Role-Combination. It is up to the PDP to figure 345 out that default. 347 4.2.2. Out Interface Role Combination 349 The format of Out Interface Role Combination policy element is as 350 follows: 352 +-------------+-------------+-------------+-------------+ 353 | Length (variable) | P-Type = OUT_ROLE_COMB | 354 +------+------+-------------+-------------+-------------+ 355 | OUT Role Combination | 356 +------+------+-------------+-------------+-------------+ 357 | ....... | 358 +------+------+-------------+-------------+-------------+ 360 Length: 16 bits 362 This is the overall length of the policy element, in octets. 363 If the length in octets does not fall on a 32-bit word boundary, 364 padding must be added to the end of the object so that it is 365 aligned to the next 32-bit boundary. 367 P-Type: 16 bits 369 OUT_ROLE_COMB policy element, as registered with IANA. 371 OUT Role Combination: Role Combination string. 373 OUT_ROLE_COMB policy element MAY appear only once in the Policy 374 Data object. In the absence of this element in the REQ message, 375 the PDP may assume a default OUT Role-Combination, which makes 376 it a policy decision. 378 5. Communicating Additional Decisions In DEC Message 380 The current COPS for RSVP draft [COPS-RSVP] allows for the possibility 381 of multiple context groups (section 3.6). We extend the use of 382 multiple context groups to include the decision to originate a proxy 383 Resv message. 385 When the PDP gets a Path IN context REQ message, it returns back a DEC 386 message with a context group for the Path IN context, as specified in 387 [COPS-RSVP]. In order to instruct the PEP to originate Resv, the PDP 388 will add another context group for Resv OUT context. 390 Appearance of Resv OUT Decision context group in a DEC message sent 391 for Path IN context, MUST be interpreted by the PEP as an instruction 392 to install Resv state and originate a Resv upstream back to the 393 previous hop defined in the Path message. 395 When Path IN context is "bundled" in the same REQ message with other 396 contexts, the following rule applies: 397 The DEC message sent for this REQ MAY include a single Resv OUT 398 Context Group and the PEP MUST take it as an extension to the 399 Path IN Context Group. 401 5.1. Policy Information to be included in the returned Resv 403 The DEC message described in the previous section will include all the 404 information to be sent back to the Sender inside the Resv. The 405 container object for this information is the Replacement Decision 406 object under the Resv OUT context group added to the DEC message. 407 Among the objects that may populate the Replacement Decision object 408 are Policy Data Object(s), DCLASS object and TSPEC object. 410 6. Illustrative Example 412 (Modified example from "COPS usage for RSVP" IETF draft). This 413 section illustrates the steps in using COPS for controlling a 414 unicast RSVP Receiver Proxy flow. 416 h1 ----> R1 417 | 418 | 419 h1 <-----+ 421 Figure 1: Single PEP View 423 Assume that the PEP, R1 has two interfaces (if1, if2). Sender h1 424 sends to some receiver r1. R1 is a PEP along the path which supports 425 RSVP Receiver Proxy. Let if1 be the interface on which h1 is 426 connected to R1 and if2 be the outgoing interface associated with 427 the receiver r1. 429 A. A Path message arrives from h1: 431 PEP --> PDP REQ := 432 433 434 435 438 PDP --> PEP DEC := 439 440 441 442 443 444 445 446 448 The decision message instructs the PEP to accept the Path message 449 in, originate a Resv and to not forward the Path further. 451 7. Compatibility With Existing RSVP COPS Implementations 453 In order to inter-operate with existing RSVP COPS clients, the PDP 454 must treat a Client-Open received with no capability objects 455 specified as a device which does not support RSVP Receiver Proxy and 456 send decisions which match the existing standard [COPS-RSVP]. The 457 assumption made here is that clients which support the functionality 458 detailed in this draft will also support the RSVP Receiver Proxy 459 functionality. 461 If a PEP supporting RSVP Receiver Proxy talks to an older PDP, the PDP 462 will ignore the capability objects sent. It will therefore treat all 463 incoming messages as quantitative service type objects. 465 8. Security Considerations 467 This Section is TBD 469 9. References 471 [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and Jamin 472 S., "Resource Reservation Protocol (RSVP) Version 1 473 Functional Specification", IETF RFC 2205, Proposed 474 Standard, September 1997. 476 [RFC2210] J. Wroclawski, "The Use of RSVP with IETF Integrated 477 Services," September 1997. 479 [RFC2474] K. Nichols, S. Blake, F. Baker, D. Black, "Definition of 480 the Differentiated Services Field (DS Field) in the IPv4 482 [RSVP-PROXY] Gai S., Dutt D., Elfassy N., Bernet Y., RSVP Receiver 483 Proxy, , October 1999. 485 [COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R., 486 Sastry, A., "The COPS (Common Open Policy Service) 487 Protocol", IETF , February 488 1999. 490 [COPS-RSVP] Jim Boyle, Ron Cohen, David Durham, Shai Herzog, Raju 491 Rajan, Arun Sastry, "COPS usage for RSVP," , June 14, 1999 494 [POL-EXT] Shai Herzog, "RSVP Extensions for Policy Control," 495 Internet Draft., < draft-ietf-rap-rsvp-ext-06.txt>, April 496 1999. 498 [COPS-PR] Reichmeyer F., Kwok Ho Chan, Durham D., Yavatkar R., 499 Gai S., McCloghrie K., Herzog S., Smith A. "COPS Usage for 500 Policy Provisioning", draft-sgai-cops-provisioning-00.txt, 501 February 1999. 503 [DCLASS] Bernet, Y., "Usage and Format of the DCLASS Object With 504 RSVP Signalling", , 505 August 1999. 507 [NULL-SERV] Yoram Bernet, Andrew Smith, Bruce Davie, "Specification of 508 the Null Service Type", 509 , September 1999. 511 [PIB] M. Fine, K. McCloghrie et. al, "An Initial Policy 512 Information Base For COPS-PR Clients and Servers", 513 February 1999. 515 10. Intellectual Property Considerations 517 The IETF is being notified of intellectual property rights claimed in 518 regard to some or all of the specification contained in this 519 document. For more information consult the online list of claimed 520 rights. 522 11. Author Information 524 Nitsan Elfassy 525 Cisco Systems, Inc. 526 4 Maskit St, P.O.Box 12497 527 Herzelia Pituach 46766, 528 Israel 529 Phone: +972 9 970 0066 530 email: nitsan@cisco.com 531 Dinesh Dutt 532 Cisco Systems, Inc. 533 170 Tasman Dr. 534 San Jose, CA 95134-1706 535 Phone: (408) 527-0955 536 email: ddutt@cisco.com 538 12. Full Copyright Statement 540 Copyright (C) The Internet Society (1997). All Rights Reserved. 542 This document and translations of it may be copied and furnished to 543 others, and derivative works that comment on or otherwise explain it 544 or assist in its implementation may be prepared, copied, published 545 and distributed, in whole or in part, without restriction of any 546 kind, provided that the above copyright notice and this paragraph are 547 included on all such copies and derivative works. However, this 548 document itself may not be modified in any way, such as by removing 549 the copyright notice or references to the Internet Society or other 550 Internet organizations, except as needed for the purpose of 551 developing Internet standards in which case the procedures for 552 copyrights defined in the Internet Standards process must be 553 followed, or as required to translate it into languages other than 554 English. 556 The limited permissions granted above are perpetual and will not be 557 revoked by the Internet Society or its successors or assigns. 558 This document and the information contained herein is provided on an 559 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 560 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 561 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 562 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 563 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.