rfc1126.txt

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

Network Working Group                                          M. Little
Request for Comments:  1126                                         SAIC
                                                            October 1989


                 Goals and Functional Requirements for
                    Inter-Autonomous System Routing

Status of this Memo

   This document describes the functional requirements for a routing
   protocol to be used between autonomous systems.  This document is
   intended as a necessary precursor to the design of a new inter-
   autonomous system routing protocol and specifies requirements for the
   Internet applicable for use with the current DoD IP, the ISO IP, and
   future Internet Protocols.  It is intended that these requirements
   will form the basis for the future development of a new inter-
   autonomous systems routing architecture and protocol.  This document
   is being circulated to the IETF and Internet community for comment.
   Comments should be sent to: "[e-mail]".  This memo
   does not specify a standard.  Distribution of this memo is unlimited.

1.  Introduction

   The development of an inter-autonomous systems routing protocol
   proceeds from those goals and functions seen as both desirable and
   obtainable for the Internet environment.  This document describes
   these goals and functional requirements.  The goals and functional
   requirements addressed by this document are intended to provide a
   context within which an inter-autonomous system routing architecture
   can be developed which will meet both current and future Internet
   routing needs.  The goals presented indicate properties and general
   capabilities desired of the Internet routing environment and what the
   inter-autonomous system routing architecture is to accomplish as a
   whole.

   The goals are followed by functional requirements, which address
   either detailed objectives or specific functionality to be achieved
   by the architecture and resulting protocol(s).  These functional
   requirements are enumerated for clarity and grouped so as to map
   directly to areas of architectural consideration.  This is followed
   by a listing and description of general objectives, such as
   robustness, which are applicable in a broad sense.  Specific
   functions which are not reasonably attainable or best left to future
   efforts are identified as non-requirements.

   The intent of this document is to provide both the goals and
   functional requirements in a concise fashion.  Supporting arguments,



Little                                                          [Page 1]

RFC 1126            Inter-Autonomous System Routing         October 1989


   tradeoff considerations and the like have been purposefully omitted
   in support of this.  An appendix has been included which addresses
   this omission to a limited extent and the reader is directed there
   for a more detailed discussion of the issues involved.

   The goals and functional requirements contained in this document are
   the result of work done by the members of the Open Routing Working
   Group.  It is our intention that these goals and requirements reflect
   not only those foreseen in the Internet community but are also
   similar to those encountered in environments proposed by ANSI, ECMA
   and ISO.  It is expected that there will be some interaction and
   relationship between this work and the product of these groups.

2.  Overall Goals

   In order to derive a set functional requirements there must be one or
   more principals or overall goals for the routing environment to
   satisfy.  These high level goals provide the basis for each of the
   functional requirements we have derived and will guide the design
   philosophy for achieving an inter-autonomous system routing solution.
   The overall goals we are utilizing are described in the following
   sections.

2.1  Route to Destination

   The routing architecture will provide for the routing of datagrams
   from a single source to one or more destinations in a timely manner.
   The larger goal is to provide datagram delivery to an identifiable
   destination, one which is not necessarily immediately reachable by
   the source.  In particular, routing is to address the needs of a
   single source requiring datagram delivery to one or more
   destinations.  The concepts of multi-homed hosts and multicasting
   routing services are encompassed by this goal.  Datagram delivery is
   to be provided to all interconnected systems when not otherwise
   constrained by autonomous considerations.

2.2  Routing is Assured

   Routing services are to be provided with assurance, where the
   inability to provide a service is communicated under best effort to
   the requester within an acceptable level of error.  This assurance is
   not to be misconstrued to mean guaranteed datagram delivery nor does
   it imply error notification for every lost datagram.  Instead,
   attempts to utilize network routing services when such service cannot
   be provided will result in requester notification within a reasonable
   period given persistent attempts.





Little                                                          [Page 2]

RFC 1126            Inter-Autonomous System Routing         October 1989


2.3  Large System

   The design of the architecture, and the protocols within this
   architecture, should accommodate a large number of routing entities.
   The exact order of magnitude is a relative guess and the best designs
   would provide for a practical level of unbounded growth.
   Nevertheless, the routing architecture is expected to accommodate the
   growth of the Internet environment for the next 10 years.

2.4  Autonomous Operation

   The routing architecture is to allow for stable operation when
   significant portions of the internetworking environment are
   controlled by disjoint entities.  The future Internet environment is
   envisioned as consisting of a large number of internetworking
   facilities owned and operated by a variety of funding sources and
   administrative concerns.  Although cooperation between these
   facilities is necessary to provide interconnectivity, it is viewed
   that both the degree and type of cooperation will vary widely.
   Additionally, each of these internetworking facilities desires to
   operate as independently as possible from the concerns and activities
   of other facilities individually and the interconnection environment
   as a whole.  Those resources used by (and available for) routing are
   to be allowed autonomous control by those administrative entities
   which own or operate them. Specifically, each controlling
   administration should be allowed to establish and maintain policies
   regarding the use of a given routing resource.

2.5  Distributed System

   The routing environment developed should not depend upon a data
   repository or topological entity which is either centralized or
   ubiquitous.  The growth pattern of the Internet, coupled with the
   need for autonomous operation, dictates an independence from the
   topological and administrative centralization of both data and
   control flows.  Past experience with a centralized topology has shown
   that it is both impractical for the needs of the community and
   restrictive of administrative freedoms.  A distributed routing
   environment should not be restrictive of either redundancy or
   diversity.  Any new routing environment must allow for arbitrary
   interconnection between internetworks.

2.6  Provide A Credible Environment

   The routing environment and services should be based upon mechanisms
   and information that exhibit both integrity and security.  The
   routing mechanisms should operate in a sound and reliable fashion
   while the routing information base should provide credible data upon



Little                                                          [Page 3]

RFC 1126            Inter-Autonomous System Routing         October 1989


   which to base routing decisions.  The environment can be unreliable
   to the extent that the resulting effect on routing services is
   negligible.  The architecture and protocol designs should be such
   that the routing environment is reasonably secure from unwanted
   modification or influence.

2.7  Be A Managed Entity

   Provide a manger insight into the operation of the inter-autonomous
   system routing environment to support resource management, problem
   solving, and fault isolation.  Allow for management control of the
   routing system and collect useful information for the internetwork
   management environment.  Datagram events as well as the content and
   distribution characteristics of relevant databases are of particular
   importance.

2.8  Minimize Required Resources

   Any feasible design should restrain the demand for resources required
   to provide inter-autonomous systems routing.  Of particular interest
   are those resources required for data storage, transmission, and
   processing.  The design must be practical in terms of today's
   technology.  Specifically, do not assume significant upgrades to the
   existing level of technology in use today for data communication
   systems.

3.  Functional Requirements

   The functional requirements we have identified have been derived from
   the overall goals and describe the critical features expected of
   inter-autonomous system routing.  To an extent, these functions are
   vague in terms of detail.  We do not, for instance, specify the
   quantity or types for quality-of-service parameters.  This is
   purposeful, as the functional requirements specified here are
   intended to define the features required of the inter-autonomous
   system routing environment rather than the exact nature of this
   environment.  The functional requirements identified have been
   loosely grouped according to areas of architectural impact.

3.1  Route Synthesis Requirements

   Route synthesis is that functional area concerned with both route
   selection and path determination (identification of a sequence of
   intermediate systems) from a source to a destination.  The functional
   requirements identified here provide for path determination which is
   adaptive to topology changes, responsive to administrative policy,
   cognizant of quality-of-service concerns, and sensitive to an
   interconnected environment of autonomously managed systems.



Little                                                          [Page 4]

RFC 1126            Inter-Autonomous System Routing         October 1989


      a) Route around failures dynamically

         Route synthesis will provide a best effort attempt to detect
         failures in those routing resources which are currently being
         utilized.  Upon detection of a failed resource, route synthesis
         will provide a best effort to utilize other available routing
         resources in an attempt to provide the necessary routing
         service.

      b) Provide loop free paths

         The path provided for a datagram, from source to destination,
         will be free of circuits or loops most of the time.  At those
         times a circuit or loop exists, it occurs with both negligible
         probability and duration.

      c) Know when a path or destination is unavailable

         Route synthesis will be capable of determining when a path
         cannot be constructed to reach a known destination.
         Additionally, route synthesis will be capable of determining
         when a given destination cannot be determined because the
         requested destination is unknown (or this knowledge is
         unavailable).

      d) Provide paths sensitive to administrative policies

         Route synthesis will accommodate the resource utilization
         policies of those administrative entities which manage the
         resources identified by the resulting path.  However, it is
         inconceivable to accommodate all policies which can be defined
         by a managing administrative entity.  Specifically, policies
         dependent upon volatile events of great celerity or those which
         are non-deterministic in nature cannot be accommodated.

      e) Provide paths sensitive to user policies

         Paths produced by route synthesis must be sensitive to policies
         expressed by the user.  These user policies are expressed in
         terms relevant to known characteristics of the topology.  The
         path achieved will meet the requirements stated by the user
         policy.

      f) Provide paths which characterize user quality-of-service
         requirements

         The characteristics of the path provided should match those
         indicated by the quality-of-service requested.  When