idnits 2.17.1 draft-ietf-rsvp-proxy-03.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 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 4 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([INTSERV], [AGGRRSVP], [RSVP-APPID], [POLICY], [DCLASS], [RSVPDIFF], [NULLSERV]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2002) is 8071 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) == Missing Reference: 'RFC 2747' is mentioned on line 274, but not defined == Unused Reference: 'DIFFSERV' is defined on line 292, but no explicit reference was found in the text == Unused Reference: 'RFC2747' is defined on line 331, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'INTSERV' ** Downref: Normative reference to an Informational RFC: RFC 2998 (ref. 'RSVPDIFF') -- Possible downref: Non-RFC (?) normative reference: ref. 'DQOS' Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Silvano Gai 2 Internet Draft Dinesh G Dutt 3 draft-ietf-rsvp-proxy-03.txt Nitsan Elfassy 4 Expiration Date: September 2002 Cisco Systems Inc. 5 Yoram Bernet 6 Microsoft 8 March 2002 10 RSVP Proxy 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. The list of 28 Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Distribution of this memo is unlimited. 33 Copyright Notice 35 Copyright (C) The Internet Society (1998). All Rights Reserved. 37 Abstract 39 RSVP has been extended in several directions [POLICY], [RSVP-APPID], 40 [DCLASS], [AGGRRSVP], [RSVPDIFF]. These extensions have broadened the 41 applicability of RSVP characterizing it as a signaling protocol 42 usable both inside and outside the Integrated Services [INTSERV] 43 model. 45 With the addition of the "Null Service Type" [NULLSERV], RSVP is 46 also being adopted by mission critical applications that require some 47 form of prioritized service, but cannot quantify their resource 48 requirements. In cases where RSVP cannot travel end-to-end, these 49 applications may still benefit from reservations that are not truly 50 end-to-end, but that are 'proxied' by a network node on the data path 51 between the sender and the receiver(s). 53 RSVP Receiver Proxy is an extension to the RSVP message processing 54 (not to the protocol itself) in which an intermediate network node 55 originates the Resv message on behalf of the receiver(s) identified 56 by the Path message. 58 RSVP Sender Proxy involves generating a Path message based on some 59 match criteria at a router. For example, a packet filter can be 60 installed at a router and the action associated with a match in the 61 filter could be to generate a Path message. 63 1. Introduction 65 Network administrators and application developers would sometimes 66 like to provide QoS to a flow based on information such as: 68 o the type of application to which the flow belongs 69 o a specific transaction within an application to which the flow 70 belongs 71 o the user running the application to which the flow belongs 73 Typically, such flows belong to applications that cannot quantify 74 their traffic characteristics. 76 Since the data packets themselves do not usually carry information 77 such as application or user id, an alternative approach is to signal 78 this information separately. 80 RSVP [RFC2205] is a well established, standard IETF protocol that is 81 used by applications to signal their QoS requirements to the network 82 and obtain feedback about the network's ability to provide the 83 requested QoS. An existing RFC [RSVP-APPID] defines the objects that 84 can be used to carry the application id/sub-id and user-id in an RSVP 85 message. Also, ISSLL has defined a new service type called Null 86 Service Type [NULLSERV] for use within the IntServ framework. This 87 service is intended for applications whose QoS requirements are 88 better left to the discretion of the network administrators. 90 However, RSVP as currently defined travels end-to-end i.e. from the 91 sender to the receiver and back. For the applications discussed 92 above, this end-to-end nature of RSVP is not always applicable. For 93 example, it might be that the application has been modified only on 94 the sender side to support RSVP; there is no use in forwarding this 95 message to the receiver since it does not support RSVP. Another 96 example is where RSVP is used only within an administrative domain 97 and a provisioned core is used outside of this domain. In such 98 situations, RSVP is beneficial only within the administrative domain 99 it has been enabled in. An example of this situation is QoS in 100 PacketCable[DQOS], where resource reservations are used only within 101 the access portion of the network and the core of the network is 102 provisioned. 104 RSVP Receiver Proxy is proposed to address such situations. 106 2. RSVP Receiver Proxy 108 RSVP Receiver Proxy is a functionality provided by a network device, 109 such as a switch or a router, in which the network device originates 110 the Resv message in response to an incoming Path message, on behalf 111 of the receiver(s) identified by the Path message. 113 The generation of the Resv message is done under policy control. 114 Policy control can be performed using policy that has either been 115 locally specified or specified by a policy server via a protocol such 116 as COPS for RSVP [COPS-RSVP]. 118 The proxy functionality does not imply merely generating a single 119 Resv message. Proxying the Resv involves installing state in the node 120 doing the proxy i.e. the proxying node should act as if it had 121 received a Resv from the true endpoint. This involves reserving 122 resources (if required), sending periodic refreshes of the Resv 123 message and tearing down the reservation if the Path is torn down. 125 Optionally, the network device can also be configured to classify the 126 packets and mark them with an appropriate DSCP. The codepoint used to 127 mark these packets can also be communicated to the sender of the Path 128 message via the DCLASS[DCLASS] object carried in the proxy Resv 129 message. 131 RSVP Receiver Proxy does not change the "on-the-wire" RSVP protocol. 132 It entails only a modification in the processing of the RSVP 133 messages. 135 RSVP Receiver Proxy can be used with all the service types - 136 Controlled Load [CLSVC], Guaranteed Service[GUSVC] and Null Service - 137 defined by Integrated Services. 139 2.1 Processing of other RSVP messages 141 Apart from proxying the Resv message, the proxying node must also be 142 modified to handle differently the following RSVP messages: 144 o PathTear message is honored and its forwarding behavior is similar 145 to a Path message. However, in addition to tearing down the Path 146 state, the node must also send a ResvTear and tear down the 147 reservation state. 149 o PathErr messages are treated as in normal RSVP. Just as in the case 150 of PathTear, if a Resv is being proxied, the PathErr should also 151 result in the tear down of the reservation state. 153 Processing of other RSVP messages is similar to existing behavior as 154 defined in [RFC2205]. 156 2.2 RSVP Receiver Proxy: An Example 158 This section illustrates the RSVP Receiver Proxy functionality 159 provided by a network device. The description is focussed mainly on 160 the two fundamental messages in RSVP, i.e. the Path Message and the 161 Resv message. 163 Figure 1 depicts a simple network topology consisting of two hosts H1 164 and H2 and four intermediate routers, R1-R4. 166 Path Message -----> 167 <----- Resv Message 169 +----+ +----+ +----+ +----+ +----+ +----+ 170 | H1 |---| R1 |---| R2 |---| R3 |---| R4 |---| H2 | 171 +----+ +----+ +----+ +----+ +----+ +----+ 173 H1 ----> R1 ----> R2 ----> R3 ----> R4 ----> H2 Case A: Normal 174 | RSVP Processing 175 v 176 H1 <---- R1 <---- R2 <---- R3 <---- R4 ----> H2 178 H1 ----> R1 179 | Case B: RSVP Receiver Proxy 180 v 181 H1 <---- R1 183 Hx: Host x 184 Ry: Router y 186 Figure 1: Possible Message Forwarding Behaviors in RSVP 188 In Figure 1, case A illustrates the normal RSVP message processing. 189 The Path message is generated by H1, is destined to H2, and it gets 190 to H2 from H1 via R1, R2, R3 and R4. The Resv message uses the 191 reverse of the path setup by the Path message and goes hop-by-hop 192 from H2 to H1. 194 With RSVP Receiver Proxy (case B) the RSVP Path message is terminated 195 by the router R1 acting as a proxy for H2. 197 A possible sequence of steps is: 199 o An application on H1 indicates to the RSVP subsystem that it is a 200 sender wishing to use RSVP. It might specify additional parameters 201 such as traffic characteristics and application specific 202 information. 204 o This causes the RSVP subsystem on H1 to start transmitting RSVP 205 Path messages in accordance with normal RSVP/SBM rules. 207 o The first hop network device (R1) receives this message and applies 208 policy control to decide how to process this message. 210 o The policy specifies a decision to not forward the Path message, 211 but instead to proxy a Resv on behalf of H2. Additionally, the 212 policy could specify the list of objects that need to be sent in 213 the Resv message. One such additional object is the DCLASS 214 object. Further, the policy could specify a DSCP that the 215 network device (R1) must mark the flow identified by the Path 216 message. 218 o On receiving the Resv message, if the DCLASS object is specified 219 the message, H1 can mark the packets of the traffic flow signaled, 220 according to the DSCP specified in the DCLASS object. 222 3. RSVP Sender Proxy 224 Just as a network device can proxy a Resv message on behalf of a 225 receiver, it can also be made to proxy a Path message on behalf of a 226 sender. However the trigger that determines when a network device 227 must generate a proxy Path message is potentially outside the RSVP 228 subsystem. One mechanism for example, would be to install filter 229 entries in the network device such that if an incoming flow matched 230 one of the filters, the device would start generating a proxy Path 231 message. At this point, it could potentially contact a policy server 232 or use local policy in determining the behavior and contents of the 233 proxy Path message. 235 The device generating the Path message must correctly terminate the 236 Resv, ResvTear and PathErr messages. 238 4. Where To Proxy 240 In the example described in section 3, the Receiver Proxy 241 functionality was placed in the network device that was the first hop 242 from the sender of the Path message. This is one possibility, not 243 a requirement. While designing a network, the following trade-offs 244 should be considered: 246 o In case of Receiver Proxy, proxying farther from the sender of the 247 Path message enables additional downstream network elements to 248 benefit from the information carried in the signaling messages, and 249 to participate in the response. For example, if some receivers are 250 located off low-bandwidth links and other receivers off 251 high-bandwidth links, the QoS to be applied could be different for 252 the different receivers. 254 o The proxying might be done at the boundary of an access network and 255 a core network as in the case of PacketCable. 257 o In case of Receiver Proxy, proxying closer to the sender results in 258 a lower the latency experienced by the sender between the 259 generation of the Path message and the receipt of the Resv 260 message. This lower latency might be desirable to some 261 applications. 263 The network administrator must take into account such factors in 264 deciding where to place the proxy. 266 5. Security Considerations 268 The security considerations related to proxying are similar to those 269 raised with respect to RSVP (section 2.8 in [RFC2205]). Specifically, 270 the main concern in using a proxy is to ensure that unauthorized 271 nodes do not mount a denial of service attack or cause theft of 272 service by generating proxy RSVP messages on behalf of either a 273 receiver or a sender. The problem is addressed via router to router 274 authentication and using the INTEGRITY object [RFC 2747] in RSVP 275 messages. Security policy enforcement can further prevent such attacks. 277 6. Intellectual Property Considerations 279 The IETF is being notified of intellectual property rights claimed in 280 regard to some or all of the specification contained in this document. 281 For more information consult the online list of claimed rights. 283 7. References 285 [INTSERV] R. Braden, D. Clark, S. Shenker, "Integrated Services in 286 the Internet Architecture: an Overview," June 1994. 288 [RFC2205] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, 289 "Resource Reservation Protocol (RSVP) Version 1 290 Functional Specification", RFC 2205, September 1997. 292 [DIFFSERV] K. Nichols, S. Blake, F. Baker, D. Black, "Definition of 293 the Differentiated Services Field (DS Field) in the IPv4 294 and IPv6 Headers," RFC 2474, December 1998. 296 [CLSVC] J. Wroclawski, "Specification of the Controlled-Load 297 Network Element Service," RFC 2211, September 1997. 299 [GUSVC] S. Shenker, C. Partridge, R. Guerin, "Specification of 300 Guaranteed Quality of Service," RFC 2212, September 1997. 302 [COPS-RSVP] J. Boyle, R. Cohen, D. Durham, S. Herzog, R. Rajan, 303 A. Sastry, "COPS usage for RSVP," RFC 2749, 304 January 2000. 306 [POLICY] Shai Herzog, "RSVP Extensions for Policy Control," 307 RFC 2750, January 2000. 309 [RSVPDIFF] Y. Bernet, R. Yavatkar, et. al., "A Framework For 310 Integrated Services Operation Over Diffserv Networks, " 311 RFC 2998, November 2000. 313 [RSVP-APPID] Y. Bernet, R. Pabbati, "Application and Sub Application 314 Identity Policy Element for Use with RSVP," RFC 2872, 315 June 2000. 317 [AGGRRSVP] F. Baker, C. Iturralde, F. Le Faucheur, B. Davie, 318 "Aggregation of RSVP for IP4 and IP6 Reservations," 319 RFC 3175, September 2001. 321 [DCLASS] Y. Bernet, "Format of the RSVP DCLASS Object", 322 RFC 2996, November 2000. 324 [NULLSERV] Y. Bernet, A. Smith, B. Davie, "Specification of the Null 325 Service Type," RFC 2997, November 2000. 327 [DQOS] PacketCable Dynamic Quality Of Service Specification, 328 Interim Version, 329 http://www.packetcable.com/specs/pkt-sp-dqos-I01-991201.pdf. 331 [RFC2747] F. Baker, B. Lindell, M.Talwar, "RSVP Cryptographic 332 Authentication", RFC 2747, January 2000. 334 8. Author Information 336 Silvano Gai 337 Cisco Systems, Inc. 338 170 Tasman Dr. 339 San Jose, CA 95134-1706 340 Phone: (408) 527-2690 341 email: sgai@cisco.com 342 Dinesh G Dutt 343 Cisco Systems, Inc. 344 170 Tasman Dr. 345 San Jose, CA 95134-1706 346 Phone: (408) 527-0955 347 email: ddutt@cisco.com 349 Nitsan Elfassy 350 Cisco Systems, Inc. 351 Cisco Systems, Inc. 352 170 Tasman Dr. 353 San Jose, CA 95134-1706 354 Phone: +972 9 970 0066 355 email: nitsan@cisco.com 357 Yoram Bernet 358 Microsoft 359 One Microsoft Way, 360 Redmond, WA 98052 361 Phone: (425) 936-9568 362 Email: yoramb@microsoft.com 364 9. Full Copyright Statement 366 Copyright (C) The Internet Society (1997). All Rights Reserved. 368 This document and translations of it may be copied and furnished to 369 others, and derivative works that comment on or otherwise explain it or 370 assist in its implementation may be prepared, copied, published and 371 distributed, in whole or in part, without restriction of any kind, 372 provided that the above copyright notice and this paragraph are 373 included on all such copies and derivative works. However, this 374 document itself may not be modified in any way, such as by removing the 375 copyright notice or references to the Internet Society or other 376 Internet organizations, except as needed for the purpose of developing 377 Internet standards in which case the procedures for copyrights defined 379 in the Internet Standards process must be followed, or as required to 380 translate it into languages other than English. 382 The limited permissions granted above are perpetual and will not be 383 revoked by the Internet Society or its successors or assigns. 385 This document and the information contained herein is provided on an 386 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 387 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 388 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 389 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 390 FITNESS FOR A PARTICULAR PURPOSE.