rfc2382.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   addressed by aggregating several RSVP flows over a single VC if the
   destinations of the VC match for all the flows being aggregated.
   However, this causes considerable complexity in the management of VCs
   and in the scheduling of packets within each VC at the root point of



Crawley, et. al.             Informational                     [Page 10]

RFC 2382         Integrated Services and RSVP over ATM       August 1998


   the VC.  Note that the rescheduling of flows within a VC is not
   possible in the switches in the core of the ATM network. Virtual
   Paths (VPs) can be used for aggregating multiple VCs. This topic is
   discussed in greater detail as it applies to multicast data
   distribution in section 4.2.3.4

2.4 Mapping QoS Parameters

   The mapping of QoS parameters from the IntServ models to the ATM
   service classes is an important issue in making RSVP and IntServ work
   over ATM.  [14] addresses these issues very completely for the
   Controlled Load and Guaranteed Service models.  An additional issue
   is that while some guidelines can be developed for mapping the
   parameters of a given service model to the traffic descriptors of an
   ATM traffic class, implementation variables, policy, and cost factors
   can make strict mapping problematic.  So, a set of workable mappings
   that can be applied to different network requirements and scenarios
   is needed as long as the mappings can satisfy the needs of the
   service model(s).

2.5 Directly Connected ATM Hosts

   It is obvious that the needs of hosts that are directly connected to
   ATM networks must be considered for RSVP and IntServ over ATM.
   Functionality for RSVP over ATM must not assume that an ATM host has
   all the functionality of a router, but such things as MARS and NHRP
   clients would be worthwhile features.  A host must manage VCs just
   like any other ATM sender or receiver as described later in section
   4.

2.6 Accounting and Policy Issues

   Since RSVP and IntServ create classes of preferential service, some
   form of administrative control and/or cost allocation is needed to
   control access.  There are certain types of policies specific to ATM
   and IP over ATM that need to be studied to determine how they
   interoperate with the IP and IntServ policies being developed.
   Typical IP policies would be that only certain users are allowed to
   make reservations.  This policy would translate well to IP over ATM
   due to the similarity to the mechanisms used for Call Admission
   Control (CAC).

   There may be a need for policies specific to IP over ATM.  For
   example, since signalling costs in ATM are high relative to IP, an IP
   over ATM specific policy might restrict the ability to change the
   prevailing QoS in a VC.  If VCs are relatively scarce, there also
   might be specific accounting costs in creating a new VC.  The work so
   far has been preliminary, and much work remains to be done.  The



Crawley, et. al.             Informational                     [Page 11]

RFC 2382         Integrated Services and RSVP over ATM       August 1998


   policy mechanisms outlined in [12] and [13] provide the basic
   mechanisms for implementing policies for RSVP and IntServ over any
   media, not just ATM.

3. Framework for IntServ and RSVP over ATM

   Now that we have defined some of the issues for IntServ and RSVP over
   ATM, we can formulate a framework for solutions.  The problem breaks
   down to two very distinct areas; the mapping of IntServ models to ATM
   service categories and QoS parameters and the operation of RSVP over
   ATM.

   Mapping IntServ models to ATM service categories and QoS parameters
   is a matter of determining which categories can support the goals of
   the service models and matching up the parameters and variables
   between the IntServ description and the ATM description(s).  Since
   ATM has such a wide variety of service categories and parameters,
   more than one ATM service category should be able to support each of
   the two IntServ models.  This will provide a good bit of flexibility
   in configuration and deployment.  [14] examines this topic
   completely.

   The operation of RSVP over ATM requires careful management of VCs in
   order to match the dynamics of the RSVP protocol.  VCs need to be
   managed for both the RSVP QoS data and the RSVP signalling messages.
   The remainder of this document will discuss several approaches to
   managing VCs for RSVP and [15] and [16] discuss their application for
   implementations in term of interoperability requirement and
   implementation guidelines.

4. RSVP VC Management

   This section provides more detail on the issues related to the
   management of SVCs for RSVP and IntServ.

4.1 VC Initiation

   As discussed in section 2.1.1.2, there is an apparent mismatch
   between RSVP and ATM. Specifically, RSVP control is receiver oriented
   and ATM control is sender oriented.  This initially may seem like a
   major issue, but really is not.  While RSVP reservation (RESV)
   requests are generated at the receiver, actual allocation of
   resources takes place at the subnet sender. For data flows, this
   means that subnet senders will establish all QoS VCs and the subnet
   receiver must be able to accept incoming QoS VCs, as illustrated in
   Figure 1.  These restrictions are consistent with RSVP version 1
   processing rules and allow senders to use different flow to VC
   mappings and even different QoS renegotiation techniques without



Crawley, et. al.             Informational                     [Page 12]

RFC 2382         Integrated Services and RSVP over ATM       August 1998


   interoperability problems.

   The use of the reverse path provided by point-to-point VCs by
   receivers is for further study. There are two related issues. The
   first is that use of the reverse path requires the VC initiator to
   set appropriate reverse path QoS parameters. The second issue is that
   reverse paths are not available with point-to-multipoint VCs, so
   reverse paths could only be used to support unicast RSVP
   reservations.

4.2 Data VC Management

   Any RSVP over ATM implementation must map RSVP and RSVP associated
   data flows to ATM Virtual Circuits (VCs). LAN Emulation [17],
   Classical IP [10] and, more recently, NHRP [4] discuss mapping IP
   traffic onto ATM SVCs, but they only cover a single QoS class, i.e.,
   best effort traffic. When QoS is introduced, VC mapping must be
   revisited. For RSVP controlled QoS flows, one issue is VCs to use for
   QoS data flows.

   In the Classic IP over ATM and current NHRP models, a single point-
   to-point VC is used for all traffic between two ATM attached hosts
   (routers and end-stations).  It is likely that such a single VC will
   not be adequate or optimal when supporting data flows with multiple
   .bp QoS types. RSVP's basic purpose is to install support for flows
   with multiple QoS types, so it is essential for any RSVP over ATM
   solution to address VC usage for QoS data flows, as shown in Figure
   1.

   RSVP reservation styles must also be taken into account in any VC
   usage strategy.

   This section describes issues and methods for management of VCs
   associated with QoS data flows. When establishing and maintaining
   VCs, the subnet sender will need to deal with several complicating
   factors including multiple QoS reservations, requests for QoS
   changes, ATM short-cuts, and several multicast specific issues. The
   multicast specific issues result from the nature of ATM connections.
   The key multicast related issues are heterogeneity, data
   distribution, receiver transitions, and end-point identification.

4.2.1 Reservation to VC Mapping

   There are various approaches available for mapping reservations on to
   VCs.  A distinguishing attribute of all approaches is how
   reservations are combined on to individual VCs.  When mapping
   reservations on to VCs, individual VCs can be used to support a
   single reservation, or reservation can be combined with others on to



Crawley, et. al.             Informational                     [Page 13]

RFC 2382         Integrated Services and RSVP over ATM       August 1998


   "aggregate" VCs.  In the first case, each reservation will be
   supported by one or more VCs.  Multicast reservation requests may
   translate into the setup of multiple VCs as is described in more
   detail in section 4.2.2.  Unicast reservation requests will always
   translate into the setup of a single QoS VC.  In both cases, each VC
   will only carry data associated with a single reservation.  The
   greatest benefit if this approach is ease of implementation, but it
   comes at the cost of increased (VC) setup time and the consumption of
   greater number of VC and associated resources.

   When multiple reservations are combined onto a single VC, it is
   referred to as the "aggregation" model. With this model, large VCs
   could be set up between IP routers and hosts in an ATM network. These
   VCs could be managed much like IP Integrated Service (IIS) point-to-
   point links (e.g. T-1, DS-3) are managed now.  Traffic from multiple
   sources over multiple RSVP sessions might be multiplexed on the same
   VC.  This approach has a number of advantages. First, there is
   typically no signalling latency as VCs would be in existence when the
   traffic started flowing, so no time is wasted in setting up VCs.
   Second, the heterogeneity problem (section 4.2.2) in full over ATM
   has been reduced to a solved problem. Finally, the dynamic QoS
   problem (section 4.2.7) for ATM has also been reduced to a solved
   problem.

   The aggregation model can be used with point-to-point and point-to-
   multipoint VCs.  The problem with the aggregation model is that the
   choice of what QoS to use for the VCs may be difficult, without
   knowledge of the likely reservation types and sizes but is made
   easier since the VCs can be changed as needed.

4.2.2 Unicast Data VC Management

   Unicast data VC management is much simpler than multicast data VC
   management but there are still some similar issues.  If one considers
   unicast to be a devolved case of multicast, then implementing the
   multicast solutions will cover unicast.  However, some may want to
   consider unicast-only implementations.  In these situations, the
   choice of using a single flow per VC or aggregation of flows onto a
   single VC remains but the problem of heterogeneity discussed in the
   following section is removed.

4.2.3 Multicast Heterogeneity

   As mentioned in section 2.1.3.1 and shown in figure 2, multicast
   heterogeneity occurs when receivers request different qualities of
   service within a single session.  This means that the amount of
   requested resources differs on a per next hop basis. A related type
   of heterogeneity occurs due to best-effort receivers.  In any IP



Crawley, et. al.             Informational                     [Page 14]

RFC 2382         Integrated Services and RSVP over ATM       August 1998


   multicast group, it is possible that some receivers will request QoS
   (via RSVP) and some receivers will not. In shared media networks,
   like Ethernet, receivers that have not requested resources can
   typically be given identical service to those that have without
   complications.  This is not the case with ATM. In ATM networks, any
   additional end-points of a VC must be explicitly added. There may be
   costs associated with adding the best-effort receiver, and there
   might not be adequate resources.  An RSVP over ATM solution will need
   to support heterogeneous receivers even though ATM does not currently
   provide such support directly.

   RSVP heterogeneity is supported over ATM in the way RSVP reservations
   are mapped into ATM VCs.  There are four alternative approaches this
   mapping. There are multiple models for supporting RSVP heterogeneity
   over ATM.  Section 4.2.3.1 examines the multiple VCs per RSVP
   reservation (or full heterogeneity) model where a single reservation
   can be forwarded onto several VCs each with a different QoS. Section
   4.2.3.2 presents a limited heterogeneity model where exactly one QoS
   VC is used along with a best effort VC.  Section 4.2.3.3 examines the
   VC per RSVP reservation (or homogeneous) model, where each RSVP
   reservation is mapped to a single ATM VC.  Section 4.2.3.4 describes
   the aggregation model allowing aggregation of multiple RSVP
   reservations into a single VC.

4.2.3.1 Full Heterogeneity Model

   RSVP supports heterogeneous QoS, meaning that different receivers of
   the same multicast group can request a different QoS.  But
   importantly, some receivers might have no reservation at all and want
   to receive the traffic on a best effort service basis.  The IP model
   allows receivers to join a multicast group at any time on a best
   effort basis, and it is important that ATM as part of the Internet
   continue to provide this service. We define the "full heterogeneity"
   model as providing a separate VC for each distinct QoS for a
   multicast session including best effort and one or more qualities of
   service.

   Note that while full heterogeneity gives users exactly what they
   request, it requires more resources of the network than other
   possible approaches. The exact amount of bandwidth used for duplicate
   traffic depends on the network topology and group membership.