idnits 2.17.1 draft-ietf-rsvp-cidr-ext-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-03-28) 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 6 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 (June 25, 1997) is 9773 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: 'LSMA' is mentioned on line 70, but not defined == Missing Reference: 'PIM-SM' is mentioned on line 173, but not defined == Unused Reference: 'HLARTI' is defined on line 340, but no explicit reference was found in the text == Unused Reference: 'IEEE1' is defined on line 345, but no explicit reference was found in the text == Unused Reference: 'IEEE2' is defined on line 348, but no explicit reference was found in the text == Unused Reference: 'LSMA-SCENARIOS' is defined on line 351, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'HLARTI' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE1' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE2' -- Possible downref: Non-RFC (?) normative reference: ref. 'LSMA-SCENARIOS' ** Obsolete normative reference: RFC 1519 (ref. 'RFCCIDR') (Obsoleted by RFC 4632) -- Possible downref: Non-RFC (?) normative reference: ref. 'RSVP' -- Possible downref: Non-RFC (?) normative reference: ref. 'RSVPMD5' Summary: 10 errors (**), 0 flaws (~~), 8 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Jim Boyle 2 Expiration: December 25, 1997 MCI 3 File: draft-ietf-rsvp-cidr-ext-01.txt 5 RSVP Extensions for CIDR Aggregated Data Flows 7 June 25, 1997 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 23 Shadow 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 Abstract 29 This document presents extensions to Version 1 of the Resource 30 Reservation Setup Protocol (RSVP). These extensions ameliorate RSVP 31 support of Large Scale Multicast Applications (LSMA) and Virtual 32 Private Networks (VPN). With these types of applications, several 33 hosts at any particular site are participating in a session. 34 Efficient RSVP use requires aggregation of their addresses into a 35 single entry for classification purposes. The extensions allow such 36 aggregation of state in a simple manner that requires no changes to 37 the base RSVP specification. 39 Table of Contents 41 1 Introduction 4 43 2 Object Overview 5 44 2.1 Examples of Use 5 45 2.2 Special Considerations 6 47 3 Object Definition 8 48 3.1 SESSION Class 8 49 3.2 FILTER_SPEC Class 9 50 3.3 SENDER_TEMPLATE Class 9 52 4 Additional Processing Rules for CIDR Extensions 10 54 5 Security Considerations 11 56 6 References 11 58 7 Acknowledgments and Authors' Information 12 59 7.1 Acknowledgments 12 60 7.2 Authors' Information 12 62 1 Introduction 64 Two of the main applications that have been focused on in development 65 of the Resource Reservation Protocol [RSVP] are mbone video tele- 66 conferencing (VTC) and point-to-multipoint media distribution. 67 Though an important set of applications, they are distinctive in that 68 they assume a small number of originators of data per geographic 69 vicinity. Other applications such as the simulation network 70 applications described in in the LSMA working group [LSMA] have 71 different architectures that includes multiple sites (i.e. LANs) 72 inter-communicating with several workstations per site originating 73 network traffic. For the case of LSMAs, RSVP can be used to protect 74 the simulation traffic over the WAN, which is desirable since the 75 multicast transport protocols currently used can not throttle 76 transmission or retransmit lost packets. The objects described in 77 the base RSVP specification do not meet the RSVP needs of LSMAs in an 78 efficient manner. Another example of an application where several 79 hosts from a sender site originate traffic is VPNs. 81 This document proposes new objects in the SESSION, SENDER_TEMPLATE 82 and FILTER_SPEC classes. These objects, termed CIDR extensions, 83 extend the base specification to meet the needs of applications with 84 several senders per site in an efficient manner. The objects allow 85 hosts within a classless inter-domain routing (CIDR) prefix [RFCCIDR] 86 to be grouped by RSVP as a single entry. With CIDR extensions, a 87 host at each site would send out a PATH message with CIDR SESSION and 88 SENDER_TEMPLATE with a Tspec that described the aggregate traffic the 89 site expected to generate. A host at each receiving site would send 90 back a fixed filter style RESV message containing CIDR SESSION and 91 FILTER_SPEC objects. 93 2 Object Overview 95 2.1 Examples of Use 97 2.1.1 LSMA 99 Suppose you have 4 sites participating in a distributed simulation. 100 Each site has 50 hosts and each site is sending 250 kbs of traffic to 101 a multicast address. A single host at each site sends a PATH message 102 with CIDR SESSION and CIDR SENDER_TEMPLATE objects and base 103 specification Tspec object describing that the site expects to 104 generate 250 kbs of traffic to the specified multicast address. 105 Nomination of which host sends this message is outside the scope of 106 RSVP, the application must perform this function. When such a PATH 107 message is received, a single host per recipient site sends back a 108 RESV message to the sender host with a CIDR SESSION and CIDR 109 FILTER_SPEC matching the sender's objects, a base specification 110 flowspec and a fixed-filter reservation style. Such a reservation 111 might say "Reserve 250 kbs of controlled load service for traffic 112 from 192.1.1.1/24 to 224.5.6.1/32". Aggregating multicast groups 113 within a range would be useful, but this proves problematic due to 114 possibly divergent routing paths per individual groups. This problem 115 is discussed in greater detail in section 2.2.??. 117 In the above example, 9 inter-site reservations would be established 118 with each reservation expected to match its respective Tspec. With 119 traditional objects, as detailed in the base specification, use of 120 RSVP to protect the aforementioned scenario could result in excessive 121 message and classification processing, in the case of distinct 122 reservations. For shared reservations, over-subscription of the 123 reservation (250 kbs of traffic flowing through a 750 kbs 124 reservation) would result. 126 2.1.2 VPN 128 CIDR extensions provide a scalable manner in which to provide VPN 129 services with RSVP. As an alternate approach, one might choose to 130 use an IP in IP tunnel which has some advantages but also has the 131 disadvantage that it forces the packets to be encapsulated at the 132 tunnel-ingress router. Suppose two corporate site offices would like 133 to setup VPN service with a main office. A host at each site would 134 send a PATH message to the respective host at the other sites. This 135 PATH message would use CIDR SESSION and SENDER_TEMPLATE objects and 136 would contain a Tspec describing the traffic from the originating 137 site to the destination site. In response, a RESV message would be 138 sent using CIDR SESSION and CIDR FILTER_SPEC objects. In the case 139 mentioned, there would be 3 RSVP reservations installed in the 140 network. Without using tunnels, the above could not be supported by 141 the base specification objects. 143 2.2 Special Considerations for CIDR Objects 145 2.2.1 Route assumptions 147 In order for CIDR objects to work, and be most effective, an 148 assumption must be made that the RSVP administrator is aware of non- 149 singular routes for the aggregated address space. For unicast CIDR 150 SESSION objects, for instance, the RSVP exchange is taking place 151 between two distinct IP addresses. This can fail to provide full 152 coverage of inter-site traffic if a subset of the addresses within 153 the CIDR SESSION is routed differently than the route over which the 154 RSVP state was installed. It is likely that such route divergence is 155 caused by circumstances that the possessor of the address range is 156 aware of (such as multi-homing). 158 2.2.2 CIDR SESSION objects and Multicast 160 The assumption listed in Section 2.2.1 are not valid with many 161 multicast routing protocols. Therefore, to establish PATH state for 162 all groups within a range, a PATH message must be sent to each 163 destination address. As these might take different routes through 164 the network, it is better to send a Tspec that specifically covers 165 traffic from a site to that particular group, obviating the need for 166 CIDR SESSION for multicast. Therefore, applications should use a CIDR 167 Prefix length of 32 for multicast destinations. 169 Multicast routing protocols are source sensitive, so one should note 170 that CIDR aggregation of sender state may fail the singular route 171 assumption. This is the case for multicast routing protocols that 172 can set up multiple routes for hosts within the same unicast route 173 entry. For instance, in PIM-SM [PIM-SM] one host's packets to a 174 multicast group could take a shortest path through route while 175 packets from another host on the same LAN route through the 176 rendezvous point. 178 2.2.3 Overlapping SESSION definitions 180 There is also an issue with how to handle establishment of SESSION 181 state where the range of destination addresses covered by the 182 Destination Address / CIDR prefix length overlaps with already 183 established sessions. In addition to some additional rules described 184 in section 4, the basic requirement is that any one session's range 185 of addresses may not bisect another session's range. Said another 186 way, they may overlap and one may be a subset of another, but they 187 cannot partially overlap. This would allow RSVP use above and beyond 188 a base level VPN RSVP use. 190 For potentially ambiguous situations where a packet could be 191 classified as belonging to different reservations, a longest match on 192 session should be done with no over-flow of best-effort traffic to 193 other reservations. As an example: 195 Reservation Sender Session 197 A 1.2.3.1/16, 5.6.7.8/24 198 B 1.2.3.1/24, 5.6.7.8/16 200 A packet from 1.2.3.4 to 5.6.7.7 would be applied to reservation A. 201 This follows the lines of RSVP's receiver oriented nature. 203 3 Object Definition 205 The FILTER_SPEC, SENDER_TEMPLATE and SESSION class objects below 206 contain a CIDR prefix field that specifies which hosts should be 207 treated identically to the specified address. For example, in the 208 CIDR FILTER_SPEC address, a source address of 199.1.1.1 with a CIDR 209 prefix length of 24 (199.1.1.1/24 shorthand) would apply to all 210 source addresses in the range of 199.1.1.0 to 199.1.1.255. 212 3.1 SESSION Class 214 SESSION Class = 1 216 o IPv4 CIDR SESSION object: Class = 1 C-Type = 5 218 +-------------+-------------+-------------+-------------+ 219 | IPv4 DestAddress (4 bytes) | 220 +-------------+-------------+-------------+-------------+ 221 | CIDR Length | /////////////////////////////////////// | 222 +-------------+-------------+-------------+-------------+ 223 | Protocol Id | Flags | DstPort | 224 +-------------+-------------+-------------+-------------+ 226 o IPv6 CIDR Session object: Class = 1 C-TYPE = 6 228 +-------------+-------------+-------------+-------------+ 229 | | 230 + + 231 | | 232 + IPv6 DestAddress (16 bytes) + 233 | | 234 + + 235 | | 236 +-------------+-------------+-------------+-------------+ 237 | CIDR Length | /////////////////////////////////////// | 238 +-------------+-------------+-------------+-------------+ 239 | Protocol Id | Flags | DstPort | 240 +-------------+-------------+-------------+-------------+ 242 3.2 FILTER_SPEC Class 244 FILTER_SPEC Class = 10 246 o IPv4 CIDR FILTER_SPEC object: Class = 10, C-Type = 6 248 +-------------+-------------+-------------+-------------+ 249 | IPv4 SrcAddress (4 bytes) | 250 +-------------+-------------+-------------+-------------+ 251 | CIDR Length | /////////// | SrcPort | 252 +-------------+-------------+-------------+-------------+ 254 o IPv6 CIDR FILTER_SPEC object: Class = 10 C-Type = 7 256 +-------------+-------------+-------------+-------------+ 257 | | 258 + + 259 | | 260 + IPv6 SrcAddress (16 bytes) + 261 | | 262 + + 263 | | 264 +-------------+-------------+-------------+-------------+ 265 | CIDR Length | /////////// | SrcPort | 266 +-------------+-------------+-------------+-------------+ 268 3.3 SENDER_TEMPLATE Class 270 SENDER_TEMPLATE Class = 11 272 o IPv4 CIDR SENDER_TEMPLATE object: Class = 11, C-Type = 6 274 Definition same as IPv4 CIDR FILTER_SPEC object. 276 o IPv6 CIDR SENDER_TEMPLATE object: Class = 11, C-Type = 7 278 Definition same as IPv6 CIDR FILTER_SPEC object. 280 4 Additional Processing Rules for CIDR Extension objects 282 If Session Protocol = 0, no non-zero protocol sessions for range of 283 Destination Addresses may exist. Alternatively, if Session 284 Protocol is non-zero, no zero protocol session for range of 285 Destination Addresses may exist. 287 PathErr Returned: xx1 Conflicting Destination Protocols 288 ResvErr Returned: xx1 Conflicting Destination Protocols 290 If Session Protocol = 0, Dst Port must also be 0. 292 PathErr Returned: xx2 Inappropriate Port for Protocol 293 ResvErr Returned: xx2 Inappropriate Port for Protocol 295 If Destination Port = 0 in SESSION, Source Port must also be 0. 296 Message discarded. 298 Err Logged: Conflicting Source Port 300 If a node that does not support CIDR extensions receives a CIDR 301 extension object, as per the base specification, it must return an 302 error. 304 PathErr Returned: 14 Unknown C-Type 305 ResvErr Returned: 14 Unknown C-Type 307 Session Destination Address Range boundaries must not bisect 308 Destination Address Ranges of already defined Sessions. 310 PathErr Returned: xx3 Conflicting Session Address Definition 311 ResvErr Returned: xx3 Conflicting Session Address Definition 313 CIDR prefixes must be within a valid range of 16 to 32 (for IPv4) 314 or 16 to 128 (for IPv6). 316 PathErr Returned: xx4 Malformed Session Address 317 PathErr Returned: 21.04 Malformed Tspec 318 ResvErr Returned: 21.03 Malformed flowspec 320 For explicit style reservation, CIDR FILTER_SPEC must exactly match 321 CIDR SENDER_TEMPLATE of session with installed sender state. 323 ResvErr Returned: 04 No Sender Information for this RESV 325 RESV session must must exactly match installed sender state 326 established by PATH message. 328 ResvErr Returned: 03 No Path Information for this RESV 330 5 Security Considerations 332 RSVP with CIDR extensions is not less secure than base specification 333 RSVP. Security for both can be addressed by use of MD5 334 authentication described in [RSVPMD5]. Though under development, 335 RSVP's policy procedures might also be used to assure that non- 336 authorized state is not installed. 338 6 References 340 [HLARTI] J.O. Calvin, R. Weatherly, "An Introduction to the High 341 Level Architecture (HLA) Runtime Infrastructure (RTI)". 14th DIS 342 Workshop, September 1995, Orlando, FL. 343 http://www.dmso.mil/docslib/briefs/DIS/14DIS/hla.html 345 [IEEE1] IEEE 1278.1-1995, Standard for Distributed Interactive 346 Simulation - Application Protocols. 348 [IEEE2] IEEE 1278.2-1995, Standard for Distributed Interactive 349 Simulation - Communication services and Profiles. 351 [LSMA-SCENARIOS] S. Seidensticker, W.G. Smith, M. Myjak. "Scenarios 352 and Appropriate Protocols for Distributed Interactive Simulation", 353 Internet Draft, June 1996, . 355 [RFCCIDR] V. Fuller, et. al. "Classless Interdomain Routing (CIDR): 356 an Address Assignment and Aggregation Strategy", RFC1519. 358 [RSVP] B. Braden, et. al. "Resource Reservation Protocol (RSVP) - 359 Version 1 Functional Specification", Internet Draft, July 1996, 360 . 362 [RSVPMD5] F. Baker, "RSVP Cryptographic Authentication", Internet 363 Draft, May 1997, . 365 7 Author Information and Acknowledgments 367 The author wishes to especially thank Fred Baker for his guidance on 368 this topic. Several members of the RSVP and LSMA mailing lists also 369 provided invaluable feedback. 371 Jim Boyle 372 MCI 373 2100 Reston Parkway 374 Reston, VA 20191 376 Phone: 703.715.7006 377 EMail: jboyle@mci.net