idnits 2.17.1 draft-ietf-rsvp-partial-service-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-27) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 2) being 60 lines 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 ([3], [1], [2,4]), 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 81: '...rs a reliable replacement it MUST also...' RFC 2119 keyword, line 88: '...n unreliable replacement it MAY export...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (April 23, 1997) is 9866 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force RSVP WG 3 INTERNET-DRAFT L. Breslau/S. Shenker 4 draft-ietf-rsvp-partial-service-00.txt Xerox PARC 5 April 23, 1997 6 Expires: 10/23/97 8 Partial Service Deployment in the Integrated Services Architecture 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 To learn the current status of any Internet-Draft, please check the 23 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Abstract 30 Specifications for providing enhanced qualities of service in the 31 Internet have been defined in [2,4]. Technical and administrative 32 concerns may prevent a network element from offering one or more of 33 these services. In this document, we present a mechanism for dealing 34 with heterogeneity in the set of services offered by different 35 network elements. This approach enables end-to-end service to be 36 composed of different per-hop services while not requiring end 37 systems to be aware of the details of the service provided at each 38 hop. 40 Introduction 42 The Integrated Services Working Group has produced specifications for 43 new types of service[2,4]. These services will provide enhanced 44 qualities of service to applications that use them. Such services 45 will be most useful when they are provided at all network elements 46 along a data distribution path. However, because these services 47 impose stricter requirements on the network elements than traditional 48 best-effort service, it may not be practical to provide these 49 services on some subnet technologies. Furthermore, the ultimate 50 decision to implement and deploy a particular service belongs to 51 vendors and network service providers, respectively. A vendor may 52 choose not to implement a service, or network service provider may 53 choose not to offer a service (e.g., for administrative reasons), 54 even if the underlying technology is able to support the service. 55 Therefore, newly defined services will not always be available end- 56 to-end along a data distribution path. In this document we describe 57 a strategy for coping with this heterogeneity in the set of services 58 offered in a network. 60 Replacement Services 62 The mechanism for addressing the problem of service heterogeneity is 63 built on the concept of "replacement" services. When a network 64 element does not offer a service, it can offer a replacement service 65 for it. Under circumstances described below, when a network element 66 receives a request for a service it does not offer, it treats the 67 request as if it were for the replacement service. A replacement 68 service can be one of the other real-time services, best-effort 69 service, or a non-compliant implementation of the original service. 70 Decisions about the use of replacement services are a local matter. 72 Replacement services are characterized as either "reliable" or 73 "unreliable". A reliable replacement is one that is expected to meet 74 the requirements of the service being replaced a large majority of 75 the time (e.g., over 95%). No assurance is given about the resulting 76 quality of an unreliable replacement. Since best effort service 77 qualifies as an unreliable replacement in all circumstances, network 78 elements are always able to at least offer unreliable replacements 79 for every service. 81 When a network element offers a reliable replacement it MUST also 82 export meaningful values for any characterization parameters required 83 by the original service. (See [1] and [3] for a discussion of 84 characterization parameters.) These parameters must accurately 85 characterize the replacement service, and when composed end-to-end 86 with parameters from other network elements they must provide 87 applications with a valid characterization of the end-to-end service. 88 When a network element offers an unreliable replacement it MAY export 89 values for any characterization parameters of the original service if 90 it is able to accurately characterize the service. However, given 91 that an unreliable replacement may be arbitrarily bad, the network 92 element may instead set the value of all characterization parameters 93 to the "invalid" values defined for those parameters. 95 We provide the following guidelines for determining whether a network 96 element offers an actual service, a reliable replacement, or an 97 unreliable replacement. 99 Offered Service: In order to claim to offer a service, a network 100 element's implementation of the service must conform to the service 101 specification. Specific conformance requirements are included in the 102 service specification documents (e.g., [2,4]). Some knowledge about 103 the environment in which an implementation is deployed can be used in 104 making this determination. For example, an implementation of 105 Controlled-Load in a router attached to an ethernet may be compliant 106 if all routers and hosts attached to the network participate in a 107 distributed admission control process to reserve resources on the 108 ethernet. However, the same implementation may not be compliant if 109 there are hosts attached to the ethernet that do not participate in 110 the bandwidth allocation procedure. Knowledge of link bandwidth can 111 also be used to determine service compliance. For example, a router 112 may be able to offer a service on an interface using FIFO scheduling 113 and no admission control if the bandwidth on the link exceeds the sum 114 of the input bandwidths on all other links. On the other hand, 115 knowledge about average levels of offered load cannot be used to 116 claim compliance with the currently defined service specifications; 117 the offered service must comply with the service specifications 118 independent of ambient loading. 120 Reliable Replacement: A network element can claim to offer a 121 reliable replacement if it does not offer the actual service but the 122 service it provides is expected to adhere to the specification of the 123 original service a large majority of the time. This determination 124 can take local conditions, including expected load, into account. 125 However, since the semantics of a reliable replacement are that it 126 emulates very closely the actual service, applications using reliable 127 replacements will expect to receive service that is in general not 128 significantly different than the original service. Therefore, the 129 reliable replacement label should be applied to service replacements 130 with caution. Furthermore, since a reliable replacement will often 131 depend on local conditions, and conditions may change over time, 132 network operators should monitor these conditions and continually 133 reassess the suitability of reliable replacements. Finally, note that 134 the ability to provide a reliable replacement may also depend on the 135 availability of appropriate invocation parameters for the replacement 136 service. 138 We offer two examples of reliable replacements. First, a router on a 139 vastly underutilized point-to-point link, which rarely experiences 140 persistent congestion, may offer best effort service as a reliable 141 replacement for Controlled Load service. Second, a router attached 142 to an ethernet that has an otherwise compliant implementation of 143 Controlled Load but has no means to control the load generated by 144 other stations attached to the ethernet may claim to offer a reliable 145 replacement for Controlled Load if the ethernet is not in general 146 highly loaded. 148 Unreliable Replacement: Since unreliable replacements make no 149 assurances about the service they provide, any service qualifies as 150 an unreliable replacement for any other service. Hence, when the 151 actual service or a reliable replacement is not offered, an 152 unreliable replacement can always be offered. For example, best 153 effort service on a congested link qualifies as an unreliable 154 replacement for any real-time service. Applications should have no 155 expectations about the resulting service when they use an unreliable 156 replacement. Finally, additional real-time services may be defined 157 after a particular implementation is deployed. Hence, a network 158 element may not even know about a requested service, so it cannot 159 make an informed decision about the suitability of its offered 160 services (other than best effort) to act as replacements. In such 161 cases, the router can always use best effort as an unreliable 162 replacement. 164 Characterizing Service Offerings 166 Each network element must export characterization parameters 167 describing the various services and replacements that it offers. An 168 example format and composition rules for these characterization 169 parameters are described in the Appendix to this document. 171 Service Handling Flags 173 When characterization parameters are provided end-to-end by a setup 174 protocol, an application will know before issuing a service request 175 whether any replacement services will be substituted for its request. 177 Applications that would be dissatisfied with the level of assurance 178 provided by the resulting service should refrain from issuing service 179 requests when such substitutions would be made. 181 The Integrated Services architecture is intended to allow services to 182 be invoked by more than one setup protocol or by network management 183 functions. Therefore, we cannot assume that end-to-end 184 characterizations of service offerings will always be available to 185 the applications. When they are not, mechanisms are needed so that 186 applications can express to the network elements their willingness to 187 accept replacement services. 189 We propose that application preferences be expressed in a new object 190 that we refer to as the Service Handling Flags, which is optionally 191 included in service requests. These flags are associated with 192 service requests in general, and not with specific services, so they 193 are associated with service_name 0 (just like general 194 characterization parameters). The parameter is a 16-bit value. The 195 most significant bit is set to 1 if service replacements are *not* 196 allowed and 0 if replacements are allowed. The remaining 15 bits are 197 currently unused. 199 Hence, the default router action is to perform replacements when a 200 requested service is not available. In environments where end-to-end 201 characterizations are available (e.g., as with RSVP) the Service 202 Handling Flags are not needed. When end-to-end characterizations are 203 not available, an end system must include the Service Handling Flags 204 with the most significant bit set in order to prevent the use of 205 replacement services. 207 Security Considerations 209 Security considerations are not discussed in this memo. 211 Appendix -- Service Availability Characterization Parameters 213 The following is an example format for characterization parameters 214 describing service availability. 216 An integrated services aware router exports a general 217 characterization parameter for each service that it knows about 218 indicating whether it offers the service, a reliable replacement for 219 the service, or an unreliable replacement for the service. These 220 parameters, when composed end-to-end, inform the endpoints about the 221 end-to-end availability of services. 223 The parameter_name for the local parameter is N. A single router can 224 export multiple characterization parameters with parameter_name N, 225 each corresponding to a different service. The specific service 226 referenced by a particular parameter is identified by a field within 227 the parameter itself. 229 Each local parameter is represented by a sequence of 4 16-bit 230 unsigned integers in network byte order. The first is the 231 service_name for the service referenced by the parameter. The 232 service_name is defined within the service specification for each 233 service (e.g., see [2,4]). The second has the value 1 if the router 234 offers the indicated service and 0 if the router does not offer the 235 service. The third field has the value 1 if the router offers a 236 reliable replacement for the service and 0 if the router does not 237 offer a reliable replacement for the service. The fourth field has 238 the value 1 if the router offers an unreliable replacement for the 239 service and 0 if the router does not offer an unreliable replacement 240 for the service. A router must assign a value of 1 to exactly one of 241 the latter three fields. Guidelines for offering reliable 242 replacements and unreliable replacements are specified earlier in 243 this document. 245 The parameter_name for the composed end-to-end parameter is N+1. The 246 specific service referenced by a particular parameter is specified by 247 a field inside the parameter itself. 249 Each composed parameter is represented by a sequence of 4 16-bit 250 unsigned integers in network byte order. The first is the 251 service_name for the service characterized by the parameter. The 252 second is the number of routers that offer the service. The third is 253 the number of routers that offer reliable replacements for the 254 service. The fourth is the number of routers that offer unreliable 255 replacements for the service. 257 The composition rule for composing a local parameter with a composed 258 parameter is to add the i_th value of the local parameter to the i_th 259 value of the composed parameter, for i = {2,3,4}. Two parameters can 260 be composed only if the first field in each parameter (the 261 service_name) is the same. 263 References 265 [1] S. Shenker and J. Wroclawski. "Specification of General 266 Characterization Parameters", Internet Draft, October 1996, . 269 [2] S. Shenker, C. Partridge and R. Guerin. "Specification of 270 Guaranteed Quality of Service", Internet Draft, February 1997, 271 . 273 [3] S. Shenker and J. Wroclawski. "Network Element Service 274 Specification Template", Internet Draft, November 1996, . 277 [4] J. Wroclawski. "Specification of Controlled-Load Network Element 278 Service", Internet Draft, November 1996, . 281 Authors' Addresses: 283 Lee Breslau 284 Xerox PARC 285 3333 Coyote Hill Road 286 Palo Alto, CA 94304-1314 287 breslau@parc.xerox.com 288 415-812-4402 289 415-812-4471 (FAX) 291 Scott Shenker 292 Xerox PARC 293 3333 Coyote Hill Road 294 Palo Alto, CA 94304-1314 295 shenker@parc.xerox.com 296 415-812-4840 297 415-812-4471 (FAX)