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-req-00.txt < prev    next >
Text File  |  1997-07-15  |  30KB  |  763 lines
  1.  
  2. Internet Draft                                                 L. Berger
  3. Expires: January 1998                                       FORE Systems
  4. File: draft-ietf-issll-atm-imp-req-00.txt
  5.  
  6.  
  7.  
  8.                RSVP over ATM Implementation Requirements
  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 requirements for running
  35.    RSVP over ATM switched virtual circuits (SVCs).  It presents
  36.    requirements that ensure interoperability between multiple
  37.    implementations and conformance to the RSVP and Integrated Services
  38.    specifications.  A separate document [6] provides specific guidelines
  39.    for running over today's ATM networks.  The general problem is
  40.    discussed in [11].   Integrated Services to ATM service mappings are
  41.    covered in [9].  The full set of documents present the background and
  42.    information needed to implement Integrated Services and RSVP over
  43.    ATM.
  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 Requirements              July 1997
  59.  
  60.  
  61. Table of Contents
  62.  
  63. 1. Introduction ........................................................3
  64.    1.1 Terms ...........................................................3
  65.    1.2 Assumptions .....................................................4
  66. 2. General RSVP Session Support ........................................4
  67.    2.1 VC Usage ........................................................4
  68.    2.2 VC Initiation ...................................................5
  69.    2.3 VC Teardown .....................................................5
  70.    2.4 Dynamic QoS .....................................................6
  71.    2.5 Encapsulation ...................................................7
  72. 3. Multicast RSVP Session Support ......................................7
  73.    3.1 Data VC Management for Heterogeneous Sessions ...................7
  74.    3.2 Multicast End-Point Identification ..............................9
  75.    3.3 Multicast Data Distribution .....................................10
  76.    3.4 Receiver Transitions ............................................11
  77. 4. Security ............................................................12
  78. 5. Acknowledgments .....................................................12
  79. 6. Author's Address ....................................................12
  80.  
  81.  
  82.  
  83.  
  84.  
  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. Berger                   Expires: January 1998                  [Page 2]
  113.  
  114.  
  115.  
  116.  
  117. Internet Draft         RSVP over ATM Requirements              July 1997
  118.  
  119.  
  120. 1. Introduction
  121.  
  122.    This note discusses running IP over ATM in an environment where SVCs
  123.    are used to support QoS flows and RSVP is used as the internet level
  124.    QoS signaling protocol.  It applies when using CLIP/ION, LANE2.0 and
  125.    MPOA[4] methods for supporting IP over ATM.  The general issues
  126.    related to running RSVP[10] over ATM have been covered in several
  127.    papers including [11,7,5,8].  This document is intended as a
  128.    companion to [11,6].  The reader should be familiar with both
  129.    documents.
  130.  
  131.    This document will define specific requirements for implementations
  132.    using ATM UNI3.x and 4.0.  These requirements must be adhered to by
  133.    all RSVP over ATM implementations to ensure interoperability.
  134.    Further recommendations to guide implementers of RSVP over ATM are
  135.    provided in [6].
  136.  
  137.    The rest of this section will define terms and assumptions. Section 2
  138.    will cover implementation guidelines common to all RSVP session.
  139.    Section 3 will cover implementation guidelines specific to multicast
  140.    sessions.
  141.  
  142.    1.1 Terms
  143.  
  144.       The terms "reservation" and "flow" are used in many contexts,
  145.       often with different meaning.  These terms are used in this
  146.       document with the following meaning:
  147.  
  148.  
  149.       o    Reservation is used in this document to refer to an RSVP
  150.            initiated request for resources.  RSVP initiates requests for
  151.            resources based on RESV message processing.  RESV messages
  152.            that simply refresh state do not trigger resource requests.
  153.            Resource requests may be made based on RSVP sessions and RSVP
  154.            reservation styles. RSVP styles dictate whether the reserved
  155.            resources are used by one sender or shared by multiple
  156.            senders.  See [10] for details of each. Each new request is
  157.            referred to in this document as an RSVP reservation, or
  158.            simply reservation.
  159.  
  160.       o    Flow is used to refer to the data traffic associated with a
  161.            particular reservation.  The specific meaning of flow is RSVP
  162.            style dependent.  For shared style reservations, there is one
  163.            flow per session.  For distinct style reservations, there is
  164.            one flow per sender (per session).
  165.  
  166.  
  167.  
  168.  
  169.  
  170.  
  171. Berger                   Expires: January 1998                  [Page 3]
  172.  
  173.  
  174.  
  175.  
  176. Internet Draft         RSVP over ATM Requirements              July 1997
  177.  
  178.  
  179.    1.2 Assumptions
  180.  
  181.       The following assumptions are made:
  182.  
  183.  
  184.       o    RSVP We assume RSVP as the internet signalling protocol which
  185.            is described in [10].  The reader is assumed to be familiar
  186.            with [10].
  187.  
  188.       o    IPv4 and IPv6 RSVP support has been defined for both IPv4 and
  189.            IPv6.  The guidelines in this document are intended to be
  190.            used to support RSVP with either IPv4 or IPv6.  This document
  191.            does not require one version over the other.
  192.  
  193.       o    Best effort service model The current Internet only supports
  194.            best effort service.  We assume that as additional components
  195.            of the Integrated Services model that best effort service
  196.            will continue to be a supported.
  197.  
  198.       o    ATM UNI 3.x and 4.0 We assume ATM service as defined by UNI
  199.            3.x and 4.0.  ATM provides both point-to-point and point-to-
  200.            multipoint Virtual Circuits (VCs) with a specified Quality of
  201.            Service (QoS).  ATM provides both Permanent Virtual Circuits
  202.            (PVCs) and Switched Virtual Circuits (SVCs).  In the
  203.            Permanent Virtual Circuit (PVC) environment, PVCs are
  204.            typically used as point-to-point link replacements.  So the
  205.            support issues are similar to point-to-point links.  This
  206.            draft assumes that SVCs are used to support RSVP over ATM.
  207.  
  208. 2. General RSVP Session Support
  209.  
  210.    This section provides implementation requirements that are common for
  211.    all (both unicast and multicast) RSVP sessions.  The section covers
  212.    VC usage, QoS VC initiation, VC teardown, handling requested changes
  213.    in QoS, and encapsulation.
  214.  
  215.    2.1 VC Usage
  216.  
  217.       There are several options open to implementations on which VC to
  218.       use for RSVP messages and how to aggregate RSVP sessions over QoS
  219.       VCs.  These options have been covered in [11] and some specific
  220.       implementation guidelines are stated in [6].  In order to ensure
  221.       interoperability between implementations that follow different
  222.       options, RSVP over ATM implementations MUST be able to receive
  223.       RSVP (control) messages on both QoS and best-effort VCs, and MUST
  224.       be able to receive multiple RSVP sessions per QoS VC.
  225.  
  226.  
  227.  
  228.  
  229.  
  230. Berger                   Expires: January 1998                  [Page 4]
  231.  
  232.  
  233.  
  234.  
  235. Internet Draft         RSVP over ATM Requirements              July 1997
  236.  
  237.  
  238.    2.2 VC Initiation
  239.  
  240.       There is an apparent mismatch between RSVP and ATM. Specifically,
  241.       RSVP control is receiver oriented and ATM control is sender
  242.       oriented.  This initially may seem like a major issue but really
  243.       is not.  While RSVP reservation (RESV) requests are generated at
  244.       the receiver, actual allocation of resources takes place at the
  245.       sub-net sender.
  246.  
  247.       For data flows, this means that sub-net senders MUST establish all
  248.       QoS VCs and the RSVP enabled sub-net receiver MUST be able to
  249.       accept incoming QoS VCs.  These restrictions are consistent with
  250.       RSVP version 1 processing rules and allow senders to use different
  251.       flow to VC mappings and even different QoS renegotiation
  252.       techniques without interoperability problems.  All RSVP over ATM
  253.       approaches that have VCs initiated and controlled by the sub-net
  254.       senders will interoperate.  Figure 1 shows this model of data flow
  255.       VC initiation.
  256.  
  257.                                Data Flow ==========>
  258.  
  259.                        +-----+
  260.                        |     |      -------------->  +----+
  261.                        | Src |    -------------->    | R1 |
  262.                        |    *|  -------------->      +----+
  263.                        +-----+       QoS VCs
  264.                             /\
  265.                             ||
  266.                         VC  ||
  267.                         Initiator
  268.  
  269.                       Figure 1: Data Flow VC Initiation
  270.  
  271.  
  272.       RSVP over ATM implementations MAY send data in the backwards
  273.       direction on a RSVP initiated QoS point-to-point VC.  When sending
  274.       in the backwards data path, the sender MUST ensure that the data
  275.       conforms to the backwards direction traffic parameters.  Since the
  276.       traffic parameters are set by the VC initiator, it is quite likely
  277.       that no resources will be requested for traffic originating at the
  278.       called party.  Of course, the backwards data path is not available
  279.       with point-to-multipoint VCs.
  280.  
  281.    2.3 VC Teardown
  282.  
  283.       VCs supporting IP over ATM data are typically torndown based on
  284.       inactivity timers.  This mechanism is used since IP is
  285.       connectionless and there is therefore no way to know when a VC is
  286.  
  287.  
  288.  
  289. Berger                   Expires: January 1998                  [Page 5]
  290.  
  291.  
  292.  
  293.  
  294. Internet Draft         RSVP over ATM Requirements              July 1997
  295.  
  296.  
  297.       no longer needed.  Since RSVP provides explicit mechanisms
  298.       (messages and timeouts) to determine when an associated data VC is
  299.       no longer needed, the traditional VC timeout mechanisms is not
  300.       needed.  Data VCs set up to support RSVP controlled flows should
  301.       only be released at the direction of RSVP. Such VCs must not be
  302.       timed out due to inactivity by either the VC initiator or the VC
  303.       receiver.  This conflicts with VCs timing out as described in RFC
  304.       1755[14], section 3.4 on VC Teardown.  RFC 1755 recommends tearing
  305.       down a VC that is inactive for a certain length of time. Twenty
  306.       minutes is recommended.  This timeout is typically implemented at
  307.       both the VC initiator and the VC receiver.  Although, section 3.1
  308.       of the update to RFC 1755[15] states that inactivity timers must
  309.       not be used at the VC receiver.
  310.  
  311.       In RSVP over ATM implementations, the configurable inactivity
  312.       timer mentioned in [14] MUST be set to "infinite" for VCs
  313.       initiated at the request of RSVP.  Setting the inactivity timer
  314.       value at the VC initiator should not be problematic since the
  315.       proper value can be relayed internally at the originator.  Setting
  316.       the inactivity timer at the VC receiver is more difficult, and
  317.       would require some mechanism to signal that an incoming VC was
  318.       RSVP initiated.  To avoid this complexity and to conform to [15],
  319.       RSVP over ATM implementations MUST not use an inactivity timer to
  320.       clear any received connection.
  321.  
  322.    2.4 Dynamic QoS
  323.  
  324.       As stated in [11], there is a mismatch in the service provided by
  325.       RSVP and that provided by ATM UNI3.x and 4.0.  RSVP allows
  326.       modifications to QoS parameters at any time, while ATM does not
  327.       support any modifications to QoS parameters after VC setup.  See
  328.       [11] for more detail.
  329.  
  330.       The method for supporting changes in RSVP reservations is to
  331.       attempt to replace an existing VC with a new appropriately sized
  332.       VC. During setup of the replacement VC, the old VC MUST be left in
  333.       place unmodified. The old VC is left unmodified to minimize
  334.       interruption of QoS data delivery.  Once the replacement VC is
  335.       established, data transmission is shifted to the new VC, and only
  336.       then is the old VC closed.
  337.  
  338.       If setup of the replacement VC fails, then the old QoS VC MUST
  339.       continue to be used.  When the new reservation is greater than the
  340.       old reservation, the reservation request MUST be answered with an
  341.       error. When the new reservation is less than the old reservation,
  342.       the request MUST be treated as if the modification was successful.
  343.       While leaving the larger allocation in place is suboptimal, it
  344.       maximizes delivery of service to the user.  The behavior is also
  345.  
  346.  
  347.  
  348. Berger                   Expires: January 1998                  [Page 6]
  349.  
  350.  
  351.  
  352.  
  353. Internet Draft         RSVP over ATM Requirements              July 1997
  354.  
  355.  
  356.       required in order to conform to RSVP error handling as defined in
  357.       sections 2.5, 3.1.8 and 3.11.2 of [10].  Implementations SHOULD
  358.       retry replacing the too large VC after some appropriate elapsed
  359.       time.
  360.  
  361.       One additional issue is that only one QoS change can be processed
  362.       at one time per reservation. If the (RSVP) requested QoS is
  363.       changed while the first replacement VC is still being setup, then
  364.       the replacement VC is released and the whole VC replacement
  365.       process is restarted.  Implementations MAY also limit number of
  366.       changes processed in a time period per [11].
  367.  
  368.    2.5 Encapsulation
  369.  
  370.       There are multiple encapsulation options for data sent over RSVP
  371.       triggered QoS VCs.  All RSVP over ATM implementations MUST be able
  372.       to support LLC encapsulation per RFC 1483[12] on such QoS VCs.
  373.       Implementations MAY negotiate alternative encapsulations using the
  374.       B-LLI negotiation procedures defined in ATM Signalling, see [14]
  375.       for details.  When a QoS VC is only being used to carry IP
  376.       packets, implementations SHOULD negotiate VC based multiplexing to
  377.       avoid incurring the overhead of the LLC header.
  378.  
  379. 3. Multicast RSVP Session Support
  380.  
  381.    There are several aspects to running RSVP over ATM that are
  382.    particular to multicast sessions.  These issues result from the
  383.    nature of ATM point-to-multipoint connections.  This section
  384.    addresses multicast end-point identification, multicast data
  385.    distribution, multicast receiver transitions and next-hops requesting
  386.    different QoS values (heterogeneity) which includes the handling of
  387.    multicast best-effort receivers.  Handling of best-effort receivers
  388.    is not strictly an RSVP issues, but needs to be addressed in any RSVP
  389.    over ATM implementation in order to maintain expected Internet
  390.    service.
  391.  
  392.    3.1 Data VC Management for Heterogeneous Sessions
  393.  
  394.       The issues relating to data VC management of heterogeneous
  395.       sessions are covered in detail in [11] and not repeated.  In
  396.       summary, heterogeneity occurs when receivers request different
  397.       levels of QoS within a single session, and also when some
  398.       receivers do not request any QoS.  Both types of heterogeneity are
  399.       shown in figure 2.
  400.  
  401.  
  402.  
  403.  
  404.  
  405.  
  406.  
  407. Berger                   Expires: January 1998                  [Page 7]
  408.  
  409.  
  410.  
  411.  
  412. Internet Draft         RSVP over ATM Requirements              July 1997
  413.  
  414.  
  415.                                     +----+
  416.                            +------> | R1 |
  417.                            |        +----+
  418.                            |
  419.                            |        +----+
  420.               +-----+ -----+   +--> | R2 |
  421.               |     | ---------+    +----+        Receiver Request Types:
  422.               | Src |                             ---->  QoS 1 and QoS 2
  423.               |     | .........+    +----+        ....>  Best-Effort
  424.               +-----+ .....+   +..> | R3 |
  425.                            :        +----+
  426.                        /\  :
  427.                        ||  :        +----+
  428.                        ||  +......> | R4 |
  429.                        ||           +----+
  430.                      Single
  431.                   IP Mulicast
  432.                      Group
  433.  
  434.                     Figure 2: Types of Multicast Receivers
  435.  
  436.  
  437.       [11] provides four models for dealing with heterogeneity: full
  438.       heterogeneity, limited heterogeneity, homogeneous, and modified
  439.       homogeneous models.  No matter which model or combination of
  440.       models is used by an implementation, implementations MUST NOT
  441.       normally send more than one copy of a particular data packet to a
  442.       particular next-hop (ATM end-point).  Some transient over
  443.       transmission is acceptable, but only during VC setup and
  444.       transition.
  445.  
  446.       Implementations MUST also ensure that data traffic is sent to
  447.       best-effort receivers.  Data traffic MAY be sent to best-effort
  448.       receivers via best-effort or QoS VCs as is appropriate for the
  449.       implemented model.  In all cases, implementations MUST NOT create
  450.       VCs in such a way that data cannot be sent to best-effort
  451.       receivers.  This includes the case of not being able to add a
  452.       best-effort receiver to a QoS VC,  but does not include the case
  453.       where best-effort VCs cannot be setup. The failure to establish
  454.       best-effort VCs is considered to be a general IP over ATM failure
  455.       and is therefore beyond the scope of this document.
  456.  
  457.       There is an interesting interaction between dynamic QoS and
  458.       heterogeneous requests when using the limited heterogeneity,
  459.       homogeneous, or modified homogeneous models.  In the case where a
  460.       RESV message is received from a new next-hop and the requested
  461.       resources are larger than any existing reservation, both dynamic
  462.       QoS and heterogeneity need to be addressed.  A key issue is
  463.  
  464.  
  465.  
  466. Berger                   Expires: January 1998                  [Page 8]
  467.  
  468.  
  469.  
  470.  
  471. Internet Draft         RSVP over ATM Requirements              July 1997
  472.  
  473.  
  474.       whether to first add the new next-hop or to change to the new QoS.
  475.       This is a fairly straight forward special case.  Since the older,
  476.       smaller reservation does not support the new next-hop, the dynamic
  477.       QoS process SHOULD be initiated first. Since the new QoS is only
  478.       needed by the new next-hop, it SHOULD be the first end-point of
  479.       the new VC.  This way signalling is minimized when the setup to
  480.       the new next-hop fails.
  481.  
  482.    3.2 Multicast End-Point Identification
  483.  
  484.       Implementations must be able to identify ATM end-points
  485.       participating in an IP multicast group.  The ATM end-points will
  486.       be IP multicast receivers and/or next-hops.  Both QoS and best-
  487.       effort end-points must be identified.  RSVP next-hop information
  488.       will usually provide QoS end-points, but not best-effort end-
  489.       points.
  490.  
  491.       There is a special case where RSVP next-hop information will not
  492.       provide the appropriate end-point.  This occurs when the next-hop
  493.       is not RSVP capable, and RSVP is being automatically tunneled. In
  494.       this case a PATH message travels through a non-RSVP egress router
  495.       on the way to the next hop RSVP node.  When the next hop RSVP node
  496.       sends a RESV message it may arrive at the source over a different
  497.       route than what the data is using.  The source will get the RESV
  498.       message, but will not know which egress router needs the QoS.  For
  499.       unicast sessions, there is no problem since the ATM end-point will
  500.       be the IP next-hop router.  Unfortunately, multicast routing may
  501.       not be able to uniquely identify the IP next-hop router.  It is
  502.       therefore possible that a multicast end-point can not be properly
  503.       identified.
  504.  
  505.       In the host case, some multicast over ATM control mechanisms, such
  506.       as MARS, can be used to identify all end-points of a multicast
  507.       group.  In the router to router case, a multicast routing protocol
  508.       may provide all next-hops for a particular multicast group.  In
  509.       either case, RSVP over ATM implementations must obtain a full list
  510.       of end-points, both QoS and non-QoS, using the appropriate
  511.       mechanisms.  The full list can be compared against the RSVP
  512.       identified end-points to determine the list of best-effort
  513.       receivers.
  514.  
  515.       There is no straightforward solution to uniquely identifying end-
  516.       points of multicast traffic handled by non-RSVP next hops.  The
  517.       preferred solution is to use multicast routing protocols that
  518.       support unique end-point identification.  In cases where such
  519.       routing protocols are unavailable, all IP routers that will be
  520.       used to support RSVP over ATM should support RSVP. To ensure
  521.       proper behavior, baseline RSVP over ATM implementations MUST only
  522.  
  523.  
  524.  
  525. Berger                   Expires: January 1998                  [Page 9]
  526.  
  527.  
  528.  
  529.  
  530. Internet Draft         RSVP over ATM Requirements              July 1997
  531.  
  532.  
  533.       establish RSVP-initiated VCs to RSVP capable end-points.  It is
  534.       permissible to allow a user to override this behavior.
  535.  
  536.    3.3 Multicast Data Distribution
  537.  
  538.       Two models are planned for IP multicast data distribution over
  539.       ATM.  In one model, senders establish point-to-multipoint VCs to
  540.       all ATM attached destinations, and data is then sent over these
  541.       VCs.  This model is often called "multicast mesh" or "VC mesh"
  542.       mode distribution.  In the second model, senders send data over
  543.       point-to-point VCs to a central point and the central point relays
  544.       the data onto point-to-multipoint VCs that have been established
  545.       to all receivers of the IP multicast group.  This model is often
  546.       referred to as "multicast server" mode distribution. Figure 3
  547.       shows data flow for both modes of IP multicast data distribution.
  548.       The goal of RSVP over ATM solutions is to ensure that IP multicast
  549.       data is distributed with appropriate QoS.
  550.  
  551.                              _________
  552.                             /         \
  553.                            / Multicast \
  554.                            \   Server  /
  555.                             \_________/
  556.                               ^  |  |
  557.                               |  |  +--------+
  558.                +-----+        |  |           |
  559.                |     | -------+  |           |         Data Flow:
  560.                | Src | ...+......|....+      V         ---->  Server
  561.                |     |    :      |    :    +----+      ....>  Mesh
  562.                +-----+    :      |    +...>| R1 |
  563.                           :      |         +----+
  564.                           :      V
  565.                           :    +----+
  566.                           +..> | R2 |
  567.                                +----+
  568.  
  569.               Figure 3: IP Multicast Data Distribution Over ATM
  570.  
  571.  
  572.       Current multicast servers [1,2] do not support any mechanisms for
  573.       communicating QoS requirements to a multicast server.  For this
  574.       reason, RSVP over ATM implementations SHOULD support "mesh-mode"
  575.       distribution for RSVP controlled multicast flows.  When using
  576.       multicast servers that do not support QoS requests, a sender MUST
  577.       set the service, not global, break bit(s). Use of the service-
  578.       specific break bit tells the receiver(s) that RSVP and Integrated
  579.       Services are supported by the router but that the service cannot
  580.       be delivered over the ATM network for the specific request.
  581.  
  582.  
  583.  
  584. Berger                   Expires: January 1998                 [Page 10]
  585.  
  586.  
  587.  
  588.  
  589. Internet Draft         RSVP over ATM Requirements              July 1997
  590.  
  591.  
  592.       In the case of MARS[1], the selection of distribution modes is
  593.       administratively controlled.  Therefore network administrators
  594.       that desire proper RSVP over ATM operation MUST appropriately
  595.       configure their network to support mesh mode distribution for
  596.       multicast groups that will be used in RSVP sessions.  For LANE1.0
  597.       networks the only multicast distribution option is over the BUS,
  598.       which means that the break bit MUST always be set.  For LANE2.0
  599.       [3] there are provisions that allow for non-BUS solutions with
  600.       which it may be possible to ensure proper QoS delivery.
  601.  
  602.    3.4 Receiver Transitions
  603.  
  604.       When setting up a point-to-multipoint VCs there will be a time
  605.       when some receivers have been added to a QoS VC and some have not.
  606.       During such transition times it is possible to start sending data
  607.       on the newly established VC.  The issue is when to start send data
  608.       on the new VC.  If data is sent both on the new VC and the old VC,
  609.       then data will be delivered with proper QoS to some receivers and
  610.       with the old QoS to all receivers.  This means the QoS receivers
  611.       would get duplicate data.  If data is sent just on the new QoS VC,
  612.       the receivers that have not yet been added will lose information.
  613.       So, the issue comes down to whether to send to both the old and
  614.       new VCs, or to send to just one of the VCs.  In one case duplicate
  615.       information will be received, in the other some information may
  616.       not be received.  This issue needs to be considered for three
  617.       cases: when establishing the first QoS VC, when establishing a VC
  618.       to support a QoS change, and when adding a new end-point to an
  619.       already established QoS VC.
  620.  
  621.       The first two cases are essentially the same.  In both, it is
  622.       possible to send data on the partially completed new VC, and the
  623.       issue of duplicate versus lost information is similar. The last
  624.       case occurs when an end-point must be added to an existing QoS VC.
  625.       In this case the end-point must be both added to the QoS VC and
  626.       dropped from a best-effort VC.  The issue is which to do first.
  627.       If the add is first requested, then the end-point may get
  628.       duplicate information.  If the drop is requested first, then the
  629.       end-point may loose information.
  630.  
  631.       In order to ensure predictable behavior and to conform to the
  632.       requirement to deliver data to all receivers, data MUST NOT be
  633.       sent on new VCs until all parties have been added.  This will
  634.       ensure that all data is only delivered once to all receivers.
  635.       This approach does not quite apply for the last case. In the last
  636.       case, the add MUST be completed first, then the drop.  This last
  637.       behavior requires receivers to be prepared to receive some
  638.       duplicate packets at times of QoS setup.
  639.  
  640.  
  641.  
  642.  
  643. Berger                   Expires: January 1998                 [Page 11]
  644.  
  645.  
  646.  
  647.  
  648. Internet Draft         RSVP over ATM Requirements              July 1997
  649.  
  650.  
  651. 4. Security
  652.  
  653.    The same considerations stated in [10] and [14] apply to this
  654.    document.  There are no additional security issues raised in this
  655.    document.
  656.  
  657. 5. Acknowledgments
  658.  
  659.    This work is based on earlier drafts [5,7] and comments from the
  660.    ISSLL working group.  The author would like to acknowledge their
  661.    contribution, most notably Steve Berson who coauthored [7].
  662.  
  663. 6. Author's Address
  664.  
  665.       Lou Berger
  666.       FORE Systems
  667.       6905 Rockledge Drive
  668.       Suite 800
  669.       Bethesda, MD 20817
  670.  
  671.       Phone: +1 301 571 2534
  672.       EMail: lberger@fore.com
  673.  
  674. REFERENCES
  675.  
  676. [1] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM
  677.     Networks," RFC 2022, November 1996.
  678.  
  679. [2] The ATM Forum, "LAN Emulation Over ATM Specification", Version 1.0.
  680.  
  681. [3] The ATM Forum, "LAN Emulation over ATM Version 2 - LUNI
  682.     Specification ", April 1997.
  683.  
  684. [4] The ATM Forum, "MPOA Baseline Version 1", May 1997.
  685.  
  686. [5] Berger, L., "RSVP over ATM: Framework and UNI3.0/3.1 Method",
  687.     Internet Draft, June 1996.
  688.  
  689. [6] Berger, L., "RSVP over ATM Implementation Guidelines", Internet
  690.     Draft, July 1997.
  691.  
  692. [7] Berson, S., Berger, L., "IP Integrated Services with RSVP over ATM,"
  693.     Internet Draft, draft-ietf-issll-atm-support-02.txt, November 1996.
  694.  
  695. [8] Borden, M., Crawley, E., Krawczyk, J, Baker, F., and Berson, S.,
  696.     "Issues for RSVP and Integrated Services over ATM," Internet Draft,
  697.     February 1996.
  698.  
  699.  
  700.  
  701.  
  702. Berger                   Expires: January 1998                 [Page 12]
  703.  
  704.  
  705.  
  706.  
  707. Internet Draft         RSVP over ATM Requirements              July 1997
  708.  
  709.  
  710. [9] Borden, M., and Garrett, M., "Interoperation of Controlled-Load and
  711.     Guaranteed-Service with ATM," Internet Draft, March 1997.
  712.  
  713. [10] Braden, R., Zhang, L., Berson, S., Herzog, S., and Jamin, S.,
  714.     "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
  715.     Specification," Internet Draft, June 1997.
  716.  
  717. [11] Crawley, E., Berger, L., Berson, S., Baker, F., Borden, M., and
  718.     Krawczyk, J, "Issues for Integrated Services and RSVP over ATM,"
  719.     Internet Draft, July 1997.
  720.  
  721. [12] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation
  722.     Layer 5," RFC 1483.
  723.  
  724. [13] Onvural, R., Srinivasan, V., "A Framework for Supporting RSVP Flows
  725.     Over ATM Networks," Internet Draft, March 1996.
  726.  
  727. [14] Perez, M., Liaw, F., Grossman, D., Mankin, A., Hoffman, E., and
  728.     Malis, A., "ATM Signalling Support for IP over ATM," RFC 1755.
  729.  
  730. [15] Maher, M., "ATM Signalling Support for IP over ATM - UNI 4.0
  731.     Update" Internet Draft, May 1997.
  732.  
  733.  
  734.  
  735.  
  736.  
  737.  
  738.  
  739.  
  740.  
  741.  
  742.  
  743.  
  744.  
  745.  
  746.  
  747.  
  748.  
  749.  
  750.  
  751.  
  752.  
  753.  
  754.  
  755.  
  756.  
  757.  
  758.  
  759.  
  760.  
  761. Berger                   Expires: January 1998                 [Page 13]
  762.  
  763.