home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_i / draft-ietf-issll-atm-imp-guide-01.txt < prev    next >
Text File  |  1997-07-15  |  14KB  |  409 lines
  1.  
  2. Internet Draft                                                 L. Berger
  3. Expires: January 1998                                       FORE Systems
  4. File: draft-ietf-issll-atm-imp-guide-01.txt
  5.  
  6.  
  7.  
  8.                 RSVP over ATM Implementation Guidelines
  9.  
  10.  
  11.  
  12.                              July 11, 1997
  13.  
  14. Status of Memo
  15.  
  16.    This document is an Internet-Draft.  Internet-Drafts are working
  17.    documents of the Internet Engineering Task Force (IETF), its areas,
  18.    and its working groups.  Note that other groups may also distribute
  19.    working documents as Internet-Drafts.
  20.  
  21.    Internet-Drafts are draft documents valid for a maximum of six months
  22.    and may be updated, replaced, or obsoleted by other documents at any
  23.    time.  It is inappropriate to use Internet-Drafts as reference
  24.    material or to cite them other than as "work in progress."
  25.  
  26.    To learn the current status of any Internet-Draft, please check the
  27.    "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
  28.    Directories on ds.internic.net (US East Coast), nic.nordu.net
  29.    (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
  30.    Rim).
  31.  
  32. Abstract
  33.  
  34.    This note presents specific implementation guidelines for running
  35.    RSVP over ATM switched virtual circuits (SVCs).  The general problem
  36.    is discussed in [8].  Implementation requirements are discussed in
  37.    [3].  Integrated Services to ATM service mappings are covered in [6].
  38.    The full set of documents present the background and information
  39.    needed to implement Integrated Services and RSVP over ATM.
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53. Berger                   Expires: January 1998                  [Page 1]
  54.  
  55.  
  56.  
  57.  
  58. Internet Draft          RSVP over ATM Guidelines               July 1997
  59.  
  60.  
  61. 1. Introduction
  62.  
  63.    This note discusses running IP over ATM in an environment where SVCs
  64.    are used to support QoS flows and RSVP is used as the internet level
  65.    QoS signaling protocol.  It applies when using CLIP/ION, LANE2.0 and
  66.    MPOA methods for supporting IP over ATM.  The general issues related
  67.    to running RSVP[7] over ATM have been covered in several papers
  68.    including [8,4,2,5].  This document is intended as a companion to
  69.    [8,3] and as a guide to implementers.  The reader should be familiar
  70.    with both documents.
  71.  
  72.    This document will provide a recommended set of functionality for
  73.    implementations using ATM UNI3.x and 4.0, while allowing for more
  74.    sophisticated approaches.  We expect some vendors to additionally
  75.    provide some of the more sophisticated approaches described in [8],
  76.    and some networks to only make use of such approaches.  The
  77.    recommended set of functionality is defined to ensure predictability
  78.    and interoperability between different implementations.  Requirements
  79.    for RSVP over ATM implementations are provided in [3].
  80.  
  81.    This document uses the same terms and assumption stated in [3].
  82.  
  83. 2. Implementation Recommendations
  84.  
  85.    This section provides implementation guidelines for implementation of
  86.    RSVP over ATM.  Several recommendations are common for all, both
  87.    unicast and multicast, RSVP sessions.  There are also recommendations
  88.    that are unique to unicast and multicast session types.
  89.  
  90.    2.1 RSVP Message VC Usage
  91.  
  92.       The general issues related to which VC should be used for RSVP
  93.       messages is covered in [8]. It discussed several implementation
  94.       options including: mixed control and data, single control VC per
  95.       session,  single control VC multiplexed among sessions, and
  96.       multiple VCs multiplexed among sessions.  QoS for control VCs was
  97.       also discussed.  The general discussion is not repeated here and
  98.       [8] should be reviewed for detailed information.
  99.  
  100.       RSVP over ATM implementations SHOULD send RSVP control (messages)
  101.       over the best effort data path, see figure 1.  It is permissible
  102.       to allow a user to override this behavior.  The stated approach
  103.       minimizes VC requirements since the best effort data path will
  104.       need to exist in order for RSVP sessions to be established and in
  105.       order for RSVP reservations to be initiated.  The specific best
  106.       effort paths that will be used by RSVP are: for unicast, the same
  107.       VC used to reach the unicast destination; and for multicast, the
  108.       same VC that is used for best effort traffic destined to the IP
  109.  
  110.  
  111.  
  112. Berger                   Expires: January 1998                  [Page 2]
  113.  
  114.  
  115.  
  116.  
  117. Internet Draft          RSVP over ATM Guidelines               July 1997
  118.  
  119.  
  120.       multicast group.  Note that for multicast there may be another
  121.       best effort VC that is used to carry session data traffic, i.e.,
  122.       for data that is both in the multicast group and matching a
  123.       sessions protocol and port.
  124.  
  125.  
  126.                              Data Flow ==========>
  127.  
  128.                                     QoS VCs
  129.                      +-----+    -------------->   +----+
  130.                      |     |  -------------->     |    |
  131.                      | Src |                      | R1 |
  132.                      |     |   Best Effort VC(s)  |    |
  133.                      +-----+  <-----------------> +----+
  134.                                   /\
  135.                                   ||
  136.                                   ||
  137.                               RSVP Control
  138.                                 Messages
  139.  
  140.                    Figure 1: RSVP Control Message VC Usage
  141.  
  142.  
  143.       The disadvantage of this approach is that best effort VCs may not
  144.       provide the reliability that RSVP needs.  However the best-effort
  145.       path is expected to satisfy RSVP reliability requirements in most
  146.       networks. Especially since RSVP allows for a certain amount of
  147.       packet loss without any loss of state synchronization.
  148.  
  149.    2.2 Aggregation
  150.  
  151.       As discussed in [8], data associated with multiple RSVP sessions
  152.       could be sent using the same shared VCs. Implementation of such
  153.       "aggregation" models is still a matter for research.  Therefore,
  154.       RSVP over ATM implementations SHOULD use independent VCs for each
  155.       RSVP reservation.
  156.  
  157.    2.3 Short-Cuts
  158.  
  159.       Short-cuts allow ATM attached routers and hosts to directly
  160.       establish point-to-point VCs across LIS boundaries, i.e., the VC
  161.       end-points are on different IP sub-nets. Short-cut support for
  162.       unicast traffic has been defined in [9] and [1].  The ability for
  163.       short-cuts and RSVP to interoperate has been raised as a general
  164.       question.  The area of concern is the ability to handle asymmetric
  165.       short-cuts.  Specifically how RSVP can handle the case where a
  166.       downstream short-cut may not have a matching upstream short-cut.
  167.       In this case, which is shown in figure 2, PATH and RESV messages
  168.  
  169.  
  170.  
  171. Berger                   Expires: January 1998                  [Page 3]
  172.  
  173.  
  174.  
  175.  
  176. Internet Draft          RSVP over ATM Guidelines               July 1997
  177.  
  178.  
  179.       following different paths.
  180.  
  181.  
  182.                            ______
  183.                           /      \
  184.                +-------- / Router \ <-------+
  185.                |         \        /         |   <....... RESVs Follow
  186.                |          \______/          |            Hop-by-hop Path
  187.                |                            |
  188.                |                            |
  189.                V           QoS VCs          |
  190.             +-----+    ==============>   +----+
  191.             |     |  ==============>     |    |
  192.             | Src |                      | R1 |
  193.             |     |   Best Effort VC(s)  |    |
  194.             +-----+  <=================> +----+
  195.  
  196.                          /\
  197.                          ::                        Data Paths:
  198.                          ::                        ----> Hop-by-hop (routed)
  199.                    PATHs and Data                  ====> Short-cut
  200.                   Follow Short-cut
  201.                          Path
  202.  
  203.        Figure 2: Asymmetric RSVP Message Forwarding With ATM Short-Cuts
  204.  
  205.  
  206.       Examination of RSVP shows that the protocol already includes
  207.       mechanisms that allows support of short-cuts.  The mechanism is
  208.       the same one used to support RESV messages arriving at the wrong
  209.       router and the wrong interface.  The key aspect of this mechanism
  210.       is RSVP only processing messages that arrive at the proper
  211.       interface and RSVP forwarding of messages that arrive on the wrong
  212.       interface.  The proper interface is indicated in the NHOP object
  213.       of the message.  So, existing RSVP mechanisms will support
  214.       asymmetric paths.
  215.  
  216.       The short-cut model of VC establishment still poses several issues
  217.       when running with RSVP. The major issues are dealing with
  218.       established best-effort short-cuts, when to establish short-cuts,
  219.       and QoS only short-cuts. These issues will need to be addressed by
  220.       RSVP implementations.
  221.  
  222.       The key issue to be addressed by any RSVP over ATM solution is
  223.       when to establish a short-cut for a QoS data flow.  RSVP over ATM
  224.       implementations SHOULD simply follow best-effort traffic. When a
  225.       short-cut has been established for best-effort traffic to a
  226.       destination or next-hop, that same end-point SHOULD be used when
  227.  
  228.  
  229.  
  230. Berger                   Expires: January 1998                  [Page 4]
  231.  
  232.  
  233.  
  234.  
  235. Internet Draft          RSVP over ATM Guidelines               July 1997
  236.  
  237.  
  238.       setting up RSVP triggered VCs for QoS traffic to the same
  239.       destination or next-hop. This will happen naturally when PATH
  240.       messages are forwarded over the best-effort short-cut.  Note that
  241.       in this approach when best-effort short-cuts are never
  242.       established, RSVP triggered QoS short-cuts will also never be
  243.       established.
  244.  
  245.    2.4 Data VC Management for Heterogeneous Sessions
  246.  
  247.       Heterogeneous sessions can only occur with multicast RSVP
  248.       sessions.  The issues relating to data VC management of
  249.       heterogeneous sessions are covered in detail in [8] and are not
  250.       repeated.  In summary, heterogeneity occurs when receivers request
  251.       different levels of QoS within a single session and also when some
  252.       receivers do not request any QoS.  Both types of heterogeneity are
  253.       shown in figure 3.
  254.  
  255.                                     +----+
  256.                            +------> | R1 |
  257.                            |        +----+
  258.                            |
  259.                            |        +----+
  260.               +-----+ -----+   +--> | R2 |
  261.               |     | ---------+    +----+        Receiver Request Types:
  262.               | Src |                             ---->  QoS 1 and QoS 2
  263.               |     | .........+    +----+        ....>  Best-Effort
  264.               +-----+ .....+   +..> | R3 |
  265.                            :        +----+
  266.                        /\  :
  267.                        ||  :        +----+
  268.                        ||  +......> | R4 |
  269.                        ||           +----+
  270.                      Single
  271.                   IP Mulicast
  272.                      Group
  273.  
  274.                     Figure 3: Types of Multicast Receivers
  275.  
  276.  
  277.       [8] provides four models for dealing with heterogeneity: full
  278.       heterogeneity,  limited heterogeneity, homogeneous, and modified
  279.       homogeneous models.  The key issue to be addressed by an
  280.       implementation is providing requested QoS downstream. One of or
  281.       some combination of the discussed models [8] may be used to
  282.       provide requested QoS.  Unfortunately, none of the described
  283.       models is the right answer for all cases.  For some networks, e.g.
  284.       public WANs, it is likely that the limited heterogeneous model or
  285.       a hybrid limited-full heterogeneous model will be desired.  In
  286.  
  287.  
  288.  
  289. Berger                   Expires: January 1998                  [Page 5]
  290.  
  291.  
  292.  
  293.  
  294. Internet Draft          RSVP over ATM Guidelines               July 1997
  295.  
  296.  
  297.       other networks, e.g. LANs, it is likely that a the modified
  298.       homogeneous model will be desired.
  299.  
  300.       Since there is not one model that satisfies all cases,
  301.       implementations SHOULD implement one of either the limited
  302.       heterogeneity model or the modified homogeneous model.
  303.       Implementations SHOULD support both approaches and provide the
  304.       ability to select which method is actually used, but are not
  305.       required to do so.
  306.  
  307. 3. Security
  308.  
  309.    The same considerations stated in [7] and [10] apply to this
  310.    document.  There are no additional security issues raised in this
  311.    document.
  312.  
  313. 4. Acknowledgments
  314.  
  315.    This work is based on earlier drafts [2,4] and comments from the
  316.    ISSLL working group.  The author would like to acknowledge their
  317.    contribution, most notably Steve Berson who coauthored [4].
  318.  
  319. 5. Author's Address
  320.  
  321.       Lou Berger
  322.       FORE Systems
  323.       6905 Rockledge Drive
  324.       Suite 800
  325.       Bethesda, MD 20817
  326.  
  327.       Phone: +1 301 571 2534
  328.       EMail: lberger@fore.com
  329.  
  330. REFERENCES
  331.  
  332. [1] The ATM Forum, "MPOA Baseline Version 1", May 1997.
  333.  
  334. [2] Berger, L., "RSVP over ATM: Framework and UNI3.0/3.1 Method",
  335.     Internet Draft, June 1996.
  336.  
  337. [3] Berger, L., "RSVP over ATM Implementation Requirements, Internet
  338.     Draft, July 1997.
  339.  
  340. [4] Berson, S., Berger, L., "IP Integrated Services with RSVP over ATM,"
  341.     Internet Draft, draft-ietf-issll-atm-support-02.txt, November 1996.
  342.  
  343. [5] Borden, M., Crawley, E., Krawczyk, J, Baker, F., and Berson, S.,
  344.     "Issues for RSVP and Integrated Services over ATM," Internet Draft,
  345.  
  346.  
  347.  
  348. Berger                   Expires: January 1998                  [Page 6]
  349.  
  350.  
  351.  
  352.  
  353. Internet Draft          RSVP over ATM Guidelines               July 1997
  354.  
  355.  
  356.     February 1996.
  357.  
  358. [6] Borden, M., and Garrett, M., "Interoperation of Controlled-Load and
  359.     Guaranteed-Service with ATM," Internet Draft, March 1997.
  360.  
  361. [7] Braden, R., Zhang, L., Berson, S., Herzog, S., and Jamin, S.,
  362.     "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
  363.     Specification," Internet Draft, June 1997.
  364.  
  365. [8] Crawley, E., Berger, L., Berson, S., Baker, F., Borden, M., and
  366.     Krawczyk, J, "Issues for Integrated Services and RSVP over ATM,"
  367.     Internet Draft, July 1997.
  368.  
  369. [9] Luciani, J., Katz, D., Piscitello, D., Cole, B., "NBMA Next Hop
  370.     Resolution Protocol (NHRP)," Internet Draft, January 1997.
  371.  
  372. [10] Perez, M., Liaw, F., Grossman, D., Mankin, A., Hoffman, E., and
  373.     Malis, A., "ATM Signalling Support for IP over ATM," RFC 1755.
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394.  
  395.  
  396.  
  397.  
  398.  
  399.  
  400.  
  401.  
  402.  
  403.  
  404.  
  405.  
  406.  
  407. Berger                   Expires: January 1998                  [Page 7]
  408.  
  409.