doc: Add RFC documents

1 files changed, 1403 insertions, 0 deletions

diff --git a/doc/rfc/rfc1126.txt b/doc/rfc/rfc1126.txt
new file mode 100644
index 0000000..69701fe
--- /dev/null
+++ b/doc/rfc/rfc1126.txt
@@ -0,0 +1,1403 @@
+
+
+
+
+
+
+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: "open-rout-editor@bbn.com".  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
+
+
+
+Little                                                          [Page 5]
+
+RFC 1126            Inter-Autonomous System Routing         October 1989
+
+
+         appropriate, utilize only those resources which can support the
+         desired quality-of-service (e.g., bandwidth).
+
+      g) Provide autonomy between inter- and intra-autonomous system
+         route synthesis
+
+         The inter- and intra-autonomous system routing environments
+         should operate independent of one another.  The architecture
+         and design should be such that route synthesis of either
+         routing environment does not depend upon information from the
+         other for successful functioning.  Specifically, the inter-
+         autonomous system route synthesis design should minimize the
+         constraints on the intra-autonomous system route synthesis
+         decisions when transiting (or delivering to) the autonomous
+         system.
+
+3.2  Forwarding Requirements
+
+   The following requirements specifically address the functionality of
+   the datagram forwarding process.  The forwarding process transfers
+   datagrams to intermediate or final destinations based upon datagram
+   characteristics, environmental characteristics, and route synthesis
+   decisions.
+
+      a) Decouple inter- and intra-autonomous system forwarding
+         decisions
+
+         The requirement is to provide a degree of independence between
+         the inter-autonomous system forwarding decision and the intra-
+         autonomous system forwarding decision within the forwarding
+         process.  Though the forwarding decisions are to be independent
+         of each other, the inter-autonomous system delivery process may
+         necessarily be dependent upon intra-autonomous system route
+         synthesis and forwarding.
+
+      b) Do not forward datagrams deemed administratively inappropriate
+
+         Forward datagrams according to the route synthesis decision if
+         it does not conflict with known policy.  Policy sensitive route
+         synthesis will prevent normally routed datagrams from utilizing
+         inappropriate resources.  However, a datagram routed abnormally
+         due to unknown events or actions can always occur and the only
+         way to prohibit unwanted traffic from entering or leaving an
+         autonomous system is to provide policy enforcement within the
+         forwarding function.
+
+
+
+
+
+
+Little                                                          [Page 6]
+
+RFC 1126            Inter-Autonomous System Routing         October 1989
+
+
+      c) Do not forward datagrams to failed resources
+
+         A datagram is not to be forwarded to a resource known to be
+         unavailable, notably an intermediate system such as a gateway.
+         This implies some ability to detect and react to resource
+         failures.
+
+      d) Forward datagram according to its characteristics
+
+         The datagram forwarding function is to be sensitive to the
+         characteristics of the datagram in order to execute the
+         appropriate route synthesis decision.  Characteristics to
+         consider are the destination, quality-of-service, precedence,
+         datagram (or user) policy, and security.  Note that some
+         characteristics, precedence for example, affect the forwarding
+         service provided whereas others affect the path chosen.
+
+3.3  Information Requirements
+
+   This functional area addresses the general information requirements
+   of the routing environment.  This encompasses both the nature and
+   disbursal of routing information.  The characteristics of the routing
+   information and its disbursal are given by the following functional
+   requirements.
+
+      a) Provide a distributed and descriptive information base
+
+         The information base must not depend upon either centralization
+         or exact replication.  The content of the information base must
+         be sufficient to support all provided routing functionality,
+         specifically that of route synthesis and forwarding.
+         Information of particular importance includes resource
+         characteristics and resource utilization policies.
+
+      b) Determine resource availability
+
+         Provide a means of determining the availability of any utilized
+         resource in a timely manner.  The timeliness of this
+         determination is dependent upon the routing service(s) to be
+         supported.
+
+      c) Restrain transmission utilization
+
+         The dynamics of routing information flow should be such that a
+         significant portion of transmission resources are not consumed.
+         Routing information flow should adjust to the demands of the
+         environment, the capacities of the distribution facilities
+         utilized, and the desires of the resource manager.
+
+
+
+Little                                                          [Page 7]
+
+RFC 1126            Inter-Autonomous System Routing         October 1989
+
+
+      d) Allow limited information exchange
+
+         Information distribution is to be sensitive to administrative
+         policies.  An administrative policy may affect the content or
+         completeness of the information distributed.  Additionally,
+         administrative policy may determine the extent of information
+         distributed.
+
+3.4  Environmental Requirements
+
+   The following items identify those requirements directly related to
+   the nature of the environment within which routing is to occur.
+
+      a) Support a packet-switching environment
+
+         The routing environment should be capable of supporting
+         datagram transfer within a packet-switched oriented networking
+         environment.
+
+      b) Accommodate a connection-less oriented user transport service
+
+         The routing environment should be designed such that it
+         accommodates the model for connection-less oriented user
+         transport service.
+
+      c) Accommodate 10K autonomous systems and 100K networks
+
+         This requirement identifies the scale of the internetwork
+         environment we view as appearing in the future.  A routing
+         design which does not accommodate this order of magnitude is
+         viewed as being inappropriate.
+
+      d) Allow for arbitrary interconnection of autonomous systems
+
+         The routing environment should accommodate interconnectivity
+         between autonomous systems which may occur in an arbitrary
+         manner.  It is recognized that a practical solution is likely
+         to favor a given structure of interconnectivity for reasons of
+         efficiency.  However, a design which does not allow for and
+         utilize interconnectivity of an arbitrary nature would not be
+         considered a feasible design.
+
+3.5  General Objectives
+
+   The following are overall objectives to be achieved by the inter-
+   autonomous routing architecture and its protocols.
+
+      a) Provide routing services in a timely manner
+
+
+
+Little                                                          [Page 8]
+
+RFC 1126            Inter-Autonomous System Routing         October 1989
+
+
+         Those routing services provided, encapsulated by the
+         requirements stated herein, are to be provided in a timely
+         manner.  The time scale for this provision must be reasonable
+         to support those services provided by the internetwork
+         environment as a whole.
+
+      b) Minimize constraints on systems with limited resources
+
+         Allow autonomous systems, or gateways, of limited resources to
+         participate in the inter-autonomous system routing
+         architecture.  This limited participation is not necessarily
+         without cost, either in terms of responsiveness, path
+         optimization, or other factor(s).
+
+      c) Minimize impact of dissimilarities between autonomous systems
+
+         Attempt to achieve a design in which the dissimilarities
+         between autonomous systems do not impinge upon the routing
+         services provided to any autonomous system.
+
+      d) Accommodate the addressing schemes and protocol mechanisms of
+         the autonomous systems
+
+         The routing environment should accommodate the addressing
+         schemes and protocol mechanisms of autonomous systems, where
+         these schemes and mechanisms may differ among autonomous
+         systems.
+
+      e) Must be implementable by network vendors
+
+         This is to say that the algorithms and complexities of the
+         design must be such that they can be understood outside of the
+         research community and implementable by people other than the
+         designers themselves.  Any feasible design must be capable of
+         being put into practice.
+
+4.  Non-Goals
+
+   In view of the conflicting nature of many of the stated goals and the
+   careful considerations and tradeoffs necessary to achieve a
+   successful design, it is important to also identify those goals or
+   functions which we are not attempting to achieve.  The following
+   items are not considered to be reasonable goals or functional
+   requirements at this time and are best left to future efforts. These
+   are non-goals, or non-requirements, within the context of the goals
+   and requirements previously stated by this document as well as our
+   interpretation of what can be practically achieved.
+
+
+
+
+Little                                                          [Page 9]
+
+RFC 1126            Inter-Autonomous System Routing         October 1989
+
+
+      a) Ubiquity
+
+         It is not a goal to design a routing environment in which any
+         participating autonomous system can obtain a routing service to
+         any other participating autonomous system in a ubiquitous
+         fashion.  Within a policy sensitive routing environment, the
+         cooperation of intermediate resources will be necessary and
+         cannot be guaranteed to all participants.  The concept of
+         ubiquitous connectivity will not be a valid one.
+
+      b) Congestion control
+
+         The ability for inter-autonomous system routing to perform
+         congestion control is a non-requirement.  Additional study is
+         necessary to determine what mechanisms are most appropriate and
+         if congestion control is best realized within the inter-AS
+         and/or intra-AS environments, and if both, what the dynamics of
+         the interactions between the two are.
+
+      c) Load splitting
+
+         The functional capability to distribute the flow of datagrams,
+         from a source to a destination, across two or more distinct
+         paths through route synthesis and/or forwarding is a non-
+         requirement.
+
+      d) Maximizing the utilization of resources
+
+         There is no goal or requirement for the inter-autonomous system
+         routing environment to be designed such that it attempts to
+         maximize the utilization of available resources.
+
+      e) Schedule to deadline service
+
+         The ability to support a schedule to deadline routing service
+         is a non-requirement for the inter-autonomous routing
+         environment at this point in time.
+
+      f) Non-interference policies of resource utilization
+
+         The ability to support routing policies based upon the concept
+         of non-interference is a not a requirement.  An example of such
+         a policy is one where an autonomous system allows the
+         utilization of excess bandwidth by external users as long as
+         this does not interfere with local usage of the link.
+
+
+
+
+
+
+Little                                                         [Page 10]
+
+RFC 1126            Inter-Autonomous System Routing         October 1989
+
+
+5.  Considerations
+
+   Although neither a specific goal nor a functional requirement,
+   consideration must be given to the transition which will occur from
+   the current operational routing environment to a new routing
+   environment.  A coordinated effort among all participants of the
+   Internet would be impractical considering the magnitude of such an
+   undertaking.  Particularly, the issues of transitional coexistence,
+   as opposed to phased upgrading between disjoint systems, should be
+   addressed as a means to minimize the disruption of service.  Careful
+   consideration should also be given to any required changes to hosts.
+   It is very unlikely that all hosts could be changed, given historical
+   precedence, their diversity and their large numbers.
+
+Appendix - Issues in Inter-Autonomous Systems Routing
+
+A.0  Acknowledgement
+
+   This appendix is an edited version of the now defunct document
+   entitled "Requirements for Inter-Autonomous Systems Routing", written
+   by Ross Callon in conjunction with the members of the Open Routing
+   Working Group.
+
+A.1  Introduction
+
+   The information and discussion contained here historically precedes
+   that of the main document body and was a major influence on its
+   content.  It is included here as a matter of reference and to provide
+   insight into some of the many issues involved in inter-autonomous
+   systems routing.
+
+   The following definitions are utilized:
+
+      Boundary Gateway
+
+            A boundary gateway is any autonomous system gateway which
+            has a network interface directly reachable from another
+            autonomous system.  As a member of an autonomous system, a
+            boundary gateway participates in the Interior Gateway
+            Protocol and other protocols used for routing (and other
+            purposes) between other gateways of this same autonomous
+            system and between those networks directly reachable by this
+            autonomous system.  A boundary gateway may also
+            participate in an Inter-Autonomous System Routing Protocol.
+            As a participant in the inter-autonomous system routing
+            protocol, a boundary gateway interacts with other boundary
+            gateways in other autonomous systems, either directly or
+            indirectly, in support of the operation of the
+
+
+
+Little                                                         [Page 11]
+
+RFC 1126            Inter-Autonomous System Routing         October 1989
+
+
+            Inter-Autonomous System Routing Protocol.
+
+      Interior Gateway
+
+            An interior gateway is any autonomous system gateway which
+            is not a boundary gateway.  As such, an interior gateway
+            does not have any network interfaces which are directly
+            reachable by any other autonomous system.  An interior
+            gateway is part of an autonomous system and, as such,
+            takes part in the Interior Gateway Protocol and other
+            protocols used in that autonomous system. However, an
+            interior gateway does not directly exchange routing
+            information with gateways in other autonomous systems via
+            the Inter-Autonomous System Routing Protocol.
+
+   The following acronyms are used:
+
+      AS -- Autonomous System
+
+            This document uses the current definition of "Autonomous
+            System": a collection of cooperating gateways running a
+            common interior routing protocol. This implies that networks
+            and hosts may be reachable through one or more Autonomous
+            Systems.
+
+            NOTE: The current notion of "Autonomous System" implicitly
+            assumes that each gateway will belong to exactly one AS.
+            Extensions to allow gateways which belong to no AS's
+            and/or gateways which belong to multiple AS's, are beyond
+            the scope of this discussion. However, we do not preclude
+            the possibility of considering such extensions in the
+            future.
+
+      IARP -- Inter-Autonomous System Routing Protocol
+
+            This is the protocol used between boundary gateways for
+            the purpose of routing between autonomous systems.
+
+      IGP -- Interior Gateway Protocol
+
+            This is the protocol used within an autonomous system for
+            routing within that autonomous system.
+
+A.2  Architectural Issues
+
+   The architecture of an inter-autonomous system routing environment is
+   mutually dependent with the notion of an Autonomous System. In
+   general, the architecture should maximize independence of the
+
+
+
+Little                                                         [Page 12]
+
+RFC 1126            Inter-Autonomous System Routing         October 1989
+
+
+   internals of an AS from the internals of other AS's, as well as from
+   the inter-autonomous system routing protocols (IARP). This
+   independence should allow technological and administrative
+   differences among AS's as well as protection against propagation of
+   misbehavior.  The following issues address ways to achieve
+   interoperation and protection, and to meet certain performance
+   criteria. We also put forth a set of minimal constraints to be
+   imposed among Autonomous Systems, and between inter- and intra-AS
+   functions.
+
+A.2.1  IGP Behavior
+
+   The IARP should be capable of tolerating an Autonomous System in
+   which its IGP is unable to route packets, provides incorrect
+   information, and exhibits unstable behavior.  Interfacing to such an
+   ill-behaved AS should not produce global instabilities within the
+   IARP and the IARP should localize any effects.  On the other hand,
+   the IGP should provide a routing environment where the information
+   and connectivity provided to the IARP from the IGP does not exhibit
+   rapid and continual changes.  An Autonomous System therefore should
+   appear as a relatively stable environment.
+
+A.2.2  Independence of Autonomous Systems
+
+   The IARP should not constrain any AS to require the use any one
+   specific IGP.  This applies both to IGPs and potentially to any other
+   internal protocols.  The architecture should also allow intra-AS
+   routing and organizational structures to be hidden from inter-AS use.
+   An Autonomous System should not be required to use any one specific
+   type of linkage between boundary gateways within the AS.  However,
+   there are some minimal constraints that gateways and the associated
+   interior routing protocol within an AS must meet in order to be able
+   to route Inter-AS traffic, as discussed in Section A.2.6.
+
+A.2.3  General Topology
+
+   The routing architecture should provide significant flexibility
+   regarding the interconnection of AS's.  The specification of IARP
+   should impose no inherent restriction on either interconnection
+   configuration or information passing among autonomous systems. There
+   may be administrative and policy limitations on the interconnection
+   of AS's, and on the extent to which routing information and data
+   traffic may be passed between AS's. However, there should be no
+   inherent restrictions imposed by limitations in the design of the
+   routing architecture.  The architecture should allow arbitrary
+   topological interconnection of Autonomous Systems.  Propagation of
+   routing information should not be restricted by the specification of
+   the IARP.  For example, the restrictions imposed by the "core model"
+
+
+
+Little                                                         [Page 13]
+
+RFC 1126            Inter-Autonomous System Routing         October 1989
+
+
+   used by EGP are not acceptable.
+
+A.2.4  Routing Firewalls
+
+   We expect AS's to have a certain amount of insulation from other
+   AS's.  This protection should apply to both the adequacy and
+   stability of routes produced by the routing scheme, and also to the
+   amount of overhead traffic and other costs necessary to run the
+   routing scheme.  There are several forms which these "routing
+   firewalls" may take:
+
+      -  An AS must be able to successfully route its own internal
+         traffic in the face of arbitrary failures of other IGPs and the
+         IARP.  In other words, the AS should be able to effectively
+         shutout the rest of the world.
+
+      -  The IARP should be able to operate correctly in the face of IGP
+         failures.  In this case, correct operation is defined as
+         recognizing that an AS has failed, and routing around it if
+         possible (traffic to or from that AS may of course fail).
+
+      -  In addition, problems in Inter-AS Routing should, as much as
+         possible, be limited in the extent of their effect.
+
+   Routing firewalls may be explicit, or may be inherent in the design
+   of the algorithms.  We expect that both explicit and inherent
+   firewalls will be utilized.  Examples of firewalls include:
+
+      -  Separating Intra- and Inter-AS Routing to some extent
+         isolates each of these from problems with the other.  Clearly
+         defined interfaces between different modules/protocols provides
+         some degree of protection.
+
+      -  Access control restrictions may provide some degree of
+         firewalls.  For example, some AS's may be non-transit (won't
+         forward transit traffic).  Failures within such AS's may be
+         prevented from affecting traffic not associated with that AS.
+
+      -  Protocol design can help.  For example, with link state routing
+         you can require that both ends must report a link before is may
+         be regarded as up, thereby eliminating the possibility of a
+         single node causing fictitious links.
+
+      -  Finally, explicit firewalls may be employed using explicit
+         configuration information.
+
+
+
+
+
+
+Little                                                         [Page 14]
+
+RFC 1126            Inter-Autonomous System Routing         October 1989
+
+
+A.2.5  Boundary Gateways
+
+   Boundary gateways will exchange Inter-AS Routing information with
+   other boundary gateways using the IARP.  Each AS which is to take
+   part in Inter-AS Routing will have one or more boundary gateways, of
+   which one or more of these boundary gateways exchanges information
+   with peer boundary gateways in other AS's.
+
+   Information related to Inter-AS Routing may be passed between
+   connected boundary gateways in different AS's.  Specific designated
+   boundary gateways will therefore be required to understand the IARP.
+   The external link between the boundary gateways may be accomplished
+   by any kind of connectivity that can be modeled as a direct link
+   between two gateways -- a LAN, an ARPANET, a satellite link, a
+   dedicated line, and so on.
+
+A.2.6  Minimal Constraints on the Autonomous System
+
+   The architectural issues discussed here for inter-AS routing imply
+   certain minimal functional constraints that an AS must satisfy in
+   order to take part in the Inter-AS Routing scheme.  These minimal
+   requirements are described in greater detail in this section. This
+   list of functional constraints is not necessarily complete.
+
+A.2.6.1  Internal Links between Boundary Gateways
+
+   In those cases where an AS may act as a transit AS (i.e., may pass
+   traffic for which neither the source nor the destination is in that
+   AS), the gateways internal to that AS will need to know which
+   boundary gateway is to serve as the exit gateway from that AS. There
+   are several ways in which this may be accomplished:
+
+      1. Boundary gateways are directly connected
+
+      2. "Tunneling" (i) using source routing (ii) using encapsulation
+
+      3. Interior gateways participate (i) limited participation (ii)
+         fully general participation
+
+   With solution (1), the boundary gateways in an AS are directly
+   connected.  This eliminates the need for other gateways in the AS to
+   have any knowledge of Inter-AS Routing.  Transit traffic is passed
+   directly among the boundary gateways of the AS.
+
+   With solution (2), transit traffic may traverse interior gateways,
+   but these interior gateways are protected from any need to have
+   knowledge about Inter-AS routes by means such as source routing or
+   encapsulation.  The boundary gateway by which the packet enters an AS
+
+
+
+Little                                                         [Page 15]
+
+RFC 1126            Inter-Autonomous System Routing         October 1989
+
+
+   determines the boundary gateway which will serve as the exit gateway.
+   This may require that the entrance boundary gateway add a source
+   route to the packet, or encapsulate the packet in another level of IP
+   or gateway-to-gateway header.  This allows boundary gateways to
+   forward data traffic using the appropriate tunnelling technique.
+
+   Finally, with solution (3), the interior gateways have some knowledge
+   of Inter-AS Routing.  At a minimum, the interior gateways would need
+   to know the identity of each boundary gateway, the address(es) that
+   can be reached by that gateway, and the Inter-AS metric associated
+   with the route to that address(es).  If the IARP allows for separate
+   routing for multiple TOS classes, then the information that the
+   interior gateways need to know includes a separate Inter-AS metric
+   for each TOS class.  The Inter-AS metrics are necessary to allow
+   gateways to choose among multiple possible exit boundary gateways.
+   In general, it is not necessary for the Inter-AS metrics to have any
+   relationship with the metric used within an AS for interior routing.
+   The interior gateways do not need to know how to interpret the
+   exterior metrics, except to know that each metric is to be
+   interpreted as an unsigned integer and a lesser value is preferable
+   to a greater value.  It would be possible, but not necessary, for the
+   interior gateways to have full knowledge of the IARP.
+
+   It is not necessary for the Inter-AS Routing architecture to specify
+   which of these solutions are to be used for any particular AS.
+   Rather, it is possible for individual AS's to choose which scheme or
+   combination of schemes to use.  Independence of the IARP from the
+   internal operation of each AS implies that this decision be left up
+   to the internal protocols used in each AS.  The IARP must be able to
+   operate as if the boundary gateways were directly connected.
+
+A.2.6.2  Forwarding of Data from the AS
+
+   The scheme used for forwarding transit traffic across an AS also has
+   implications for the forwarding of traffic which originates within an
+   AS, but whose destination is reachable only from other AS's.  If
+   either of solutions (1) or (2) in Section A.2.6.1 is followed, then
+   it will be sufficient for an interior gateway to forward such traffic
+   to any boundary gateway.  Greater efficiency may optionally be
+   achieved in some cases by providing interior gateways with additional
+   information which will allow them to choose the "best" boundary
+   gateway in some sense.  If solution (3) is followed, then the
+   information passed to interior gateways to allow them to forward
+   transit traffic will also be sufficient to forward traffic
+   originating within that AS.
+
+
+
+
+
+
+Little                                                         [Page 16]
+
+RFC 1126            Inter-Autonomous System Routing         October 1989
+
+
+A.2.6.3  Forwarding of Data to a Destination in the AS
+
+   If a packet whose destination is reachable from an AS arrives at that
+   AS, then it is desired that the interior routing protocol used in
+   that AS be able to successfully deliver the packet without reliance
+   on Inter-AS Routing.  This does not preclude that the Inter-AS
+   Routing protocol will deal with partitioned AS's.
+
+   An AS may have access control, security, and policy restrictions that
+   restrict which data packets may enter or leave the AS. However, for
+   any data packet which is allowed access to the AS, the AS is expected
+   to deliver the packet to its destination without further restrictions
+   between parts of the AS.  In this sense, the internal structure of
+   the AS should not be visible to the IARP.
+
+A.3  Policy Issues
+
+   The interconnection of multiple heterogeneous networks and multiple
+   heterogeneous autonomous systems owned and operated by multiple
+   administrations into a single combined internet is a very complex
+   task.  It is expected that the administrations associated with such
+   an internet will wish to impose a variety of constraints on the
+   operation of the internet.  Specifically, externally imposed routing
+   constraints may include a variety of transit access control,
+   administrative policy, and security constraints.
+
+   Transit access control refers to those access control restrictions
+   which an AS may impose to restrict which traffic the AS is willing to
+   forward.  There are a large number of access control restrictions
+   which one could envision being used.  For example, some AS's may wish
+   to operate only as "non-transit" AS's, that is, they will only
+   forward data traffic which either originates or terminates within
+   that AS.  Other AS's may restrict transit traffic to datagrams which
+   originate within a specified set of source hosts. Restrictions may
+   require that datagrams be associated with specific applications (such
+   as electronic mail traffic only), or that datagrams be associated
+   with specific classes of users.
+
+   Policy restrictions may allow either the source of datagrams, or the
+   organization that is paying for transmission of a datagram, to limit
+   which AS's the datagrams may transit.  For example, an organization
+   may wish to specify that certain traffic originating within their AS
+   should not transit any AS administered by its main competitor.
+
+   Security restrictions on traffic relates to the official security
+   classification level of traffic.  As an example, an AS may specify
+   that all classified traffic is not allowed to leave its AS.
+
+
+
+
+Little                                                         [Page 17]
+
+RFC 1126            Inter-Autonomous System Routing         October 1989
+
+
+   The main problem with producing a routing scheme which is sensitive
+   to transit access control, administrative policy, and security
+   constraints is the associated potential for exponential growth of
+   routes.  For example, suppose that there are 20 packets arriving at a
+   particular gateway, each for the same destination, but subject to a
+   different combination of access control, policy, and security
+   constraints.  It is possible that all 20 packets would need to follow
+   different routes to the destination.
+
+   This explosive growth of routes leads to the question: "Is it
+   practically feasible to deal with complete general external routing
+   constraints?" One approach would allow only a smaller subset of
+   constraints, chosen to provide some useful level of control while
+   allowing minimal impact on the routing protocol.  Further work is
+   needed to determine the feasibility of this approach.
+
+   There is another problem with dealing with transit access control,
+   policy, and security restrictions in a fully general way.
+   Specifically, it is not clear just what the total set of possible
+   restrictions should be.  Efforts to study this issue are currently
+   underway, but are not expected to produce definitive results within a
+   short to medium time frame.  It is therefore not practical to wait
+   for this effort to be finished before defining the next generation of
+   Inter-AS Routing.
+
+A.4  Service Features
+
+   The following paragraphs discuss issues concerning the services an
+   Inter-AS Routing Protocol may provide.  This is not a complete list
+   of service issues but does address many of those services which are
+   of concern to a significant portion of the community.
+
+A.4.1  Cost on Toll Networks
+
+   Consideration must be given to the use of routing protocols with toll
+   (i.e., charge) networks.  Although uncommon in the Internet at the
+   moment, they will become more common in the future, and thought needs
+   to be given to allowing their inclusion in an efficient and effective
+   manner.
+
+   There are two areas in which concerns of cost intrude.  First,
+   provision must be made to include in the routing information
+   distributed throughout the system the information that certain links
+   cost money, so that traffic patterns may account for the cost.
+   Second, the actual operation of the algorithm, in terms of the
+   messages that must be exchanged to operate the algorithm, must
+   recognize that fact that on certain links, the exchange may have an
+   associated cost which must be taken into account.  These areas often
+
+
+
+Little                                                         [Page 18]
+
+RFC 1126            Inter-Autonomous System Routing         October 1989
+
+
+   involve policy questions on the part of the user.  It is a
+   requirement of the algorithm that facilities be available to allow
+   different groups to answer these questions in different ways.  The
+   first area is related to type-of-service routing, and is discussed in
+   Section A.4.2.  The second area is discussed below.
+
+   Previous attempts at providing these sorts of controls were
+   incomplete because they were not thought through fully; a new effort
+   must avoid these pitfalls.  For instance, even though the Hello rate
+   in EGP may be adjusted, turning the rate down too low (to control the
+   costs) could cause the route to be dropped from databases through
+   timeout.
+
+   In a large internet, changes will be occurring constantly; a
+   simplistic mechanism might mean that a site which is only connected
+   by toll networks has to either accept having an old picture of the
+   network, or spend more to keep a more current picture of things.
+   However, that is not necessarily the case if incomplete knowledge and
+   cache-based techniques are used more. For instance, if a site
+   connected only by toll links keeps an incomplete or less up-to-date
+   map of the situation, an agreement with a neighbor which does not
+   labor under these restrictions might allow it to get up-to-date
+   information only when needed.
+
+A.4.2  Type-of-Service Routing
+
+   The need for type-of-service (TOS) has been increasing as networks
+   become more heterogeneous in physical channel components, high-level
+   applications, and administrative management.  For instance, some
+   recently installed fiber cables provide abundant communication
+   bandwidths, while old narrow-band channels will still be with us for
+   a long time period.  Electronic mail traffic tolerates delivery
+   delays and low throughput.  New image transmissions are coming up;
+   these require high bandwidths but are not effected by a few bit
+   errors.  Furthermore, some networks may soon install accounting
+   functions to charge users, while others may still provide free
+   services.
+
+   Considering the long life span of a new routing architecture, it is
+   mandatory that it be built with mechanisms to provide TOS routing.
+   Unfortunately, we have had very little experience with TOS routing,
+   even with a single network.  No TOS routing system has ever been
+   field-tested on a large-scale basis.
+
+   We foresee the need for TOS routing and recognize the possible
+   complexities and difficulties in design and implementation.  We also
+   consider that new applications coming along may require novel
+   services that are unforeseeable today.  We feel a practical approach
+
+
+
+Little                                                         [Page 19]
+
+RFC 1126            Inter-Autonomous System Routing         October 1989
+
+
+   is to provide a small set of TOS routing functions as a first step
+   while the design of the architecture should be such that new classes
+   of TOS can be easily added later and incrementally deployed.  The
+   Inter-AS Routing Architecture should allow both globally and locally
+   defined TOS classes.
+
+   We intend to address TOS routing based on the following metrics:
+
+      -  Delay
+
+      -  Throughput
+
+      -  Cost
+
+   Delay and throughput are the main network performance concerns.
+   Considering that some networks may soon start charging users for the
+   transmission services provided, the cost should also be added as a
+   factor in route selection.
+
+   Reliability is not included in the above list.  Different
+   applications with different reliability requirements will differ in
+   terms of what Transport Protocol they use.  However, IP offers only a
+   "moderate" level of reliability, suitable to applications such as
+   voice, or possibly even less than that required by voice. The level
+   of reliability offered by IP will not differ substantially based on
+   the application.  Thus the requested level of reliability will not
+   affect Inter-AS Routing.
+
+   Delay and throughput will be measured from the physical
+   characteristics of communication channels, without considering
+   instantaneous load.  This is necessary in order to provide stable
+   routes, and to minimize the overhead caused by the Inter-AS Routing
+   scheme.
+
+   A number of TOS service classes may be defined according to these
+   metrics.  Each class will present defined requirements for each of
+   the TOS metrics.  For example, one class may require low delay,
+   require only low throughput, and require low cost.
+
+A.4.3  Multipath Routing
+
+   There are two types of multipath routing which are useful for Inter-
+   AS Routing: (1) there may be multiple gateways between any two
+   neighboring AS's; (2) there may be multiple AS-to-AS paths between
+   any pair of source and destination AS's.  Both forms of multipath are
+   useful in order to allow for loadsplitting.  Provision for multipath
+   routing in the IARP is desirable, but not an absolute requirement.
+
+
+
+
+Little                                                         [Page 20]
+
+RFC 1126            Inter-Autonomous System Routing         October 1989
+
+
+A.5  Performance Issues
+
+   The following paragraphs discuss issues related to the performance of
+   an Inter-AS Routing Protocol.  This discussion addresses size as well
+   as efficiency considerations.
+
+A.5.1  Adaptive Routing
+
+   It is necessary that the Inter-AS Routing scheme respond in a timely
+   fashion to major network problems, such as the failure of specific
+   network resources.  In this sense, Inter-AS Routing needs to use
+   adaptive routing mechanisms similar to those commonly used within
+   individual networks and AS's.  It is important that the adaptive
+   routing mechanism chosen for Inter-AS Routing achieve rapid
+   convergence following internet topological changes, with little or
+   none of the serious convergence problems (such as "counting to
+   infinity") that have been experienced in some existing dynamic
+   routing protocols.
+
+   The Inter-AS Routing scheme must provide stability of routes.  It is
+   totally unacceptable for routes to vary on a frequent basis.  This
+   requirement is not meant to limit the ability of the routing
+   algorithm to react rapidly to major topological changes, such as the
+   loss of connectivity between two AS's.  The need for adaptive routing
+   does not imply any desire for load-based routing.
+
+A.5.2  Large Internets
+
+   One key question in terms of the targets is the maximum size of the
+   Internet this algorithm is supposed to support.  To some degree, this
+   is tied to the timeline for which this protocol is expected to be
+   active.  However, it is necessary to have some size targets.
+   Techniques that work at one order of size may be impractical in a
+   system ten or twenty times larger.
+
+   Over the past five years there has been an approximate doubling of
+   the Internet each year.  In January 1988, there were more than 330
+   operational networks and more than 700 network assigned numbers.
+   Exact figures for the future growth rate of the Internet are
+   difficult to predict accurately.  However, if this doubling trend
+   continues, we would reach 10,000 nets sometime near January 1993.
+
+   Taking a projection purely on the number of networks (the top level
+   routing entity) may be overly conservative since the introduction and
+   wide use of subnets has absorbed some growth, but will not continue
+   to be able to do so.  In addition, there are plans being discussed
+   that will continue or accelerate the current rate of growth.
+   Nonetheless, the number of networks is very important because
+
+
+
+Little                                                         [Page 21]
+
+RFC 1126            Inter-Autonomous System Routing         October 1989
+
+
+   networks constitute the "top level entities" in the current
+   addressing structure.
+
+   The implications of the size parameter are fairly serious.  The
+   current system has only one level of addressing above subnets. While
+   it is possible to adjust certain parameters (for example, the
+   unsolicited or unnecessary retransmission rate) to produce a larger
+   but less robust system, other parameters (for example, the rate of
+   change in the system) cannot be so adjusted.  This will provide
+   eventual limits on the size of a system that can be dealt with in a
+   flat address space.
+
+   The exact size that necessitates moving from the current single-
+   level system to a multi-level system is not clear.  Among the
+   parameters which affect it are the assumed minimum speed of links in
+   the system (faster links can allocate more bandwidth to routing
+   traffic before it becomes obtrusive), speed and memory capacity of
+   routing nodes (needed to store and process routing data), rate at
+   which topology changes, etc.  The maximum size which can be handled
+   in a single layer is generally thought to be somewhere on the order
+   of 10 thousand objects.  The IARP must be designed to deal with
+   internets bigger than this.
+
+A.5.3  Addressing Implications
+
+   Given the current rate of growth of the Internet, we can expect that
+   the current addressing structure will become unworkable early within
+   the lifetime of the new IARP.  It is therefore essential that any new
+   IARP be able to use a new addressing format which allows for
+   addressing hierarchies beyond the network level.  Any new IARP should
+   allow for graceful migration from the current routing protocols, and
+   should also allow for graceful migration from a routing scheme based
+   on the current addressing, to a scheme based on a new multi-level
+   addressing format such as that described by OSI 8473.
+
+A.5.4  Memory, CPU, and Bandwidth Costs
+
+   Routing costs can be measured in terms of the memory needed to store
+   routing information, the CPU costs of calculating routes and
+   forwarding packets, and the bandwidth costs of exchanging routing
+   information and of forwarding packets.  These significant factors
+   should provide the basis for comparison between competing proposals
+   in IARP design.
+
+
+
+
+
+
+
+
+Little                                                         [Page 22]
+
+RFC 1126            Inter-Autonomous System Routing         October 1989
+
+
+   The routing architecture will be driven by the expected size of the
+   Internet, the expected memory capacity of the gateways, capacity of
+   the Inter-AS links, and the computing speed of the gateways. Given
+   our experience with the current Internet, it is clearly necessary for
+   the scheme to function adequately even if the Internet grows more
+   quickly than we predict and its capacity grows more slowly.  Memory,
+   CPU, and bandwidth costs should be in line with what is economically
+   practical at any point in time given the size of the Internet at that
+   time.
+
+A.6  Other Issues
+
+   The following are issues of a general nature and includes discussion
+   of items which have been considered to be best left for future
+   efforts.
+
+A.6.1  Implementation
+
+   The specification of IARP should allow interoperation among multi-
+   vendor implementations.  This requires that multiple vendors be able
+   to implement the same protocol, and that equipment from multiple
+   vendors be able to interoperate successfully.
+
+   There are potential practical difficulties of realizing multi-vendor
+   interoperation.  Any such difficulty should not be inherent to the
+   protocol specifications.  Towards this end, we should produce a
+   protocol specification that is precise and unambiguous.  This implies
+   that the specification should include a detailed specification using
+   Pseudo-Code or a Formal Description Technique.
+
+A.6.2  Configuration
+
+   It is expected that any IARP will require a certain amount of
+   configuration information to be maintained by gateways.  However, in
+   practice it is often difficult to maintain configuration information
+   in a fully correct and up-to-date form.  Problems in configuration
+   have been known to cause significant problems in existing operational
+   networks and internets.  The design of an Inter-AS Routing
+   architecture must therefore simplify the maintenance of configuration
+   information, consistent with other requirements. Simplification of
+   configuration information may require minimizing the amount of
+   configuration information, and using automated or semi-automated
+   configuration mechanisms.
+
+A.6.3  Migration
+
+   In any event, whether the address format changes or not, a viable
+   transition plan which allows for interoperability must be arranged.
+
+
+
+Little                                                         [Page 23]
+
+RFC 1126            Inter-Autonomous System Routing         October 1989
+
+
+   In a system of this magnitude, which is in operational use, a
+   coordinated change is not possible.  Where possible, changes should
+   not affect the hosts, since deploying such a change is probably
+   several orders of magnitude more difficult than changing only the
+   gateways, due to the larger number of host implementations as well as
+   hosts.  There are two important questions that need to be addressed:
+   (1) migration from the existing EGP to a new IARP; (2) migration from
+   the current DD IP to future protocols (including the ISO IP, and
+   other future protocols).
+
+A.6.4  Load-Based Routing
+
+   Some existing networks are able to route packets based on current
+   load in the network.  For example, one approach to congestion
+   involves adjusting the routes in real time to send as much traffic as
+   possible on lightly loaded network links.
+
+   This sort of load-based routing is a relatively delicate procedure
+   which is prone to instability.  It is particularly difficult to
+   achieve stability in multi-vendor environments, in large internets,
+   and in environments characterized by a large variation in network
+   characteristics.  For these reasons, we believe that it would be a
+   mistake to attempt to achieve effective load-based routing in an
+   Inter-AS Routing scheme.
+
+A.6.5  Non-Interference Policies
+
+   There are policies which are in effect, or desired to be in effect,
+   which are based upon the concept of non-interference.  These policies
+   state that the utilization of a given resource is permissible by one
+   party as long as that utilization does not disrupt the current or
+   future utilization of another party.  These policies are often of the
+   kind "you may use the excess capacity of my link" without
+   guaranteeing any capacity will be available.  The expectation is to
+   be able to utilize the link as needed, perhaps to the exclusion of
+   the other party.  The problem with supporting such a policy is the
+   need to be cognizant of highly dynamic state information and the
+   implicit requirement to adapt to these changes. Rapid, persistent,
+   and non-deterministic state changes would lead to routing
+   oscillations and looping.  We do not believe it is feasible to
+   support policies based on these considerations in a large
+   internetworking environment based on the current design of IP.
+
+Security Considerations
+
+   Security issues are not addressed in this memo.
+
+
+
+
+
+Little                                                         [Page 24]
+
+RFC 1126            Inter-Autonomous System Routing         October 1989
+
+
+Author's Address
+
+   Mike Little
+   Science Applications International Corporation (SAIC)
+   8619 Westwood Center Drive
+   Vienna, Virginia  22182
+
+   Phone: 703-734-9000
+
+   EMail: little@SAIC.COM
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Little                                                         [Page 25]
+
\ No newline at end of file