rfc2386.txt

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

Network Working Group                                       E. Crawley
Request for Comments: 2386                              Argon Networks
Category: Informational                                        R. Nair
                                                            Arrowpoint
                                                        B. Rajagopalan
                                                               NEC USA
                                                            H. Sandick
                                                          Bay Networks
                                                           August 1998


           A Framework for QoS-based Routing in the Internet

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

ABSTRACT

   QoS-based routing has been recognized as a missing piece in the
   evolution of QoS-based service offerings in the Internet. This
   document describes some of the QoS-based routing issues and
   requirements, and proposes a framework for QoS-based routing in the
   Internet. This framework is based on extending the current Internet
   routing model of intra and interdomain routing to support QoS.

1. SCOPE OF  DOCUMENT & PHILOSOPHY

   This document proposes a framework for QoS-based routing, with the
   objective of fostering the development of an Internet-wide solution
   while encouraging innovations in solving the many problems that
   arise.  QoS-based routing has many complex facets and it is
   recommended that the following two-pronged approach be employed
   towards its development:

    1. Encourage the growth and evolution of novel intradomain QoS-based
       routing architectures. This is to allow the development of
       independent, innovative solutions that address the many QoS-based
       routing issues. Such solutions may be deployed in autonomous
       systems (ASs), large and small, based on their specific needs.





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


    2. Encourage simple, consistent and stable interactions between ASs
       implementing routing solutions developed as above.

   This approach follows the traditional separation between intra and
   interdomain routing. It allows solutions like QOSPF [GKOP98, ZSSC97],
   Integrated PNNI [IPNNI] or other schemes to be deployed for
   intradomain routing without any restriction, other than their ability
   to interact with a common, and perhaps simple, interdomain routing
   protocol. The need to develop a single, all encompassing solution to
   the complex problem of QoS-based routing is therefore obviated. As a
   practical matter, there are many different views on how QoS-based
   routing should be done. Much overall progress can be made if an
   opportunity exists for various ideas to be developed and deployed
   concurrently, while some consensus on the interdomain routing
   architecture is being developed.  Finally, this routing model is
   perhaps the most practical from an evolution point of view. It is
   superfluous to say that the eventual success of a QoS-based Internet
   routing architecture would depend on the ease of evolution.

   The aim of this document is to describe the QoS-based routing issues,
   identify basic requirements on intra and interdomain routing, and
   describe an extension of the current interdomain routing model to
   support QoS. It is not an objective of this document to specify the
   details of intradomain QoS-based routing architectures.  This is left
   up to the various intradomain routing efforts that might follow.  Nor
   is it an objective to specify the details of the interface between
   reservation protocols such as RSVP and QoS-based routing. The
   specific interface functionality needed, however, would be clear from
   the intra and interdomain routing solutions devised.  In the
   intradomain area, the goal is to develop the basic routing
   requirements while allowing maximum freedom for the development of
   solutions. In the interdomain area, the objectives are to identify
   the QoS-based routing functions, and facilitate the development or
   enhancement of a routing protocol that allows relatively simple
   interaction between domains.

   In the next section, a glossary of relevant terminology is given. In
   Section 3, the objectives of QoS-based routing are described and the
   issues that must be dealt with by QoS-based Internet routing efforts
   are outlined. In Section 4, some requirements on intradomain routing
   are defined. These requirements are purposely broad, putting few
   constraints on solution approaches. The interdomain routing model and
   issues are described in Section 5 and QoS-based multicast routing is
   discussed in Section 6.  The interaction between QoS-based routing
   and resource reservation protocols is briefly considered in Section
   7. Security considerations are listed in Section 8 and related work
   is described in Section 9. Finally, summary and conclusions are
   presented in Section 10.



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


2.  GLOSSARY

   The following glossary lists the terminology used in this document
   and an explanation of what is meant. Some of these terms may have
   different connotations, but when used in this document, their meaning
   is as given.

   Alternate Path Routing : A routing technique where multiple paths,
   rather than just the shortest path, between a source and a
   destination are utilized to route traffic. One of the objectives of
   alternate path routing is to distribute load among multiple paths in
   the network.

   Autonomous System (AS): A routing domain which has a common
   administrative authority and consistent internal routing policy. An
   AS may employ multiple intradomain routing protocols internally and
   interfaces to other ASs via a common interdomain routing protocol.

   Source: A host or router that can be identified by a unique unicast
   IP address.

   Unicast destination: A host or router that can be identified by a
   unique unicast IP address.

   Multicast destination: A multicast IP address indicating all hosts
   and routers that are members of the corresponding group.

   IP flow (or simply "flow"): An IP packet stream from a source to a
   destination (unicast or multicast) with an associated Quality of
   Service (QoS) (see below) and higher level demultiplexing
   information. The associated QoS could be "best-effort".

   Quality-of-Service (QoS): A set of service requirements to be met by
   the network while transporting a flow.

   Service class: The definitions of the semantics and parameters of a
   specific type of QoS.

   Integrated services:  The Integrated Services model for the Internet
   defined in RFC 1633 allows for integration of QoS services with the
   best effort services of the Internet.  The Integrated Services
   (IntServ) working group in the IETF has defined two service classes,
   Controlled Load Service [W97] and Guaranteed Service [SPG97].

   RSVP:  The ReSerVation Protocol [BZBH97].  A QoS signaling protocol
   for the Internet.

   Path: A unicast or multicast path.



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


   Unicast path: A sequence of links from an IP source to a unicast IP
   destination, determined by the routing scheme for forwarding packets.

   Multicast path (or Multicast Tree): A subtree of the network topology
   in which all the leaves and zero or more interior nodes are members
   of the same multicast group. A multicast path may be per-source, in
   which case the subtree is rooted at the source.

   Flow set-up: The act of establishing state in routers along a path to
   satisfy the QoS requirement of a flow.

   Crankback: A technique where a flow setup is recursively backtracked
   along the partial flow path up to the first node that can determine
   an alternative path to the destination.

   QoS-based routing: A routing mechanism under which paths for flows
   are determined based on some knowledge of resource availability in
   the network as well as the QoS requirement of flows.

   Route pinning: A mechanism to keep a flow path fixed for a duration
   of time.

   Flow Admission Control (FAC): A process by which it is determined
   whether a link or a node has sufficient resources to satisfy the QoS
   required for a flow. FAC is typically applied by each node in the
   path of a flow during flow set-up to check local resource
   availability.

   Higher-level admission control: A process by which it is determined
   whether or not a flow set-up should proceed, based on estimates and
   policy requirements of the overall resource usage by the flow.
   Higher-level admission control may result in the failure of a flow
   set-up even when FAC at each node along the flow path indicates
   resource availability.

3.  QOS-BASED ROUTING: BACKGROUND AND ISSUES

3.1  Best-Effort and QoS-Based Routing

   Routing deployed in today's Internet is focused on connectivity and
   typically supports only one type of datagram service called "best
   effort" [WC96]. Current Internet routing protocols, e.g. OSPF, RIP,
   use "shortest path routing", i.e. routing that is optimized for a
   single arbitrary metric, administrative weight or hop count. These
   routing protocols are also "opportunistic," using the current
   shortest path or route to a destination. Alternate paths with
   acceptable but non-optimal cost can not be used to route traffic
   (shortest path routing protocols do allow a router to alternate among



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


   several equal cost paths to a destination).

   QoS-based routing must extend the current routing paradigm in three
   basic ways.  First, to support traffic using integrated-services
   class of services, multiple paths between node pairs will have to be
   calculated. Some of these new classes of service will require the
   distribution of additional routing metrics, e.g. delay, and available
   bandwidth. If any of these metrics change frequently, routing updates
   can become more frequent thereby consuming network bandwidth and
   router CPU cycles.

   Second, today's opportunistic routing will shift traffic from one
   path to another as soon as a "better" path is found.  The traffic
   will be shifted even if the existing path can meet the service
   requirements of the existing traffic.  If routing calculation is tied
   to frequently changing consumable resources (e.g. available
   bandwidth) this change will happen more often and can introduce
   routing oscillations as traffic shifts back and forth between
   alternate paths. Furthermore, frequently changing routes can increase
   the variation in the delay and jitter experienced by the end users.

   Third, as mentioned earlier, today's optimal path routing algorithms
   do not support alternate routing.   If the best existing path cannot
   admit a new flow, the associated traffic cannot be forwarded even if
   an adequate alternate path exists.

3.2 QoS-Based Routing and Resource Reservation

   It is important to understand the difference between QoS-based
   routing and resource reservation.  While resource reservation
   protocols such as RSVP [BZBH97] provide a method for requesting and
   reserving network resources, they do not provide a mechanism for
   determining a network path that has adequate resources to accommodate
   the requested QoS.  Conversely, QoS-based routing allows the
   determination of a path that has a good chance of accommodating the
   requested QoS, but it does not include a mechanism to reserve the
   required resources.

   Consequently, QoS-based routing is usually used in conjunction with
   some form of resource reservation or resource allocation mechanism.
   Simple forms of QoS-based routing have been used in the past for Type
   of Service (TOS) routing [M98].  In the case of OSPF, a different
   shortest-path tree can be computed for each of the 8 TOS values in
   the IP header [ISI81]. Such mechanisms can be used to select
   specially provisioned paths but do not completely assure that