idnits 2.17.1 draft-williams-issll-vcuse-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-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 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 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.) ** The abstract seems to contain references ([For94]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (17 September 1996) is 10076 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) -- Missing reference section? 'For94' on line 241 looks like a reference -- Missing reference section? 'For95' on line 244 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force D. Williams 2 INTERNET DRAFT R. Guerin 3 D. Kandlur 4 17 September 1996 6 ATM Virtual Circuit Identification Support for an RSVP-based Service 7 draft-williams-issll-vcuse-00.txt 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 17 months, and may be updated, replaced, or obsoleted by other documents 18 at any time. It is not appropriate to use Internet Drafts as 19 reference material, or to cite them other than as a ``working draft'' 20 or ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check 23 the ``1id-abstracts.txt'' listing contained in the internet-drafts 24 Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net 25 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 26 Rim). 28 Abstract 30 In this document we present a specification for associating RSVP 31 flows with Virtual Connections on an ATM network. The text in this 32 document is meant as an addendum to the text in Subsection 3.2 33 ``Sending RSVP Messages'' of the RSVP specification [Bzb+96]. This 34 document specifies a usage of the Logical Interface Handle (LIH) in 35 the RSVP_HOP Class Object when either a host or a router is attached 36 to an ATM network. This document also specifies ATM UNI [For94] 37 signaling semantics for associating a switched ATM connection with 38 RSVP flows. These ATM UNI semantics use the Broadband High Layer 39 Information (BHLI) Information Element. 41 1. Motivation 43 The purpose for this document is to propose a standard method for 44 hosts and routers using the RSVP Protocol [Bzb+96] over an ATM 45 network to associate RSVP flows with a unique Virtual Connection 46 (permanent or switched). Specifically this document presents a 47 specification that is to be used as addendum text to Subsection 48 3.2 ``Sending RSVP Messages'' of the RSVP Specification. This 49 document does not present any new RSVP Objects, or in fact, any 50 particular change to the basic framework of either RSVP or ATM 51 UNI signaling, rather, this document presents a usage of existing 52 protocol mechanisms. 54 The motivation for this work is to allow hosts and routers to 55 efficiently and consistently use the underlying ATM link layer 56 technology (i.e. manage VCs). While there are several alternatives 57 to mapping RSVP sessions to a data-link connection, this document 58 specifies a "one connection per session" model, in which a new 59 connection is created for each RSVP session. This model has the 60 following advantages: 62 - It exploits the traffic control and scheduling capabilities of the 63 data link, which are typically supported with hardware mechanisms. 65 - It reduces the network level processing load by removing the need 66 for multiplexing of RSVP sessions onto a connection. 68 The advantages of this model can be extended further when the 69 receiving end-point of the connection is made aware of the 70 association between the RSVP session and the data-link connection. 71 For example, when the receiver is a network device, the data-link 72 connection can be used as a mechanism for pre-sorting packets to 73 their network level session. This can assist the network device in 74 performing appropriate forwarding and scheduling actions at very high 75 speeds. Similarly, when the receiver is an end-station, the data 76 link connection can be exploited to perform an early de-multiplexing 77 of arriving packets to their appropriate application endpoint. This 78 early de-multiplexing has been shown to reduce latency and processing 79 overheads within the end-station, thereby improving the performance 80 of multimedia applications. Moreover, when the consuming application 81 endpoint is a device within the end-station (such as a graphics 82 display adapter) the data link connection can be used to direct 83 packets to the device. 85 Another reason for keeping track of RSVP-related connections at the 86 data link layer is related to connection management. The IP over 87 ATM signaling standard (RFC 1755) specifies that end systems must 88 support the use of inactivity timers for connections. However, this 89 provision should not apply to connections that were created for RSVP. 90 The presence of RSVP signaling messages is sufficient to indicate 91 that the application desires a reservation, even when there is no 92 data traffic on the session. Since these data link connections are 93 established and maintained at the behest of RSVP, it is logical to 94 leverage RSVP to convey data link connection information between 95 the endpoints. Moreover, RSVP messages contain all the elements 96 necessary to identify the data flows that are carried on the 97 connection. 99 The advantages of data link connections for supporting QoS have been 100 recognized in many different forms, and there have been proposals put 101 forth to define protocols to exploit them. Among these proposals are 102 SINP and the Ipsilon flow management protocol. Our approach differs 103 from these efforts in that it is defined as a usage of existing 104 protocols, namely RSVP and ATM UNI Signaling. We feel this to be of 105 importance as while the functionality we seek to provide is useful 106 in many different settings, its support should be through existing 107 signaling protocols rather than by developing a new protocol for that 108 purpose. 110 2. Specification 112 The following text is meant to be an addendum to the end of 113 Subsection 3.2 ``Sending RSVP Messages'' in the RSVP Specification. 115 When operating over and ATM link-layer, it can be desirable to 116 associate each RSVP session with a separate Virtual Connection 117 (either Permanent or Switched). ATM attached RSVP capable hosts and 118 routers can support this capability in the following manner: 120 1. When a node N forwards a PATH message over an ATM network 121 connection, this PATH message is sent on a default IP/Control 122 Virtual Connection. The message includes an RSVP_HOP object 123 class with one of the following codings for the LIH: 125 - In a Permanent Virtual Connection environment, the LIH 126 contains the VPI:VCI of the ATM Virtual Connection as 127 follows: 129 +--------------+--------------+--------------+--------------+ 130 | NULL VPI VCI VCI | 131 +--------------+--------------+--------------+--------------+ 133 - In a Switched Virtual Connection environment, the Logical 134 Interface Handle contains a Flow ID Handle as follows: 136 +--------------+--------------+--------------+--------------+ 137 | Flow ID Handle (32-bit integer) | 138 +--------------+--------------+--------------+--------------+ 140 2. Both N and the next hop node N' store the LIH in their Path State 141 Tables. 143 3. When N' sends a RESV message to N, it includes the LIH value from 144 the Path State Table in an RSVP_HOP object. 146 4. When a RESV message(s) arrives at N for this session, the LIH 147 information from the Path State Table is used to identify the 148 Virtual Connection for this session's data packets. In the case 149 of PVCs, this association is immediate, in the case of SVCs, the 150 VPI:VCI is identified after node N performs the ATM UNI signaling 151 described in Step 5 below. 153 5. In the case of a Switched Virtual Connection, when N receives the 154 RESV message it performs ATM UNI signaling [For94] to establish 155 the connection for this reservation. In the UNI SETUP Message, a 156 Broadband High Layer Information Information Element is included 157 with the 32-bit Flow ID Handle for the session that will be using 158 this Virtual Connection (i.e the same Flow ID that was sent in 159 the original PATH message for this session). When N' receives 160 the ATM UNI SETUP message, it extracts the Flow ID Handle from 161 the BHLI field and uses it to associate the particular RSVP 162 session with the VPI:VCI being setup. The BHLI Information 163 Element is coded as follows: 165 Bits 166 8 7 6 5 4 3 2 1 Octets 167 +----------------------------------------------+ 168 | BHLI IE Identifier | 169 | 0 1 0 1 1 1 0 1 | 1 170 +----------------------------------------------+ 171 | ext | Coding | Instruction Field | 172 | 1 | 0 0 | 0 0 0 0 0 | 2 173 +----------------------------------------------+ 174 | Length | 175 | 0 0 0 0 0 0 0 0 | 3 176 +----------------------------------------------+ 177 | Length (cont) | 178 | 0 0 0 0 0 1 0 0 | 4 179 +----------------------------------------------+ 180 | ext | High Layer Information Type | 181 | 1 | 0 0 0 0 0 0 1 | 5 182 +----------------------------------------------+ 183 | Flow ID Handle (bits 1-8) | 6 184 +----------------------------------------------+ 185 | Flow ID Handle (bits 9-16) | 7 186 +----------------------------------------------+ 187 | Flow ID Handle (bits 17-24) | 8 188 +----------------------------------------------+ 189 | Flow ID Handle (bits 25-32) | 9 190 +----------------------------------------------+ 192 3. Example 194 The figure below shows a simple example network. In which two IP 195 hosts are connected to each other through an ATM switch and a router. 197 |------| |------| |------| | |------| 198 | H1 |-----| S1 |-----| R1 |--|--| H2 | 199 |------| |------| |------| | |------| 201 H1 is an RSVP sender and H2 is an RSVP receiver; assume two PVCs 202 between H1 and R1 and R1 and H2 are connected by an Ethernet. 203 Using the mechanisms outlined in this document, H1 sends an RSVP 204 PATH message over one of the two PVCs (referred to as the default 205 VC). This PATH message flows as normal through the network to 206 the destination, in this case H2 is the destination. The PATH 207 message contains the VPI:VCI of the second PVC (referred to as the 208 reserved data PVC) in the LIH field of the RSVP_HOP Object as shown 209 above. When R1 receives the PATH message, it creates a Path State 210 Table entry that includes the VPI:VCI that is located in the LIH 211 field. H2 determines that it would like to setup a Reservation for 212 this particular session, that is, it sends a RESV message. When 213 R1 receives this message, along with normal RSVP processing, it 214 associates the PVC connection that corresponds to the VPI:VCI that 215 was stored in the Path State Table with this session. R1 then sends 216 the RESV message to H1 with the LIH again set to its VPI:VCI for the 217 reserved data PVC. When H1 receives the RESV message it sets up its 218 resources and sends the session's data on the reserved data PVC. 220 In the case of an SVC connection, the flow is the same as the PVC 221 case, with the exception that H1 includes a 32-bit Flow ID handle 222 in the LIH field instead of a VPI:VCI (note that in the SVC case, 223 the reserved data SVC is not established until the sender receives 224 the RESV message), R1 stores the Flow ID handle in the Path State 225 Table. When the RESV message arrives at H1, it requests a reserved 226 data VC to R1 using UNI signaling. The UNI signaling includes the 227 Flow ID handle in the BHLI as shown above. When R1 receives the call 228 request, it is responsible for associating this particular VC with 229 the RSVP session that is identified in the Path State Table (i.e. 231 comparing Flow ID handles). When the ATM SVC is fully established, 232 the reserved data flows over this SVC. 234 4. References 236 [Bzb+96] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, 237 "Resource ReSerVation Protocol (RSVP) -- Version 1, Functional 238 Specification", Internet Draft, draft-ietf-rsvp-spec-12.txt, May 239 1996. 241 [For94] ATM Forum, "ATM User-Network Interface Specifications, 242 Version 3.1", September 1994. 244 [For95] ATM Forum, "ATM User-Network Interface Specifications, 245 Version 4.0", ATM Forum/94-1018. 247 5. Authors' Address 249 Roch Guerin 250 T. J. Watson Research Center 251 IBM Corporation 252 30 Saw Mill River Rd. 253 Hawthorne, NY 10532 255 Phone: +1-914-784-7038 256 E-mail: guerin@watson.ibm.com 258 Dilip Kandlur 259 T. J. Watson Research Center 260 IBM Corporation 261 30 Saw Mill River Rd. 262 Hawthorne, NY 10532 264 Phone: +1-914-784-7722 265 E-mail: kandlur@watson.ibm.com 267 Doug Williams 268 T. J. Watson Research Center 269 IBM Corporation 270 30 Saw Mill River Rd. 271 Hawthorne, NY 10532 273 Phone: +1-914-784-5047 274 E-mail: dougw@watson.ibm.com