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-00.txt < prev    next >
Text File  |  1997-03-25  |  37KB  |  942 lines
  1.  
  2.  
  3. Internet Draft                                                 L. Berger
  4. Expires: September 1997                                     FORE Systems
  5. File: draft-ietf-issll-atm-imp-guide-00.txt
  6.  
  7.  
  8.  
  9.                 RSVP over ATM Implementation Guidelines
  10.  
  11.  
  12.  
  13.                              March 25, 1997
  14.  
  15. Status of Memo
  16.  
  17.    This document is an Internet-Draft.  Internet-Drafts are working
  18.    documents of the Internet Engineering Task Force (IETF), its areas,
  19.    and its working groups.  Note that other groups may also distribute
  20.    working documents as Internet-Drafts.
  21.  
  22.    Internet-Drafts are draft documents valid for a maximum of six months
  23.    and may be updated, replaced, or obsoleted by other documents at any
  24.    time.  It is inappropriate to use Internet-Drafts as reference
  25.    material or to cite them other than as "work in progress."
  26.  
  27.    To learn the current status of any Internet-Draft, please check the
  28.    "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
  29.    Directories on ds.internic.net (US East Coast), nic.nordu.net
  30.    (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
  31.    Rim).
  32.  
  33. Abstract
  34.  
  35.    This note presents specific implementation guidelines for running
  36.    RSVP over ATM switched virtual circuits (SVCs).  It presents
  37.    requirements and specific guidelines for running over today's ATM
  38.    networks.  The general problem is discussed in [5].   Integrated
  39.    Services to ATM service mappings are covered in [7].
  40.  
  41.  
  42. Author's Note
  43.  
  44.    The postscript version of this document contains figures that are not
  45.    included in the text version, so it is best to use the postscript
  46.    version.  Figures will be converted to ASCII in a future version.
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54. Berger                  Expires: September 1997                 [Page 1]
  55.  
  56.  
  57.  
  58.  
  59. Internet Draft  RSVP over ATM Implementation Guidelines       March 1996
  60.  
  61.  
  62. Table of Contents
  63.  
  64. 1. Introduction ........................................................3
  65.    1.1 Terms ...........................................................3
  66.    1.2 Assumptions .....................................................4
  67. 2. Multicast RSVP Session Support ......................................4
  68.    2.1 Data VC Management for Heterogeneous Sessions ...................5
  69.    2.2 Multicast End-Point Identification ..............................6
  70.    2.3 Multicast Data Distribution .....................................7
  71.    2.4 Receiver Transitions ............................................7
  72. 3. General RSVP Session Support ........................................8
  73.    3.1 RSVP Message VC Usage ...........................................8
  74.    3.2 VC Initiation ...................................................9
  75.    3.3 VC Teardown .....................................................10
  76.    3.4 Reservation to VC Mapping .......................................10
  77.    3.5 Dynamic QoS .....................................................11
  78.    3.6 Short-Cuts ......................................................12
  79.    3.7 Encapsulation ...................................................13
  80. 4. Security ............................................................13
  81. 5. Implementation Summary ..............................................13
  82.    5.1 Requirements ....................................................13
  83.    5.2 Baseline Requirements ...........................................14
  84. 6. Author's Address ....................................................15
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113. Berger                  Expires: September 1997                 [Page 2]
  114.  
  115.  
  116.  
  117.  
  118. Internet Draft  RSVP over ATM Implementation Guidelines       March 1996
  119.  
  120.  
  121. 1. Introduction
  122.  
  123.    This note discusses running IP over ATM in an environment where SVCs
  124.    are used to support QoS flows and RSVP is used as the internet level
  125.    QoS signaling protocol. The general issues related to running RSVP[8]
  126.    over ATM have been covered in several papers including [5,4,6,11].
  127.    This document is intended as a companion to [5] and as a guide to
  128.    implementers.  The reader should be familiar with[5].  This document
  129.    will define specific baseline requirements for implementations using
  130.    ATM UNI3.x and 4.0. Some stated requirements must be adhered to by
  131.    all RSVP over ATM implementations.  Other stated requirements provide
  132.    a baseline set of functionality, while allowing for more
  133.    sophisticated approaches. We expect some vendors to additionally
  134.    provide some of the more sophisticated approaches described in [5],
  135.    and some networks to only make use of such approaches.  The baseline
  136.    set of functionality is defined to ensure predictability and
  137.    interoperability between different implementations.  We expect that
  138.    the baseline requirements may change in the future, and at such a
  139.    time this document will be replaced.
  140.  
  141.    The rest of this section will define terms and assumptions used in
  142.    the document.  Section 2 will cover implementation guidelines
  143.    specific to multicast sessions.  Section 3 will cover implementation
  144.    guidelines common to all RSVP session.  Section 5 will conclude with
  145.    a summary of stated requirements.
  146.  
  147.    1.1 Terms
  148.  
  149.       The terms "reservation" and "flow" are used in many contexts,
  150.       often with different meaning.  These terms are used in this
  151.       document with the following meaning:
  152.  
  153.  
  154.       o    Reservation is used in this document to refer to an RSVP
  155.            initiated request for resources.  RSVP initiates requests for
  156.            resources based on RESV message processing.  RESV messages
  157.            that simply refresh state do not trigger resource requests.
  158.            Resource requests may be made based on RSVP sessions and RSVP
  159.            reservation styles. RSVP styles dictate whether the reserved
  160.            resources are used by one sender or shared by multiple
  161.            senders.  See [8] for details of each. Each new request is
  162.            referred to in this document as an RSVP reservation, or
  163.            simply reservation.
  164.  
  165.       o    Flow is used to refer to the data traffic associated with a
  166.            particular reservation.  The specific meaning of flow is RSVP
  167.            style dependent.  For shared style reservations, there is one
  168.            flow per session.  For distinct style reservations, there is
  169.  
  170.  
  171.  
  172. Berger                  Expires: September 1997                 [Page 3]
  173.  
  174.  
  175.  
  176.  
  177. Internet Draft  RSVP over ATM Implementation Guidelines       March 1996
  178.  
  179.  
  180.            one flow per sender (per session).
  181.  
  182.    1.2 Assumptions
  183.  
  184.       The following assumptions are made:
  185.  
  186.  
  187.       o    RSVP We assume RSVP as the internet signalling protocol which
  188.            is described in [8].  The reader is assumed to be familiar
  189.            with [8].
  190.  
  191.       o    IPv4 and IPv6 RSVP support has been defined for both IPv4 and
  192.            IPv6.  The guidelines in this document are intended to be
  193.            used to support RSVP with either IPv4 or IPv6.  This document
  194.            does not require on version over the other.
  195.  
  196.       o    Best effort service model The current Internet only supports
  197.            best effort service.  We assume that as additional components
  198.            of the Integrated Services model that best effort service
  199.            will continue to be a supported.
  200.  
  201.       o    ATM UNI 3.x and 4.0 We assume ATM service as defined by UNI
  202.            3.x and 4.0.  ATM provides both point-to-point and point-to-
  203.            multipoint Virtual Circuits (VCs) with a specified Quality of
  204.            Service (QoS).  ATM provides both Permanent Virtual Circuits
  205.            (PVCs) and Switched Virtual Circuits (SVCs).  In the
  206.            Permanent Virtual Circuit (PVC) environment, PVCs are
  207.            typically used as point-to-point link replacements.  So the
  208.            support issues are similar to point-to-point links.  This
  209.            draft assumes that SVCs are used to support RSVP over ATM.
  210.  
  211. 2. Multicast RSVP Session Support
  212.  
  213.    There are several aspects to running RSVP over ATM that are
  214.    particular to multicast sessions.  These issues result from the
  215.    nature of ATM point-to-multipoint connections.  This section
  216.    addresses multicast end-point identification, multicast data
  217.    distribution, multicast receiver transitions and next-hops requesting
  218.    different QoS values (heterogeneity) which includes the handling of
  219.    multicast best-effort receivers.  Handling of best-effort receivers
  220.    is not strictly an RSVP issues, but needs to be addressed in any RSVP
  221.    over ATM implementation in order to maintain expected Internet
  222.    service.  Implementation guidelines for issues related to all RSVP
  223.    sessions are covered in Section 3.  Some of these guidelines cover
  224.    issues that have special interactions for multicast session, these
  225.    interactions are covered together with the more general issues.
  226.  
  227.  
  228.  
  229.  
  230.  
  231. Berger                  Expires: September 1997                 [Page 4]
  232.  
  233.  
  234.  
  235.  
  236. Internet Draft  RSVP over ATM Implementation Guidelines       March 1996
  237.  
  238.  
  239.    2.1 Data VC Management for Heterogeneous Sessions
  240.  
  241.       The issues relating to data VC management of heterogeneous
  242.       sessions are covered in detail in [5] and not repeated.  In
  243.       summary, heterogeneity occurs when receivers request different
  244.       levels of QoS within a single session, and also when some
  245.       receivers do not request any QoS.  Both types of heterogeneity are
  246.       shown in figure .
  247.  
  248.       [Figure goes here]
  249.                     Figure 1: Types of Multicast Receivers
  250.  
  251.  
  252.       [5] provided four models for dealing with heterogeneity: full
  253.       heterogeneity,  limited heterogeneity, homogeneous, and modified
  254.       homogeneous models.  No matter which model or combination of
  255.       models is used by an implementation, implementations must not
  256.       normally send more than one copy of a particular data packet to a
  257.       particular next-hop (ATM end-point).  Some transient over
  258.       transmission is acceptable, but only during VC setup and
  259.       transition.
  260.  
  261.       Implementations must also ensure that data traffic is sent to
  262.       best-effort receivers.  Data traffic may be sent to best-effort
  263.       receivers via best-effort or QoS VCs as is appropriate for the
  264.       implemented model.  In all cases, implementations must not create
  265.       VCs in such a way that data cannot be sent to best-effort
  266.       receivers.  This includes the case of not being able to add a
  267.       best-effort receiver to a QoS VC,  but does not include the case
  268.       where best-effort VCs cannot be setup. The failure to establish
  269.       best-effort VCs is considered to be a general IP over ATM failure
  270.       and is therefore beyond the scope of this document.
  271.  
  272.       The key issue to be addressed by an implementation is providing
  273.       requested QoS downstream. One of or some combination of the
  274.       discussed models [5] may be used to provide requested QoS.
  275.       Unfortunately, none of the described models is the right answer
  276.       for all cases.  For some networks, e.g. public WANs, it is likely
  277.       that the limited heterogeneous model or a hybrid limited-full
  278.       heterogeneous model will be desired.  In other networks, e.g.
  279.       LANs, it is likely that a the modified homogeneous model will be
  280.       desired.
  281.  
  282.       Since there is not one model that satisfies all cases,
  283.       implementations must implement one of either the limited
  284.       heterogeneity model or the modified homogeneous model.
  285.       Implementations should support both approaches and provide the
  286.       ability to select which method is actually used, but are not
  287.  
  288.  
  289.  
  290. Berger                  Expires: September 1997                 [Page 5]
  291.  
  292.  
  293.  
  294.  
  295. Internet Draft  RSVP over ATM Implementation Guidelines       March 1996
  296.  
  297.  
  298.       required to do so.  Implementations may also support heterogeneity
  299.       through some other mechanism, e.g., using multiple appropriately
  300.       sized VCs.
  301.  
  302.    2.2 Multicast End-Point Identification
  303.  
  304.       Implementations must be able to identify ATM end-points
  305.       participating in an IP multicast group.  The ATM end-points will
  306.       be IP multicast receivers and/or next-hops.  Both QoS and best-
  307.       effort end-points must be identified.  RSVP next-hop information
  308.       will usually provide QoS end-points, but not best-effort end-
  309.       points.
  310.  
  311.       There is even a case where RSVP next-hop information will not
  312.       provide the appropriate end-point.  This occurs when the next-hop
  313.       is not RSVP capable, and RSVP is being automatically tunneled. In
  314.       this case a PATH message travels through a non-RSVP egress router
  315.       on the way to the next hop RSVP node.  When the next hop RSVP node
  316.       sends a RESV message it may arrive at the source over a different
  317.       route than what the data is using.  The source will get the RESV
  318.       message, but will not know which egress router needs the QoS.  For
  319.       unicast sessions, there is no problem since the ATM end-point will
  320.       be the IP next-hop router.  Unfortunately, multicast routing may
  321.       not be able to uniquely identify the IP next-hop router.  So it is
  322.       possible that a multicast end-point can not be identified.
  323.  
  324.       In the host case, MARS can be used to identify all end-points of a
  325.       multicast group.  In the router to router case, a multicast
  326.       routing protocol may provide all next-hops for a particular
  327.       multicast group.  In either case, RSVP over ATM implementations
  328.       must obtain a full list of end-points, both QoS and non-QoS, using
  329.       the appropriate mechanisms.  The full list can be compared against
  330.       the RSVP identified end-points to determine the list of best-
  331.       effort receivers.
  332.  
  333.       There is no straightforward solution to uniquely identifying end-
  334.       points of multicast traffic handled by non-RSVP next hops.  The
  335.       preferred solution is to use multicast routing protocols that
  336.       support unique end-point identification.  In cases where such
  337.       routing protocols are unavailable, all IP routers that will be
  338.       used to support RSVP over ATM should support RSVP. To ensure
  339.       proper behavior, baseline RSVP over ATM implementations must only
  340.       establish RSVP-initiated VCs to RSVP capable end-points.  It is
  341.       permissible to allow a user to override this behavior.
  342.  
  343.  
  344.  
  345.  
  346.  
  347.  
  348.  
  349. Berger                  Expires: September 1997                 [Page 6]
  350.  
  351.  
  352.  
  353.  
  354. Internet Draft  RSVP over ATM Implementation Guidelines       March 1996
  355.  
  356.  
  357.    2.3 Multicast Data Distribution
  358.  
  359.       Two models are planned for IP multicast data distribution over
  360.       ATM.  In one model, senders establish point-to-multipoint VCs to
  361.       all ATM attached destinations, and data is then sent over these
  362.       VCs.  This model is often called "multicast mesh" or "VC mesh"
  363.       mode distribution.  In the second model, senders send data over
  364.       point-to-point VCs to a central point and the central point relays
  365.       the data onto point-to-multipoint VCs that have been established
  366.       to all receivers of the IP multicast group.  This model is often
  367.       referred to as "multicast server" mode distribution. Figure  shows
  368.       data flow for both modes of IP multicast data distribution.  RSVP
  369.       over ATM solutions must ensure that IP multicast data is
  370.       distributed with appropriate QoS.
  371.  
  372.       [Figure goes here]
  373.               Figure 2: IP Multicast Data Distribution Over ATM
  374.  
  375.  
  376.  
  377.       Current multicast servers [1] do not support any mechanisms for
  378.       communicating QoS requirements to a multicast server.  For this
  379.       reason, RSVP over ATM implementations must support "mesh-mode"
  380.       distribution for RSVP controlled multicast flows. When using
  381.       multicast servers that do not support QoS requests, a sender must
  382.       set the service, not global, break bit(s).
  383.  
  384.       In the case of MARS[1], the selection of distribution modes is
  385.       administratively controlled.  Therefore network administrators
  386.       that desire proper RSVP over ATM operation must appropriately
  387.       configure their network to support mesh mode distribution for
  388.       multicast groups that will be used in RSVP sessions.
  389.  
  390.    2.4 Receiver Transitions
  391.  
  392.       When setting up a point-to-multipoint VCs there will be a time
  393.       when some receivers have been added to a QoS VC and some have not.
  394.       During such transition times it is possible to start sending data
  395.       on the newly established VC.  The issue is when to start send data
  396.       on the new VC.  If data is sent both on the new VC and the old VC,
  397.       then data will be delivered with proper QoS to some receivers and
  398.       with the old QoS to all receivers.  This means the QoS receivers
  399.       would get duplicate data.  If data is sent just on the new QoS VC,
  400.       the receivers that have not yet been added will lose information.
  401.       So, the issue comes down to whether to send to both the old and
  402.       new VCs, or to send to just one of the VCs.  In one case duplicate
  403.       information will be received, in the other some information may
  404.       not be received.  This issue needs to be considered for three
  405.  
  406.  
  407.  
  408. Berger                  Expires: September 1997                 [Page 7]
  409.  
  410.  
  411.  
  412.  
  413. Internet Draft  RSVP over ATM Implementation Guidelines       March 1996
  414.  
  415.  
  416.       cases: when establishing the first QoS VC, when establishing a VC
  417.       to support a QoS change, and when adding a new end-point to an
  418.       already established QoS VC.
  419.  
  420.       The first two cases are very similar.  It both, it is possible to
  421.       send data on the partially completed new VC, and the issue of
  422.       duplicate versus lost information is the same.
  423.  
  424.       The last case is when an end-point must be added to an existing
  425.       QoS VC.  In this case the end-point must be both added to the QoS
  426.       VC and dropped from a best-effort VC.  The issue is which to do
  427.       first.  If the add is first requested, then the end-point may get
  428.       duplicate information.  If the drop is requested first, then the
  429.       end-point may loose information.
  430.  
  431.       In order to ensure predictable behavior and delivery of data to
  432.       all receivers, data must not be sent on a new VCs until all
  433.       parties have been added.  This will ensure that all data is only
  434.       delivered once to all receivers.  This approach does not quite
  435.       apply for the last case. In the last case, the add must be
  436.       completed first, then the drop.  This last behavior requires
  437.       receivers to be prepared to receive some duplicate packets at
  438.       times of QoS setup.
  439.  
  440. 3. General RSVP Session Support
  441.  
  442.    This section provides implementation guidelines that are common for
  443.    all (both unicast and multicast) RSVP sessions.  The section covers
  444.    RSVP VC usage, QoS VC initiation, VC teardown, reservation to VC
  445.    Mapping, handling requested changes in QoS, short-cuts, and
  446.    encapsulation.
  447.  
  448.    3.1 RSVP Message VC Usage
  449.  
  450.       [5] covered the issues related to VC usage by RSVP messages.  It
  451.       discussed several options including: mixed control and data,
  452.       single control VC per session,  single control VC multiplexed
  453.       among sessions, and multiple VCs multiplexed among sessions.  QoS
  454.       for control VCs was also discussed.  Again that discussion is not
  455.       repeated, [5] should be reviewed for detailed information.
  456.  
  457.       Baseline RSVP over ATM implementations must send RSVP control
  458.       (messages) over the best effort data path, see figure .  It is
  459.       permissible to allow a user to override this behavior.  The stated
  460.       approach minimizes VC requirements since the best effort data path
  461.       will need to exist in order for RSVP sessions to be established
  462.       and in order for RSVP reservations to be initiated.  The specific
  463.       best effort paths that will be used by RSVP are: for unicast, the
  464.  
  465.  
  466.  
  467. Berger                  Expires: September 1997                 [Page 8]
  468.  
  469.  
  470.  
  471.  
  472. Internet Draft  RSVP over ATM Implementation Guidelines       March 1996
  473.  
  474.  
  475.       same VC used to reach the unicast destination; and for multicast,
  476.       the same VC that is used for best effort traffic destined to the
  477.       IP multicast group.  Note that for multicast there may be another
  478.       best effort VC that is used to carry session data traffic, i.e.,
  479.       for data that is both in the multicast group and matching a
  480.       sessions protocol and port.
  481.  
  482.       [Figure goes here]
  483.                    Figure 3: RSVP Control Message VC Usage
  484.  
  485.  
  486.  
  487.       The disadvantage of this approach is that best effort VCs may not
  488.       provide the reliability that RSVP needs.  However the best-effort
  489.       path is expected to satisfy RSVP reliability requirements in most
  490.       networks. Especially since RSVP allows for a certain amount of
  491.       packet loss without any loss of state synchronization.
  492.  
  493.    3.2 VC Initiation
  494.  
  495.       There is an apparent mismatch between RSVP and ATM. Specifically,
  496.       RSVP control is receiver oriented and ATM control is sender
  497.       oriented.  This initially may seem like a major issue, but really
  498.       is not.  While RSVP reservation (RESV) requests are generated at
  499.       the receiver, actual allocation of resources takes place at the
  500.       sub-net sender.
  501.  
  502.       For data flows, this means that sub-net senders must establish all
  503.       QoS VCs and the sub-net receiver must be able to accept incoming
  504.       QoS VCs.  These restrictions are consistent with RSVP version 1
  505.       processing rules and allow senders to use different flow to VC
  506.       mappings and even different QoS renegotiation techniques without
  507.       interoperability problems.  All RSVP over ATM approaches that have
  508.       VCs initiated and controlled by the sub-net senders will
  509.       interoperate.  Figure  shows this model of data flow VC
  510.       initiation.
  511.  
  512.       [Figure goes here]
  513.                       Figure 4: Data Flow VC Initiation
  514.  
  515.  
  516.  
  517.       Baseline RSVP over ATM implementations are prohibited from sending
  518.       data on a RSVP initiated QoS VC in the backwards direction.  There
  519.       are two reasons.  The first is that use of the backwards data path
  520.       requires the VC initiator to appropriate set backwards QoS
  521.       parameters.  The second is that backwards data paths are not
  522.       available with point-to-multipoint VCs, so backwards data paths
  523.  
  524.  
  525.  
  526. Berger                  Expires: September 1997                 [Page 9]
  527.  
  528.  
  529.  
  530.  
  531. Internet Draft  RSVP over ATM Implementation Guidelines       March 1996
  532.  
  533.  
  534.       could only be used to support unicast RSVP reservations.  Since
  535.       reverse path usage is a special case that cannot be used to
  536.       support multicast flows and such use for unicast requires some
  537.       undefined out of band communication, implementations must not send
  538.       data on QoS VCs in the backwards direction.
  539.  
  540.    3.3 VC Teardown
  541.  
  542.       Normally data VCs are torndown based on inactivity timers.  This
  543.       mechanism is used since IP is connectionless and there is
  544.       therefore no way to know when a VC is no longer needed.  Since
  545.       RSVP provides explicit mechanisms (messages and timeouts) to
  546.       determine when an associated data VC is no longer needed, the
  547.       traditional VC timeout mechanisms is not needed.  Data VCs set up
  548.       to support RSVP controlled flows should only be released at the
  549.       direction of RSVP. Such VCs must not be timed out due to
  550.       inactivity by either the VC initiator or the VC receiver.  This
  551.       conflicts with VCs timing out as described in RFC 1755[12],
  552.       section 3.4 on VC Teardown.  RFC 1755 recommends tearing down a VC
  553.       that is inactive for a certain length of time. Twenty minutes is
  554.       recommended.  This timeout is typically implemented at both the VC
  555.       initiator and the VC receiver.  Although, section 3.1 of the
  556.       update to RFC 1755[13] states that inactivity timers must not be
  557.       used at the VC receiver.
  558.  
  559.       In RSVP over ATM implementations, the configurable inactivity
  560.       timer mentioned in [12] must be set to "infinite" for VCs
  561.       initiated at the request of RSVP.  Setting the inactivity timer
  562.       value at the VC initiator should not be problematic since the
  563.       proper value can be relayed internally at the originator.  Setting
  564.       the inactivity timer at the VC receiver is more difficult, and
  565.       would require some mechanism to signal that an incoming VC was
  566.       RSVP initiated.  To avoid this complexity and to conform to [13],
  567.       RSVP over ATM implementations must not use an inactivity timer to
  568.       clear any received connection.
  569.  
  570.    3.4 Reservation to VC Mapping
  571.  
  572.       As discussed in [5], data associated with multiple RSVP sessions
  573.       could be sent using the same shared VCs. Implementation of such
  574.       "aggregation" models is still a matter for research.  Therefore,
  575.       baseline RSVP over ATM implementations must use independent VCs
  576.       for each RSVP session. Implementations may also support
  577.       aggregation approaches.  Use of such approaches must be at the
  578.       discretion of the user.
  579.  
  580.  
  581.  
  582.  
  583.  
  584.  
  585. Berger                  Expires: September 1997                [Page 10]
  586.  
  587.  
  588.  
  589.  
  590. Internet Draft  RSVP over ATM Implementation Guidelines       March 1996
  591.  
  592.  
  593.    3.5 Dynamic QoS
  594.  
  595.       As stated in [5], there is a mismatch in the service provided by
  596.       RSVP and that provided by ATM UNI3.x and 4.0.  RSVP allows
  597.       modifications to QoS parameters at any time, while ATM does not
  598.       support any modifications to QoS parameters after VC setup.  See
  599.       [5] for more detail.
  600.  
  601.       The baseline method for supporting changes in RSVP reservations is
  602.       to attempt to replace an existing VC with a new appropriately
  603.       sized VC. During setup of the replacement VC, the old VC must be
  604.       left in place unmodified. The old VC is left unmodified to
  605.       minimize interruption of QoS data delivery.  Once the replacement
  606.       VC is established, data transmission is shifted to the new VC, and
  607.       only then is the old VC closed.
  608.  
  609.       If setup of the replacement VC fails, then the old QoS VC should
  610.       continue to be used. When the new reservation is greater than the
  611.       old reservation, the reservation request should be answered with
  612.       an error. When the new reservation is less than the old
  613.       reservation, the request should be treated as if the modification
  614.       was successful. While leaving the larger allocation in place is
  615.       suboptimal, it maximizes delivery of service to the user.
  616.       Implementations should retry replacing the too large VC after some
  617.       appropriate elapsed time.
  618.  
  619.       One additional issue is that only one QoS change can be processed
  620.       at one time per reservation. If the (RSVP) requested QoS is
  621.       changed while the first replacement VC is still being setup, then
  622.       the replacement VC is released and the whole VC replacement
  623.       process is restarted.  Implementations may also limit number of
  624.       changes processed in a time period per [5].
  625.  
  626.       There is an interesting interaction between heterogeneous
  627.       reservations and dynamic QoS.  In the case where a RESV message is
  628.       received from a new next-hop and the requested resources are
  629.       larger than any existing reservation, both dynamic QoS and
  630.       heterogeneity need to be addressed.  A key issue is whether to
  631.       first add the new next-hop or to change to the new QoS.  This is a
  632.       fairly straight forward special case.  Since the older, smaller
  633.       reservation does not support the new next-hop, the dynamic QoS
  634.       process should be initiated first. Since the new QoS is only
  635.       needed by the new next-hop, it should be the first end-point of
  636.       the new VC.  This way signalling is minimized when the setup to
  637.       the new next-hop fails.
  638.  
  639.  
  640.  
  641.  
  642.  
  643.  
  644. Berger                  Expires: September 1997                [Page 11]
  645.  
  646.  
  647.  
  648.  
  649. Internet Draft  RSVP over ATM Implementation Guidelines       March 1996
  650.  
  651.  
  652.    3.6 Short-Cuts
  653.  
  654.       Short-cuts [10] allow ATM attached routers and hosts to directly
  655.       establish point-to-point VCs across LIS boundaries, i.e., the VC
  656.       end-points are on different IP sub-nets.  The ability for short-
  657.       cuts and RSVP to interoperate has been raised as a general
  658.       question.  The area of concern is the ability to handle asymmetric
  659.       short-cuts.  Specifically how RSVP can handle the case where a
  660.       downstream short-cut may not have a matching upstream short-cut.
  661.       In this case, which is shown in figure , PATH and RESV messages
  662.       following different paths.
  663.  
  664.       [Figure goes here]
  665.        Figure 5: Asymmetric RSVP Message Forwarding With ATM Short-Cuts
  666.  
  667.  
  668.  
  669.       Examination of RSVP shows that the protocol already includes
  670.       mechanisms that will support short-cuts.  The mechanism is the
  671.       same one used to support RESV messages arriving at the wrong
  672.       router and the wrong interface.  The key aspect of this mechanism
  673.       is RSVP only processing messages that arrive at the proper
  674.       interface and RSVP forwarding of messages that arrive on the wrong
  675.       interface.  The proper interface is indicated in the NHOP object
  676.       of the message.  So, existing RSVP mechanisms will support
  677.       asymmetric short-cuts.
  678.  
  679.       The short-cut model of VC establishment still poses several issues
  680.       when running with RSVP. The major issues are dealing with
  681.       established best-effort short-cuts, when to establish short-cuts,
  682.       and QoS only short-cuts. These issues will need to be addressed by
  683.       RSVP implementations.
  684.  
  685.       The key issue to be addressed by any RSVP over ATM solution is
  686.       when to establish a short-cut for a QoS data flow.  Baseline RSVP
  687.       over ATM implementations should simply follow best-effort traffic.
  688.       When a short-cut has been established for best-effort traffic to a
  689.       destination or next-hop, that same end-point should be used when
  690.       setting up RSVP triggered VCs for QoS traffic to the same
  691.       destination or next-hop. This will happen naturally when PATH
  692.       messages are forwarded over the best-effort short-cut.  Note that
  693.       in this approach when best-effort short-cuts are never
  694.       established, RSVP triggered QoS short-cuts will also never be
  695.       established.
  696.  
  697.  
  698.  
  699.  
  700.  
  701.  
  702.  
  703. Berger                  Expires: September 1997                [Page 12]
  704.  
  705.  
  706.  
  707.  
  708. Internet Draft  RSVP over ATM Implementation Guidelines       March 1996
  709.  
  710.  
  711.    3.7 Encapsulation
  712.  
  713.       Since RSVP is a signalling protocol used to control flows of IP
  714.       data packets, encapsulation for both RSVP packets and associated
  715.       IP data packets must be defined. There are multiple encapsulation
  716.       options for running IP over ATM, for example RFC 1483[9] and
  717.       LANE[2].  There is also other encapsulation options, such as
  718.       MPOA[3].
  719.  
  720.       Baseline RSVP over ATM  implementations must use a consistent
  721.       encapsulation scheme for all IP over ATM packets.  This includes
  722.       RSVP packets and associated IP data packets.  So, encapsulation
  723.       used on QoS data VCs and related control VCs must be the same as
  724.       used by best-effort VCs.
  725.  
  726. 4. Security
  727.  
  728.    The same considerations stated in [8] and [12] apply to this
  729.    document.  There are no additional security issues raised in this
  730.    document.
  731.  
  732. 5. Implementation Summary
  733.  
  734.    This section provides a summary of previously stated requirements.
  735.  
  736.    5.1 Requirements
  737.  
  738.       All RSVP over ATM UNI 3.0 and 4.0 implementations must conform to
  739.       the following:
  740.  
  741.  
  742.       o    Heterogeneity
  743.            Implementations must not, in the normal case, send more than
  744.            one copy of a particular data packet to a particular next-hop
  745.            (ATM end-point).
  746.            Implementations must ensure that data traffic is sent to
  747.            best-effort receivers.
  748.  
  749.       o    Multicast Data Distribution
  750.            When using multicast servers that do not support QoS
  751.            requests, a sender must set the service, not global, break
  752.            bit(s).
  753.  
  754.       o    Receiver Transitions
  755.            While creating new VCs, senders must either send on only the
  756.            old VC or on both the old and the new VCs.
  757.  
  758.       o    VC Initiation
  759.  
  760.  
  761.  
  762. Berger                  Expires: September 1997                [Page 13]
  763.  
  764.  
  765.  
  766.  
  767. Internet Draft  RSVP over ATM Implementation Guidelines       March 1996
  768.  
  769.  
  770.            All RSVP triggered QoS VCs must be established by the sub-net
  771.            senders.
  772.            VC receivers must be able to accept incoming QoS VCs.
  773.  
  774.       o    VC Teardown
  775.            VC initiators must not tear down RSVP initiated VCs due to
  776.            inactivity.
  777.            VC receivers must not tear down any incoming VCs due to
  778.            inactivity.
  779.  
  780.    5.2 Baseline Requirements
  781.  
  782.       Baseline requirements define a minimum set of functionality that
  783.       must be provided by implementations.  Implementations may also
  784.       provide additional functionality that may be configured to
  785.       override the baseline behavior.  Which behavior is selected is a
  786.       policy issue for network providers.  We expect some networks to
  787.       only make use of baseline functionality and others to only make
  788.       use of additional functionality.
  789.  
  790.  
  791.       o    Heterogeneity
  792.            Either limited heterogeneity model or the modified
  793.            homogeneous model must be supported for handling
  794.            heterogeneity.
  795.            Implementations should support both approaches and provide
  796.            the ability to select which method is actually used, but are
  797.            not required to do so.
  798.  
  799.       o    Multicast End-Point Identification
  800.            Implementations must only establish RSVP-initiated VCs to
  801.            RSVP capable end-points.
  802.  
  803.       o    Multicast Data Distribution
  804.            Implementations must support "mesh-mode" distribution for
  805.            RSVP controlled multicast flows.   In the case of MARS,
  806.            distribution mode is administratively controlled.  So this
  807.            requirement can only be implemented by network
  808.            administrators.
  809.  
  810.       o    RSVP Control VC Management
  811.            Implementations must send RSVP control (messages) over the
  812.            best effort data path.
  813.  
  814.       o    Reservation to VC Mapping
  815.            Implementations must use a single VC to support each RSVP
  816.            reservation.
  817.  
  818.  
  819.  
  820.  
  821. Berger                  Expires: September 1997                [Page 14]
  822.  
  823.  
  824.  
  825.  
  826. Internet Draft  RSVP over ATM Implementation Guidelines       March 1996
  827.  
  828.  
  829.       o    Dynamic QoS
  830.            Implementations must support RSVP requested changes in
  831.            reservations by attempting to replace an existing VC with a
  832.            new appropriately sized VC. During setup of the replacement
  833.            VC, the old VC must be left in place unmodified.
  834.  
  835.       o    Short-Cuts
  836.            Implementations should establish QoS short-cut whenever a
  837.            best-effort short-cut is in use to a particular  destination
  838.            or next-hop.  This means that when best-effort short-cuts are
  839.            never established, RSVP triggered short-cuts also should not
  840.            be established.
  841.  
  842.       o    Encapsulation
  843.            Implementations must encapsulate data sent on QoS VCs with
  844.            the same encapsulation as is used on best-effort VCs.
  845.  
  846.  
  847. 6. Author's Address
  848.  
  849.       Lou Berger
  850.       FORE Systems
  851.       6905 Rockledge Drive
  852.       Suite 800
  853.       Bethesda, MD 20817
  854.  
  855.       Phone: +1 301 571 2534
  856.       EMail: lberger@fore.com
  857.  
  858. REFERENCES
  859.  
  860. [1] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM
  861.     Networks," Internet Draft, February 1996.
  862.  
  863. [2] The ATM Forum, "LAN Emulation Over ATM Specification", Version 1.0.
  864.  
  865. [3] The ATM Forum, "MPOA Baseline Version 1", 95-0824r9, September 1996.
  866.  
  867. [4] Berson, S., "`Classical' RSVP and IP over ATM," INET '96, July 1996.
  868.  
  869. [5] Berson, S., Berger, L., "IP Integrated Services with RSVP over ATM,"
  870.     Internet Draft, March 1997.
  871.  
  872. [6] Borden, M., Crawley, E., Krawczyk, J, Baker, F., and Berson, S.,
  873.     "Issues for RSVP and Integrated Services over ATM," Internet Draft,
  874.     February 1996.
  875.  
  876. [7] Borden, M., and Garrett, M., "Interoperation of Controlled-Load and
  877.  
  878.  
  879.  
  880. Berger                  Expires: September 1997                [Page 15]
  881.  
  882.  
  883.  
  884.  
  885. Internet Draft  RSVP over ATM Implementation Guidelines       March 1996
  886.  
  887.  
  888.     Guaranteed-Service with ATM," Internet Draft, June 1996.
  889.  
  890. [8] Braden, R., Zhang, L., Berson, S., Herzog, S., and Jamin, S.,
  891.     "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
  892.     Specification," Internet Draft, November 1996.
  893.  
  894. [9] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation Layer
  895.     5," RFC 1483.
  896.  
  897. [10] Luciani, J., Katz, D., Piscitello, D., Cole, B., "NBMA Next Hop
  898.     Resolution Protocol (NHRP)," Internet Draft, June 1996.
  899.  
  900. [11] Onvural, R., Srinivasan, V., "A Framework for Supporting RSVP Flows
  901.     Over ATM Networks," Internet Draft, March 1996.
  902.  
  903. [12] Perez, M., Liaw, F., Grossman, D., Mankin, A., Hoffman, E., and
  904.     Malis, A., "ATM Signalling Support for IP over ATM," RFC 1755.
  905.  
  906. [13] Perez, M., Mankin, A.  "ATM Signalling Support for IP over ATM -
  907.     UNI 4.0 Update" Internet Draft, November 1996.
  908.  
  909.  
  910.  
  911.  
  912.  
  913.  
  914.  
  915.  
  916.  
  917.  
  918.  
  919.  
  920.  
  921.  
  922.  
  923.  
  924.  
  925.  
  926.  
  927.  
  928.  
  929.  
  930.  
  931.  
  932.  
  933.  
  934.  
  935.  
  936.  
  937.  
  938.  
  939. Berger                  Expires: September 1997                [Page 16]
  940.  
  941.  
  942.