rfc2386.txt

<VC++网络游戏建摸与实现>源代码

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


5.1 Interdomain QoS-Based Routing Model

   The interdomain QoS-based routing model is depicted below:

          AS1                   AS2             AS3
      ___________        _____________      ____________
     |           |      |             |    |            |
     |           B------B             B----B            |
     |           |      |             |    |            |
      -----B-----       B-------------      --B---------
            \         /                      /
             \       /                      /
          ____B_____B____         _________B______
         |               |       |                |
         |               B-------B                |
         |               |       |                |
         |               B-------B                |
          ---------------         ----------------
               AS4                           AS5

   Here, ASs exchange standardized routing information via border nodes
   B.  Under this model, each AS can itself consist of a set of
   interconnected ASs, with standardized routing interaction. Thus, the
   interdomain routing model is hierarchical.  Also, each lowest level
   AS employs an intradomain QoS-based routing scheme (proprietary or
   standardized by intradomain routing efforts such as QOSPF). Given
   this structure, some questions that arise are:

   - What information is exchanged between ASs?

   - What routing capabilities does the information exchange lead to?
     (E.g., source routing, on-demand path computation, etc.)

   - How is the external routing information represented within an AS?

   - How are interdomain paths computed?

   - What sort of policy controls may be exerted on interdomain path
     computation and flow routing?, and

   - How is interdomain QoS-based multicast routing accomplished?

   At a high level, the answers to these questions depend on the routing
   paradigm. Specifically, considering link state routing, the
   information exchanged between domains would consist of an abstract
   representation of the domains in the form of logical nodes and links,
   along with metrics that quantify their properties and resource
   availability.  The hierarchical structure of the ASs may be handled



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


   by a hierarchical link state representation, with appropriate metric
   aggregation.

   Link state routing may not necessarily be advantageous for
   interdomain routing for the following reasons:

   - One advantage of intradomain link state routing is that it would
     allow fairly detailed link state information be used to compute
     paths on demand for flows requiring QoS. The state and metric
     aggregation used in interdomain routing, on the other hand, erodes
     this property to a great degree.

   - The usefulness of keeping track of the abstract topology and
     metrics of a remote domain, or the interconnection between remote
     domains is not obvious. This is especially the case when the remote
     topology and metric encoding are lossy.

   - ASs may not want to advertise any details of their internal
     topology or resource availability.

   - Scalability in interdomain routing can be achieved only if
     information exchange between domains is relatively infrequent.
     Thus, it seems practical to limit information flow between domains
     as much as possible.

   Compact information flow allows the implementation QoS-enhanced
   versions of existing interdomain protocols such as BGP-4. We look at
   the interdomain routing issues in this context.

5.2  Interdomain Information Flow

   The information flow between routing domains must enable certain
   basic functions:

   1.  Determination of reachability to various destinations

   2.  Loop-free flow routes

   3.  Address aggregation whenever possible

   4.  Determination of the QoS that will be supported on the path to a
       destination. The QoS information should be relatively static,
       determined from the engineered topology and capacity of an AS
       rather than ephemeral fluctuations in traffic load through the
       AS. Ideally, the QoS supported in a transit AS should be allowed
       to vary significantly only under exceptional circumstances, such
       as failures or focused overload.




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


   5.  Determination, optionally, of multiple paths for a given
       destination, based on service classes.

   6.  Expression of routing policies, including monetary cost, as a
       function of flow parameters, usage and administrative factors.

   Items 1-3 are already part of existing interdomain routing. Item 5 is
   also a straightfoward extension of the current model. The main
   problem areas are therefore items 4 and 6.

   The QoS of an end-to-end path is obtained by composing the QoS
   available in each transit AS.  Thus, border routers must first
   determine what the locally available QoS is in order to advertise
   routes to both internal and external destinations. The determination
   of local "AS metrics" (corresponding to link metrics in the
   intradomain case) should not be subject to too much dynamism. Thus,
   the issue is how to define such metrics and what triggers an
   occasional change that results in re-advertisements of routes.

   The approach suggested in this document is not to compute paths based
   on residual or instantaneous values of AS metics (which can be
   dynamic), but utilize only the QoS capabilities engineered for
   aggregate transit flows.  Such engineering may be based on the
   knowledge of traffic to be expected from each neighboring ASs and the
   corresponding QOS needs.  This information may be obtained based on
   contracts agreed upon prior to the provisioning of services. The AS
   metric then corresponds to the QoS capabilities of the "virtual path"
   engineered through the AS (for transit traffic) and a different
   metric may be used for different neighbors. This is illustrated in
   the following figure.

          AS1                   AS2             AS3
      ___________        _____________      ____________
     |           |      |             |    |            |
     |           B------B1           B2----B            |
     |           |      |             |    |            |
      -----B-----       B3------------      --B---------
            \         /
             \       /
          ____B_____B____
         |               |
         |               |
         |               |
         |               |
          ---------------
               AS4





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


   Here, B1 may utilize an AS metric specific for AS1 when computing
   path metrics to be  advertised to AS1. This metric is based on the
   resources engineered in AS2 for transit traffic from AS1. Similarly,
   B3 may utilize a different metric when computing path metrics to be
   advertised to AS4.  Now, it is assumed that as long as traffic flow
   into AS2 from AS1 or AS4 does not exceed the engineered values, these
   path metrics would hold.  Excess traffic due to transient
   fluctuations, however, may be handled as best effort or marked with a
   discard bit.

   Thus, this model is different from the intradomain model, where end
   nodes pick a path dynamically based on the QoS needs of the flow to
   be routed.  Here, paths within ASs are engineered based on presumed,
   measured or declared traffic and QoS requirements. Under this model,
   an AS can contract for routes via multiple transit ASs with different
   QoS requirements. For instance, AS4 above can use both AS1 and AS2 as
   transits for same or different destinations. Also, a QoS contract
   between one AS and another may generate another contract between the
   second and a third AS and so forth.

   An issue is what triggers the recomputation of path metrics within an
   AS.  Failures or other events that prevent engineered resource
   allocation should certainly trigger recomputation. Recomputation
   should not be triggered in response to arrival of flows within the
   engineered limit.

5.3   Path Computation

   Path computation for an external destination at a border node is
   based on reachability, path metrics and local policies of selection.
   If there are multiple selection criteria (e.g., delay, bandwidth,
   cost, etc.), mutiple alternaives may have to be maintained as well as
   propagated by border nodes. Selection of a path from among many
   alternatives would depend on the QoS requests of flows, as well as
   policies. Path computation may also utilze any heuristics for
   optimizing resource usage.

5.4  Flow Aggregation

   An important issue in interdomain routing is the amount of flow state
   to be processed by transit ASs. Reducing the flow state by
   aggregation techniques must therefore be seriously considered. Flow
   aggregation means that transit traffic through an AS is classified
   into a few aggregated streams rather than being routed at the
   individual flow level. For example, an entry border router may
   classify various transit flows entering an AS into a few coarse
   categories, based on the egress node and QoS requirements of the
   flows.  Then, the aggregated stream for a given traffic class may be



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


   routed as a single flow inside the AS to the exit border router. This
   router may then present individual flows to different neighboring ASs
   and the process repeats at each entry border router. Under this
   scenario, it is essential that entry border routers keep track of the
   resource requirements for each transit flow and apply admission
   control to determine whether the aggregate requirement from any
   neighbor exceeds the engineered limit. If so, some policy must be
   invoked to deal with the excess traffic. Otherwise, it may be assumed
   that aggregated flows are routed over paths that have adequate
   resources to guarantee QoS for the member flows. Finally, it is
   possible that entry border routers at a transit AS may prefer not to
   aggregate flows if finer grain routing within the AS may be more
   efficient (e.g., to aid load balancing within the AS).

5.5   Path Cost Determination

   It is hoped that the integrated services Internet architecture would
   allow providers to charge for IP flows based on their QoS
   requirements.  A QoS-based routing architecture can aid in
   distributing information on expected costs of routing flows to
   various destinations via different domains. Clearly, from a
   provider's point of view, there is a cost incurred in guaranteeing
   QoS to flows.  This cost could be a function of several parameters,
   some related to flow parameters, others based on policy. From a
   user's point of view, the consequence of requesting a particular QoS
   for a flow is the cost incurred, and hence the selection of providers
   may be based on cost. A routing scheme can aid a provider in
   distributing the costs in routing to various destinations, as a
   function of several parameters, to other providers or to end users.
   In the interdomain routing model described earlier, the costs to a
   destination will change as routing updates are passed through a
   transit domain. One of the goals of the routing scheme should be to
   maintain a uniform semantics for cost values (or functions) as they
   are handled by intermediate domains. As an example, consider the cost
   function generated by border node B1 in domain A and passed to node
   B2 in domain B below.  The routing update may be injected into domain
   B by B2 and finally passed to B4 in domain C by router B3. Domain B
   may interpret the cost value received from domain A in any way it
   wants, for instance, adding a locally significant component to it.
   But when this cost value is passed to domain C, the meaning of it
   must be what domain A intended, plus the incremental cost of
   transiting domain B, but not what domain B uses internally.