rfc2998.txt

中、英文RFC文档大全打包下载完全版 .

    - resources dynamically provisioned by other means (e.g., a form of
      Bandwidth Broker).

   Some of the details of using each of these different approaches are
   discussed in the following section.





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


4. Detailed Examples of the Operation of Intserv over Diffserv Regions

   In this section we provide detailed examples of our framework in
   action.  We discuss two examples, one in which the Diffserv network
   region is RSVP unaware, the other in which the Diffserv network
   region is RSVP aware.

4.1 Statically Provisioned Diffserv Network Region

   In this example, no devices in the Diffserv network region are RSVP
   aware.  The Diffserv network region is statically provisioned.  The
   customer(s) of the Diffserv network regions and the owner of the
   Diffserv network region have negotiated a static contract (service
   level specification, or SLS) for the transmit capacity to be provided
   to the customer at each of a number of standard Diffserv service
   levels.  The "transmit capacity" may be simply an amount of bandwidth
   or it could be a more complex "profile" involving a number of factors
   such as burst size, peak rate, time of day etc.

   It is helpful to consider each edge router in the customer network as
   consisting of two halves, a standard Intserv half, which interfaces
   to the customer's network regions and a Diffserv half which
   interfaces to the Diffserv network region.  The Intserv half is able
   to identify and process traffic on per-flow granularity.

   The Diffserv half of the router can be considered to consist of a
   number of virtual transmit interfaces, one for each Diffserv service
   level negotiated in the SLS.  The router contains a table that
   indicates the transmit capacity provisioned, per the SLS at each
   Diffserv service level.  This table, in conjunction with the default
   mapping described in 4.2.1, is used to perform admission control
   decisions on Intserv flows which cross the Diffserv network region.

4.1.1 Sequence of Events in Obtaining End-to-end QoS

   The following sequence illustrates the process by which an
   application obtains end-to-end QoS when RSVP is used by the hosts.

   1. The QoS process on the sending host Tx generates an RSVP PATH
   message that describes the traffic offered by the sending
   application.

   2. The PATH message is carried toward the receiving host, Rx.  In the
   network region to which the sender is attached, standard RSVP/Intserv
   processing is applied at capable network elements.

   3. At the edge router ER1, the PATH message is subjected to standard
   RSVP processing and PATH state is installed in the router.  The PATH



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


   message is sent onward to the Diffserv network region.

   4. The PATH message is ignored by routers in the Diffserv network
   region and then processed at ER2 according to standard RSVP
   processing rules.

   5. When the PATH message reaches the receiving host Rx, the operating
   system generates an RSVP RESV message, indicating interest in offered
   traffic of a certain Intserv service type.

   6. The RESV message is carried back towards the Diffserv network
   region and the sending host.  Consistent with standard RSVP/Intserv
   processing, it may be rejected at any RSVP-capable node in the path
   if resources are deemed insufficient to carry the traffic requested.

   7. At ER2, the RESV message is subjected to standard RSVP/Intserv
   processing.  It may be rejected if resources on the downstream
   interface of ER2 are deemed insufficient to carry the resources
   requested.  If it is not rejected, it will be carried transparently
   through the Diffserv network region, arriving at ER1.

   8. In ER1, the RESV message triggers admission control processing.
   ER1 compares the resources requested in the RSVP/Intserv request to
   the resources available in the Diffserv network region at the
   corresponding Diffserv service level.  The corresponding service
   level is determined by the Intserv to Diffserv mapping discussed
   previously.  The availability of resources is determined by the
   capacity provisioned in the SLS.  ER1 may also apply a policy
   decision such that the resource request may be rejected based on the
   customer's specific policy criteria, even though the aggregate
   resources are determined to be available per the SLS.

   9. If ER1 approves the request, the RESV message is admitted and is
   allowed to continue upstream towards the sender.  If it rejects the
   request, the RESV is not forwarded and the appropriate RSVP error
   messages are sent.  If the request is approved, ER1 updates its
   internal tables to indicate the reduced capacity available at the
   admitted service level on its transmit interface.

   10. The RESV message proceeds through the network region to which the
   sender is attached.  Any RSVP node in this region may reject the
   reservation request due to inadequate resources or policy.  If the
   request is not rejected, the RESV message will arrive at the sending
   host, Tx.

   11. At Tx, the QoS process receives the RESV message.  It interprets
   receipt of the message as indication that the specified traffic flow
   has been admitted for the specified Intserv service type (in the



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


   Intserv-capable nodes).  It may also learn the appropriate DSCP
   marking to apply to packets for this flow from information provided
   in the RESV.

   12. Tx may mark the DSCP in the headers of packets that are
   transmitted on the admitted traffic flow.  The DSCP may be the
   default value which maps to the Intserv service type specified in the
   admitted RESV message, or it may be a value explicitly provided in
   the RESV.

   In this manner, we obtain end-to-end QoS through a combination of
   networks that support RSVP/Intserv and networks that support
   Diffserv.

4.2 RSVP-Aware Diffserv Network Region

   In this example, the customer's edge routers are standard RSVP
   routers.  The border router, BR1 is RSVP aware.  In addition, there
   may be other routers within the Diffserv network region which are
   RSVP aware.  Note that although these routers are able to participate
   in some form of RSVP signaling, they classify and schedule traffic in
   aggregate, based on DSCP, not on the per-flow classification criteria
   used by standard RSVP/Intserv routers.  It can be said that their
   control-plane is RSVP while their data-plane is Diffserv.  This
   approach exploits the benefits of RSVP signaling while maintaining
   much of the scalability associated with Diffserv.

   In the preceding example, there is no signaling between the Diffserv
   network region and network elements outside it.  The negotiation of
   an SLS is the only explicit exchange of resource availability
   information between the two network regions.  ER1 is configured with
   the information represented by the SLS and as such, is able to act as
   an admission control agent for the Diffserv network region.  Such
   configuration does not readily support dynamically changing SLSs,
   since ER1 requires reconfiguration each time the SLS changes.  It is
   also difficult to make efficient use of the resources in the Diffserv
   network region.  This is because admission control does not consider
   the availability of resources in the Diffserv network region along
   the specific path that would be impacted.

   By contrast, when the Diffserv network region is RSVP aware, the
   admission control agent is part of the Diffserv network.  As a
   result, changes in the capacity available in the Diffserv network
   region can be indicated to the Intserv-capable nodes outside the
   Diffserv region via RSVP.  By including routers interior to the
   Diffserv network region in RSVP signaling, it is possible to
   simultaneously improve the efficiency of resource usage within the
   Diffserv region and to improve the level of confidence that the



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


   resources requested at admission control are indeed available at this
   particular point in time.  This is because admission control can be
   linked to the availability of resources along the specific path that
   would be impacted.  We refer to this benefit of RSVP signaling as
   "topology aware admission control".  A further benefit of supporting
   RSVP signaling within the Diffserv network region is that it is
   possible to effect changes in the provisioning of the Diffserv
   network region (e.g., allocating more or less bandwidth to the EF
   queue in a router) in response to resource requests from outside of
   the Diffserv region.

   Various mechanisms may be used within the Diffserv network region to
   support dynamic provisioning and topology aware admission control.
   These include aggregated RSVP, per-flow RSVP and bandwidth brokers,
   as described in the following paragraphs.

4.2.1 Aggregated or Tunneled RSVP

   A number of documents [3,6,15,16] propose mechanisms for extending
   RSVP to reserve resources for an aggregation of flows between edges
   of a network.  Border routers may interact with core routers and
   other border routers using aggregated RSVP to reserve resources
   between edges of the Diffserv network region.  Initial reservation
   levels for each service level may be established between major border
   routers, based on anticipated traffic patterns.  Border routers could
   trigger changes in reservation levels as a result of the cumulative
   per-flow RSVP requests from the non-Diffserv regions reaching high or
   low-water marks.

   In this approach, admission of per-flow RSVP requests from nodes
   outside the Diffserv region would be counted against the appropriate
   aggregate reservations for the corresponding service level.  The size
   of the aggregate reservations may or may not be dynamically adjusted
   to deal with the changes in per-flow reservations.

   The advantage of this approach is that it offers dynamic, topology
   aware admission control to the Diffserv network region without
   requiring the level of RSVP signaling processing that would be
   required to support per-flow RSVP.

   We note that resource management of a Diffserv region using
   aggregated RSVP is most likely to be feasible only within a single
   administrative domain, as each domain will probably choose its own
   mechanism to manage its resources.







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


4.2.3 Per-flow RSVP

   In this approach, described in [3], routers in the Diffserv network
   region respond to the standard per-flow RSVP signaling originating
   from the Intserv-capable nodes outside the Diffserv region.  This
   approach provides the benefits of the previous approach (dynamic,
   topology aware admission control) without requiring aggregated RSVP
   support.  Resources are also used more efficiently as a result of the
   per-flow admission control.  However, the demands on RSVP signaling
   resources within the Diffserv network region may be significantly
   higher than in an aggregated RSVP approach.

   Note that per-flow RSVP and aggregated RSVP are not mutually
   exclusive in a single Diffserv region. It is possible to use per-flow
   RSVP at the edges of the Diffserv region and aggregation only in some
   "core" region within the Diffserv region.

4.2.4 Granularity of Deployment of RSVP Aware Routers

   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.