idnits 2.17.1 draft-ietf-intserv-data-encoding-01.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-19) 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 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.) ** There are 3 instances of too long lines in the document, the longest one being 3 characters in excess of 72. 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 J. Wroclawski 3 draft-ietf-intserv-data-encoding-01.txt MIT LCS 4 November, 1995 5 Expires: 6/96 7 Standard Data Encoding for Integrated Services Objects 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 Shadow 23 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 This draft is a product of the Integrated Services Working Group of 28 the Internet Engineering Task Force. Comments are solicited and 29 should be addressed to the working group's mailing list at int- 30 serv@isi.edu and/or the author(s). 32 Abstract 34 A number of data objects must be transmitted between end-nodes and 35 network elements to support resource reservation in an integrated 36 services internet. This document provides some background 37 requirements and specifies preferred transmission encodings for 38 these objects, which include RSpecs, TSpecs, characterization 39 paramters, and composition function intermediate parameters. 41 Introduction 43 Support for end-to-end resource reservation and controlled qualities 44 of service requires that several types of information be communicated 45 between end-nodes and intermediate network elements. This information 46 may include characterizations of the traffic to be sent over that 47 path, requests for a specific level of service, characterizations of 48 the chosen data path, and other related data. 50 The specifics of this communication depend heavily on the mechanisms 51 being used to set up and reserve resources for QoS-controlled paths. 52 The same integrated services building blocks may be used to support a 53 range of different setup protocols, reservation styles, and 54 management functions. Data and message formats designed for use with 55 these building blocks must be able to support this varied use. 57 This note provides some background information about the requirements 58 of the integrated services data transport formats. It then describes 59 a general set of encoding rules which, together with the information 60 contained in a particular service specification document, specify the 61 preferred wire encoding format for the data associated with that 62 service. Finally, it gives some usage examples for these rules. 64 Background and Requirements 66 Current IETF integrated services documents discuss four types of data 67 objects: 69 - Traffic Specifications, or TSpecs, describe a flow of data 70 traffic. This may be the traffic generated by a data source, the 71 traffic expected by a data receiver, or the traffic subject to a 72 resource reservation at an intermediate network element. 74 - Request Specifications, or RSpecs, describe a request for a 75 specific QoS control service. This may be request being placed by 76 an application or end-node, or it may be a request delivered to a 77 particular intermediate network element. 79 - Characterization Parameters are specific parameters made 80 available by the service module at an end-node or intermediate 81 network element for the purpose of characterizing the end-to-end 82 QoS delivered over a data path. The parameters made available by a 83 service module are a function of the service that module 84 implements. 86 - Composition variables are the intermediate variables and end 87 results of composition functions; the functions which process per- 88 hop characterization parameters to compute end-to-end path 89 characterizations. 91 NOTE: Traffic Specifications, Request Specifications and 92 Characterization Parameters are defined further in [the template 93 document]. The phrase "Composition Variables", or equivalent, is 94 not currently defined in current version of that document, but 95 will be included inthe next version. 97 NOTE: Additional types of data objects may be defined in the 98 future. 100 These objects may be used in a variety of different ways, depending 101 on the situation. Some examples are listed below: 103 - A routing protocol might query network elements for certain 104 characterization parameters, such as link bandwidth or delay. 105 This protocol would make no use of RSpecs or TSpecs, and may or 106 may not use composition variables. 108 - A management station setting up a quasi-permanant flow might 109 transmit RSpecs (specifying the requested service) and TSpecs 110 (specifying the level of traffic for which the service is 111 requested) directly from a central point to each of a number of 112 network elements. 114 - A one-pass receiver based resource reservation protocol such as 115 RSVP might do the following: 117 o Transmit TSpecs describing each sender's traffic from the 118 sender to intermediate network elements. 120 o Compute end-to-end characterizations in the sender-to- 121 receiver direction, by collecting characterization parameters 122 at the sending end-node and intermediate elements, executing 123 composition functions at the intermediate nodes, and 124 transmitting composition variables from senders towards 125 receivers. 127 o Transmit an RSpec (describing each receiver's desired 128 reservation request) and a TSpec (describing the traffic 129 parameters for which each receiver desires this level of 130 service) from each receiver to intermediate network elements. 132 o Compute an appropriate RSpec and TSpec for each network 133 element, based on the protocol's rules, and attempt to reserve 134 resources based on that RSpec and TSpec. 136 - A two-pass sender-based setup protocol such as ST-II might do 137 the following: 139 o On pass one, transmit each sender's RSpec (describing the 140 sender's service request) and TSpec (describing the sender's 141 traffic generation pattern) into the network. 143 o On pass one, compute end-to-end characterizations in the 144 sender-to-receiver direction, by collecting characterization 145 parameters at the sending end-node and intermediate elements, 146 executing composition functions at the intermediate nodes, and 147 transmitting composition variables from senders towards 148 receivers. 150 o Between passes, compute a final RSpec and TSpec for the 151 resource reservation request, based on information collected in 152 pass one. 154 o On pass two, carry the final RSpec and TSpec from the 155 receiver towards the sender, placing reservations using these 156 parameters. 158 These differing examples show that a single protocol message may 159 contain one, some, or all of these data objects. For this reason, 160 the format described below is self-parsing at the object level. 162 The examples also show that a single protocol message may be 163 required to carry objects relating to several services at the same 164 time. For example, a one-pass reservation protocol such as RSVP may 165 transport composition variables for several services from sender to 166 receiver to more fully characterize the path. For this reason, the 167 format described below has a two-level structure which can carry 168 objects from multiple services simultaneously. 170 Message Format 172 This section describes the preferred wire format for protocol 173 messages used to transmit integrated services data objects. It 174 provides rules constructing the overall data format for carrying 175 integrated messages. The data contained *within a specific object* is 176 unique to the service defining the object, and is described in the 177 service definition. To fully interpret a message, the recipient must 178 understand both the overall format presented here and the data 179 objects defined by the specific service. However, the format is 180 self-parsing at the service level, so that objects belonging to an 181 unknown service may be ignored entirely. 183 All fields described below are drawn and transmitted in big-endian 184 "network byte order". 186 The overall representation consists of a 32-bit header specifying the 187 version number and total length of the message, followed by any 188 number of service-specific data blocks. The overall message must be 189 aligned to a 32-bit boundary within the protocol's data packet. The 190 message length is measured in 32-bit words *not including the word 191 containing the header*. 193 Each service-specific data block begins with a 16-bit header 194 containing the service number and length field, followed by the 195 service-specific parameters. The length field specifies the number of 196 32-bit words used to hold data specific to this service as a count of 197 32-bit words *not including the word containing the header*. Note 198 that the alignment rules described below ensure that the 16-bit 199 service header will always be aligned to a 32-bit boundary. 201 Each parameter within a service-specific data block is identified by 202 a 16-bit parameter-id header containing the parameter identifier 203 (parameter number) and a flag field. The data field(s) of the 204 parameter follow. The parameter's ID number, as well as the meaning, 205 data format, and location of each data field within the parameter, 206 are given by the specification which defines the parameter. The 207 placement and alignment of a parameter's data fields within the 208 message is specified by the alignment rules below. 210 Within a service-specific data block, parameter headers and parameter 211 data fields are aligned to their natural boundaries (16 bit fields 212 aligned to a 16 bit boundary, etc.) by pre-padding with zero bytes if 213 required. Note that this implies that parameter headers are aligned 214 only to the nearest 16-bit boundary. Within a service-specific data 215 block, all parameter headers after the first may appear in either the 216 high-order or low-order 16 bits of a 32-bit word, depending on where 217 the data field(s) of the previous parameter end. 219 If the last field of the last parameter in a service-specific data 220 block does not end on a 32 bit boundary the data block is padded to 221 the next 32-bit boundary with zero bytes. 223 Message Header Field 225 31 28 27 16 15 0 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | V | Unused | OVERALL LENGTH | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 V - Flowspec version; currently 0 231 OVERALL LENGTH - Overall length in 32-bit words not including header 233 Service-Specific Data Header Field 235 15 8 7 0 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | SVC_NUMBER | LENGTH | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 SVC_NUMBER - Service ID number (defined in service specification) 241 LENGTH - Service-specific data length in 32-bit words, 242 not including header. 244 Parameter-ID Header 246 15 8 7 0 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | PARAM_NUM | PARAM_FLAGS | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 I 251 n 252 v 254 PARAM_NUM - Parameter ID number (defined in service specification) 255 PARAM_FLAGS - Flags. Currently: 256 INV (Invalid) (bit 7) - This parameter may be invalid. 258 Examples 260 Shown below is an example message carrying both a TSpec (parameter 1) 261 and RSpec (parameter 2) for service number 2. This message might be 262 contained within a FLOWSPEC object in the RSVP protocol. 264 31 24 23 16 15 8 7 0 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | 0 (a) | Unused | 5 (b) | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | 2 (c) | 4 (d) | 1 (e) | 0 (f) | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | 16-bit TSpec field | zero padding | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | 32-bit TSpec field | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | 16-bit TSPec field | 16-bit TSpec field | 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | 2 (g) | 0 (h) | 16-bit RSpec field | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 (a) - Version number (0) 280 (b) - Overall length (6 words not including header) 281 (c) - Service header, service number 2 282 (d) - Length of per-service data, 5 words not including header 283 (e) - Parameter ID, parameter 1 (TSpec) 284 (f) - Parameter 1 flags (none set) 285 (g) - Parameter ID, parameter 2 286 (h) - Parameter 2 flags (none set) 288 Shown below is an example message carrying characterization 289 information for two different services simultaneously. This message 290 might be contained within an ADSPEC object in the RSVP protocol. 292 31 24 23 16 15 8 7 0 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | 0 (a) | Unused | 7 (b) | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | 10 (c) | 3 (d) | 17 (e) | 0 (f) | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | 32-bit characterization parameter value | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | 18 (g) |1(h) | zero padding | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | 32-bit characterization parameter value | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | 11 (i) | 2 (j) | 17 (k) | 0 (l) | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | 16-bit parameter 17 value | 18 (m) | 0 (n) | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | 16-bit parameter 18 value | zero padding | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 (a) - Version number (0) 312 (b) - Overall length, 7 words not including header 313 (c) - Service header, indicates service number 10 314 (d) - Length of per-service data, 3 words not including header 315 (e) - Parameter ID, indicates characterization parameter 17 316 (f) - Parameter 17 flags (none set) 317 (g) - Parameter ID, indicates characterization parameter 18 318 (h) - Parameter 18 flags. INVALID flag set. 319 (i) - Service header, indicates service number 11 320 (j) - Length of per-service data, 2 words not including header 321 (k) - Parameter ID, indicates characterization parameter 17 322 (l) - Parameter 17 flags (none set) 323 (m) - Parameter ID, indicates characterization parameter 18 324 (n) - Parameter 18 flags (none set) 326 Security Considerations 328 Security considerations are not discussed in this memo. 330 Authors' Address: 332 John Wroclawski 333 MIT Laboratory for Computer Science 334 545 Technology Sq. 335 Cambridge, MA 02139 336 jtw@lcs.mit.edu 337 617-253-7885 338 617-253-2673 (FAX)