idnits 2.17.1 draft-ietf-rsvp-proxy-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: ---------------------------------------------------------------------------- == 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 2 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 (July 2000) is 8685 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: 'RFC2205' is mentioned on line 270, but not defined == Unused Reference: 'RSVP' is defined on line 283, but no explicit reference was found in the text == Unused Reference: 'DIFFSERV' is defined on line 287, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'INTSERV' -- Possible downref: Non-RFC (?) normative reference: ref. 'RSVPDIFF' -- Possible downref: Non-RFC (?) normative reference: ref. 'AGGRRSVP' -- Possible downref: Non-RFC (?) normative reference: ref. 'DCLASS' -- Possible downref: Non-RFC (?) normative reference: ref. 'NULLSERV' -- Possible downref: Non-RFC (?) normative reference: ref. 'DQOS' Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 8 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-01.txt Nitsan Elfassy 4 Expiration Date: December 2000 Cisco Systems Inc. 6 Yoram Bernet 7 Microsoft 9 July 2000 11 RSVP Proxy 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. The list of 29 Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Distribution of this memo is unlimited. 34 Copyright Notice 36 Copyright (C) The Internet Society (1998). All Rights Reserved. 38 Abstract 40 RSVP has been extended in several directions [POLICY], [RSVP-APPID], 41 [DCLASS], [AGGRRSVP], [RSVPDIFF]. These extensions have broadened the 42 applicability of RSVP characterizing it as a signaling protocol 43 usable both inside and outside the Integrated Services [INTSERV] 44 model. 46 With the addition of the "Null Service Type" [NULLSERV], RSVP is 47 also being adopted by mission critical applications that require some 48 form of prioritized service, but cannot quantify their resource 49 requirements. In cases where RSVP cannot travel end-to-end, these 50 applications may still benefit from reservations that are not truly 51 end-to-end, but that are 'proxied' by a network node on the data path 52 between the sender and the receiver(s). 54 RSVP Receiver Proxy is an extension to the RSVP message processing 55 (not to the protocol itself) in which an intermediate network node 56 originates the Resv message on behalf of the receiver(s) identified 57 by the Path message. 59 RSVP Sender Proxy involves generating a Path message based on some 60 match criteria at a router. For example, a packet filter can be 61 installed at a router and the action associated with a match in the 62 filter could be to generate a Path message. 64 1. Introduction 66 Network administrators and application developers would sometimes 67 like to provide QoS to a flow based on information such as: 69 o the type of application to which the flow belongs 70 o a specific transaction within an application to which the flow 71 belongs 72 o the user running the application to which the flow belongs 74 Typically, such flows belong to applications that cannot quantify 75 their traffic characteristics. 77 Since the data packets themselves do not usually carry information 78 such as application or user id, an alternative approach is to signal 79 this information separately. 81 RSVP [RFC2205] is a well established, standard IETF protocol that is 82 used by applications to signal their QoS requirements to the network 83 and obtain feedback about the network's ability to provide the 84 requested QoS. An existing RFC [RSVP-APPID] defines the objects that 85 can be used to carry the application id/sub-id and user-id in an RSVP 86 message. Also, ISSLL has defined a new service type called Null 87 Service Type [NULLSERV] for use within the IntServ framework. This 88 service is intended for applications whose QoS requirements are 89 better left to the discretion of the network administrators. 91 However, RSVP as currently defined travels end-to-end i.e. from the 92 sender to the receiver and back. For the applications discussed 93 above, this end-to-end nature of RSVP is not always applicable. For 94 example, it might be that the application has been modified only on 95 the sender side to support RSVP; there is no use in forwarding this 96 message to the receiver since it does not support RSVP. Another 97 example is where RSVP is used only within an administrative domain 98 and a provisioned core is used outside of this domain. In such 99 situations, RSVP is beneficial only within the administrative domain 100 it has been enabled in. An example of this situation is QoS in 101 PacketCable[DQOS], where resource reservations are used only within 102 the access portion of the network and the core of the network is 103 provisioned. 105 RSVP Receiver Proxy is proposed to address such situations. 107 2. RSVP Receiver Proxy 109 RSVP Receiver Proxy is a functionality provided by a network device, 110 such as a switch or a router, in which the network device originates 111 the Resv message in response to an incoming Path message, on behalf 112 of the receiver(s) identified by the Path message. 114 The generation of the Resv message is done under policy control. 115 Policy control can be performed using policy that has either been 116 locally specified or specified by a policy server via a protocol such 117 as COPS for RSVP [COPS-RSVP]. 119 The proxy functionality does not imply merely generating a single 120 Resv message. Proxying the Resv involves installing state in the node 121 doing the proxy i.e. the proxying node should act as if it had 122 received a Resv from the true endpoint. This involves reserving 123 resources (if required), sending periodic refreshes of the Resv 124 message and tearing down the reservation if the Path is torn down. 126 Optionally, the network device can also be configured to classify the 127 packets and mark them with an appropriate DSCP. The codepoint used to 128 mark these packets can also be communicated to the sender of the Path 129 message via the DCLASS[DCLASS] object carried in the proxy Resv 130 message. 132 RSVP Receiver Proxy does not change the "on-the-wire" RSVP protocol. 133 It entails only a modification in the processing of the RSVP 134 messages. 136 RSVP Receiver Proxy can be used with all the service types - 137 Controlled Load [CLSVC], Guaranteed Service[GUSVC] and Null Service - 138 defined by Integrated Services. 140 2.1 Processing of other RSVP messages 142 Apart from proxying the Resv message, the proxying node must also be 143 modified to handle differently the following RSVP messages: 145 o PathTear message is honored and its forwarding behavior is similar 146 to a Path message. However, in addition to tearing down the Path 147 state, the node must also send a ResvTear and tear down the 148 reservation state. 150 o PathErr messages are treated as in normal RSVP. Just as in the case 151 of PathTear, if a Resv is being proxied, the PathErr should also 152 result in the tear down of the reservation state. 154 Processing of other RSVP messages is similar to existing behavior as 155 defined in [RFC2205]. 157 2.2 RSVP Receiver Proxy: An Example 159 This section illustrates the RSVP Receiver Proxy functionality 160 provided by a network device. The description is focussed mainly on 161 the two fundamental messages in RSVP, i.e. the Path Message and the 162 Resv message. 164 Figure 1 depicts a simple network topology consisting of two hosts H1 165 and H2 and four intermediate routers, R1-R4. 167 Path Message -----> 168 <----- Resv Message 170 +----+ +----+ +----+ +----+ +----+ +----+ 171 | H1 |---| R1 |---| R2 |---| R3 |---| R4 |---| H2 | 172 +----+ +----+ +----+ +----+ +----+ +----+ 174 H1 ----> R1 ----> R2 ----> R3 ----> R4 ----> H2 Case A: Normal 175 | RSVP Processing 176 v 177 H1 <---- R1 <---- R2 <---- R3 <---- R4 ----> H2 179 H1 ----> R1 180 | Case B: RSVP Receiver Proxy 181 v 182 H1 <---- R1 184 Hx: Host x 185 Ry: Router y 187 Figure 1: Possible Message Forwarding Behaviors in RSVP 189 In Figure 1, case A illustrates the normal RSVP message processing. 190 The Path message is generated by H1, is destined to H2, and it gets 191 to H2 from H1 via R1, R2, R3 and R4. The Resv message uses the 192 reverse of the path setup by the Path message and goes hop-by-hop 193 from H2 to H1. 195 With RSVP Receiver Proxy (case B) the RSVP Path message is terminated 196 by the router R1 acting as a proxy for H2. 198 A possible sequence of steps is: 200 o An application on H1 indicates to the RSVP subsystem that it is a 201 sender wishing to use RSVP. It might specify additional parameters 202 such as traffic characteristics and application specific 203 information. 205 o This causes the RSVP subsystem on H1 to start transmitting RSVP 206 Path messages in accordance with normal RSVP/SBM rules. 208 o The first hop network device (R1) receives this message and applies 209 policy control to decide how to process this message. 211 o The policy specifies a decision to not forward the Path message, 212 but instead to proxy a Resv on behalf of H2. Additionally, the 213 policy could specify the list of objects that need to be sent in 214 the Resv message. One such additional object is the DCLASS 215 object. Further, the policy could specify a DSCP that the 216 network device (R1) must mark the flow identified by the Path 217 message. 219 o On receiving the Resv message, if the DCLASS object is specified 220 the message, H1 can mark the packets of the traffic flow signaled, 221 according to the DSCP specified in the DCLASS object. 223 3. RSVP Sender Proxy 225 Just as a network device can proxy a Resv message on behalf of a 226 receiver, it can also be made to proxy a Path message on behalf of a 227 sender. However the trigger that determines when a network device 228 must generate a proxy Path message is potentially outside the RSVP 229 subsystem. One mechanism for example, would be to install filter 230 entries in the network device such that if an incoming flow matched 231 one of the filters, the device would start generating a proxy Path 232 message. At this point, it could potentially contact a policy server 233 or use local policy in determining the behavior and contents of the 234 proxy Path message. 236 The device generating the Path message must correctly terminate the 237 Resv, ResvTear and PathErr messages. 239 4. Where To Proxy 241 In the example described in section 3, the Receiver Proxy 242 functionality was placed in the network device that was the first hop 243 from the sender of the Path message. This is one possibility, not 244 a requirement. While designing a network, the following trade-offs 245 should be considered: 247 o In case of Receiver Proxy, proxying farther from the sender of the 248 Path message enables additional downstream network elements to 249 benefit from the information carried in the signaling messages, and 250 to participate in the response. For example, if some receivers are 251 located off low-bandwidth links and other receivers off 252 high-bandwidth links, the QoS to be applied could be different for 253 the different receivers. 255 o The proxying might be done at the boundary of an access network and 256 a core network as in the case of PacketCable. 258 o In case of Receiver Proxy, proxying closer to the sender results in 259 a lower the latency experienced by the sender between the 260 generation of the Path message and the receipt of the Resv 261 message. This lower latency might be desirable to some 262 applications. 264 The network administrator must take into account such factors in 265 deciding where to place the proxy. 267 5. Security Considerations 269 The security considerations related to proxying are similar to those 270 raised with respect to RSVP (section 2.8 in [RFC2205]). 272 6. Intellectual Property Considerations 274 The IETF is being notified of intellectual property rights claimed in 275 regard to some or all of the specification contained in this document. 276 For more information consult the online list of claimed rights. 278 7. References 280 [INTSERV] R. Braden, D. Clark, S. Shenker, "Integrated Services in 281 the Internet Architecture: an Overview," June 1994. 283 [RSVP] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, 284 "Resource Reservation Protocol (RSVP) Version 1 285 Functional Specification", RFC 2205, September 1997. 287 [DIFFSERV] K. Nichols, S. Blake, F. Baker, D. Black, "Definition of 288 the Differentiated Services Field (DS Field) in the IPv4 289 and IPv6 Headers," RFC 2474, December 1998. 291 [CLSVC] J. Wroclawski, "Specification of the Controlled-Load 292 Network Element Service," RFC 2211, September 1997. 294 [GUSVC] S. Shenker, C. Partridge, R. Guerin, "Specification of 295 Guaranteed Quality of Service," RFC 2212, September 1997. 297 [COPS-RSVP] J. Boyle, R. Cohen, D. Durham, S. Herzog, R. Rajan, 298 A. Sastry, "COPS usage for RSVP," RFC 2749, 299 January 2000. 301 [POLICY] Shai Herzog, "RSVP Extensions for Policy Control," 302 RFC 2750, January 2000. 304 [RSVPDIFF] Y. Bernet, R. Yavatkar, et. al., "A Framework For 305 Integrated Services Operation Over Diffserv Networks, " 306 , May 2000. 308 [RSVP-APPID] Y. Bernet, R. Pabbati, "Application and Sub Application 309 Identity Policy Element for Use with RSVP," RFC 2872, 310 June 2000. 312 [AGGRRSVP] F. Baker, C. Iturralde, F. Le Faucheur, B. Davie, 313 "Aggregation of RSVP for IP4 and IP6 Reservations," 314 , March 2000. 316 [DCLASS] Y. Bernet, "Usage and Format of the DCLASS Object With 317 RSVP Signaling," , 318 October 1999. 320 [NULLSERV] Y. Bernet, A. Smith, B. Davie, "Specification of the Null 321 Service Type," , 322 September 1999. 324 [DQOS] PacketCable Dynamic Quality Of Service Specification, 325 Interim Version, 326 http://www.packetcable.com/specs/pkt-sp-dqos-I01-991201.pdf. 328 8. Author Information 330 Silvano Gai 331 Cisco Systems, Inc. 332 170 Tasman Dr. 333 San Jose, CA 95134-1706 334 Phone: (408) 527-2690 335 email: sgai@cisco.com 337 Dinesh G Dutt 338 Cisco Systems, Inc. 339 170 Tasman Dr. 340 San Jose, CA 95134-1706 341 Phone: (408) 527-0955 342 email: ddutt@cisco.com 343 Nitsan Elfassy 344 Cisco Systems, Inc. 345 Cisco Systems, Inc. 346 170 Tasman Dr. 347 San Jose, CA 95134-1706 348 Phone: +972 9 970 0066 349 email: nitsan@cisco.com 351 Yoram Bernet 352 Microsoft 353 One Microsoft Way, 354 Redmond, WA 98052 355 Phone: (425) 936-9568 356 Email: yoramb@microsoft.com 358 9. Full Copyright Statement 360 Copyright (C) The Internet Society (1997). All Rights Reserved. 362 This document and translations of it may be copied and furnished to 363 others, and derivative works that comment on or otherwise explain it or 364 assist in its implementation may be prepared, copied, published and 365 distributed, in whole or in part, without restriction of any kind, 366 provided that the above copyright notice and this paragraph are 367 included on all such copies and derivative works. However, this 368 document itself may not be modified in any way, such as by removing the 369 copyright notice or references to the Internet Society or other 370 Internet organizations, except as needed for the purpose of developing 371 Internet standards in which case the procedures for copyrights defined 373 in the Internet Standards process must be followed, or as required to 374 translate it into languages other than English. 376 The limited permissions granted above are perpetual and will not be 377 revoked by the Internet Society or its successors or assigns. 379 This document and the information contained herein is provided on an 380 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 381 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 382 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 383 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 384 FITNESS FOR A PARTICULAR PURPOSE. 386 -- 387 Where is the wisdom we have lost in knowledge? 388 Where is the knowledge we have lost in information? - T. S. Eliot