Internet Draft Jim Boyle Expiration: December 25, 1997 MCI File: draft-ietf-rsvp-cidr-ext-01.txt RSVP Extensions for CIDR Aggregated Data Flows June 25, 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 December 25, 1997 [Page 1]
Internet Draft RSVP Extensions for CIDR objects June 25, 1997 Abstract This document presents extensions to Version 1 of the Resource Reservation Setup Protocol (RSVP). These extensions ameliorate RSVP support of Large Scale Multicast Applications (LSMA) and Virtual Private Networks (VPN). With these types of applications, several hosts at any particular site are participating in a session. Efficient RSVP use requires aggregation of their addresses into a single entry for classification purposes. The extensions allow such aggregation of state in a simple manner that requires no changes to the base RSVP specification. BOYLE Expires December 25, 1997 [Page 2]
Internet Draft RSVP Extensions for CIDR objects June 25, 1997 Table of Contents 1 Introduction 4 2 Object Overview 5 2.1 Examples of Use 5 2.2 Special Considerations 6 3 Object Definition 8 3.1 SESSION Class 8 3.2 FILTER_SPEC Class 9 3.3 SENDER_TEMPLATE Class 9 4 Additional Processing Rules for CIDR Extensions 10 5 Security Considerations 11 6 References 11 7 Acknowledgments and Authors' Information 12 7.1 Acknowledgments 12 7.2 Authors' Information 12 BOYLE Expires December 25, 1997 [Page 3]
Internet Draft RSVP Extensions for CIDR objects June 25, 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. Though an important set of applications, they are distinctive in that they assume a small number of originators of data per geographic vicinity. Other applications such as the simulation network applications described in in the LSMA working group [LSMA] have different architectures that includes multiple sites (i.e. LANs) inter-communicating with several workstations per site originating network traffic. For the case of LSMAs, RSVP can be used to protect the simulation traffic over the WAN, which is desirable since the multicast transport protocols currently used can not throttle transmission or retransmit lost packets. The objects described in the base RSVP specification do not meet the RSVP needs of LSMAs in an efficient manner. Another example of an application where several hosts from a sender site originate traffic is VPNs. 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 applications with several senders per site in an efficient manner. The objects allow hosts within a classless inter-domain routing (CIDR) prefix [RFCCIDR] to be grouped by RSVP as a single entry. With CIDR extensions, a host at each site would send out a PATH message with CIDR SESSION and 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 containing CIDR SESSION and FILTER_SPEC objects. BOYLE Expires December 25, 1997 [Page 4]
Internet Draft RSVP Extensions for CIDR objects June 25, 1997 2 Object Overview 2.1 Examples of Use 2.1.1 LSMA Suppose you have 4 sites participating in a distributed simulation. Each site has 50 hosts and each site is sending 250 kbs of traffic to a multicast address. A single host at each site sends a PATH message with CIDR SESSION and CIDR SENDER_TEMPLATE objects and base specification Tspec object describing that the site expects to generate 250 kbs of traffic to the specified multicast address. Nomination of which host sends this message is 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 250 kbs of controlled load service for traffic from 192.1.1.1/24 to 224.5.6.1/32". Aggregating multicast groups within a range would be useful, but this proves problematic due to possibly divergent routing paths per individual groups. This problem is discussed in greater detail in section 2.2.??. In the above example, 9 inter-site reservations would be established with each reservation expected to match its respective Tspec. With traditional objects, as detailed in the base specification, use of RSVP to protect the aforementioned scenario could result in excessive message and classification processing, in the case of distinct reservations. For shared reservations, over-subscription of the reservation (250 kbs of traffic flowing through a 750 kbs reservation) would result. 2.1.2 VPN CIDR extensions provide a scalable manner in which to provide VPN services with RSVP. As an alternate approach, one might choose to use an IP in IP tunnel which has some advantages but also has the disadvantage that it forces the packets to be encapsulated at the tunnel-ingress router. Suppose two corporate site offices would like to setup VPN service with a main office. A host at each site would send a PATH message to the respective host at the other sites. This PATH message would use CIDR SESSION and SENDER_TEMPLATE objects and would contain a Tspec describing the traffic from the originating site to the destination site. In response, a RESV message would be BOYLE Expires December 25, 1997 [Page 5]
Internet Draft RSVP Extensions for CIDR objects June 25, 1997 sent using CIDR SESSION and CIDR FILTER_SPEC objects. In the case mentioned, there would be 3 RSVP reservations installed in the network. Without using tunnels, the above could not be supported by the base specification objects. 2.2 Special Considerations for CIDR Objects 2.2.1 Route assumptions In order for CIDR objects to work, and be most effective, an assumption must be made that the RSVP administrator is aware of non- singular routes for the aggregated address space. For unicast CIDR SESSION objects, for instance, the RSVP exchange is taking place between two distinct IP addresses. This can fail to provide full coverage of inter-site traffic if a subset of the addresses within the CIDR SESSION is routed differently than the route over which the RSVP state was installed. It is likely that such route divergence is caused by circumstances that the possessor of the address range is aware of (such as multi-homing). 2.2.2 CIDR SESSION objects and Multicast The assumption listed in Section 2.2.1 are not valid with many multicast routing protocols. Therefore, to establish PATH state for all groups within a range, a PATH message must be sent to each destination address. As these might take different routes through the network, it is better to send a Tspec that specifically covers traffic from a site to that particular group, obviating the need for CIDR SESSION for multicast. Therefore, applications should use a CIDR Prefix length of 32 for multicast destinations. Multicast routing protocols are source sensitive, so one should note that CIDR aggregation of sender state may fail the singular route assumption. This is the case for multicast routing protocols that can set up multiple routes for hosts within the same unicast route entry. For instance, in PIM-SM [PIM-SM] one host's packets to a multicast group could take a shortest path through route while packets from another host on the same LAN route through the rendezvous point. 2.2.3 Overlapping SESSION definitions There is also an issue with how to handle establishment of SESSION state where the range of destination addresses covered by the Destination Address / CIDR prefix length overlaps with already BOYLE Expires December 25, 1997 [Page 6]
Internet Draft RSVP Extensions for CIDR objects June 25, 1997 established sessions. In addition to some additional rules described in section 4, the basic requirement is that any one session's range of addresses may not bisect another session's range. 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 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 December 25, 1997 [Page 7]
Internet Draft RSVP Extensions for CIDR objects June 25, 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 Length | /////////////////////////////////////// | +-------------+-------------+-------------+-------------+ | Protocol Id | Flags | DstPort | +-------------+-------------+-------------+-------------+ o IPv6 CIDR Session object: Class = 1 C-TYPE = 6 +-------------+-------------+-------------+-------------+ | | + + | | + IPv6 DestAddress (16 bytes) + | | + + | | +-------------+-------------+-------------+-------------+ | CIDR Length | /////////////////////////////////////// | +-------------+-------------+-------------+-------------+ | Protocol Id | Flags | DstPort | +-------------+-------------+-------------+-------------+ BOYLE Expires December 25, 1997 [Page 8]
Internet Draft RSVP Extensions for CIDR objects June 25, 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 Length | /////////// | SrcPort | +-------------+-------------+-------------+-------------+ o IPv6 CIDR FILTER_SPEC object: Class = 10 C-Type = 7 +-------------+-------------+-------------+-------------+ | | + + | | + IPv6 SrcAddress (16 bytes) + | | + + | | +-------------+-------------+-------------+-------------+ | CIDR 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 December 25, 1997 [Page 9]
Internet Draft RSVP Extensions for CIDR objects June 25, 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 December 25, 1997 [Page 10]
Internet Draft RSVP Extensions for CIDR objects June 25, 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 RSVP with CIDR extensions is not less secure than base specification RSVP. Security for both can be addressed by use of MD5 authentication described in [RSVPMD5]. Though under development, RSVP's policy procedures might also be used to assure that non- authorized state is not installed. 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. [LSMA-SCENARIOS] S. Seidensticker, W.G. Smith, M. Myjak. "Scenarios and Appropriate Protocols for Distributed Interactive Simulation", Internet Draft, June 1996, <draft-ietf-lsma-scenarios-00.txt>. [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, <draft-ietf-rsvp-spec-14.txt>. [RSVPMD5] F. Baker, "RSVP Cryptographic Authentication", Internet Draft, May 1997, <draft-ietf-rsvp-md5-03.txt>. BOYLE Expires December 25, 1997 [Page 11]
Internet Draft RSVP Extensions for CIDR objects June 25, 1997 7 Author Information and Acknowledgments The author wishes to especially thank Fred Baker for his guidance on this topic. Several members of the RSVP and LSMA mailing lists also provided invaluable feedback. Jim Boyle MCI 2100 Reston Parkway Reston, VA 20191 Phone: 703.715.7006 EMail: jboyle@mci.net BOYLE Expires December 25, 1997 [Page 12]
