Internet Draft Jim Boyle Expiration: February 15, 1997 MITRE File: draft-ietf-rsvp-cidr-ext-00.txt RSVP Extensions for CIDR Aggregated Data Flows February 15, 1997 Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). BOYLE Expires August 15, 1997 [Page 1] Internet Draft RSVP Extensions for CIDR objects February 15, 1997 Abstract This document presents extensions to Version 1 of the Resource Reservation Setup Protocol (RSVP). These extensions permit support of Large Scale Multicast Applications (LSMAs). With this type of application, several sites use multicast IP to distribute state information about simulated entities. Current scenarios consist of numbers on the order of 10 sites with 50 host per site, though future scenarios are expected to be much larger. Each host sends and receives traffic. RSVP will be used to protect the scenario traffic on the WAN. However, current RSVP objects do not meet the needs of LSMAs in a scalable, efficient manner. The CIDR extensions described in this document would allow address aggregation of sender and session so that each site can have a single, protected, reservation to each of the other sites. Others have mentioned alternative uses for such extensions, including support of virtual private network (VPN) services. BOYLE Expires August 15, 1997 [Page 2] Internet Draft RSVP Extensions for CIDR objects February 15, 1997 Table of Contents 1 Introduction 4 2 Object Overview 5 2.1 Examples of Use 5 2.2 Special Considerations 5 3 Object Definition 7 3.1 SESSION Class 7 3.2 FILTER_SPEC Class 8 3.3 SENDER_TEMPLATE Class 8 4 Additional Processing Rules for CIDR Extensions 9 5 Security Considerations 10 6 References 10 7 Acknowledgments and Authors' Information 11 7.1 Acknowledgments 11 7.2 Authors' Information 11 BOYLE Expires August 15, 1997 [Page 3] Internet Draft RSVP Extensions for CIDR objects February 15, 1997 1 Introduction Two of the main applications that have been focused on in development of the Resource Reservation Protocol [RSVP] are mbone video tele- conferencing (VTC) and point-to-multipoint media distribution. Another set of important applications are those discussed in the large scale multicast application [LSMA] working group. In these applications, multiple sites might have several workstations with each workstation simulating entity actions and updating entity status to a scenario multicast address. RSVP is used to protect the scenario traffic over the WAN. The objects described in the base RSVP specification do not meet the RSVP needs of LSMA applications in an efficient manner. As described in more detail below, use of base specification IPv4 SESSION, SENDER and FILTER objects with shared- explicit (SE) style reservations would lead to excessively large RSVP messages and use of fixed-filter (FF) style reservations would lead to excessive amounts of RSVP message traffic. LSMA applications do not meet some of the assumptions underlying wildcard-filters (WF), and use of WF requires over-subscription of reservations, especially in the case of asymmetric traffic flows. This document proposes new objects in the SESSION, SENDER_TEMPLATE and FILTER_SPEC classes. These objects, termed CIDR extensions, extend the base specification to meet the needs of LSMAs in an efficient manner. The objects allow hosts within a classless inter- domain routing (CIDR) prefix [RFCCIDR] to be grouped by the packet classifier as a single entry. Therefore, a host at each site would send out a CIDR SENDER_TEMPLATE with a Tspec that described the aggregate traffic the site expected to generate. A host at each receiving site would send back a fixed filter style RESV message requesting a reservation. The CIDR SESSION objects defined also allow destination traffic to be aggregated along CIDR prefixes. This is seen as potentially useful for virtual private networks (VPN) and LSMAs using the High Level Architecture's Run Time Infrastructure (HLA/RTI) [HLARTI], which is currently under development and expected to be in use in the near future. LSMAs that use HLA/RTI would group multicast destination addresses along CIDR prefixes to allow further efficiencies in use of RSVP to cover traffic to several multicast groups. BOYLE Expires August 15, 1997 [Page 4] Internet Draft RSVP Extensions for CIDR objects February 15, 1997 2 Object Overview 2.1 Examples of Use As an example of use of CIDR extensions, suppose you have 4 sites participating in a distributed simulation. Each site has 50 hosts and each site is sending 500 kbs of traffic to a range of multicast addresses. A single host at each site sends a PATH message with CIDR SESSION and CIDR SENDER_TEMPLATE objects and base specification Tspec objects describing that the site expects to generate 500 kbs of traffic to the specified range of multicast addresses. Nomination of which host sends this message should be outside the scope of RSVP, the application must perform this function. When such a PATH message is received, a single host per recipient site sends back a RESV message to the sender host with a CIDR SESSION and CIDR FILTER_SPEC matching the sender's objects, a base specification flowspec and a fixed-filter reservation style. Such a reservation might say "Reserve 500 kbs of controlled load service for traffic from 192.1.1.1/24 to 224.5.6.1/30". The above assumes an alignment of Tspecs with LANs. The objects below would, however, allow for a configuration where the CIDR prefix used for LAN segmentation did not match the CIDR prefix in the RSVP extension objects. Such a case might involve a VPN configuration where a remote site office has 4 LANs sharing a common Class C network address via subnet mask of 255.255.255.192 (CIDR prefix of 26). If CIDR RSVP extensions were used to set up a pair of RSVP reservations between the site and main office, the CIDR prefix of 24 should be used. Until a clear mechanism for merging PATH messages is put forward, configuration of VPN services as outlined above would have only one host per site send PATH and RESV messages and those messages would describe the aggregate RSVP parameters of the hosts. 2.2 Special Considerations One issue quickly surfaces with SESSION aggregation, especially for multicast addresses. If one is reserving bandwidth for use by a group of multicast addresses, what would one use for the destination address of at the IP layer. For unicast, the IP destination address can be the address of the host that will be returning a RESV message. But for multicast, a PATH message must be sent to each multicast address that a site will be sending traffic too. This allows proper propagation of RSVP state to interested receivers that have joined groups within the session definition. BOYLE Expires August 15, 1997 [Page 5] Internet Draft RSVP Extensions for CIDR objects February 15, 1997 There is also an issue with how to handle establishment of sender state where the range of destination addresses covered by the Destination Address / CIDR prefix length overlaps with already established sessions. In addition to some additional rules described below, the basic requirement is that any one sessions range of addresses may not bisect another sessions address space. Said another way, they may overlap and one may be a subset of another, but they cannot partially overlap. This would allow RSVP use above and beyond a base level VPN RSVP use. For multicast applications with current constraints (or lack thereof) on multicast address space, this is not currently viewed as much of an increase in value. For potentially ambiguous situations where a packet could be classified as belonging to different reservations, a longest match on session should be done with no over-flow of best-effort traffic to other reservations. As an example: Reservation Sender Session A 1.2.3.1/16, 5.6.7.8/24 B 1.2.3.1/24, 5.6.7.8/16 A packet from 1.2.3.4 to 5.6.7.7 would be applied to reservation A. This follows the lines of RSVP's receiver oriented nature. BOYLE Expires August 15, 1997 [Page 6] Internet Draft RSVP Extensions for CIDR objects February 15, 1997 3 Object Definition The FILTER_SPEC, SENDER_TEMPLATE and SESSION class objects below contain a CIDR prefix field that specifies which hosts should be treated identically to the specified address. For example, in the CIDR FILTER_SPEC address, a source address of 199.1.1.1 with a CIDR prefix length of 24 (199.1.1.1/24 shorthand) would apply to all source addresses in the range of 199.1.1.0 to 199.1.1.255. 3.1 SESSION Class SESSION Class = 1 o IPv4 CIDR SESSION object: Class = 1 C-Type = 5 +-------------+-------------+-------------+-------------+ | IPv4 DestAddress (4 bytes) | +-------------+-------------+-------------+-------------+ | ////// | ////// | CIDR Prefix Length | +-------------+-------------+-------------+-------------+ | Protocol Id | Flags | DstPort | +-------------+-------------+-------------+-------------+ o IPv6 CIDR Session object: Class = 1 C-TYPE = 6 +-------------+-------------+-------------+-------------+ | | + + | | + IPv6 DestAddress (16 bytes) + | | + + | | +-------------+-------------+-------------+-------------+ | ////// | ////// | CIDR Prefix Length | +-------------+-------------+-------------+-------------+ | Protocol Id | Flags | DstPort | +-------------+-------------+-------------+-------------+ BOYLE Expires August 15, 1997 [Page 7] Internet Draft RSVP Extensions for CIDR objects February 15, 1997 3.2 FILTER_SPEC Class FILTER_SPEC Class = 10 o IPv4 CIDR FILTER_SPEC object: Class = 10, C-Type = 6 +-------------+-------------+-------------+-------------+ | IPv4 SrcAddress (4 bytes) | +-------------+-------------+-------------+-------------+ | CIDR Prefix Length | SrcPort | +-------------+-------------+-------------+-------------+ o IPv6 CIDR FILTER_SPEC object: Class = 10 C-Type = 7 +-------------+-------------+-------------+-------------+ | | + + | | + IPv6 SrcAddress (16 bytes) + | | + + | | +-------------+-------------+-------------+-------------+ | CIDR Prefix Length | SrcPort | +-------------+-------------+-------------+-------------+ 3.3 SENDER_TEMPLATE Class SENDER_TEMPLATE Class = 11 o IPv4 CIDR SENDER_TEMPLATE object: Class = 11, C-Type = 6 Definition same as IPv4 CIDR FILTER_SPEC object. o IPv6 CIDR SENDER_TEMPLATE object: Class = 11, C-Type = 7 Definition same as IPv6 CIDR FILTER_SPEC object. BOYLE Expires August 15, 1997 [Page 8] Internet Draft RSVP Extensions for CIDR objects February 15, 1997 4 Additional Processing Rules for CIDR Extension objects If Session Protocol = 0, no non-zero protocol sessions for range of Destination Addresses may exist. Alternatively, if Session Protocol is non-zero, no zero protocol session for range of Destination Addresses may exist. PathErr Returned: xx1 Conflicting Destination Protocols ResvErr Returned: xx1 Conflicting Destination Protocols If Session Protocol = 0, Dst Port must also be 0. PathErr Returned: xx2 Inappropriate Port for Protocol ResvErr Returned: xx2 Inappropriate Port for Protocol If Destination Port = 0 in SESSION, Source Port must also be 0. Message discarded. Err Logged: Conflicting Source Port If a node that does not support CIDR extensions receives a CIDR extension object, as per the base specification, it must return an error. PathErr Returned: 14 Unknown C-Type ResvErr Returned: 14 Unknown C-Type Session Destination Address Range boundaries must not bisect Destination Address Ranges of already defined Sessions. PathErr Returned: xx3 Conflicting Session Address Definition ResvErr Returned: xx3 Conflicting Session Address Definition CIDR prefixes must be within a valid range of 16 to 32 (for IPv4) or 16 to 128 (for IPv6). PathErr Returned: xx4 Malformed Session Address PathErr Returned: 21.04 Malformed Tspec ResvErr Returned: 21.03 Malformed flowspec For explicit style reservation, CIDR FILTER_SPEC must exactly match CIDR SENDER_TEMPLATE of session with installed sender state. ResvErr Returned: 04 No Sender Information for this RESV BOYLE Expires August 15, 1997 [Page 9] Internet Draft RSVP Extensions for CIDR objects February 15, 1997 RESV session must must exactly match installed sender state established by PATH message. ResvErr Returned: 03 No Path Information for this RESV 5 Security Considerations Security concern with CIDR extensions come in two parts. The first is the basic security concerns raised by using the base specification of RSVP and the other are concerns raised by use of CIDR aggregation of addresses. Both concerns can be addressed by means outside the scope of this draft or that of the base specification. In particular, the Policy Architecture being developed in other drafts within the working group provides a means to provide a base level of policy on RSVP state creation [LPM]. At a lower level, standard security measures such as access control at the IP level can be applied to limit exposure to un-desired RSVP state creation. 6 References [HLARTI] J.O. Calvin, R. Weatherly, "An Introduction to the High Level Architecture (HLA) Runtime Infrastructure (RTI)". 14th DIS Workshop, September 1995, Orlando, FL. http://www.dmso.mil/docslib/briefs/DIS/14DIS/hla.html [IEEE1] IEEE 1278.1-1995, Standard for Distributed Interactive Simulation - Application Protocols. [IEEE2] IEEE 1278.2-1995, Standard for Distributed Interactive Simulation - Communication services and Profiles. [LPM] S. Herzog, "RSVP Extensions for Policy Control", Internet Draft, November 1997, . [LSMA-SCENARIOS] S. Seidensticker, W.G. Smith, M. Myjak. "Scenarios and Appropriate Protocols for Distributed Interactive Simulation", Internet Draft, June 1996, . [RFCCIDR] V. Fuller, et. al. "Classless Interdomain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC1519. [RSVP] B. Braden, et. al. "Resource Reservation Protocol (RSVP) - Version 1 Functional Specification", Internet Draft, July 1996, . BOYLE Expires August 15, 1997 [Page 10] Internet Draft RSVP Extensions for CIDR objects February 15, 1997 7 Author Information and Acknowledgments The author wishes to especially thank Fred Baker for his guidance and insight on this topic. Special thanks to John Wroclawski, Lixia Zhang and other participants on the RSVP and LSMA mailing lists who provided valuable feedback for this draft. Jim Boyle MITRE Corporation 11493 Sunset Hills Road Reston, VA 22090 Phone: 703.883.7825 EMail: jboyle@gateway.mitre.org BOYLE Expires August 15, 1997 [Page 11]