idnits 2.17.1 draft-ietf-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 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 5 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([COPS-RSVP-EXT], [Policy], [Identity], [DiffModel], [DCLASS], [COPS-RSVP], [AggrRSVP], [NullServ]), 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 240: '...e network device SHOULD put its IP add...' RFC 2119 keyword, line 244: '...e SESSION object SHOULD be copied from...' RFC 2119 keyword, line 246: '... RSVP HOP object MUST be filled in wit...' RFC 2119 keyword, line 253: '...The STYLE object MUST be set to what i...' RFC 2119 keyword, line 260: '...as specified by policy control MUST be...' (5 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 (February 2000) is 8830 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: 'RSVP-APPID' is mentioned on line 81, but not defined == Missing Reference: 'RSVP-COPS' is mentioned on line 292, but not defined == Unused Reference: 'RFC1633' is defined on line 335, but no explicit reference was found in the text == Unused Reference: 'RFC2474' is defined on line 348, but no explicit reference was found in the text == Unused Reference: 'RFC2475' is defined on line 352, but no explicit reference was found in the text == Unused Reference: 'RSVPDIFF' is defined on line 386, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1633 ** Downref: Normative reference to an Informational RFC: RFC 2475 -- Possible downref: Non-RFC (?) normative reference: ref. 'COPS-RSVP-EXT' -- Possible downref: Non-RFC (?) normative reference: ref. 'DiffModel' ** Obsolete normative reference: RFC 2752 (ref. 'Identity') (Obsoleted by RFC 3182) -- 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. 'RSVPDIFF' -- Possible downref: Non-RFC (?) normative reference: ref. 'DQOS' Summary: 9 errors (**), 0 flaws (~~), 8 warnings (==), 9 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-00.txt Nitsan Elfassy 4 Expiration Date: August 2000 Cisco Systems 5 Yoram Bernet 6 Microsoft 8 February 2000 10 RSVP Receiver 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 RSVP Receiver Proxy February 2000 38 Abstract 40 RSVP has been extended in several directions [Policy], [Identity], 41 [DCLASS], [AggrRSVP], [DiffModel],[COPS-RSVP], These extensions have 42 broadened the applicability of RSVP characterizing it as a signaling 43 protocol usable both inside and outside the IntServ model. 45 With the addition of the "Null Service Type" [NullServ], RSVP is 46 being adopted also by mission critical applications that require some 47 form of prioritized service, but cannot readily specify their 48 resource requirements. These applications do not need to set-up a 49 reservation end-to-end, but only to signal to the network their policy 50 information [Policy], [Identity] and obtain in response an applicable 51 DSCP [DCLASS]. 53 RSVP Receiver Proxy is an extension to the RSVP message processing 54 (not to the protocol itself), mainly designed to operate in 55 conjunction with the Null Service Type. If COPS is used for policy 56 control, an extension to the COPS for RSVP protocol [COPS-RSVP-EXT] 57 is also required. 59 1. Introduction 61 Network administrators and application developers would like to have 62 the QoS provided to a packet be based on information such as: 64 o the type of application a packet belongs to 65 o a specific transaction within the application that a packet belongs 66 to 67 o the user running the application that a packet belongs to. 69 In turn, the machine hosting the applications would like to know some 70 information about the QoS being provided to the applications. This 71 could include information such as the DSCP assigned to the packets 72 belonging to an application. The host machine could then use this 73 information to mark the packets appropriately. Since the data packets 74 themselves may not carry information such as application or user id, 75 an alternative approach is to therefore signal this information 76 separately. 78 RSVP [RFC2205] is a well established, standard IETF protocol that is 79 used by applications to signal their QoS requirements to the network 80 and obtain feedback about the network's ability to provide the 81 requested QoS. An existing draft [RSVP-APPID] defines the objects 82 that can be used to carry the application id/sub-id and user-id in an 83 RSVP message. Also, ISSLL has defined a new service type called Null 84 Service Type [NullServ] for use within the IntServ framework. This 85 service is intended for applications whose QoS requirements are 86 better left to the discretion of the network administrators. As a 87 result of these characteristics, RSVP emerges as a good choice as a 88 signaling protocol to carry information such as, application 89 id/sub-id and/or, user id. 91 RSVP Receiver Proxy February 2000 93 RSVP as currently defined travels end-to-end i.e. from the sender to 94 the receiver and back. For the applications discussed above, this 95 end-to-end nature of RSVP is not necessarily an useful feature. For 96 example, the latency incurred in the Resv message returning to the 97 sender might constitute a disadvantage. Or it might be that the 98 application has been modified only on the sender side and so there is 99 no use in forwarding this message to the receiver since it might not 100 support RSVP. RSVP Receiver Proxy is proposed to address such 101 concerns. 103 2. An overview of RSVP Receiver Proxy 105 RSVP Receiver Proxy is a functionality provided by a network device, 106 such as a switch or a router, in which the network device generates a 107 proxy Resv message in response to an incoming Path message, on behalf 108 of the receiver identified by the Path message. 110 The generation of the Resv message is done under policy 111 control. Policy control can either be performed using local policy or 112 by a policy server via a protocol such as COPS for RSVP 113 [COPS-RSVP]. The network device can be configured to classify the 114 packets and mark them with an appropriate DSCP. This marking decision 115 can also be communicated to the sender of the Path message via a 116 DCLASS [DCLASS] object carried in the proxy Resv message. 118 RSVP Receiver Proxy does not change the RSVP protocol. Only a 119 modification in the processing of the RSVP messages is required. 121 This document defines RSVP Receiver Proxy in association with the 122 Null Service Type, but there do not appear to be any obvious problems 123 in using this feature in association with other service types such as 124 the Controlled Load service. For example, PacketCable [DQOS] uses 125 RSVP Receiver Proxy to do admission control for voice in cable 126 networks. 128 RSVP Receiver Proxy does not provide any special support for subflows 129 (a set of packets inside a microflow). Of course, an application may 130 send different Path messages for the same flow at different times, 131 thus providing a support for subflows not overlapping in time. 133 3. RSVP Receiver Proxy: An Example 135 This section illustrates the RSVP Receiver Proxy functionality 136 provided by a network device. The description is focussed mainly on 137 the two fundamental messages in RSVP, i.e. the Path Message and the 138 Resv message. Other messages are discussed in Section 3.3. 140 Figure 1 depicts a simple network topology (two hosts H1 & H2 and 141 intermediate routers, R1-R4) that is used in the description that 142 follows. 144 RSVP Receiver Proxy February 2000 146 Path Message -----> 147 <----- Resv Message 149 +-----+ +-----+ 150 | PS1 | +--| PS1 | 151 +-----+ / +-----+ 152 / | / / 153 / | / / 154 / | / / 155 +----+ +----+ +----+ +----+ +----+ +----+ 156 | H1 |---| R1 |---| R2 |---| R3 |---| R4 |---| H2 | 157 +----+ +----+ +----+ +----+ +----+ +----+ 159 H1 ----> R1 ----> R2 ----> R3 ----> R4 ----> H2 Case A: Normal 160 | RSVP Processing 161 v 162 H1 <---- R1 <---- R2 <---- R3 <---- R4 ----> H2 164 H1 ----> R1 165 | Case B: RSVP Receiver Proxy 166 v 167 H1 <---- R1 169 Hx: Host x 170 Ry: Router y 171 PSz: Policy Server z 173 Figure 1: Possible Message Forwarding Behaviors in RSVP 175 In figure 1 above, case A illustrates the normal RSVP message 176 processing. The Path message goes hop-by-hop from H1 to H2. The Resv 177 message uses the reverse of the path setup by the Path message and 178 goes from H2 to H1. The interaction between the network devices and 179 the policy servers is as specified by COPS for RSVP ([COPS], 180 [COPS-RSVP]). 182 With RSVP Receiver Proxy (case B) the RSVP Path message is terminated 183 by the router R1 acting as a proxy for H2 under the control of a 184 policy server (local policy at R1 could also have been used to 185 achieve the same result). 187 A possible sequence of steps that occurs is as follows: 189 o An application on H1 indicates to the RSVP subsystem that it is a 190 sender wishing to use RSVP. It might specify additional parameters 191 such as traffic characteristics and application specific 192 information. 194 RSVP Receiver Proxy February 2000 195 o This causes the RSVP subsystem on H1 to start transmitting RSVP 196 Path messages in accordance with normal RSVP/SBM rules. 198 o The first hop network device (R1) receives this message and it 199 communicates with the policy server for a decision on how to treat 200 the Path message. It copies all the relevant information contained 201 in the Path message in the request sent to the policy server. 203 o The policy server communicates a decision to R1 to not forward the 204 Path message, but instead to generate and send a Resv message to 205 H1. H1 data traffic can be marked with the right DSCP by the network 206 device if specified by the policy server. The policy server could 207 also specify the list of objects that need to be sent in the Resv 208 message. 210 o On receiving the Resv message, H1 might decide to mark the packets 211 of the traffic flow signaled, according to the DSCP specified in 212 the DCLASS object contained in the Resv. 214 In the example, the Receiver Proxy functionality was placed in the 215 network device that was the first hop from the sender of the Path 216 message. This is a possibility, but it is not a requirement. While 217 designing a network, the following trade-offs should be considered: 219 o Proxying closer to the sender of the Path message reduces turn 220 around time. 222 o Proxying farther from the sender of the Path message enables 223 additional downstream network elements to benefit from the 224 information carried in the signaling messages, and to participate 225 in the response. 227 The network administrator can decide how to make these trade-offs via 228 policy control. 230 3.1 Generation of the Resv message by the Proxy 232 The format of a Resv message generated by the proxy network device is 233 as follows (see [RFC2205] for details): 235 ::= [ ] 236 237 [] [] [...] 238