rfc2998.txt

RFC 的详细文档！

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


3.1 Reference Network

   The two realizations of the framework will be discussed in the
   context of the following reference network:

             ________         ______________         ________
            /        \       /              \       /        \
           /          \     /                \     /          \
    |---| |        |---|   |---|          |---|   |---|        | |---|
    |Tx |-|        |ER1|---|BR1|          |BR2|---|ER2|        |-|Rx |
    |---| |        |-- |   |---|          |---|   |---|        | |---|
           \          /     \                /     \          /
            \________/       \______________/       \________/

        Non-Diffserv region   Diffserv region     Non-Diffserv region

                 Figure 1: Sample Network Configuration

   The reference network includes a Diffserv region in the middle of a
   larger network supporting Intserv end-to-end.  The Diffserv region
   contains a mesh of routers, at least some of which provide aggregate
   traffic control.  The regions outside the Diffserv region (non-
   Diffserv regions) contain meshes of routers and attached hosts, at
   least some of which support the Integrated Services architecture.

   In the interest of simplicity we consider a single QoS sender, Tx
   communicating across this network with a single QoS receiver, Rx.
   The edge routers (ER1, ER2) which are adjacent to the Diffserv region
   interface to the border routers (BR1, BR2) within the Diffserv
   region.

   From an economic viewpoint, we may consider that the Diffserv region
   sells service to the network outside the Diffserv region, which in
   turn provides service to hosts.  Thus, we may think of the non-
   Diffserv regions as clients or customers of the Diffserv region.  In
   the following, we use the term "customer" for the non-Diffserv
   regions.  Note that the boundaries of the regions may or may not
   align with administrative domain boundaries, and that a single region
   might contain multiple administrative domains.

   We now define the major components of the reference network.

3.1.1 Hosts

   We assume that both sending and receiving hosts use RSVP to
   communicate the quantitative QoS requirements of QoS-aware
   applications running on the host.  In principle, other mechanisms may
   be used to establish resource reservations in Intserv-capable nodes,



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


   but RSVP is clearly the prevalent mechanism for this purpose.

   Typically, a QoS process within the host operating system generates
   RSVP signaling on behalf of applications.  This process may also
   invoke local traffic control.

   As discussed above, traffic control in the host may mark the DSCP in
   transmitted packets, and shape transmitted traffic to the
   requirements of the Intserv service in use.  Alternatively, the first
   Intserv-capable router downstream from the host may provide these
   traffic control functions.

3.1.2 End-to-End RSVP Signaling

   We assume that RSVP signaling messages travel end-to-end between
   hosts Tx and Rx to support RSVP/Intserv reservations outside the
   Diffserv network region.  We require that these end-to-end RSVP
   messages are at least carried across the Diffserv region.  Depending
   on the specific realization of the framework, these messages may be
   processed by none, some or all of the routers in the Diffserv region.

3.1.3 Edge Routers

   ER1 and ER2 are edge routers, residing adjacent to the Diffserv
   network regions.  The functionality of the edge routers varies
   depending on the specific realization of the framework.  In the case
   in which the Diffserv network region is RSVP unaware, edge routers
   act as admission control agents to the Diffserv network.  They
   process signaling messages from both Tx and Rx, and apply admission
   control based on resource availability within the Diffserv network
   region and on customer defined policy.  In the case in which the
   Diffserv network region is RSVP aware, the edge routers apply
   admission control based on local resource availability and on
   customer defined policy.  In this case, the border routers act as the
   admission control agent to the Diffserv network region.

   We will later describe the functionality of the edge routers in
   greater depth for each of the two realizations of the framework.

3.1.4 Border Routers

   BR1 and BR2 are border routers, residing in the Diffserv network
   region.  The functionality of the border routers varies depending on
   the specific realization of the framework.  In the case in which the
   Diffserv network region is RSVP-unaware, these routers act as pure
   Diffserv routers.  As such, their sole responsibility is to police
   submitted traffic based on the service level specified in the DSCP
   and the agreement negotiated with the customer (aggregate



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


   trafficcontrol).  In the case in which the Diffserv network region is
   RSVP-aware, the border routers participate in RSVP signaling and act
   as admission control agents for the Diffserv network region.

   We will later describe the functionality of the border routers in
   greater depth for each of the two realizations of the framework.

3.1.5 Diffserv Network Region

   The Diffserv network region supports aggregate traffic control and is
   assumed not to be capable of MF classification.  Depending on the
   specific realization of the framework, some number of routers within
   the Diffserv region may be RSVP aware and therefore capable of per-
   flow signaling and admission control.  If devices in the Diffserv
   region are not RSVP aware, they will pass RSVP messages transparently
   with negligible performance impact (see [6]).

   The Diffserv network region provides two or more levels of service
   based on the DSCP in packet headers.  It may be a single
   administrative domain or may span multiple domains.

3.1.6 Non-Diffserv Network Regions

   The network outside of the Diffserv region consists of Intserv
   capable hosts and other network elements.  Other elements may include
   routers and perhaps various types of network (e.g., 802, ATM, etc.).
   These network elements may reasonably be assumed to support Intserv,
   although this might not be required in the case of over-provisioning.
   Even if these elements are not Intserv capable, we assume that they
   will pass RSVP messages unhindered.  Routers outside of the Diffserv
   network region are not precluded from providing aggregate traffic
   control to some subset of the traffic passing through them.

3.2 Service Mapping

   Intserv service requests specify an Intserv service type and a set of
   quantitative parameters known as a "flowspec".  At each hop in an
   Intserv network, the Intserv service requests are interpreted in a
   form meaningful to the specific link layer medium.  For example at an
   802.1 hop, the Intserv parameters are mapped to an appropriate 802.1p
   priority level [5].

   In our framework, Diffserv regions of the network are analogous to
   the 802.1p capable switched segments described in [5].  Requests for
   Intserv services must be mapped onto the underlying capabilities of
   the Diffserv network region.  Aspects of the mapping include:





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


    - selecting an appropriate PHB, or set of PHBs, for the requested
      service;
    - performing appropriate policing (including, perhaps, shaping or
      remarking) at the edges of the Diffserv region;
    - exporting Intserv parameters from the Diffserv region (e.g., for
      the updating of ADSPECs);
    - performing admission control on the Intserv requests that takes
      into account the resource availability in the Diffserv region.

   Exactly how these functions are performed will be a function of the
   way bandwidth is managed inside the Diffserv network region, which is
   a topic we discuss in Section 4.3.

   When the PHB (or set of PHBs) has been selected for a particular
   Intserv flow, it may be necessary to communicate the choice of DSCP
   for the flow to other network elements. Two schemes may be used to
   achieve this end, as discussed below.

3.2.1 Default Mapping

   In this scheme, there is some standard, well-known mapping from
   Intserv service type to a DSCP that will invoke the appropriate
   behavior in the Diffserv network.

3.2.2 Network Driven Mapping

   In this scheme, RSVP conversant routers in the Diffserv network
   region (perhaps at its edge) may override the well-known mapping
   described in 4.2.1.  In the case that DSCPs are marked at the ingress
   to the Diffserv region, the DSCPs can simply be remarked at the
   boundary routers.  However, in the case that DSCP marking occurs
   upstream of the Diffserv region, either in a host or a router, then
   the appropriate mapping needs to be communicated upstream, to the
   marking device.  This may be accomplished using RSVP, as described in
   [14].

   The decision regarding where to mark DSCP and whether to override the
   well-known service mapping is a mater of policy to be decided by the
   administrator of the Diffserv network region in cooperation with the
   administrator of the network adjacent to the Diffserv region.

3.2.3 Microflow Separation

   Boundary routers residing at the edge of the Diffserv region will
   typically police traffic submitted from the outside the Diffserv
   region in order to protect resources within the Diffserv region.
   This policing will be applied on an aggregate basis, with no regard
   for the individual microflows making up each aggregate.  As a result,



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


   it is possible for a misbehaving microflow to claim more than its
   fair share of resources within the aggregate, thereby degrading the
   service provided to other microflows.  This problem may be addressed
   by:

   1. Providing per microflow policing at the edge routers - this is
   generally the most appropriate location for microflow policing, since
   it pushes per-flow work to the edges of the network, where it scales
   better.  In addition, since Intserv-capable routers outside the
   Diffserv region are responsible for providing microflow service to
   their customers and the Diffserv region is responsible for providing
   aggregate service to its customers, this distribution of
   functionality mirrors the distribution of responsibility.

   2. Providing per microflow policing at the border routers - this
   approach tends to be less scalable than the previous approach.  It
   also imposes a management burden on the Diffserv region of the
   network.  However, it may be appropriate in certain cases, for the
   Diffserv boundary routers to offer per microflow policing as a
   value-add to its Intserv customers.

   3. Relying on upstream shaping and policing - in certain cases, the
   customer may trust the shaping of certain groups of hosts
   sufficiently to not warrant reshaping or policing at the boundary of
   the Diffserv region.  Note that, even if the hosts are shaping
   microflows properly, these shaped flows may become distorted as they