rfc2998.txt

RFC 的详细文档！

   how such a region may be used in delivery of end-to-end QOS when only
   BA classification is performed inside the Diffserv region.

   Non-Diffserv Region.  The portions of the network outside the
   Diffserv region.  Such a region may also offer a variety of different
   types of classification and traffic control.



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


   Note that, for the purposes of this document, the defining features
   of a Diffserv region is the type of classification and traffic
   control that is used for the delivery of end-to-end QOS for a
   particular application.  Thus, while it may not be possible to
   identify a certain region as "purely Diffserv" with respect to all
   traffic flowing through the region, it is possible to define it in
   this way from the perspective of the treatment of traffic from a
   single application.

1.6 The Framework

   In the framework we present, end-to-end, quantitative QoS is provided
   by applying the Intserv model end-to-end across a network containing
   one or more Diffserv regions.  The Diffserv regions may, but are not
   required to, participate in end-to-end RSVP signaling for the purpose
   of optimizing resource allocation and supporting admission control.

   From the perspective of Intserv, Diffserv regions of the network are
   treated as virtual links connecting Intserv capable routers or hosts
   (much as an 802.1p network region is treated as a virtual link in
   [5]).  Within the Diffserv regions of the network routers implement
   specific PHBs (aggregate traffic control).  The total amount of
   traffic that is admitted into the Diffserv region that will receive a
   certain PHB may be limited by policing at the edge.  As a result we
   expect that the Diffserv regions of the network will be able to
   support the Intserv style services requested from the periphery.  In
   our framework, we address the support of end-to-end Integrated
   Services over the Diffserv regions of the network.  Our goal is to
   enable seamless inter-operation.  As a result, the network
   administrator is free to choose which regions of the network act as
   Diffserv regions.  In one extreme the Diffserv region is pushed all
   the way to the periphery, with hosts alone having full Intserv
   capability.  In the other extreme, Intserv is pushed all the way to
   the core, with no Diffserv region.

1.7 Contents

   In section 3 we discuss the benefits that can be realized by using
   the aggregate traffic control provided by Diffserv network regions in
   the broader context of the Intserv architecture.  In section 4, we
   present the framework and the reference network.  Section 5 details
   two possible realizations of the framework.  Section 6 discusses the
   implications of the framework for Diffserv.  Section 7 presents some
   issues specific to multicast flows.







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


2. Benefits of Using Intserv with Diffserv

   The primary benefit of Diffserv aggregate traffic control is its
   scalability.  In this section, we discuss the benefits that
   interoperation with Intserv can bring to a Diffserv network region.
   Note that this discussion is in the context of servicing quantitative
   QoS applications specifically.  By this we mean those applications
   that are able to quantify their traffic and QoS requirements.

2.1 Resource Based Admission Control

   In Intserv networks, quantitative QoS applications use an explicit
   setup mechanism (e.g., RSVP) to request resources from the network.
   The network may accept or reject these requests in response.  This is
   "explicit admission control".  Explicit and dynamic admission control
   helps to assure that network resources are optimally used.  To
   further understand this issue, consider a Diffserv network region
   providing only aggregate traffic control with no signaling.  In the
   Diffserv network region, admission control is applied in a relatively
   static way by provisioning policing parameters at network elements.
   For example, a network element at the ingress to a Diffserv network
   region could be provisioned to accept only 50 Kbps of traffic for the
   EF DSCP.

   While such static forms of admission control do protect the network
   to some degree, they can be quite ineffective.  For example, consider
   that there may be 10 IP telephony sessions originating outside the
   Diffserv network region, each requiring 10 Kbps of EF service from
   the Diffserv network region.  Since the network element protecting
   the Diffserv network region is provisioned to accept only 50 Kbps of
   traffic for the EF DSCP, it will discard half the offered traffic.
   This traffic will be discarded from the aggregation of traffic marked
   EF, with no regard to the microflow from which it originated.  As a
   result, it is likely that of the ten IP telephony sessions, none will
   obtain satisfactory service when in fact, there are sufficient
   resources available in the Diffserv network region to satisfy five
   sessions.

   In the case of explicitly signaled, dynamic admission control, the
   network will signal rejection in response to requests for resources
   that would exceed the 50 Kbps limit.  As a result, upstream network
   elements (including originating hosts) and applications will have the
   information they require to take corrective action.  The application
   might respond by refraining from transmitting, or by requesting
   admission for a lesser traffic profile.  The host operating system
   might respond by marking the application's traffic for the DSCP that
   corresponds to best-effort service.  Upstream network elements might
   respond by re-marking packets on the rejected flow to a lower service



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


   level.  In some cases, it may be possible to reroute traffic over
   alternate paths or even alternate networks (e.g., the PSTN for voice
   calls).  In any case, the integrity of those flows that were admitted
   would be preserved, at the expense of the flows that were not
   admitted.  Thus, by appointing an Intserv-conversant admission
   control agent for the Diffserv region of the network it is possible
   to enhance the service that the network can provide to quantitative
   QoS applications.

2.2 Policy Based Admission Control

   In network regions where RSVP is used, resource requests can be
   intercepted by RSVP-aware network elements and can be reviewed
   against policies stored in policy databases.  These resource requests
   securely identify the user and the application for which the
   resources are requested.  Consequently, the network element is able
   to consider per-user and/or per-application policy when deciding
   whether or not to admit a resource request.  So, in addition to
   optimizing the use of resources in a Diffserv network region (as
   discussed in 3.1) RSVP conversant admission control agents can be
   used to apply specific customer policies in determining the specific
   customer traffic flows entitled to use the Diffserv network region's
   resources.  Customer policies can be used to allocate resources to
   specific users and/or applications.

   By comparison, in Diffserv network regions without RSVP signaling,
   policies are typically applied based on the Diffserv customer network
   from which traffic originates, not on the originating user or
   application within the customer network.

2.3 Assistance in Traffic Identification/Classification

   Within Diffserv network regions, traffic is allotted service based on
   the DSCP marked in each packet's IP header.  Thus, in order to obtain
   a particular level of service within the Diffserv network region, it
   is necessary to effect the marking of the correct DSCP in packet
   headers.  There are two mechanisms for doing so, host marking and
   router marking.  In the case of host marking, the host operating
   system marks the DSCP in transmitted packets.  In the case of router
   marking, routers in the network are configured to identify specific
   traffic (typically based on MF classification) and to mark the DSCP
   as packets transit the router.  There are advantages and
   disadvantages to each scheme.  Regardless of the scheme used,
   explicit signaling offers significant benefits.







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


2.3.1 Host Marking

   In the case of host marking, the host operating system marks the DSCP
   in transmitted packets.  This approach has the benefit of shifting
   per-flow classification and marking to the source of the traffic,
   where it scales best.  It also enables the host to make decisions
   regarding the mark that is appropriate for each transmitted packet
   and hence the relative importance attached to each packet.  The host
   is generally better equipped to make this decision than the network.
   Furthermore, if IPSEC encryption is used, the host may be the only
   device in the network that is able to make a meaningful determination
   of the appropriate marking for each packet, since various fields such
   as port numbers would be unavailable to routers for MF
   classification.

   Host marking requires that the host be aware of the interpretation of
   DSCPs by the network.  This information can be configured into each
   host.  However, such configuration imposes a management burden.
   Alternatively, hosts can use an explicit signaling protocol such as
   RSVP to query the network to obtain a suitable DSCP or set of DSCPs
   to apply to packets for which a certain Intserv service has been
   requested.  An example of how this can be achieved is described in
   [14].

2.3.2 Router Marking

   In the case of router marking, MF classification criteria must be
   configured in the router in some way.  This may be done dynamically
   (e.g., using COPS provisioning), by request from the host operating
   system, or statically via manual configuration or via automated
   scripts.

   There are significant difficulties in doing so statically.  In many
   cases, it is desirable to allot service to traffic based on the
   application and/or user originating the traffic.  At times it is
   possible to identify packets associated with a specific application
   by the IP port numbers in the headers.  It may also be possible to
   identify packets originating from a specific user by the source IP
   address.  However, such classification criteria may change
   frequently.  Users may be assigned different IP addresses by DHCP.
   Applications may use transient ports.  To further complicate matters,
   multiple users may share an IP address.  These factors make it very
   difficult to manage static configuration of the classification
   information required to mark traffic in routers.

   An attractive alternative to static configuration is to allow host
   operating systems to signal classification criteria to the router on
   behalf of users and applications.  As we will show later in this



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


   document, RSVP signaling is ideally suited for this task.  In
   addition to enabling dynamic and accurate updating of MF
   classification criteria, RSVP signaling enables classification of
   IPSEC [13] packets (by use of the SPI) which would otherwise be
   unrecognizable.

2.4 Traffic Conditioning

   Intserv-capable network elements are able to condition traffic at a
   per-flow granularity, by some combination of shaping and/or policing.
   Pre-conditioning traffic in this manner before it is submitted to the
   Diffserv region of the network is beneficial.  In particular, it
   enhances the ability of the Diffserv region of the network to provide
   quantitative services using aggregate traffic control.

3. The Framework

   In the general framework we envision an Internet in which the
   Integrated Services architecture is used to deliver end-to-end QOS to
   applications.  The network includes some combination of Intserv
   capable nodes (in which MF classification and per-flow traffic
   control is applied) and Diffserv regions (in which aggregate traffic
   control is applied).  Individual routers may or may not participate
   in RSVP signaling regardless of where in the network they reside.

   We will consider two specific realizations of the framework. In the
   first, resources within the Diffserv regions of the network are
   statically provisioned and these regions include no RSVP aware
   devices.  In the second, resources within the Diffserv region of the
   network are dynamically provisioned and select devices within the
   Diffserv network regions participate in RSVP signaling.