idnits 2.17.1 draft-ietf-intserv-svc-template-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-25) 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 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.) 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.) -- 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) No issues found here. Summary: 7 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Integrated Services WG 2 INTERNET-DRAFT Scott Shenker 3 draft-ietf-intserv-svc-template-00.txt Xerox PARC 4 March, 1995 5 Expires: 9/1/95 7 Network Element Service Specification Template 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet- Drafts as reference 19 material or to cite them other than as ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 23 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 Abstract 29 This document defines a format for specifying services provided by 30 network elements, and available to applications, in an integrated 31 service network. The specification template includes per-element 32 information such as scheduling and admission control requirements, 33 end-to-end information such as composition rules, and evaluation 34 criteria for elements providing the service. 36 Introduction 38 This document presents a format for describing services available 39 within an integrated services network. Each service incorporated into 40 the service model must be described. These service descriptions 41 define what is required of a router (or, more generally, a network 42 element) to support a particular service. They do not describe the 43 behavior of the protocols or mechanisms used to setup flows that use 44 the service, except to describe formal interactions between the 45 network elements and the setup mechanisms. 47 The document uses the terms "network element" and "element" to mean 48 any component of the internetwork which is capable of exercising QOS 49 control over data flowing through it. Network elements might include 50 routers, QOS-aware subnetworks, and end-note operating systems. 52 This document is a product of the Integrated Services working group 53 within the Internet Engineering Task Force. Comments are solicited 54 and should be addressed to the working group's mailing list at 55 intserv@isi.edu and/or the author(s). 57 Template Format 59 The following multipart template will be used for these service 60 descriptions. In what follows, we will describe the content of each 61 of the parts of this template. Note that while the presence or 62 absence of admission control is part of the service description, the 63 nature of the admission control algorithm (if applicable) is not. 65 o Motivation 67 This describes the intended usage of the service, for informational 68 purposes only. 70 o Per-hop Service 72 This is a description of how the packets are handled. These are 73 requirements on, for example, maximal packet delays or bandwidth 74 shares given to a flow. This also includes issues of feedback (as in 75 explicit congestion feedback, where bits in the header must be set or 76 control messages sent). This portion of the service description is 77 the most central aspect (at least for most services) and will require 78 the most care in describing. 80 o Advertisements 82 This is a description of how the services provided by the network 83 element are characterized. In particular, this section describes 84 what information the network element is obliged to give the setup 85 protocols or mechanisms. 87 Note that this section is not tied directly to the one-pass-with- 88 advertising proposal (OPWA) made to the RSVP WG (although OPWA does 89 use it); any service which wants its behavior characterized must make 90 these quantities available. These characterizations are not 91 necessarily the same parameters that were used to invoke the service. 92 These advertisements are provided in response from a request (most 93 likely from either the set-up protocol or the routing protocol). 94 These quantities can either be mandatory (any element offering this 95 service must be able to provide this characterization) or optional. 96 It is assumed that these characterizations are composed along the 97 path, and part of the specification of an advertisement is the 98 composition rule. These composition rules should result in 99 characterizations that are independent of the order in which the 100 element are composed; commutativity and associativity are sufficient 101 but not necessary conditions for this. 103 The issue of exactly how advertisements are used in a specific 104 protocol (e.g., RSVP) is another issue that is best described in the 105 context of that specific protocol. However, the interface to the 106 service module should be flexible enough to allow the request of any 107 and all advertised numbers. 109 o Traffic Specification and Policing 111 For many kinds of network service, flows must provide a specification 112 of their traffic to the network before receiving service. This 113 portion of the service description must both describe the nature of 114 the traffic specification (e.g., a token bucket filter) and the 115 nature of policing (e.g., policing could either drop or delay 116 nonconforming packets) used to enforce adherence to that traffic 117 specification. The description of policing must also describe where 118 that policing is done, which might for example be at the edge of the 119 network only, at every hop, or at all merge points (considering the 120 edge a merge point). The abstractions available to the service 121 module from the set-up protocol about the topology must include these 122 notions of edge and merge points. 124 o Invocation 126 This describes the set of parameters handed to the network element's 127 service control module to invoke the service, and the mapping between 128 those parameter values and the resulting service. For example, one 129 might hand the element a delay target and have the flow mapped into 130 the bounded delay class with the bound closest to that target. This 131 portion of the service description will eventually describe the 132 detailed layout of the bits in the service invocation (but not in 133 this draft). 135 The invocation for all the services listed so far can be broken into 136 two parts, the traffic descriptor (which we will call the TSpec) and 137 the service request descriptor (which we will call the RSpec). For 138 instance, the TSpec might be token bucket filter parameters and the 139 RSpec the level of Predictive service desired. 141 o Ordering 143 The service module must be able to answer questions about the 144 ordering between different service requests. This is used when 145 merging service requests from different receivers. One service 146 request is greater than or equal to another if and only if both its 147 TSpec and its RSpec are greater than or equal. 149 This portion of the service description should also note any ordering 150 relationships with other services. Of course, this portion of the 151 service description must be updated as new services are added to 152 ensure that the entries are complete and consistent. 154 o Resulting Service 156 This is a description of the service that results if all network 157 elements along the path offer the same service. This is for 158 informational purposes only. Its inclusion does not imply that the 159 common case is that all elements offer the same service end-to-end. 160 Rather, there are some services, Guaranteed being the most notable 161 example, where the resulting delay bound is a highly nontrivial 162 result of the concatenation of per-hop services; the purpose of this 163 entry in the template is so that such nontrivial results are not left 164 unrevealed to the reader of this document. 166 o Evaluation Criteria 168 This section describes how to evaluate how well an element implements 169 the particular service. The focus of this section is on tests that 170 can be used to test an element's implementation of a given service. 172 Security Considerations 174 Security considerations are not discussed in this memo. 176 Author's Address: 178 Scott Shenker 179 Xerox PARC 180 3333 Coyote Hill Road 181 Palo Alto, CA 94304-1314 182 shenker@parc.xerox.com 183 415-812-4840 184 415-812-4471 (FAX)