rfc1322.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 1,376 行 · 第 1/5 页

      always be bound by the complexity requirements outlined earlier
      [Foonote: As discussed earlier, theoretically the state overhead
      could grow O(N^2) with the number of domains in an internet.
      However, there is no evidence or intuition to suggest that
      this will be a limiting factor on the wide utilization of SDR,
      provided that NR is available to handle generic routes.].



Estrin, Rekhter & Hotz                                         [Page 10]

RFC 1322       A Unified Approach to Inter-Domain Routing       May 1992


2.4 Support for TOS Routing

   Throughout this document we refer to support for type of service
   (TOS) routing.  There is a great deal of research and development
   activity currently underway to explore network architectures and
   protocols for high-bandwidth, multimedia traffic.  Some of this
   traffic is delay sensitive, while some requires high throughput.  It
   is unrealistic to assume that a single communication fabric will be
   deployed homogeneously across the internet (including all
   metropolitan, regional, and backbone networks) that will support all
   types of traffic uniformly.  To support diverse traffic requirements
   in a heterogeneous environment, various resource management
   mechanisms will be used in different parts of the global internet
   (e.g., resource reservation of various kinds) [ST2-90, Zhang91].

   In this context, it is the job of routing protocols to locate routes
   that can potentially support the particular TOS requested.  It is
   explicitly not the job of the general routing protocols to locate
   routes that are guaranteed to have resources available at the
   particular time of the route request.  In other words, it is not
   practical to assume that instantaneous resource availability will be
   known at all remote points in the global internet.  Rather, once a
   TOS route has been identified, an application requiring particular
   service guarantees will attempt to use the route (e.g., using an
   explicit setup message if so required by the underlying networks).
   In Section 4 we describe additional services that may be provided to
   support more adaptive route selection for special TOS [Footnote:
   Adaptive route selection implies adaptability only during the route
   selection process.  Once a route is selected, it is not going to be a
   subject to any adaptations, except when it becomes infeasible.].

2.5 Commonality between Routing Components

   While it is acceptable for the NR and SDR components to be
   dissimilar, we do recognize that such a solution is less desirable --
   all other things being equal.  In theory, there are advantages in
   having the NR and SDR components use similar algorithms and
   mechanisms.  Code and databases could be shared and the architecture
   would be more manageable and comprehensible.  On the other hand,
   there may be some benefit (e.g., robustness) if the two parts of the
   architecture are heterogeneous, and not completely inter-dependent.
   In Section 5 we list several areas in which opportunities for
   increased commonality (unification) will be exploited.

2.6 Interaction with Addressing

   The proposed architecture should be applicable to various addressing
   schemes.  There are no specific assumptions about a particular



Estrin, Rekhter & Hotz                                         [Page 11]

RFC 1322       A Unified Approach to Inter-Domain Routing       May 1992


   address structure, except that this structure should facilitate
   information aggregation, without forcing rigid hierarchical routing.

   Beyond this requirement, most of the proposals for extending the IP
   address space, for example, can be used in conjunction with our
   architecture.  But our architecture itself does not provide (or
   impose) a particular solution to the addressing problem.












































Estrin, Rekhter & Hotz                                         [Page 12]

RFC 1322       A Unified Approach to Inter-Domain Routing       May 1992


3.0 Design Choices for Node Routing (NR)

   This section addresses the design choices made for the NR component
   in light of the above architectural requirements and priorities.  All
   of our discussion of NR assumes hop-by-hop routing.  Source routing
   is subject to different constraints and is used for the complementary
   SDR component.

3.1 Overview of NR

   The NR component is designed and optimized for an environment where a
   large percentage of packets will travel over routes that can be
   shared by multiple sources and that have predictable traffic
   patterns.  The efficiency of the NR component improves when a number
   of source domains share a particular route from some intermediate
   point to a destination.  Moreover, NR is best suited to provide
   routing for inter-domain data traffic that is either steady enough to
   justify the existence of a route, or predictable, so that a route may
   be installed when needed (based on the prediction, rather than on the
   actual traffic).  Such routes lend themselves to distributed route
   computation and installation procedures.

   Routes that are installed in routers, and information that was used
   by the routers to compute these routes, reflect the known operational
   state of the routing facilities (as well as the policy constraints)
   at the time of route computation.  Route computation is driven by
   changes in either operational status of routing facilities or policy
   constraints.  The NR component supports route computation that is
   dynamically adaptable to both changes in topology and policy.  The NR
   component allows time-dependent selection or deletion of routes.
   However, time dependency must be predictable (e.g., advertising a
   certain route only after business hours) and routes should be used
   widely enough to warrant inclusion in NR.

   The proposed architecture assumes that most of the inter-domain
   conversations will be forwarded via routes computed and installed by
   the NR component.

   Moreover, the exchange of routing information necessary for the SDR
   component depends on facilities provided by the NR component; i.e.,
   NR policies must allow SDR reachability information to travel.
   Therefore, the architecture requires that all domains in an internet
   implement and participate in NR.  Since scalability (with respect to
   the size of the internet) is one of the fundamental requirements for
   the NR component, it must provide multiple mechanisms with various
   degrees of sophistication for information aggregation and
   abstraction.




Estrin, Rekhter & Hotz                                         [Page 13]

RFC 1322       A Unified Approach to Inter-Domain Routing       May 1992


   The potential reduction of routing and forwarding information depends
   very heavily on the way addresses are assigned and how domains and
   their confederations are structured.  "If there is no correspondence
   between the address registration hierarchy and the organisation of
   routeing domains, then ... each and every routeing domain in the OSIE
   would need a table entry potentially at every boundary IS of every
   other routeing domain" ([Oran89]).  Indeed, scaling in the NR
   component is almost entirely predicated on the assumption that there
   will be general correspondence between the hierarchy of address
   assignment authorities and the way routing domains are organised, so
   that the efficient and frequent aggregation of routing and forwarding
   information will be possible.  Therefore, given the nature of inter-
   domain routing in general, and the NR component in particular,
   scalability of the architecture depends very heavily on the
   flexibility of the scheme for information aggregation and
   abstraction, and on the preconditions that such a scheme imposes.
   Moreover, given a flexible architecture, the operational efficiency
   (scalability) of the global internet, or portions thereof, will
   depend on tradeoffs made between flexibility and aggregation.

   While the NR component is optimized to satisfy the common case
   routing requirements for an extremely large population of users, this
   does not imply that routes produced by the NR component would not be
   used for different types of service (TOS).  To the contrary, if a TOS
   becomes sufficiently widely used (i.e., by multiple domains and
   predictably over time), then it may warrant being computed by the NR
   component.

   To summarize, the NR component is best suited to provide routes that
   are used by more than a single domain.  That is, the efficiency of
   the NR component improves when a number of source domains share a
   particular route from some intermediate point to a destination.
   Moreover, NR is best suited to provide routing for inter-domain data
   traffic that is either steady enough to justify the existence of a
   route, or predictable, so that a route may be installed when needed,
   (based on the prediction, rather than on the actual traffic).

3.2 Routing Algorithm Choices for NR

   Given that a NR component based on hop-by-hop routing is needed to
   provide scalable, efficient inter-domain routing, the remainder of
   this section considers the fundamental design choices for the NR
   routing algorithm.

   Typically the debate surrounding routing algorithms focuses on link
   state and distance vector protocols.  However, simple distance vector
   protocols (i.e., Routing Information Protocol [Hedrick88]), do not
   scale because of convergence problems.  Improved distance vector



Estrin, Rekhter & Hotz                                         [Page 14]

RFC 1322       A Unified Approach to Inter-Domain Routing       May 1992


   protocols, such as those discussed in [Jaffee82, Zaumen91, Shin87],
   have been developed to address this issue using synchronization
   mechanisms or additional path information.  In the case of inter-
   domain routing, having additional path information is essential to
   supporting policy.  Therefore, the algorithms we consider for NR are
   link state and one we call path vector (PV).  Whereas the
   characteristics of link state algorithms are generally understood
   (for example, [Zaumen 91]), we must digress from our evaluation
   discussion to describe briefly the newer concept of the PV algorithm
   [Footnote: We assume that some form of SPF algorithm will be used to
   compute paths over the topology database when LS algorithms are used
   [Dijkstra59, OSPF]].

3.2.1 Path Vector Protocol Overview

   The Border Gateway Protocol (BGP) (see [BGP91]) and the Inter Domain
   Routing Protocol (IDRP) (see [IDRP91]) are examples of path vector
   (PV) protocols [Footnote: BGP is an inter-autonomous system routing
   protocol for TCP/IP internets.  IDRP is an OSI inter-domain routing
   protocol that is being progressed toward standardization within ISO.
   Since in terms of functionality BGP represents a proper subset of
   IDRP, for the rest of the paper we will only consider IDRP.].

   The routing algorithm employed by PV bears a certain resemblance to
   the traditional Bellman-Ford routing algorithm in the sense that each
   border router advertises the destinations it can reach to its
   neighboring BRs.  However,the PV routing algorithm augments the
   advertisement of reachable destinations with information that
   describes various properties of the paths to these destinations.

   This information is expressed in terms of path attributes.  To
   emphasize the tight coupling between the reachable destinations and
   properties of the paths to these destinations, PV defines a route as
   a pairing between a destination and the attributes of the path to
   that destination.  Thus the name, path-vector protocol, where a BR
   receives from its neighboring BR a vector that contains paths to a
   set of destinations [Footnote: The term "path-vector protocol" bears
   an intentional similarity to the term "distance-vector protocol",