idnits 2.17.1 draft-viswanathan-aris-rsvp-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-20) 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([1]), 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 (March 1997) is 9898 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) -- Looks like a reference, but probably isn't: '2-4' on line 45 -- Looks like a reference, but probably isn't: '6-8' on line 119 == Missing Reference: '9' is mentioned on line 258, but not defined == Unused Reference: '6' is defined on line 405, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 409, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 413, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-rsvp-spec-14 ** Downref: Normative reference to an Informational RFC: RFC 1953 (ref. '2') == Outdated reference: A later version (-01) exists of draft-rekhter-tagswitch-arch-00 -- Possible downref: Normative reference to a draft: ref. '3' -- Possible downref: Normative reference to a draft: ref. '4' -- Possible downref: Normative reference to a draft: ref. '5' == Outdated reference: A later version (-07) exists of draft-ietf-intserv-guaranteed-svc-06 == Outdated reference: A later version (-04) exists of draft-ietf-intserv-ctrl-load-svc-03 -- Possible downref: Normative reference to a draft: ref. '8' Summary: 9 errors (**), 0 flaws (~~), 9 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft Arun Viswanathan 3 Expires: September 1997 Vijay Srinivasan 4 IBM Corp. 6 March 1997 8 Soft State Switching 9 A Proposal to Extend RSVP for Switching RSVP Flows 11 13 Status of This Memo 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them 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), 28 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 29 ftp.isi.edu (US West Coast). 31 Abstract 33 This memo describes a mechanism for establishing a switched path with 34 guaranteed Quality of Service for RSVP [1] flows in an integrated 35 switch-router environment. It proposes an extension to the RSVP 36 protocol that allows establishment of a sequence of virtual 37 connections along the hop-by-hop routed path by enabling adjacent 38 nodes to exchange Layer-2 labels. The labels correspond to 39 information that identifies the virtual connections; for example, the 40 VPI/VCI value in the case of an ATM-based Layer-2 infrastructure. 42 1. Introduction 44 An Integrated Switch-Router (ISR) is a switching node that has an IP 45 Control Point (IP-CP) and implements a IP switching technology [2-4]. 46 The ISRs form adjacencies through a well-known virtual circuit (VC), 47 also called the default VC, that terminates at the adjacent ISR's 48 IP-CP. This hop-by-hop VC connectivity gives a cloud of ISRs the 49 same nature as any ubiquitous IP internet. The objective is to 50 switch RSVP flows in such an environment. 52 This document proposes an extension to RSVP that introduces new 53 objects to the existing RSVP messages. Using these objects, each 54 downstream ISR provides its neighboring upstream ISR with the Layer-2 55 (L2) label on which it wishes to receive a RSVP flow. In an ATM- 56 based ISR environment, this label would correspond to a VPI/VCI value 57 for the ATM virtual circuit on which the ISR wishes to receive 58 traffic from the RSVP flow. Then, using an approach similar to those 59 outlined in [2], [3], and [4], the L2 labels are spliced hop-by-hop 60 to form an end-to-end VC. The data from the RSVP flow then uses this 61 this end-to-end VC, and the RSVP signalling messages are forwarded 62 through the default VC. By moving RSVP flows from the default VCs to 63 a dedicated end-to-end VC, it is possible to leverage the QoS 64 capabilities of the underlying L2 technology to provide the type of 65 service desired for the RSVP flow. 67 In this memo the term virtual circuit (VC) is used loosely to imply a 68 switched data path under any switching technology that has the 69 ability to isolate flows from each other, e.g. ATM, Frame Relay etc. 70 The memo proposes a "one VC per sender" approach. Merging of RSVP 71 flows into a single VC will be considered in a later revision of the 72 draft. 74 It is assumed here that the ISRs on the edge of an ISR cloud can 75 either auto-learn or are configured to indicate that they are edge 76 ISRs (on a per interface basis). 78 2. Soft State Switching 80 In soft state switching, the goal is to switch traffic from an RSVP 81 flow at L2 instead of having to forward them hop-by-hop as in 82 conventional IP routers. By doing so, it is possible to leverage the 83 high-performance switching and Quality of Service capabilities of the 84 L2 technology. This is achieved when all neighboring ISRs along the 85 routed path could exchange L2 labels for establishing the switched 86 path for RSVP flows. Then, the L2 labels may be "spliced" hop-by-hop 87 to setup an end-to-end (ingress-to-egress) VC along the preferred 88 routed path. By splicing, we refer to the process by which an 89 incoming VC is associated with an outgoing VC at L2, without traffic 90 from the incoming VC being processed at the network layer. For 91 example, this can be achieved in ATM switches by establishing this 92 association in the ATM switching tables. Once the splicing is 93 complete, the default VC carrying best effort traffic between 94 adjacent routers provides the IP forwarding path. The RSVP 95 signalling messages are forwarded on the default VC. 97 The L2 labels are assumed to have only unidirectional significance. 98 In other words, there exists a separate L2 label space for each 99 direction of flow on a link. Moreover, the downstream ISR is chosen 100 to be the L2 label space owner (allocator) on a link. The single 101 owner approach keeps the L2 label usage simple and manageable. If a 102 L2 label space had more than one owner, it would require that owners 103 synchronize their use of the L2 labels or the space would have to be 104 partitioned amongst the owners. For flexibility, the proposed 105 extension to RSVP also supports the concept of "upstream on demand" 106 allocation described in [3]. In this method, the upstream ISR 107 allocates labels when demanded by the downstream ISR. This enables 108 co-existence with other protocols that consume L2 labels. 110 3. Motivation 112 In this section, we discuss why the RSVP protocol is ideal for 113 establishing a switched path for RSVP flows. 115 One motivating factor for using RSVP is that mapping the network 116 layer QoS request to a L2 virtual connection is simple. The RESV 117 message carries the QoS requested by the receiver(s) of the RSVP 118 flow. For example, this could correspond to one of the Integrated 119 Service classes described in [6-8]. This QoS information is needed 120 when L2 labels are set up and spliced; i.e., when the resource 121 reservations are made. Otherwise, the VC establishment protocol 122 would have to carry its own QoS entity and/or map the VC setup to 123 RSVP tables at each ISR hop. 125 Another motivating reason for extending RSVP is multicast support. 126 RSVP is designed to scale well for multicast sessions requiring 127 resource reservation. RSVP also allows receivers to join existing 128 sessions with different QoS requirements. An independent VC 129 establishment protocol should be able to handle such session "joins" 130 equally well. 132 With the RSVP protocol the receivers can make sender selection 133 through the provision of different filter styles. In this, multiple 134 sender flows (as chosen by the receivers) in a RSVP session can be 135 associated with a single reservation. In other words, sender flows 136 in a RSVP session can be merged into a single downstream reservation. 137 A new VC establishment protocol would have to support a similar 138 mechanism for seamless interoperability with the RSVP protocol. 140 Finally, any mechanism for set up the VCs would, in any case, require 141 extensive interfacing with RSVP protocol and/or its state tables. 143 Due to these reasons, it is best if RSVP can be extended without 144 changing its existing mechanics, to provide support for setting up 145 the switched path for RSVP flows. This need not be viewed as 146 "piggy-backing" another protocol on RSVP, but rather, a natural 147 extension to RSVP to provide QoS in an integrated switch-router 148 environment. 150 4. L2 Label Exchange Mechanism 152 The proposed extension to RSVP calls for adding a new object to carry 153 the L2 label information in the RESV message. The egress ISR, say 154 ISR A, (i.e. the "last" node in the ISR environment, or the ISR 155 through which the RSVP flow exits the ISR environment) places this 156 object in the RESV message and sends it to the PHOP ISR for the flow 157 (as stored in the Path state for this flow) -- call this ISR B. The 158 RESV message is sent to ISR B via the default routed path. ISR B 159 will use the L2 label in the RESV message to setup a VC to ISR A (in 160 this case, the egress ISR) on the outgoing interface. The QoS for 161 this VC corresponds to a mapping of the Integrated Service class 162 specified in the RESV message to an appropriate set of QoS values for 163 the L2 technology. 165 ISR B then chooses a new L2 label on the incoming interface through 166 which the RSVP flow enters the ISR, and sends this label to its own 167 PHOP, ISR C, using the new object in the RESV message. When a VC is 168 set up from ISR C to ISR B using this label, the L2 label on the 169 incoming interface of ISR B is then mapped to the L2 label of the 170 outgoing interface in ISR B's label swap table for L2 switching. 171 This completes the splicing process at ISR B. 173 Repeating this process at each PHOP ISR, the RESV eventually reaches 174 the ingress ISR (the ISR through which the RSVP flow enters the ISR 175 environment). The ingress ISR will make necessary entries to forward 176 packets for this flow through the VC identified by the L2 label in 177 RESV message. All ingress ISRs will delete the L2 object before 178 forwarding the RESV message to their PHOPs. The L2 labels used for 179 an RSVP session are released whenever the RSVP session is torn down 180 or is timed-out. 182 Using this process, an end-to-end switched path is established for an 183 RSVP flow through an ISR network. The data packets from the RSVP 184 flow are forwarded via this switched path, while RSVP control 185 messages continue to use the default VCs between ISRs. 187 The procedure described in this section does not describe how flow 188 merging is performed in such an environment. Flow merging is a key 189 feature of RSVP, and the ability to perform merging in an ISR 190 environment is dependent on the capabilities of the ISRs. This topic 191 is addressed in detail in the following section. 193 5. Merging 195 There are several switching technologies available today (ATM, Frame 196 Relay etc.) and perhaps more in the future. Moreover, the 197 capabilities of a switch of a certain technology vary from vendor to 198 vendor. Three basic characteristics are identified that determine 199 how the underlying L2 technology can be used in conjunction with this 200 proposal to address merging of flows under appropriate environment. 201 They are: 203 o Attribute A: Can correctly merge several upstream VCs into 204 a single downstream VC. Frame switches are typically able 205 to do this in a straightforward manner. However, for ATM 206 switches without appropriate functionality built in, cells 207 from different AAL SDUs may become interleaved on the 208 outgoing VC, thus corrupting the higher layer information. 210 o Attribute B: Can treat a set of VCs as a single entity for 211 QoS purposes. A switch with this property is able to treat 212 all traffic from a set of VCs in a like manner for purposes 213 of scheduling, fair queueing etc. For example, an ATM 214 switch that performs per-class queueing would assign all 215 the VCs from a given set to a particular class. Then, 216 cells from all the VCs in the sets would receive the QoS 217 corresponding to that class. 219 o Attribute C: Can demultiplex senders flows in a single VC 220 into a separate VC for a sender. For example, using label 221 stack for L2 tunneling ([3], [4]). 223 The current version of the document does not address the logical 224 merging of sender flows in a RSVP session. The above attributes may 225 be used to determine how RSVP flows are merged into a single VC. 227 6. Multicast Support 229 In order to support multicast sessions, at split points within the 230 ISR network, where data from upstream ISRs splits into multiple 231 downstream flows, the ISR can perform the required duplication (at L2 232 level) of flows through the hardware multicast capability (for 233 example, point-to-multipoint VC) of the switch, if available. 234 Otherwise, the flow has to be processed at the network layer and 235 multicast in the normal manner. Note that the network layer 236 forwarding is interoperable with all switch types. 238 7. Unreserved Receivers 240 When none of the receivers have reserved, the multicast session may 241 flow through the default VC as best-effort traffic. But as soon as a 242 receiver makes a reservation, the data flow may stop to receivers 243 that haven't made any reservation yet. The receivers without 244 reservation only get PATH messages but no data (even through best- 245 effort). This problem can be addressed in several different ways 246 determined by the switch architecture. 248 This problem does not exist for switches that support Attribute A. 249 They can add the default forwarding VC as a branch in the point-to- 250 multipoint VC. If the switch architecture allow adding the local 251 IP-CP to the point-to-multipoint VC, then the IP-CP can multicast the 252 packets only to those interface from which there is no reservation 253 but are listed in the multicast table. This would be the most 254 preferable approach for all switches. 256 Another way to alleviate this problem is to use the PATH message to 257 do the VC establishment from the node downstream on which there are 258 interfaces through which no reservation has been received [9]. This 259 reservation uses a UBR-like QoS. This is done when there is at least 260 one reservation in place for the RSVP session. This may not work in 261 environments where upstream label allocation is not permitted. 263 8. TTL Decrement 265 When IP packets flow through a switched path, the TTL value in the IP 266 header cannot be decremented. The decrementing of TTL value is used 267 to delete packets in a routing loop to avoid/reduce congestion. For 268 this purpose, the proposed PATH L2 Object carries a hop-count that 269 counts the number of consecutive ISR hops. The ISRs increment the 270 hop-count only if there is a switched path for that sender flow 271 through that ISR. All ISRs maintain the hop count in the Path State. 272 Only the egress ISR on which the VC terminates would use the count to 273 decrement the TTL on packets for that sender flow. The ISRs of a 274 switching technology that have a TTL equivalent in the L2 header may 275 not use the PATH L2 Object. 277 9. Upstream on Demand Label Allocation 279 The memo describes the RSVP extension when the downstream ISR is the 280 label space owner. But a upstream label allocator can be supported. 281 In this, the RESV message uses a NULL L2 Object to indicate a request 282 for label allocation. The upstream ISR responds with a L2 label for 283 the RSVP session in the PATH messages to the downstream neighbor. 284 This flexibility allows co-existence with other IP switching 285 protocols. This can also be useful in other environments such as 286 [5]. 288 10. Adjacency 290 The ISR neighbors need some mechanism to establish adjacencies. This 291 is required because the neighbors need to exchange the label range 292 for correct label allocation. They also need to elect the label 293 allocator. The current version of this memo does not propose any 294 extension to RSVP protocol for this mechanism. It is assumed that 295 adjacency would be established by another protocol (as proposed in 296 [2], [3] or [4]) and such information would be made available to the 297 RSVP module. In absence of such mechanism the ISRs would have to be 298 configured with the required information to operate as described in 299 this memo. 301 11. Object Formats 303 This section describes the object formats for the proposed extension. 304 The L2 object for different scenarios are defined below: 306 o L2 HOP COUNT object: Class = x, C-Type = 1 308 +-------------+-------------+-------------+-------------+ 309 | Hop Count | Reserved | 310 +-------------+-------------+-------------+-------------+ 312 Hop Count 313 Counts the length (in ISR hops) of the switched path. 315 o NULL L2 Object: Class = y, C-Type = 1 317 o ATM RESV L2 object: Class = y, C-Type = 2 318 +-------------+-------------+-------------+-------------+ 319 | IPv4 SrcAddress (4 bytes) | 320 +-------------+-------------+-------------+-------------+ 321 | ////// | ////// | SrcPort | 322 +-------+-----+-------------+-------------+-------------+ 323 | | VPI | VCI | 324 +-------+-------------------+-------------+-------------+ 325 // // 326 +-------------+-------------+-------------+-------------+ 327 | IPv4 SrcAddress (4 bytes) | 328 +-------------+-------------+-------------+-------------+ 329 | ////// | ////// | SrcPort | 330 +-------+-----+-------------+-------------+-------------+ 331 | | VPI | VCI | 332 +-------+-------------------+-------------+-------------+ 334 IPv4 SrcAddress 335 IPv4 address of the sender. 337 VPI - 12 bits 338 Virtual Path Identifier. If lesser than 12 bits then its 339 right justified in this field. 341 VCI - 16 bits 342 Virtual Circuit Identifier. If lesser than 16 bits then 343 its right justified in this field. 345 o ATM PATH L2 object: Class = y, C-Type = 3 347 +-------+-------------------+-------------+-------------+ 348 | Flags | VPI | VCI | 349 +-------+-------------------+-------------+-------------+ 351 Flags - 4 bits 352 0x01 - Implies that the PATH message is in response to an 353 upstream on demand label allocation and may not be 354 propogated any further. 356 VPI - 12 bits 357 Virtual Path Identifier. If lesser than 12 bits then its 358 right justified in this field. 360 VCI - 16 bits 361 Virtual Circuit Identifier. If lesser than 16 bits then 362 its right justified in this field. 364 The IPv6 extension and error codes will be defined in a later 365 revision of the draft. 367 The reader may have noticed that the new RESV L2 object has 368 duplicated information already present in the FILTER_SPEC object. 369 Another approach could be to extend the FILTER_SPEC object definition 370 to carry the link layer labels or insert the label object following 371 the FILTER_SPEC object. 373 12. Security Considerations 375 Security considerations are not discussed in this document. 377 13. Acknowledgements 379 The authors wishes to acknowledge Nancy Feldman for her input. 381 14. References 383 [1] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, Resource 384 ReSerVation Protocol (RSVP) -- Version 1 Functional 385 Specification. Internet Draft, draft-ietf-rsvp-spec-14, 386 November 1996. 388 [2] P. Newman, W. L. Edwards, R. Hinden, E. Hoffman, F. Ching Liaw, 389 T. Lyon, G. Minshall, Ipsilon Flow Management Protocol 390 Specification for IPv4, Version 1.0. Internet RFC 1953, May 391 1996. 393 [3] Y. Rekhter, B. Davie, D. Katz, E. Rosen, G. Swallow, D. 394 Farinacci, Tag Switching Architecture - Overview. Internet 395 Draft, draft-rekhter-tagswitch-arch-00.txt, January 1997. 397 [4] A. Viswanathan, N. Feldman, R. Boivie, R. Woundy, ARIS: 398 Aggregated Route-Based IP Switching. Internet Draft, draft- 399 viswanathan-aris-overview-00.txt, November 1996. 401 [5] D. Farinacci, Partitioning Tag Space among Multicast Routers on 402 a Common Subnet. Internet Draft, draft-farinacci-multicast-tag- 403 part-00.txt, December 1996. 405 [6] S. Shenker, C. Partridge, R. Guerin, Specification of Guaranteed 406 Quality of Service. Internet Draft, draft-ietf-intserv- 407 guaranteed-svc-06.txt, August 1996. 409 [7] J. Wroclawski, Specification of the Controlled-Load Network 410 Element Service. Internet Draft, draft-ietf-intserv-ctrl-load- 411 svc-03.txt, August 1996. 413 [8] F. Baker, R. Guerin, D. Kandlur, Specification of Committed Rate 414 Quality of Service. Internet Draft, draft-ietf-intserv-commit- 415 rate-svc-00.txt, June 1996. 417 Author's Address 419 Vijay Srinivasan 420 IBM Corporation 421 PO Box 12195 422 Research Triangle Park, NC 27709 424 Phone: +1 (919) 254-2730 425 Email: vijay@raleigh.ibm.com 427 Arun Viswanathan 428 IBM Corporation 429 17 Skyline Drive 430 Hawthorne, NY 10532 432 Phone: +1 (914) 784-3273 433 Email: arunv@vnet.ibm.com