rfc2998.txt

RFC 的详细文档！

   In 4.2.2 and 4.2.3 some subset of the routers within the Diffserv
   network is RSVP signaling aware (though traffic control is aggregated
   as opposed to per-flow).  The relative number of routers in the core
   that participate in RSVP signaling is a provisioning decision that
   must be made by the network administrator.

   In one extreme case, only the border routers participate in RSVP
   signaling.  In this case, either the Diffserv network region must be
   extremely over-provisioned and therefore, inefficiently used, or else
   it must be carefully and statically provisioned for limited traffic
   patterns.  The border routers must enforce these patterns.

   In the other extreme case, each router in the Diffserv network region
   might participate in RSVP signaling.  In this case, resources can be
   used with optimal efficiency, but signaling processing requirements
   and associated overhead increase.  As noted above, RSVP aggregation
   is one way to limit the signaling overhead at the cost of some loss
   of optimality in resource utilization.

   It is likely that some network administrators will compromise by
   enabling RSVP signaling on some subset of routers in the Diffserv
   network region.  These routers will likely represent major traffic
   switching points with over-provisioned or statically provisioned
   regions of RSVP unaware routers between them.








Bernet, et al.               Informational                     [Page 20]

RFC 2998       Integrated Services Over Diffserv Networks  November 2000


4.3 Dynamically Provisioned, Non-RSVP-aware Diffserv Region

   Border routers might not use any form of RSVP signaling within the
   Diffserv network region but might instead use custom protocols to
   interact with an "oracle".  The oracle is an agent that has
   sufficient knowledge of resource availability and network topology to
   make admission control decisions.  The set of RSVP aware routers in
   the previous two examples can be considered collectively as a form of
   distributed oracle.  In various definitions of the "bandwidth broker"
   [4], it is able to act as a centralized oracle.

5. Implications of the Framework for Diffserv Network Regions

   We have described a framework in which RSVP/Intserv style QoS can be
   provided across end-to-end paths that include Diffserv network
   regions.  This section discusses some of the implications of this
   framework for the Diffserv network region.

5.1 Requirements from Diffserv Network Regions

   A Diffserv network region must meet the following requirements in
   order for it to support the framework described in this document.

   1. A Diffserv network region must be able to provide support for the
   standard Intserv QoS services between its border routers.  It must be
   possible to invoke these services by use of standard PHBs within the
   Diffserv region and appropriate behavior at the edge of the Diffserv
   region.

   2. Diffserv network regions must provide admission control
   information to their "customer" (non-Diffserv) network regions.  This
   information can be provided by a dynamic protocol or through static
   service level agreements enforced at the edges of the Diffserv
   region.

   3. Diffserv network regions must be able to pass RSVP messages, in
   such a manner that they can be recovered at the egress of the
   Diffserv network region.  The Diffserv network region may, but is not
   required to, process these messages.  Mechanisms for transparently
   carrying RSVP messages across a transit network are described in
   [3,6,15,16].

   To meet these requirements, additional work is required in the areas
   of:

   1. Mapping Intserv style service specifications to services that can
   be provided by Diffserv network regions.




Bernet, et al.               Informational                     [Page 21]

RFC 2998       Integrated Services Over Diffserv Networks  November 2000


   2. Definition of the functionality required in network elements to
   support RSVP signaling with aggregate traffic control (for network
   elements residing in the Diffserv network region).
   3. Definition of mechanisms to efficiently and dynamically provision
   resources in a Diffserv network region (e.g., aggregated RSVP,
   tunneling, MPLS, etc.).  This might include protocols by which an
   "oracle" conveys information about resource availability within a
   Diffserv region to border routers.  One example of such a mechanism
   is the so-called "bandwidth broker" proposed in [19,20,21].

5.2 Protection of Intserv Traffic from Other Traffic

   Network administrators must be able to share resources in the
   Diffserv network region between three types of traffic:

   a. End-to-end Intserv traffic.  This is typically traffic associated
   with quantitative QoS applications.  It requires a specific quantity
   of resources with a high degree of assurance.

   b. Non-Intserv traffic.  The Diffserv region may allocate resources
   to traffic that does not make use of Intserv techniques to quantify
   its requirements, e.g., through the use of static provisioning and
   SLSs enforced at the edges of the region.  Such traffic might be
   associated with applications whose QoS requirements are not readily
   quantifiable but which require a "better than best-effort" level of
   service.

   c. All other (best-effort) traffic.  These three classes of traffic
   must be isolated from each other by the appropriate configuration of
   policers and classifiers at ingress points to the Diffserv network
   region, and by appropriate provisioning within the Diffserv network
   region.  To provide protection for Intserv traffic in Diffserv
   regions of the network, we suggest that the DSCPs assigned to such
   traffic not overlap with the DSCPs assigned to other traffic.

6. Multicast

   The use of integrated services over Diffserv networks is
   significantly more complex for multicast sessions than for unicast
   sessions.  With respect to a multicast connection, each participating
   region has a single ingress router and zero, one or several egress
   routers.  The difficulties of multicast are associated with Diffserv
   regions that contain several egress routers.  (Support of multicast
   functionality outside the Diffserv region is relatively
   straightforward since every Intserv-capable router along the
   multicast tree stores state for each flow.)

   Consider the following reference network:



Bernet, et al.               Informational                     [Page 22]

RFC 2998       Integrated Services Over Diffserv Networks  November 2000


                                          Non-Diffserv region 2
                                                    ________
                                                   /        \
                                                  |          | |---|
             ________         _____________       |          |-|Rx1|
            /        \       /          |--\      |---|      | |---|
           /          \     /          /|BR2\-----\ER2|     /
    |---| |        |---|   |---|  |--|/ |---|      \--|____/
    |Tx |-|        |ER1|---|BR1|--|RR|      |       ________
    |---| |        |-- |   |---|  |--|\ |---|      /--|     \
           \          /     \          \|BR3/-----|ER3|      | |---|
            \________/       \__________|--/      |---|      |-|Rx2|
                                                  |          | |---|
    Non-Diffserv region 1   Diffserv region        \        /
                                                    \______/

                                          Non-Diffserv region 3

           Figure 2: Sample Multicast Network Configuration

   The reference network is similar to that of Figure 1.  However, in
   Figure 2, copies of the packets sent by Tx are delivered to several
   receivers outside of the Diffserv region, namely to Rx1 and Rx2.
   Moreover, packets are copied within the Diffserv region in a "branch
   point" router RR.  In the reference network BR1 is the ingress router
   to the Diffserv region whereas BR2 and BR3 are the egress routers.

   In the simplest case the receivers, Rx1 and Rx2 in the reference
   network, require identical reservations.  The Diffserv framework [18]
   supports service level specifications (SLS) from an ingress router to
   one, some or all of the egress routers.  This calls for a "one to
   many" SLS within the Diffserv region, from BR1 to BR2 and BR3.  Given
   that the SLS is granted by the Diffserv region, the ingress router
   BR1, or perhaps an upstream node such as ER1, marks packets entering
   the Diffserv region with the appropriate DSCP.  The packets are
   routed to the egresses of the Diffserv domain using the original
   multicast address.

   The two major problems, explained in the following, are associated
   with heterogeneous multicast trees containing branch points within
   the Diffserv region, i.e., multicast trees where the level of
   resource requirement is not uniform among all receivers.  An example
   of such a scenario in the network of Figure 2 is the case where both
   Rx1 and Rx2 need to receive multicast data from Tx1 but only one of
   the receivers has requested a level of service above best effort.  We
   consider such scenarios in the following paragraphs.





Bernet, et al.               Informational                     [Page 23]

RFC 2998       Integrated Services Over Diffserv Networks  November 2000


6.1 Remarking of packets in branch point routers

   In the above scenario, the packets that arrive at BR1 are marked with
   an appropriate DSCP for the requested Intserv service and are sent to
   RR.  Packets arriving at the branch point must be sent towards BR2
   with the same DSCP otherwise the service to Rx1 is degraded.
   However, the packets going from RR towards BR3 need not maintain the
   high assurance level anymore.  They may be demoted to best effort so
   that the QoS provided to other packets along this branch of the tree
   is not disrupted.  Several problems can be observed in the given
   scenario:

        - In the Diffserv region, DSCP marking is done at edge routers
          (ingress), whereas a branch point router might be a core
          router, which does not mark packets.

        - Being a core Diffserv router, RR classifies based on
          aggregate traffic streams (BA), as opposed to per flow (MF)
          classification.  Hence, it does not necessarily have the
          capability to distinguish those packets which belong to a
          specific multicast tree and require demotion from the other
          packets in the behavior aggregate, which carry the same DSCP.

        - Since RR may be RSVP-unaware, it may not participate in the
          admission control process, and would thus not store any per-
          flow state about the reservations for the multicast tree.
          Hence, even if RR were able to perform MF classification and
          DSCP remarking, it would not know enough about downstream
          reservations to remark the DSCP intelligently.

   These problems could be addressed by a variety of mechanisms.  We
   list some below, while noting that none is ideal in all cases and
   that further mechanisms may be developed in the future:

   1. If some Intserv-capable routers are placed within the Diffserv
   region, it might be possible to administer the network topology and
   routing parameters so as to ensure that branch points occur only
   within such routers.  These routers would support MF classification
   and remarking and hold per-flow state for the heterogeneous
   reservations for which they are the branch point.  Note that in this
   case, branch point routers would have essentially the same
   functionality as ingress routers of an RSVP-aware Diffserv domain.

   2. Packets sent on the "non-reserved" branch (from RR towards BR3)
   are marked with the "wrong" DSCP; that is, they are not demoted to
   best effort but retain their DSCP.  This in turn requires over
   reservation of resources along that link or runs the risk of
   degrading service to packets that legitimately bear the same DSCP



Bernet, et al.               Informational                     [Page 24]

RFC 2998       Integrated Services Over Diffserv Networks  November 2000


   along this path.  However, it allows the Diffserv routers to remain
   free of per-flow state.

   3. A combination of mechanism 1 and 2 may be an effective compromise.
   In this case, there are some Intserv-capable routers in the core of
   the network, but the network cannot be administered so that ALL
   branch points fall at such routers.

   4. Administrators of Diffserv regions may decide no