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-tunnels-interop-00.txt < prev    next >
Text File  |  1997-03-12  |  6KB  |  233 lines
  1.  
  2.      INTERNET DRAFT  Tunnels/RSVP Interoperability       March 1997
  3.  
  4.  
  5.      INTERNET DRAFT                                John J. Krawczyk
  6.      RSVP Working Group                          Bay Networks, Inc.
  7.      draft-ietf-rsvp-tunnels-interop-00.txt          March 11, 1997
  8.                                            Expires: September, 1997
  9.  
  10.  
  11.  
  12.             Designing Tunnels for Interoperability with RSVP
  13.  
  14.  
  15.  
  16.      1.  Status of this Memo
  17.  
  18.      This document is an Internet-Draft.  Internet-Drafts are
  19.      working documents of the Internet Engineering Task Force
  20.      (IETF), its areas, and its working groups.  Note that other
  21.      groups may also distribute working documents as Internet-
  22.      Drafts.
  23.  
  24.      Internet-Drafts are draft documents valid for a maximum of six
  25.      months and may be updated, replaced, or obsoleted by other
  26.      documents at any time.  It is inappropriate to use Internet-
  27.      Drafts as reference material or to cite them other than as
  28.      "work in progress".
  29.  
  30.      To learn the current status of any Internet-Draft, please
  31.      check the "1id-abstracts.txt" listing contained in the
  32.      Internet-Drafts Shadow Directories on ftp.is.co.za (Africa),
  33.      ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim),
  34.      ds.internic.net (US East Coast), or ftp.isi.edu (US West
  35.      Coast).
  36.  
  37.  
  38.  
  39.      2.  Abstract
  40.  
  41.      This memo provides information for designers of tunneling
  42.      protocols that use IP-in-IP encapsulation.  It describes how
  43.      to design a tunnel header so that RSVP [RSVPv1] can be used to
  44.      signal the Quality of Service requirements for individual
  45.      flows within an IP-in-IP tunnel.
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.      JJ Krawczyk         Expires September 1997            [Page 1]
  56.  
  57.  
  58.  
  59.  
  60.  
  61.      INTERNET DRAFT  Tunnels/RSVP Interoperability       March 1997
  62.  
  63.  
  64.      3.  Introduction
  65.  
  66.      There are many issues concerning the use of RSVP when data is
  67.      encapsulated within IP-in-IP tunnels.  This memo discusses the
  68.      problem of classifying flows within a tunnel.  It is hoped
  69.      that this will aid those designing new tunneling mechanisms to
  70.      make their proposals "RSVP friendly".
  71.  
  72.      A problem with most of the existing IP-in-IP tunneling
  73.      mechanisms is the inability to distinguish between flows
  74.      within a tunnel based upon the tunnel "wrapper", or outer
  75.      header.  Therefore, while it is possible to make a reservation
  76.      for the tunnel itself, all traffic in the tunnel is then
  77.      treated in the same manner.
  78.  
  79.      Performing classification based upon the tunnel payload is
  80.      undesirable.  Two major reasons are:
  81.  
  82.           Examing additional fields in a packet can have severe
  83.           performance penalties.
  84.  
  85.           The payload may be encrypted.
  86.  
  87.      Therefore, it is desirable to be able to distinguish flows
  88.      based on fields in the encapsulating header.  This memo
  89.      explains how to design a tunnel header to meet this goal.
  90.  
  91.  
  92.  
  93.      4.  Requirements for an RSVP-Friendly Tunnel Header
  94.  
  95.      We will assume here that any simplex IP-in-IP tunnel, unicast
  96.      or multicast, can, at a minimum, be identified by the source
  97.      and destination IP addresses and an IP protocol number [e.g.,
  98.      RFC2003].  In order to classify individual flows within a
  99.      tunnel, at least one additional field is needed.  To be
  100.      compliant with RSVP version 1, the following alternatives can
  101.      be considered:
  102.  
  103.           UDP/TCP ports, or fields in the same location in the
  104.           packet for protocols other than UDP and TCP.
  105.  
  106.           For IPv6, the Flow ID.
  107.  
  108.           Any mechanism compliant with the Generalized Port
  109.  
  110.  
  111.  
  112.  
  113.  
  114.      JJ Krawczyk         Expires September 1997            [Page 2]
  115.  
  116.  
  117.  
  118.  
  119.  
  120.      INTERNET DRAFT  Tunnels/RSVP Interoperability       March 1997
  121.  
  122.  
  123.           Identifier as described in [RSVPIPSEC].
  124.  
  125.      If classification on any other fields is desired, new RSVP
  126.      SESSION and/or FILTER_SPEC / SENDER_TEMPLATE C-Types have to
  127.      be defined.
  128.  
  129.  
  130.      5.  An Example: UDP Encapsulation
  131.  
  132.      A UDP encapsulation scheme would be compatible with RSVP
  133.      version 1.  A well-known port number is necessary for the UDP
  134.      destination port field.  Up to 65534 individual flows could
  135.      then be multiplexed over the tunnel by using a different value
  136.      for the UDP source port for each flow.
  137.  
  138.  
  139.      6.  Security Considerations
  140.  
  141.      Using a tunnel header as described in this document allows for
  142.      a type of traffic pattern analysis. The required level of
  143.      exposure may be acceptable in many situations because the
  144.      actual source and destination of the traffic will not be
  145.      visible if the end-to-end packet format does not make it so.
  146.      If this exposure is unacceptable, per-flow classification is
  147.      not possible.
  148.  
  149.  
  150.  
  151.      7.  References
  152.  
  153.      [RSVPv1] R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin,
  154.      "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
  155.      Specification", Internet Draft draft-ietf-rsvp-spec-14.txt,
  156.      November, 1996.
  157.  
  158.      [RFC2003] C. Perkins, "IP Encapsulation within IP", IETF RFC
  159.      2003, October, 1996.
  160.  
  161.      [RSVPIPSEC] L. Berger, T. O'Malley, "RSVP Extensions for IPSEC
  162.      Data Flows", Internet Draft draft-berger-rsvp-ext-06.txt, Jan,
  163.      1997.
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170.  
  171.  
  172.  
  173.      JJ Krawczyk         Expires September 1997            [Page 3]
  174.  
  175.  
  176.  
  177.  
  178.  
  179.      INTERNET DRAFT  Tunnels/RSVP Interoperability       March 1997
  180.  
  181.  
  182.      8.  Author's Address
  183.  
  184.      John J. Krawczyk
  185.      Bay Networks, Inc.
  186.      2 Federal Street
  187.      Billerica, MA  01821
  188.      +1-508-916-3811
  189.      jj@baynetworks.com
  190.  
  191.  
  192.  
  193.  
  194.  
  195.  
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202.  
  203.  
  204.  
  205.  
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226.  
  227.  
  228.  
  229.  
  230.  
  231.  
  232.      JJ Krawczyk         Expires September 1997            [Page 4]
  233.