idnits 2.17.1 draft-hoffman-issll-l2tcreq-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-26) 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 the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Expected the document's filename to be given on the first page, but didn't find any == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 1) being 62 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 a Security Considerations 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.) ** There are 161 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The abstract seems to contain references (5], 6], 3,, [6], 4,, 5,, [1,2,), 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 233: '... forwarding node MUST attempt to forwa...' RFC 2119 keyword, line 313: '...trol environment MUST continue to meet...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 377 has weird spacing: '...er-flow polic...' == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- 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 section? '6' on line 418 looks like a reference -- Missing reference section? '1' on line 399 looks like a reference -- Missing reference section? '2' on line 403 looks like a reference -- Missing reference section? '3' on line 407 looks like a reference -- Missing reference section? '4' on line 411 looks like a reference -- Missing reference section? '5' on line 415 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Don Hoffman 3 INTERNET-DRAFT Sun Microsystems, Inc. 5 Raj Yavatkar 6 Intel Corporation 8 December, 1996 9 Expires: June 30, 1997 11 Integrated-Services/RSVP Requirements for Layer 2 Traffic Control 13 Status of this Memo 15 This document is an Internet-Draft. Internet-Drafts are working documents of 16 the Internet Engineering Task Force (IETF), its areas, and its working 17 groups. Note that other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months and may 21 be updated, replaced, or obsoleted by other documents at any time. It is 22 inappropriate to use Internet-Drafts as reference material or to cite them 23 other than as "work in progress." 25 To learn the current status of any Internet-Draft, please check the 26 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 27 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au 28 (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West 29 Coast). 31 Distribution of this memo is unlimited. 33 Abstract 35 This documents discusses some of the requirements placed on L2 traffic control 36 in IEEE 802-style networks by IP Integrated Services (IntServ) and RSVP 37 signaling. It outlines some of the features of IntServ/RSVP which are of 38 particular relevance to this style of network, and defines the of the 39 requirements that a L2 network must meet to fully support these features. 40 Finally, it discusses certain L2 mechanism which may aid in meeting these 41 requirements. 43 0) What's Changed Since Last Version 45 1) First version of document. 47 1) Introduction 49 This documents discusses some of the requirements placed on L2 traffic control 50 in IEEE 802-style networks by IP Integrated Services (IntServ) and RSVP 51 signaling. It is intended to be used as a condensed set of guidelines for L2 52 systems architects wishing to provide complete support for an IntServ/RSVP 53 infrastructure. 55 For the purposes of discussion, this document hypothesizes various L2 56 mechanisms (especially Section 5). These L2 mechanisms are NOT part of the 57 specification of requirements, and should be taken as suggestions only. This 58 document reflects only the opinions of the authors, and is intended to be 59 used as a starting point for further discussion within the IETF and IEEE 802 60 communities. 62 2) Reference environment 64 For the purposes of the discussion that follows, we make certain assumptions 65 about the reference environment. No claim is made that these are the only 66 valid set of assumptions, and they may be modified after further discussion. 68 First, we assume an IP-based environment that makes use of the 69 following protocols/specifications in their referenced versions: 71 IP multicast and unicast datagram service [Ref needed] 72 RSVP signaling [6] 73 Integrated Controlled Load Service and Guaranteed Service [1, 2, 3, 4, 74 5] 76 We further assume that each IP subnet corresponds to a single L2 "domain". A 77 domain is arbitrarily defined to be the set of nodes and links interconnected 78 without passing through some sort of IP (L3) forwarding function. If new 79 802-proposed mechanisms such as Virtual LANS (VLANs) are employed, then 80 multiple IP subnets (and multiple L2 domains) could reside on a single 81 physical L2 topology. An "edge-device" (ED) is defined to be an IP network 82 element that is a source of or sink for IP traffic for the subnet. An ED can 83 be either a host or a router. Each ED's interface to the L2 network has a 84 unique IP address. Multiple physical interfaces with the same address (as 85 might be used for L2 load balancing) are considered to be a single interface 86 for the purposes of this discussion. Multiple "virtual interfaces" on the 87 same physical interface are considered to be distinct if they have distinct 88 IP addresses. 90 For the purposes of this specification, we will model the L2 domain as a 91 black box, defined as a single logical link with multiple input and output 92 ports. The behavior of this link is assumed to be more complex than strictly 93 FIFO. 95 The following assumptions are defined in order to clarify the intended scope 96 of this document: 98 A L2 domain will be built from an arbitrarily large set of L2 elements 99 such as hubs, switches and shared LAN segments. The number 100 of elements that make up a subnet is allowed to be quite 101 large, and the number of EDs also quite large (say an entire 102 class B address). 104 On certain elements, the maximum possible aggregate input bandwidth 105 may exceed the capacity of any single output port. Similarly, 106 certain L2 links may be shared, and the total possible output 107 bandwidth of all attached devices on to the link may exceed the 108 capacity of the link and any of the input ports of the attached 109 devices. 111 Some of the L2 elements (e.g, switches and bridges) may buffer data 112 on an output port when the offered load exceeds the rate of that 113 port. The amount of buffering on switches is considered to be 114 finite and usually small. 116 A bridge or switch may have varying amounts of intelligence in 117 terms of policing and outgoing queue management. This is, 118 for the most part, considered to be less than the average 119 ED and may be none for certain legacy or very low cost devices. 121 Although all links that make up the L2 topology are considered 122 to be very high speed, their speeds can range over several orders 123 of magnitude. EDs are also considered to support interfaces and 124 transfer rates ranging over several orders of magnitude. 126 3) Integrated Services and RSVP Background 128 Certain key feature of RSVP and the IP Integrated Services architecture are 129 described here as they are believed to be important for a full understanding 130 of L3 requirements. 132 The relevant IETF RFCs and Internet Drafts [1, 2, 3, 4, 5, 6] provide a full 133 description of IP Integrated Services and RSVP and this section is derived 134 from these specifications. 136 Readers already familiar with the above documents may wish to skip to the 137 next section. 139 3.1) RSVP 141 3.1.1) Definition of a flow: The RSVP specification defines a flow as a 142 tuple consisting of the IP destination and source address, an IP protocol ID, 143 and if the protocol is TCP or UDP, the destination and source port number. 144 All but the destination IP address may be defined as a wild-card according to 145 specific rules. Note that a particular IP source and destination address 146 pair may have several flows (each with different flow specifications 147 distinguished by port number) running between them. Also, there may be best 148 effort traffic between these two nodes not associated with any flow. 150 A flow is described by a Tspec and an Rspec. The Tspec describes the nature 151 of the flow coming from the sender, and takes the form of a token bucket 152 specification (r, b) plus a peak rate (p), a minimum policed unit (m) and a 153 maximum packet size (M). It is common to all service types. The Rspec 154 described the required QoS from the receiver, and is specific to the service 155 type (e.g., Controlled Load or Guaranteed Service). A reservation request 156 from a receiver will contain both a TSpec component and an RSpec component. 158 3.1.2) Heterogeneous reservations: Each receiver determines its own flow 159 requirements, and the reservation request from each receiver is free to 160 define a different set of requirements. There are a few restrictions 161 preventing receivers from using different >styles< of reservations, but in 162 general each receiver is free to set any of the parameters of the TSpec or 163 RSpec to receiver-specific values. 165 Note - reservations can differ not only in the TSpec information, but also in 166 the RSpec information (e.g., max delay in the IntServ Guaranteed Service). 168 One form of heterogeneity that will almost always be seen is between 169 receivers that have obtained reservations and those which are satisfied with 170 best effort service (or who have not yet requested the reservation). 172 3.1.3) Policing/reshaping at merge points: In the case of multicast flows, 173 reservations from multiple receivers are, depending on the style of 174 reservation, "merged" at IP multicast branch points as the reservation 175 propagates back up toward the sender. It is then possible that some of the 176 outgoing interfaces at this downstream branch point will not be able to 177 support the full combined flowspec from upstream. 179 For example, a reservation arrives with a TSpec "r" value of 64Kbps on a 180 128Kbps link. Another reservation, with an "r" value of 1Mbps, for the same 181 flow and sender arrives on an ethernet interface on the same router. 182 Admission control on each interface can succeed, and a merged reservation of 183 1Mbps is forwarded toward the sender. A sending ED may offer up to 1Mbps of 184 load toward both the 1Mbps interface and the 128Kbps interface. The slower 185 interface must police this flow to 64Kbps in order to minimize the effects on 186 other traffic on the interface (both reserved and non-reserved). (See Section 187 3.2 discussion on handling of excess traffic.) 189 In addition, a reservation may be "shared" among multiple senders (in the 190 case of WF or SE reservation styles). In such cases, the total possible 191 aggregate offered load from all the senders may exceed the reservation on a 192 single outgoing interface by a significant amount. In certain conferencing 193 applications this can be by a factor of several hundred. The application 194 assumes in this case that some external mechanisms (which may not always be 195 reliable) prevents too many senders from transmitting at once. 197 Finally, the effects of queuing at intermediate systems may cause 198 sufficient traffic rate distortion that a compliant flow no longer 199 remains compliant with the Tspec. 201 Because of these three scenarios, the RSVP/IntServ architecture requires that 202 reshaping and/or policing be done at all source merge points and at 203 heterogeneous branch points. These policing points are known to RSVP and 204 provided to local traffic control mechanisms on each outgoing interface. 206 (Side note - It should be noted, however, that the more extreme cases 207 discussed above will not be common in actual operation.) 209 3.1.4) Scalability: One motivation for RSVP's receiver-orientation 210 is to achieve very large scale multicast fan-out. A key part of this is the 211 merging process mentioned above. It is still uncertain how RSVP will scale 212 on subnets with VERY large fanout within a single hop (many of thousands, as 213 might be seen in a single campus wide L2 topology), where the merging 214 functions are of limited assistance. Although the soft-state refresh 215 interval for RESV messages can be set arbitrarily long, this is in conflict 216 with responsive recovery from certain error conditions. 218 3.2) Integrated Services 220 3.2.1) Controlled Load Service: The basic behavior of a compliant 221 Controlled Load (CL) Service stream is approximated by the behavior visible 222 to applications receiving best-effort service under unloaded conditions. 223 This behavior should be seen by all compliant CL streams even in the case of 224 severe congestion for best-effort traffic. The implication of this is that 225 congestion in the best-effort class should not interfere with CL traffic. 226 This can generally be taken to imply that some sort of priority, traffic 227 limiting or traffic separation scheme should be implemented on each outgoing 228 interface, and if the link is multi-access (i.e., multiple senders), an 229 equivalent scheme should be implemented on the link (or coordinated across 230 all output ports on to the link). 232 The CL specification requires that if a flow is non-conformant to the TSpec, 233 the forwarding node MUST attempt to forward excess traffic on a best-effort 234 basis. Further, non-conformance will not be unusual at merge and branch 235 points and will happen as "a matter of normal operation." Non-conformant 236 traffic must not interfere with conformant CL traffic in other flows. 238 The specification suggests that a marking scheme be used for non-conformant 239 traffic if one is available. 241 In the case of flow non-conformance, the forwarding element is allowed to 242 degrade all the flow's packets equally, or it may sort the flow's traffic into 243 conformant and non-conformant sets. In the latter case the packets in a flow 244 may be reordered by the network elements. 246 3.2.2) Guaranteed Service: The basic behavior of a Guaranteed Service (GS) 247 flow is an assured level of bandwidth that produces a delay-bounded service 248 with no queuing loss for all conforming datagrams. Unlike CL service, there 249 are fairly specific requirements on the behavior of all forwarding elements 250 in the path. Briefly, the end-end behavior conforms to the fluid model 251 within a specified set of error bounds. The GS draft should be consulted for 252 a full understanding of these requirements. 254 As with CL services, traffic is is policed at the edge of the network and 255 non-conforming traffic should be treated as best-effort datagrams (with the 256 same implications with regard to packet reordering). The handling at interior 257 merge and branch point is different, however. In this case, non-conforming 258 flows are "reshaped" by delaying datagrams until the flow is within 259 conformance of the TSpec. Again, reordering is allowed, but the GS 260 specification suggests ways that this can be minimized. 262 4) Layer 2 Requirements 264 Unless otherwise specified, the requirements defined in this section are 265 mandatory for a L2 mapping of IP Integrated Services to be considered 266 compliant. (Note - These are offered for discussion, and my be seriously 267 modified in future versions of the draft) 269 Unless otherwise specified, a compliant L3/L2 mapping must maintain the RSVP 270 and Integrated Services semantics and behavior defined in section 3 for the 271 services it supports (at this time either Controlled Load or Guaranteed 272 Service). This includes semantics not mentioned directly, but covered in 273 referenced specifications. No specific L2 or L3 mechanisms to accomplish 274 this are required by this document. 276 Taken as a black box, the L2 domain can be considered to be a single shared 277 link with multiple input and output interfaces. As such, it can also be 278 considered an implicit merge and split point. The behavior of this link is 279 assumed to be more complex than strictly FIFO. As they are based on a black 280 box model, these requirements do not mandate policing and reshaping in the 281 interior of the L2 domain. (Although it may be desirable. See Section 5.) 282 Nor do they mandate any particular scheduling algorithm. 284 Instead, compliance is measured at the receiving ED, based on IS-compliant 285 behavior at the sending EDs. An L2 traffic control mechanism is considered 286 compliant if the traffic, measured at a point after each receiving ED's input 287 queue, meets the Rspec for the flow, assuming: 289 The flow sources are policed/reshaped at each ED output interface 290 onto the domain according to the appropriate TSpec for that flow. 292 The aggregate flow bandwidth from all sender ED output interface does 293 not exceed the merged Tspec at any particular receiver. Merging is 294 defined to be according to the reservation style in use for that 295 flow. 297 If one of the above assumptions is not met, compliant behavior for the L2 298 traffic control mechanism is not defined. In particular, the second 299 assumption may be violated in the course of normal operation. Several 300 complexities arise from this: 302 The flow may be multicast, and the available bandwidth on each of the 303 receiver input ports may be different (For example, some receivers 304 have 100Mbps input ports, other only have 10Mbps input ports). 305 Consequently, it might be possible for all assumptions to apply to 306 only a subset of the receivers. In this case, a traffic control 307 mechanism is considered compliant if the flow is compliant with the 308 RSpec at the subset of receivers that satisfy all assumptions. 310 These requirements do not mandate that the effective utilized 311 bandwidth at ED input ports be less than the merged (were 312 appropriate) TSpecs for shared reservation styles. But, a compliant 313 L2 traffic control environment MUST continue to meet the Rspec for 314 other flows where the above input assumptions are met. For example, 315 in cases where many senders to a WF flow all send at once, exceeding 316 the merged Tspec at all receivers, compliant behavior for that flow 317 is undefined, and may result in violating the Rspec. A compliant L2 318 traffic control implementation will not cause other flows that do 319 meet the input assumptions to violate the Rspec. 321 An L2 traffic control mechanism may (and probably will) provide some way to 322 limit the total number of reserved flows, or the total amount of bandwidth 323 allowed in that domain. The exact nature of that mechanism and the interface 324 between L3 signaling and the L2 mechanism is outside the scope of this 325 document. 327 As multicast is a key element of many of the applications that make use of 328 Integrated Services, the mechanisms provided in L2 traffic control must scale 329 to the maximum number of nodes anticipated for that domain. 331 5) L2 Pragmatics 333 The approaches discussed in this section are not firm requirements, but are 334 to be taken as suggestions for possible mechanisms for implementing the 335 Integrated Services and RSVP functions over 802-style networks. The 336 implementor or specified of L2 mechanisms is free to employ other 337 approaches. Multiple mechanisms may be suggested in several cases. (Note - 338 These are offered for discussion, and my be seriously modified or dropped in 339 future versions of the draft.) 341 5.1) Policing/reshaping at merge/split points. 343 As mentioned above, a L2 domain is an implicit merge/split point for RSVP 344 flows. As long as the requirements in section 4 are met, there is no 345 specific requirement to do policing or reshaping at these implicit merge 346 points. It is likely, however, that in order to avoid congestion of internal 347 links and ED input ports some sort of policing/reshaping may be desirable 348 internal to the L2 switched environment. Several mechanisms may be possible: 350 The L2 environment may employ sufficiently conservative admission 351 control criteria such that offered loads significantly over the 352 receiver TSpec do not result in congestion or delay bound violation. 353 No policing/reshaping is done. 355 Police/reshape on aggregations of flows. Note that policing 356 mechanisms based on aggregated sets of flows may result in service 357 degradation for conformant flows due to non-conformance by other 358 flows in the same aggregation. 360 Implement IntServ-style per-flow mechanisms in L2. 362 The first two approaches may result in behavior that does not meet 363 the requirements in Section 4. This will be the most problematic for 364 GS, but may provide a useful approximation of CL service in certain 365 environments. (See Section 5.3.) 367 5.2) Flow identification 369 It is probably undesirable to require flow packet classification based on IP 370 header information in all L2 elements. The L2 mechanism may use some sort of 371 information in the L2 header (e.g., VLAN tag, flow tag, COS field or priority 372 bits) to facilitate packet processing in the interior of the L2 domain. In 373 this case, the supplemental L2 header information may be derived based on 374 information provided by the L3 ED, obtained from the IP flow classifier in 375 that node. 377 If full per-flow policing and merging is implemented in the interior of the 378 L2 domain, then the L2 header info must key to a specific IP flow. If no or 379 only loose policing is done then this header information may map to some 380 aggregation of IP flows (e.g., based on service type). 382 Note that policing mechanisms based on aggregated sets of flows may result in 383 service degradation for conformant flows due to non-conformance by other 384 flows. 386 5.3) Service approximation 388 In the above sections, several cases are discussed where extreme cases of 389 receiver heterogeneity and sender fan-in can result in significant issues for 390 a compliant L2 traffic control mechanism. It may be worthwhile to define 391 approximations to full compliance that meet the practical requirements of 392 actual applications in real-life situations. Future versions of this 393 document may talk more specifically on agreed-on approximations. 395 Expires: June 30, 1997 397 References: 399 [1] Braden, R., Clark, D., and S. Shenker, "Integrated Services 400 in the Internet Architecture: an Overview", RFC 1633, ISI, MIT, and 401 PARC, June 1994. 403 [2] S. Shenker and J. Wroclawski. "Network Element QoS Control 404 Service Specification Template". Internet Draft, July 1996, 407 [3] J. Wroclawski, "Specification of the Controlled-Load Network 408 Element Service", Internet Draft, August 1996, 409 411 [4] S. Shenker et. al., "Specification of Guaranteed Quality 412 of Service", Internet Draft, August 1996, 413 415 [5] J. Wroclawski, "Use of RSVP with IETF Integrated Services", 416 Internet Draft, July 1996, 418 [6] B. Braden, et. al. "Resource Reservation Protocol (RSVP) - 419 Version 1 Functional Specification", Internet Draft, July 1996, 420 422 Authors' Addresses: 424 Don Hoffman 425 Sun Microsystems, Inc. 426 MS: UMPK14-305 427 2550 Garcia Avenue 428 Mountain View, California 94043-1100 429 USA 430 phone: +1 503-297-1580 431 email: don.hoffman@eng.sun.com 433 Raj Yavatkar 434 Intel Corporation 435 MS: JF3-206 436 2111 N.E. 25th Avenue, 437 Hillsboro, OR 97124 438 USA 439 phone: +1 503-264-9077 440 email: yavatkar@ibeam.intel.com