rfc1126.txt
来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 1,403 行 · 第 1/4 页
TXT
1,403 行
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 mannerLittle [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 19895. 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 RoutingA.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 theLittle [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 theLittle [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⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?