idnits 2.17.1 draft-ghanwani-istr-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 6 months document validity. ** 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 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character 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.) -- The document date (3 June 1996) is 10190 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' -- No information found for draft-ietf-ipnwg-token-ring - is the name correct? -- Possible downref: Normative reference to a draft: ref. '4' Summary: 10 errors (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force A. Ghanwani 2 INTERNET DRAFT J. W. Pace 3 V. Srinivasan 4 IBM 5 3 June 1996 7 Integrated Services over Token Ring Networks 8 draft-ghanwani-istr-00.txt 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 18 months, and may be updated, replaced, or obsoleted by other documents 19 at any time. It is not appropriate to use Internet Drafts as 20 reference material, or to cite them other than as a ``working draft'' 21 or ``work in progress.'' 23 To learn the current status of any Internet-Draft, please check 24 the ``1id-abstracts.txt'' listing contained in the internet-drafts 25 Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net 26 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 27 Rim). 29 Abstract 31 The RSVP and Integrated Services working groups have been working 32 towards the goal of an "Integrated Services Internet" where 33 applications can request a Quality of Service (QoS) from the network 34 in order to meet their end-to-end service requirements. This 35 document reviews various issues related to supporting Integrated 36 Service models over token ring networks. It also describes 37 features of token ring networks that can be leveraged to provide 38 QoS guarantees. It is intended as a starting point for building 39 an architectural framework to support these services in token ring 40 environments. 42 1. Introduction 44 The Internet is soon expected to carry significant amounts of 45 multimedia traffic requiring end-to-end Quality of Service (QoS) 46 guarantees. In anticipation of this transition from largely 47 data-oriented traffic to multimedia traffic with QoS over the 48 Internet, the IETF is studying several service definitions within 49 the Integrated Services (INTSERV) working group. These service 50 definitions are called Guaranteed Delay, Predictive, Controlled 51 Delay, and Controlled Load. The QoS guarantees that these services 52 provide to flows range from the very stringent Guaranteed Delay 53 service to the minimal -- "better than best effort" -- Controlled 54 Load service. 56 The Internet spans a wide range of subnetwork technologies, from 57 dedicated, high bandwidth, router-to-router, point-to-point links 58 to shared LANs and dialup SLIP/PPP connections. This range of 59 subnetworks continues to expand with the advent of new technologies 60 such as ATM. Consequently, to be able provide a multimedia session 61 with end-to-end guaranteed QoS over the Internet, we must be able to 62 support the Integrated Services on any subnetwork that the session 63 might traverse. To this end, the IETF recently formed the Integrated 64 Services over Specific Link Layers (ISSLL) proto-working-group 65 to develop techniques and guidelines needed to support Internet 66 Integrated Service capabilities on specific network technologies. 67 The purpose of this document is to describe some of the issues 68 related to supporting Integrated Services over token ring networks. 69 Token ring networks possess many features such as source routing and 70 frame priorities that differentiate them from other shared media 71 LAN technologies. In this document, we will identify key features 72 of token rings that may be exploited in order to provide Integrated 73 Services and describe a possible framework for supporting QoS in a 74 shared environment. 76 2. Source Routing 78 The token ring MAC frame format is shown in Figure 1. 80 --------------------------------------------------------------------- 81 | SD | AC | FC | DA | SA |Routing Info.|Info. field| FCS | ED | FS | 82 --------------------------------------------------------------------- 84 Figure 1: Token ring Network Frame Format. SD is the starting 85 delimiter; AC is the access control field; FC is the frame control field; 86 ED is the ending delimiter; and FS is the frame status field. 88 Source routing is an important feature that differentiates token ring 89 networks from other LAN types. In source routing, each frame carries 90 information about the route it will follow through a multiple-segment 91 bridged network. This information is specified in the optional 92 Routing Information (RI) field in the frame. The RI field (RIF) 93 can be up to 32 bytes. When the RIF is included by the station 94 originating the frame, bridges processing the frame examine this 95 field to determine how to forward the frame. 97 The RIF is made up of a 2 byte control field, followed by up to 30 98 bytes of Route Designator (RD) fields. The control field contains: 99 - the type of frame, 100 - length of the RIF, 101 - direction in which to process the RIF, and 102 - largest-size information field that can be transmitted between two 103 communicating stations on a specific route. 105 Each segment in a given multiple-segment network is assigned a unique 106 ring number, and each bridge is assigned a number which may or may 107 not be unique. Together, a (ring number, bridge number) pair make up 108 a route designator. The RD fields in the RIF are made up of these 109 pairs that specify the frame's path through the network. 111 There are three token ring frame types that can be specified in the 112 control portion of the RIF: 113 - Specifically Routed Frame (SRF): this indicates that the RD fields 114 contain a specific route for the frame to traverse the network. 115 - All Routes Explorer (ARE): this indicates that the frame will be 116 transmitted along every route in the network to the destination 117 station. Frames transmitted as ARE will result in as many copies 118 being delivered to the destination as there are different routes to 119 the destination station. 120 - Spanning Tree Explorer (STE): this indicates that only certain 121 designated bridges (the ones on the spanning tree) will relay the 122 frame from one segment to another with the result that the frame will 123 appear exactly once on every segment in the network. 125 When an ARE or STE frame is transmitted, each bridge that forwards 126 the frame to another ring adds its bridge number and that ring's 127 number to the frame's RIF. When such a frame reaches its destination, 128 the routing information in the frame indicates the path taken by the 129 frame through the network. This routing information can be used 130 for subsequent communication between the stations, eliminating the 131 need to broadcast frames and conserving network bandwidth. In this 132 manner, source routing provides a dynamic mechanism to select routes 133 between stations in a token ring network. This feature can be used 134 in conjunction with a resource allocation mechanism, such as the one 135 described in the last section, to perform "QoS routing" of RSVP flows 136 through multiple ring networks. 138 3. Token Priority 140 The token ring standard [1] provides a priority mechanism that can 141 be used to control both the queuing of packets for transmission and 142 the access of packets to the shared media. The priority mechanisms 143 are implemented using bits within the Access Control (AC) and the 144 Frame Control (FC) fields of a LLC frame. The first three bits of 145 the AC field, the Token Priority bits, together with the last three 146 bits of the AC field, the Reservation bits, regulate which stations 147 get access to the ring. The last three bits of the FC field of an 148 LLC frame, the User Priority bits, are obtained from the higher 149 layer when it requests transmission of a packet. The requested 150 user priority establishes the requested access priority. The user 151 priority is conveyed end-to-end by the User Priority bits in the FC 152 field. In all cases, B'000' is the lowest priority. 154 A token ring station is theoretically capable of separately queuing 155 each of the eight levels of requested user priority and then 156 transmitting frames in order of priority. A station sets Reservation 157 bits according to the user priority of frames that are queued 158 for transmission in the highest priority queue. This allows the 159 access mechanism to ensure that the frame with the highest priority 160 throughout the entire ring will be transmitted before any lower 161 priority frame. Annex I to the IEEE 802.5 token ring standard 162 ([1]) recommends that stations queue MAC frames and LAN management 163 frames with a user priority of 7 and 4, respectively. For LLC 164 frames, the annex recommends that time sensitive traffic (e.g., 165 video playback) be queued with user priority 5, real time critical 166 service traffic (e.g., interactive video) with user priority 6, and 167 non-time critical traffic with user priority 0. Priorities 1-3 168 are left for use by other user traffic. To reduce frame jitter 169 associated with high-priority traffic, the annex also recommends 170 that only one frame be transmitted per token and that the maximum 171 information field size be 4399 octets whenever delay-sensitive 172 traffic in traversing the ring. Most existing implementations of 173 token ring bridges forward all LLC frames with a default access 174 priority of 4. Annex I recommends that bridges forward LLC frames 175 that have a user priorities greater that 4 with a reservation equal 176 to the user priority. (The draft IEEE Standard P802.1p ([2]) permits 177 network management to control whether bridges forward frames with the 178 outbound user priority set to the same value as received in the user 179 priority field. It also describes the forwarding process for bridges 180 that support traffic classes and multiple queues.) The capabilities 181 provided by token ring's user and reservation priorities and by IEEE 182 802.1p can provide effective support for Integrated Services flows 183 that request QoS using RSVP. These mechanisms can provide, with few 184 or no addition to the token ring architecture, bandwidth guarantees 185 and the network flow control necessary to support quarantees. 187 4. Multicast Addressing 189 RSVP is designed to inherently support multicast IP destination 190 addresses. References [3] and [4] define methods for mapping 191 multicast IP addresses (respectively) to multicast MAC addresses 192 for use on all IEEE 802 LANs and to functional addresses for use on 193 token ring networks. IEEE Standard 802.1p is also defining a method 194 to support the filtering of multicast MAC addresses by LAN bridges 195 and switches. With a fully implemented network of 802.1p compliant 196 bridges, it therefore becomes possible to filter Integrated Services 197 flows at both the IP layer (via IGMP) and at the MAC layer (via 198 802.1p). Multicast filtering can potentially reduce the bandwidth 199 consumed by Integrated Services flows on parts of the spanning 200 tree. This filtering is available on both token ring and IEEE 802.3 201 networks. In the absence of 802.1p filtering, source routing might 202 be used on token ring networks to limit the bandwidth consumed on 203 those segments of the network that have no receivers for a particular 204 Integrated Services flow. 206 5. Client-Server QoS Framework 208 One method of exploiting the above features of token ring and of 209 supporting QoS in a shared LAN is via a client-server mechanism. 210 The server implements a "QoS Allocator" that is responsible for 211 maintaining awareness of the resource usage of various LAN components 212 (e.g. bridges, segments). End stations desiring to transmit data 213 with QoS guarantees implement a "QoS Requestor," which is the client 214 component responsible for making requests to reserve resources 215 across the LAN. The Allocator determines whether a particular 216 request for a quality of service allocation can be satisfied, and 217 maintains knowledge of existing QoS allocations. (Note: this simple 218 client-server framework has been informally referred to as a "Mother 219 May I?" protocol.) 221 The Allocator may be implemented in a distributed fashion or as a 222 single entity. In the former case, each token ring segment could 223 have a separate Allocator, and all Allocators would periodically 224 exchange information about available resources on all segments. If 225 implemented as a single entity, there would be a single Allocator 226 for all segments and bridges in the network. Having a centralized 227 Allocator is simpler to implement, and avoids synchronization and 228 deadlock problems. However, this approach does not scale well with 229 larger networks. 231 In order to support Integrated Services, the Requestor-Allocator 232 framework must interact with higher layer QoS signalling mechanisms 233 such as RSVP. Each RSVP router/host in the network must use the QoS 234 Requestor to reserve resources for RSVP flows. When an RSVP RESV 235 message containing a reservation request is received at a station 236 (router/host) on the LAN, it must be translated into an appropriate 237 request to the Allocator to reserve resources at Layer 2. The 238 Allocator will process the request and send a reply to the Requestor 239 with a success/failure indication. This reply is returned to the 240 RSVP daemon which will take appropriate action such as forwarding the 241 RESV message upstream, or sending a RESVERR to the originator of the 242 RESV message. 244 The QoS Allocator can use the various features of token rings, such 245 as source routing and token priorities, in order to accomplish 246 resource reservations for RSVP flows. In the earlier sections, we 247 have described some of these features. 249 6. References 251 [1] IEEE Standards for Local and Metroplitan Area Networks: Token 252 Ring Access Method and Physical Layer Specifications. IEEE Std 253 802.5-1995. 255 [2] IEEE Standards for Local and Metropolitan Area Networks: Draft 256 Standard for Traffic Class and Dynamic Multicast Filtering Services 257 in Bridged Local Area Networks (Draft Supplement to 802.1D), 258 P802.1p/D3, April 30, 1996. 260 [3] S. Deering, Host Extensions for IP Multicasting, Std 5, RFC 1112, 261 August 1989. 263 [4] S. Thomas, A Method for the Transmission of IPv6 Packets over 264 Token Ring Networks, draft-ietf-ipnwg-token-ring-01.txt, work in 265 progress, Jan 22, 1996. 267 7. Authors' Address 269 Anoop Ghanwani 270 IBM Corporation 271 P. O. Box 12195 272 Research Triangle Park, NC 27709 273 Phone: +1-919-254-0260 274 Fax: +1-919-254-5410 275 E-mail: anoop@raleigh.ibm.com 277 Wayne Pace 278 IBM Corporation 279 P. O. Box 12195 280 Research Triangle Park, NC 27709 282 Phone: +1-919-254-4930 283 Fax: +1-919-254-5410 284 E-mail: pacew@raleigh.ibm.com 286 Vijay Srinivasan 287 IBM Corporation 288 P. O. Box 12195 289 Research Triangle Park, NC 27709 291 Phone: +1-919-254-2730 292 Fax: +1-919-254-5410 293 E-mail: vijay@raleigh.ibm.com