home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
drafts
/
draft_ietf_q_t
/
draft-ietf-rsvp-cidr-ext-00.txt
< prev
next >
Wrap
Text File
|
1997-02-12
|
19KB
|
638 lines
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, <draft-ietf-rsvp-policy-ext-01.txt>.
[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>.
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]