idnits 2.17.1 draft-ietf-issll-nullservice-00.txt: ** The Abstract section seems to be numbered 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: ---------------------------------------------------------------------------- ** 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? == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 8 longer pages, the longest (page 5) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 205 has weird spacing: '...essages for t...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 'M' is mentioned on line 410, but not defined == Unused Reference: 'RFC2205' is defined on line 433, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2216 Summary: 7 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Y. Bernet, Microsoft 3 Expires March 2000 A. Smith, Extreme Networks 4 draft-ietf-issll-nullservice-00.txt B. Davie, Cisco Systems 5 September, 1999 7 Specification of the Null Service Type 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- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet- Drafts as 22 reference 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 The list of Internet- 26 Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Distribution of this memo is unlimited. 31 Copyright Notice 33 Copyright (C) The Internet Society (1999). All Rights Reserved. 35 1. Abstract 37 In the typical RSVP/Intserv model, applications request a specific 38 Intserv service type and quantify the resources required for that 39 service. For certain applications, the determination of service 40 parameters is best left to the discretion of the network 41 administrator. For example, ERP applications are often mission 42 critical and require some form of prioritized service, but cannot 43 readily specify their resource requirements. To serve such 44 applications, we introduce the notion of the 'Null Service'. The 45 Null Service allows applications to identify themselves to network 46 QoS policy agents, using RSVP signaling. However, it does not 47 require them to specify resource requirements. QoS policy agents in 48 the network respond by applying QoS policies appropriate for the 49 application (as determined by the network administrator). This mode 50 of RSVP usage is particularly applicable to networks that combine 51 differentiated service (diffserv) QoS mechanisms with RSVP signaling 52 [intdiff]. In this environment, QoS policy agents may direct the 54 Bernet expires March 2000 1 55 draft-ietf-issll-nullservice-00.txt September, 1999 57 signaled application's traffic to a particular diffserv class of 58 service. 60 2. Motivation 62 Using standard RSVP/Intserv signaling, applications running on hosts 63 issue requests for network resources by communicating the following 64 information to network devices: 66 1. A requested service level (Guaranteed or Controlled Load). 67 2. The quantity of resources required at that service level. 68 3. Classification information by which the network can recognize 69 specific traffic (filterspec). 70 4. Policy/identity information indicating the user and/or the 71 application for which resources are required. 73 In response, standard RSVP aware network nodes choose to admit or 74 deny a resource request. The decision is based on the availability 75 of resources along the relevant path and on policies. Policies 76 define the resources that may be granted to specific users and/or 77 applications. When a resource request is admitted, network nodes 78 install classifiers that are used to recognize the admitted traffic 79 and policers that are used to assure that the traffic remains within 80 the limits of the resources requested. 82 The Guaranteed and Controlled Load Intserv services are not suitable 83 for certain applications that are unable to (or choose not 84 to)specify the resources they require from the network. Diffserv 85 services are better suited for this type of application. Nodes in a 86 diffserv network are typically provisioned to classify arriving 87 packets to some small number of behaviour aggregates (BAs) 88 [diffarch]. Traffic is handled on a per-BA basis. This provisioning 89 tends to be 'top-down' with respect to end-user traffic flows in the 90 sense that there is no signaling between hosts and the network. 91 Instead, the network administrator uses a combination of heuristics, 92 measurement and experience to provision the network devices to 93 handle aggregated traffic, with no deterministic knowledge of the 94 volume of traffic that will arrive at any specific node. 96 In applying diffserv mechanisms to manage application traffic, 97 network administrators are faced with two challenges: 99 1. Provisioning - network administrators need to anticipate the 100 volume of traffic likely to arrive at each network node for each 101 diffserv BA. If the volume of traffic arriving is likely to 102 exceed the capacity available for the BA claimed, the network 103 administrator has the choice of increasing the capacity for the 104 BA, reducing the volume of traffic claiming the BA, or 105 compromising service to all traffic arriving for the BA. 106 2. Classification - diffserv nodes classify traffic to user and/or 107 application, based on the diff-serv codepoint (DSCP) in each 108 packet's IP header or based on other fields in the packet's IP 109 header (source/destination address/port and protocol). The latter 111 Bernet expires March, 2000 2 112 draft-ietf-issll-nullservice-00.txt September, 1999 114 method of classification is referred to as MF classification. 115 This method of classification may be unreliable and imposes a 116 management burden. 118 By using RSVP signaling, the management of application traffic in 119 diffserv networks can be significantly facilitated. (Note that 120 RSVP/diffserv interoperability has been discussed previously in the 121 context of the Guaranteed and Controlled Load Intserv services. This 122 draft focuses on RSVP/diffserv interoperability in the context of 123 the Null Service. 125 3. Operational Overview 127 In the proposed mechanism, the RSVP sender offers the new service 128 type, 'Null Service Type' in the ADSPEC that is included with the 129 PATH message. A new Tspec corresponding to the new service type is 130 added to the SENDER_TSPEC. In addition, the RSVP sender will 131 typically include with the PATH message policy objects identifying 132 the user, application and sub application ID [identity, 133 application]. 135 (Note that at this time, the new Tspec is defined only to carry the 136 maximum packet size parameter (M), for the purpose of avoiding 137 fragmentation. No other parameters are defined.) 139 Network nodes receiving these PATH messages interpret the service 140 type to indicate that the application is requesting no specific 141 service type or quantifiable resources. Instead, network nodes 142 manage the traffic flow based on the requesting user, the requesting 143 application and the type of application sub-flow. 145 This mechanism offers significant advantages over a pure diffserv 146 network. At the very least, it informs each network node which would 147 be affected by the traffic flow (and which is interested in 148 intercepting the signaling) of: 150 1. The demand for resources in terms of number of flows of a 151 particular type traversing the node. 152 2. The binding between classification information and user, 153 application and sub-application. 155 This information is particularly useful to policy enforcement points 156 and policy decision points (PEPs and PDPs). The network 157 administrator can configure these elements of the policy management 158 system to apply appropriate policy based on the identity of the 159 user, the application and the specific sub application ID. 161 PEPs and PDPs may be configured to return an RSVP RESV message to 162 the sender. The returned RESV message may include a DCLASS object 163 [dclass]. The DCLASS object instructs the sender to mark packets on 164 the corresponding flow with a specific DSCP (or set of DSCPs). This 165 mechanism allows PEP/PDPs to affect the volume of traffic arriving 167 Bernet expires March, 2000 3 168 draft-ietf-issll-nullservice-00.txt September, 1999 170 at a node for any given BA. It enables the PEP/PDP to do so based on 171 sophisticated policies. 173 3.1 Operational Notes 175 3.1.1 Scalability Issues 177 In any network in which per-flow signaling is used, it is wise to 178 consider scalability concerns. The Null Service encourages signaling 179 for a broader set of applications than that which would otherwise be 180 signaled for. However, RSVP signaling does not, in general, generate 181 a significant amount of traffic relative to the actual data traffic 182 associated with the session. In addition, the Null Service does not 183 encourage every application to signal. It should be used by 184 applications that are considered mission critical or needing QoS 185 management by network administrators. 187 Perhaps of more concern is the impact on processing resources at 188 network nodes that process the signaling messages. When considering 189 this issue, it's important to point out that it is not necessary to 190 process the signaling messages at each network node. In fact, the 191 combination of RSVP signaling with diff-serv networks may afford 192 significant benefits even when the RSVP messages are processed only 193 at certain key nodes (such as boundaries between network domains, 194 first-hop routers, PEPs or any subset of these). Individual nodes 195 should be enabled or disabled for RSVP processing at the discretion 196 of the network administrator. See [intdiff] for a discussion of the 197 impact of RSVP signaling on diff-serv networks. 199 In any case, per-flow state is not necessarily required, even in 200 nodes that apply per-flow processing. 202 3.1.2 Policy Enforcement in Legacy Networks 204 Network nodes that adhere to the RSVP spec should transparently pass 205 signaling messages for the Null Service. As such, it is possible to 206 introduce a small number of PEPs that are enabled for Null Service 207 into a legacy network and to realize the benefits described in this 208 draft. 210 3.1.3 Combining Existing Intserv Services with the Null Service 212 This draft does not preclude applications from offering both a 213 quantitative Intserv service (Guaranteed or Controlled Load)and the 214 Null Service, at the same time. An example of such an application 215 would be a telephony application that benefits from the Guaranteed 216 Service but is able to adapt to a less strict service. By 217 advertising its support for both, the application enables network 218 policy to decide which service type to provide. 220 4. Signaling Details 222 4.1 ADSPEC Generation 224 Bernet expires March, 2000 4 225 draft-ietf-issll-nullservice-00.txt September, 1999 227 The RSVP sender constructs an initial RSVP ADSPEC object specifying 228 the Null Service Type. Since there are no service specific 229 parameters associated with this service type, the associated ADSPEC 230 fragment is empty and contains only the header word. Network nodes 231 may or may not supply valid values for bandwidth and latency general 232 parameters. As such, they may use the unknown values defined in 233 [RFC2216]. 235 The ADSPEC is added to the RSVP PATH message created at the sender. 237 4.2 RSVP SENDER_TSPEC Object 239 An additional Tspec is defined to correspond to the Null Service. If 240 only the Null Service is offered in the ADSPEC, then this is the 241 only Tspec included in the SENDER_TSPEC object. If guaranteed or 242 controlled load services are also offered in the ADSPEC, then the 243 new Tspec is appended following the standard Intserv token-bucket 244 Tspec [RFC2210]. 246 4.3 RSVP FLOWSPEC Object 248 Receivers may respond to PATH messages by generating an RSVP RESV 249 message including a FLOWSPEC object. The FLOWSPEC object should 250 specify that it is requesting the Null Service. It is possible that, 251 in the future, a specific Rspec may be defined to correspond to the 252 new service type. 254 5. Detailed Message Formats 256 5.1 Standard ADSPEC Format 258 A standard RSVP ADSPEC object is described in [RFC2210]. It includes 259 a message header and a default general parameters fragment. 260 Following the default general parameters fragment are fragments for 261 each supported service type. 263 5.2 ADSPEC for Null Service Type 265 The Null Service ADSPEC includes the message header and the default 266 general parameters fragment, followed by a single fragment denoting 267 the Null Service. The new fragment introduced for the Null Service 268 is formatted as follows: 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | 6 (a) |x| Reserved | 0 (b) | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 a - indicates Null Service (6). 275 x - is the break-bit. 276 b - indicates zero words in addition to the header. 278 Bernet expires March, 2000 5 279 draft-ietf-issll-nullservice-00.txt September, 1999 281 A complete ADSPEC supporting only the Null Service is illustrated 282 below: 283 31 24 23 16 15 8 7 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 1 | 0 (a) | Reserved | Msg length �1 (b) | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 2 | 1 (c) |x| Reserved | 8 (d) | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 3 | 4 (e) | (f) | 1 (g) | 290 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 4 | IS hop cnt (32-bit unsigned) | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 5 | 6 (h) | (i) | 1 (j) | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 6 | Path b/w estimate (32-bit IEEE floating point number) | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 7 | 8 (k) | (l) | 1 (m) | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 8 | Minimum path latency (32-bit integer) | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 9 | 10 (n) | (o) | 1 (p) | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 10 | Composed MTU (32-bit unsigned) | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 11 | 6 (q) |x| Reserved | 0 (r) | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 Word 1: Message Header: 309 (a) - Message header and version number 310 (b) - Message length - 10 words not including header 312 Words 2-10: Default general characterization parameters 313 (c) - Per-Service header, service number 1 (Default General 314 Parameters) 315 (x) - Global Break bit (NON_IS_HOP general parameter 2) 316 (d) - Length of General Parameters data block (8 words) 317 (e) - Parameter ID, parameter 4 (NUMBER_OF_IS_HOPS general 318 parameter) 319 (f) - Parameter 4 flag byte 320 (g) - Parameter 4 length, 1 word not including header 321 (h) - Parameter ID, parameter 6 (AVAILABLE_PATH_BANDWIDTH general 322 parameter) 323 (i) - Parameter 6 flag byte 324 (j) - Parameter 6 length, 1 word not including header 325 (k) - Parameter ID, parameter 8 (MINIMUM_PATH_LATENCY general 326 parameter) 327 (l) - Parameter 8 flag byte 328 (m) - Parameter 8 length, 1 word not including header 329 (n) - Parameter ID, parameter 10 (PATH_MTU general parameter) 330 (o) - Parameter 10 flag byte 331 (p) - Parameter 10 length, 1 word not including header 333 Word 11: Null Service parameters 335 Bernet expires March, 2000 6 336 draft-ietf-issll-nullservice-00.txt September, 1999 338 (q) - Per-Service header, service number 6 (Null) 339 (x) - Break bit for Null Service 340 (r) - Length (0) of per-service data not including header word. 342 Note that the standard rules for parsing ADSPEC service fragments 343 ensure that the ADSPEC will not be rejected by legacy network 344 elements. Specifically, these rules state that a network element 345 encountering a per-service data header which it does not understand 346 should set bit 23 (the break-bit) to indicate that the service is 347 not supported and should use the length field from the header to 348 skip over the rest of the fragment. 350 Also note that it is likely that it will not be possible for hosts 351 or network nodes to generate meaningful values for words 5 and/or 7 352 (bandwidth estimates and path latency), due to the nature of the 353 service. In this case, the unknown values from [RFC2216] should be 354 used. 356 5.3 SENDER_TSPEC Object Format 358 The following Tspec is defined to correspond to the Null Service: 360 31 24 23 16 15 8 7 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 1 | 6 (a) |0| Reserved | 2 (b) | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 2 | 128 (c) | 0 (d) | 1 (e) | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 3 | Maximum Packet Size [M] (32-bit integer) | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 Word 1: Service header 370 (a) - Service number 6 (Null Service) 371 (b) - Length of per-service data, 2 words not including per-service 372 header 374 Word 2-3: Parameter 375 (c) - Parameter ID, parameter 128 (Null Service TSpec) 376 (d) - Parameter 128 flags (none set) 377 (e) - Parameter 128 length, 1 words not including parameter header 379 Note that the illustration above does not include the standard RSVP 380 SENDER_TSPEC object header, nor does it include the sub-object 381 header (which indicates the message format version number and 382 length), defined in RFC 2205 and RFC 2210, respectively. 384 In the case that only the Null Service is advertised in the ADSPEC, 385 the Tspec above would be appended immediately after the SENDER_TSPEC 386 object header and sub-object header. In the case that additional 387 service types are advertised, requiring the token bucket specific 388 Tspec defined in RFC2210, the Tspec above would be appended 389 following the token bucket Tspec, which would in turn follow the 390 object header and sub-object header. 392 Bernet expires March, 2000 7 393 draft-ietf-issll-nullservice-00.txt September, 1999 395 5.4 FLOWSPEC Object Format 397 The format of an RSVP FLOWSPEC object originating at a receiver 398 requesting the Null Service is shown below. The value of 6 in the 399 per-service header (field (c), below) indicates that Null Service is 400 being requested. 402 31 24 23 16 15 8 7 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 1 | 0 (a) | reserved | 3 (b) | 405 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 2 | 6 (c) |0| Reserved | 2 (d) | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 3 | 128 (e) | 0 (f) | 1 (g) | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 4 | Maximum Packet Size [M] (32-bit integer) | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 (a) - Message format version number (0) 414 (b) - Overall length 3 words not including header) 415 (c) - Service header, service number 6 (Null) 416 (d) - Length of data, 2 words not including per-service header 417 (e) - Parameter ID, parameter 128 (Null Service TSpec) 418 (f) - Parameter 128 flags (none set) 419 (g) - Parameter 128 length, 1 words not including parameter header 421 5.5 DCLASS Object Format 423 DCLASS objects may be included in RESV messages. For details 424 regarding the DCLASS object format, see [dclass]. 426 6. Security Considerations 428 The message formatting and usage rules described in this note raise 429 no new security issues beyond standard RSVP. 431 9. References 433 [RFC2205] Braden, B., et al., "Resource Reservation Protocol (RSVP) 434 - Version 1 Functional Specification", RFC 2205, September 1997. 436 [RFC2216] Shenker, S., and Wroclawski, J., "Network Element QoS 437 Control Service Specification Template", RFC 2216, September 1997. 439 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 440 Services", RFC 2210, September 1997. 442 [intdiff] Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L., 443 Nichols, K., Speer, M., Braden, B., Davie, B., "Integrated Services 444 Operation over Diffserv Networks", Internet Draft, June 1999. 446 Bernet expires March, 2000 8 447 draft-ietf-issll-nullservice-00.txt September, 1999 449 [diffarch] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 450 Weiss, W., "An Architecture for Differentiated Services", RFC 2475, 451 December 1998. 453 [identity] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, 454 T., Herzog, S., "Identity Representation for RSVP", Internet Draft, 455 February 1999. 457 [application] Bernet, Y., "Application and Sub Application Identity 458 Policy Objects for Use with RSVP", Internet Draft, February 1999. 460 [dclass] Bernet, Y., "Usage and Format of the DCLASS Object with 461 RSVP Signaling", Internet Draft, June 1999. 463 10. Acknowledgments 465 We thank Fred Baker, Dinesh Dutt, Nitsan Elfassy, John Schnizlein, 466 Ramesh Pabbati and Sanjay Kaniyar for their comments on this draft. 468 11. Author's Addresses 470 Yoram Bernet 471 Microsoft 472 One Microsoft Way 473 Redmond, WA 98052 474 (425) 936-9568 475 Yoramb@microsoft.com 477 Andrew Smith 478 Extreme Networks 479 3585 Monroe St. 480 Santa Clara CA 95051 481 USA 482 +1 (408) 579 2821 483 andrew@extremenetworks.com 485 Bruce Davie 486 Cisco Systems 487 250 Apollo Drive 488 Chelmsford, MA 01824 489 (978)-244-8000 490 bsd@cisco.com 492 Bernet expires March, 2000 9