rfc2386.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,375 行 · 第 1/5 页

   resources are not overbooked along the path.  As long as strict
   resource management and control are not needed, mechanisms such as
   TOS-based routing are useful for separating whole classes of traffic



Crawley, et. al.             Informational                      [Page 5]

RFC 2386           A Framework for QoS-based Routing         August 1998


   over multiple routes.  Such mechanisms might work well with the
   emerging Differential Services efforts [BBCD98].

   Combining a resource reservation protocol with QoS-based routing
   allows fine control over the route and resources at the cost of
   additional state and setup time. For example, a protocol such as RSVP
   may be used to trigger QoS-based routing calculations to meet the
   needs of a specific flow.

3.3  QoS-Based Routing: Objectives

   Under QoS-based routing,  paths for flows would be determined based
   on some knowledge of resource availability in the network, as well as
   the QoS requirement of flows. The main objectives of QoS-based
   routing are:

   1.  Dynamic determination of feasible paths:  QoS-based routing can
       determine a path, from among possibly many choices, that has a
       good chance of accommodating the QoS of the given flow. Feasible
       path selection may be subject to policy constraints, such as path
       cost, provider selection, etc.

   2.  Optimization of resource usage: A network state-dependent QoS-
       based routing scheme can aid in the efficient utilization of
       network resources by improving the total network throughput. Such
       a routing scheme can be the basis for efficient network
       engineering.

   3.  Graceful performance degradation: State-dependent routing can
       compensate for transient inadequacies in network engineering
       (e.g., during focused overload conditions), giving better
       throughput and a more graceful performance degradation as
       compared to a state-insensitive routing scheme [A84].

   QoS-based routing in the Internet, however, raises many issues:

   -  How do routers determine the QoS capability of each outgoing link
      and reserve link resources? Note that some of these links may be
      virtual, over ATM networks and others may be broadcast multi-
      access links.

   -  What is the granularity of routing decision (i.e., destination-
      based, source and destination-based, or flow-based)?

   -  What routing metrics are used and how are QoS-accommodating paths
      computed for unicast flows?





Crawley, et. al.             Informational                      [Page 6]

RFC 2386           A Framework for QoS-based Routing         August 1998


   -  How are QoS-accommodating paths computed for multicast flows with
      different reservation styles and receiver heterogeneity?

   -  What are the performance objectives while computing QoS-based
      paths?

   -  What are the administrative control issues?

   -  What factors affect the routing overheads?, and

   -  How is scalability achieved?

   Some of these issues are discussed briefly next. Interdomain routing
   is discussed in Section 5.

3.4  QoS Determination and Resource Reservation

   To determine whether the QoS requirements of a flow can be
   accommodated on a link, a router must be able to determine the QoS
   available on the link. It is still an open issue as to how the QoS
   availability is determined for broadcast multiple access links (e.g.,
   Ethernet). A related problem is the reservation of resources over
   such links.  Solutions to these problems are just emerging [GPSS98].

   Similar problems arise when a router is connected to a large non-
   broadcast multiple access network, such as ATM. In this case, if the
   destination of a flow is outside the ATM network, the router may have
   multiple egress choices. Furthermore, the QoS availability on the ATM
   paths to each egress point may be different. The issues then are,

      o   how does a router determine all the egress choices across the
          ATM network?
      o   how  does it determine what QoS is available over the path to
          each egress point?, and
      o   what QoS value does the router advertise for the ATM link.

   Typically, IP routing over ATM (e.g., NHRP) allows the selection of a
   single egress point in the ATM network, and the procedure does not
   incorporate any knowledge of the QoS required over the path. An
   approach like I-PNNI [IPNNI] would be helpful here, although it
   introduces some complexity.

   An additional problem with resource reservation is how to determine
   what resources have already been allocated to a multicast flow. The
   availability of this information during path computation improves the
   chances of finding a path to add a new receiver to a multicast flow.
   QOSPF [ZSSC97] handles this problem by letting routers broadcast
   reserved resource information to other routers in their area.



Crawley, et. al.             Informational                      [Page 7]

RFC 2386           A Framework for QoS-based Routing         August 1998


   Alternate path routing [ZES97] deals with this issue by using probe
   messages to find a path with sufficient resources. Path QoS
   Computation (PQC) method, proposed in [GOA97], propagates bandwidth
   allocation information in RSVP PATH messages. A router receiving the
   PATH message gets an indication of the resource allocation only on
   those links in the path to itself from the source.  Allocation for
   the same flow on other remote branches of the multicast tree is not
   available. Thus, the PQC method may not be sufficient to find
   feasible QoS-accommodating paths to all receivers.

3.5  Granularity of Routing Decision

   Routing in the Internet is currently based only on the destination
   address of a packet.  Many multicast routing protocols require
   routing based on the source AND destination of a packet. The
   Integrated Services architecture and RSVP allow QoS determination for
   an individual flow between a source and a destination. This set of
   routing granularities presents a problem for QoS routing solutions.

   If routing based only on destination address is considered, then an
   intermediate router will route all flows between different sources
   and a given destination along the same path. This is acceptable if
   the path has adequate capacity but a problem arises if there are
   multiple flows to a destination that exceed the capacity of the link.

   One version of QOSPF [ZSSC97] determines QoS routes based on source
   and destination address.  This implies that all traffic between a
   given source and destination, regardless of the flow, will travel
   down the same route.  Again, the route must have capacity for all the
   QoS traffic for the source/destination pair.  The amount of routing
   state also increases since the routing tables must include
   source/destination pairs instead of just the destination.

   The best granularity is found when routing is based on individual
   flows but this incurs a tremendous cost in terms of the routing
   state.  Each QoS flow can be routed separately between any source and
   destination. PQC [GOA97] and alternate path routing [ZES97], are
   examples of solutions which operate at the flow level.

   Both source/destination and flow-based routing may be susceptible to
   packet looping under hop-by-hop forwarding. Suppose a node along a
   flow or source/destination-based path loses the state information for
   the flow.  Also suppose that the flow-based route is different from
   the regular destination-based route. The potential then exists for a
   routing loop to form when the node forwards a packet belonging to the
   flow using its destination-based routing table to a node that occurs





Crawley, et. al.             Informational                      [Page 8]

RFC 2386           A Framework for QoS-based Routing         August 1998


   earlier on the flow-based path. This is because the latter node may
   use its flow-based routing table to forward the packet again to the
   former and this can go on indefinitely.

3.6   Metrics and Path Computation

3.6.1 Metric Selection and Representation

   There are some considerations in defining suitable link and node
   metrics [WC96]. First, the metrics must represent the basic network
   properties of interest. Such metrics include residual bandwidth,
   delay and jitter.  Since the flow QoS requirements have to be mapped
   onto path metrics, the metrics define the types of QoS guarantees the
   network can support.  Alternatively, QoS-based routing cannot support
   QoS requirements that cannot be meaningfully mapped onto a reasonable
   combination of path metrics.  Second, path computation based on a
   metric or a combination of metrics must not be too complex as to
   render them impractical. In this regard, it is worthwhile to note
   that path computation based on certain combinations of metrics (e.g.,
   delay and jitter) is theoretically hard. Thus, the allowable
   combinations of metrics must be determined while taking into account
   the complexity of computing paths based on these metrics and the QoS
   needs of flows. A common strategy to allow flexible combinations of
   metrics while at the same time reduce the path computation complexity
   is to utilize "sequential filtering". Under this approach, a
   combination of metrics is ordered in some fashion, reflecting the
   importance of different metrics (e.g., cost followed by delay, etc.).
   Paths based on the primary metric are computed first (using a simple
   algorithm, e.g., shortest path) and a subset of them are eliminated
   based on the secondary metric and so forth until a single path is
   found. This is an approximation technique and it trades off global
   optimality for path computation simplicity (The filtering technique
   may be simpler, depending on the set of metrics used. For example,
   with bandwidth and cost as metrics, it is possible to first eliminate
   the set of links that do not have the requested bandwidth and then
   compute the least cost path using the remaining links.)

   Now, once suitable link and node metrics are defined, a uniform
   representation of them is required across independent domains -
   employing possibly different routing schemes - in order to derive
   path metrics consistently (path metrics are obtained by the
   composition of link and node metrics). Encoding of the maximum,
   minimum, range, and granularity of the metrics are needed. Also, the
   definitions of comparison and accumulation operators are required. In
   addition, suitable triggers must be defined for indicating a
   significant change from a minor change.  The former will cause a
   routing update to be generated. The stability of the QoS routes would




Crawley, et. al.             Informational                      [Page 9]

RFC 2386           A Framework for QoS-based Routing         August 1998


   depend on the ability to control the generation of updates. With
   interdomain routing, it is essential to obtain a fairly stable view
   of the interconnection among the ASs.

3.6.2  Metric Hierarchy

   A hierarchy can be defined among various classes of service based on
   the degree to which traffic from one class can potentially degrade
   service of traffic from lower classes that traverse the same link. In
   this hierarchy, guaranteed constant bit rate traffic is at the top
   and "best-effort" datagram traffic at the bottom.  Classes providing
   service higher in the hierarchy impact classes providing service in
   lower levels. The same situation is not true in the other direction.
   For example, a datagram flow cannot affect a real-time service. Thus,
   it may be necessary to distribute and update different metrics for
   each type of service in the worst case.  But, several advantages
   result by identifying a single default metric.  For example, one
   could derive a single metric combining the availability of datagram
   and real-time service over a common substrate.

3.6.3  Datagram Flows

   A delay-sensitive metric is probably the most obvious type of metric
   suitable for datagram flows. However, it requires careful analysis to
   avoid instabilities and to reduce storage and bandwidth requirements.
   For example, a recursive filtering technique based on a simple and
   efficient weighted averaging algorithm [NC94] could be used. This
   filter is used to stabilize the metric. While it is adequate for
   smoothing most loading patterns, it will not distinguish between
   patterns consisting of regular bursts of traffic and random loading.
   Among other stabilizing tools, is a minimum time between updates that
   can help filter out high-frequency oscillations.

3.6.4 Real-time Flows

   In real-time quality-of-service, delay variation is generally more
   critical than delay as long as the delay is not too high.  Clearly,
   voice-based applications cannot tolerate more than a certain level of
   delay. The condition of varying delays may be expected to a greater
   degree in a shared medium environment with datagrams, than in a