[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
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]