📄 rfc1126.txt
字号:
Network Working Group M. LittleRequest for Comments: 1126 SAIC October 1989 Goals and Functional Requirements for Inter-Autonomous System RoutingStatus 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 19892.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 uponLittle [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. WhenLittle [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
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -