RFC 1126

Goals and functional requirements for inter-autonomous system routing

📅 published October 1989, from ietf

RFC 1126: Goals and Functional Requirements for Inter-Autonomous System Routing 🎀

part 1 of 6

  • RFC: 1126 💖
  • Author: M. Little, SAIC ✨
  • Network Working Group
  • Date: October 1989 🌸
  • Status: does not specify a standard, it's a comment-welcome doc 💅
  • Obsoletes / Updates: the header doesn't list anything this one obsoletes or updates 🦋

Status of this Memo ✨

okay so bestie, this doc lays out the functional requirements for a routing protocol that runs between autonomous systems 🌸 It's the necessary precursor before anyone designs a brand new inter-autonomous system routing protocol. The requirements are for the Internet specifically, and they apply to the current DoD IP, the ISO IP, and future Internet Protocols too 🦋 The big hope is that these requirements become the foundation for building a new inter-autonomous systems routing architecture and protocol later.

It's being circulated to the IETF and the wider Internet community for comment, so send your thoughts to: "open-rout-editor@bbn.com" 💌 To be super clear, this memo does not specify a standard. Distribution is unlimited, so share it with whoever you want 🫶

1. Introduction 🧚

okay so the whole point is that an inter-autonomous systems routing protocol gets built out of goals and functions that are both desirable and actually achievable for the Internet. This doc describes those goals and functional requirements 💖 They're meant to give you a context for developing an inter-autonomous system routing architecture that can handle both current and future Internet routing needs. The goals show the properties and general capabilities the Internet routing environment should have, and what the architecture is supposed to accomplish as a whole ✨

The goals are followed by the functional requirements, which cover either detailed objectives or specific functionality the architecture and resulting protocol(s) should achieve. These requirements are numbered so they're easy to reference, and they're grouped so they map directly onto areas of architectural consideration 🎀 After that comes a list and description of general objectives, like robustness, that apply in a broad sense. And anything that isn't reasonably attainable, or is better left for future efforts, gets identified as a non-requirement 🙈

The intent here is to give you the goals and functional requirements in a concise way. That means supporting arguments, tradeoff considerations, and that kind of thing were purposefully left out 🍓 There's an appendix that covers this gap to a limited extent, so if you want the deeper discussion of the issues, go there.

The goals and functional requirements in this document are the result of work done by the members of the Open Routing Working Group. The group's intention is that these goals and requirements reflect not only what's foreseen in the Internet community, but also things similar to environments proposed by ANSI, ECMA and ISO 👑 Some interaction and relationship between this work and the output of those groups is expected.

2. Overall Goals 👑

okay so to come up with a set of functional requirements, you need one or more principals or overall goals that the routing environment has to satisfy. These high-level goals are the basis for each of the functional requirements, and they guide the design philosophy for reaching an inter-autonomous system routing solution 🔥 The overall goals we're using are described in the sections below.

2.1. Route to Destination 🦋

The routing architecture will provide for routing datagrams from a single source to one or more destinations in a timely manner. The bigger goal is datagram delivery to an identifiable destination, even one the source can't reach immediately 💅 Routing is meant to address the needs of a single source that needs datagram delivery to one or more destinations. Multi-homed hosts and multicast routing services are both covered by this goal ✨ Datagram delivery is to be provided to all interconnected systems, unless autonomous considerations constrain it otherwise.

2.2. Routing is Assured 🔥

Routing services are provided with assurance. If a service can't be provided, that's communicated to the requester on a best-effort basis, within an acceptable level of error 💖 This assurance should not be misread as guaranteed datagram delivery, and it doesn't mean you get an error notification for every lost datagram 🙈 Instead, if someone tries to use a routing service that can't be provided, the requester gets notified within a reasonable period, given persistent attempts.

2.3. Large System 🌈

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

2.4. Autonomous Operation 🍓

The routing architecture is to allow stable operation even when big chunks of the internetworking environment are controlled by disjoint entities. The future Internet is envisioned as a large number of internetworking facilities, owned and operated by all kinds of funding sources and administrative concerns 🎀 Cooperation between these facilities is necessary for interconnectivity, but the degree and type of cooperation will vary widely. Each facility also wants to operate as independently as possible from the concerns and activities of other facilities, and from the interconnection environment as a whole 💅 The resources used by (and available for) routing are to be under autonomous control by the administrative entities that own or operate them. Specifically, each controlling administration should be allowed to establish and maintain policies about the use of a given routing resource ✨

2.5. Distributed System 🧚

The routing environment should not depend on a data repository or topological entity that is either centralized or ubiquitous. The growth pattern of the Internet, plus the need for autonomous operation, means it has to be independent of topological and administrative centralization of both data and control flows 🦋 Past experience with a centralized topology has shown that it's both impractical for the community's needs and restrictive of administrative freedoms 💀 A distributed routing environment should not restrict either redundancy or diversity. And 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 on mechanisms and information that show both integrity and security. The routing mechanisms should operate in a sound and reliable fashion, while the routing information base should provide credible data to base routing decisions on 🔥 The environment can be unreliable, as long as 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 manager 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, plus the content and distribution characteristics of relevant databases, are of particular importance ✨

2.8. Minimize Required Resources 🍓

okay so any feasible design should hold down the demand for resources needed to provide inter-autonomous systems routing 💖 The resources of particular interest are the ones 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 used today for data communication systems 🙈

3. Functional Requirements 🧚

The functional requirements we've identified come from the overall goals, and they describe the critical features expected of inter-autonomous system routing 🌸 To an extent, these functions are vague in terms of detail. We don't specify, for instance, the quantity or types of quality-of-service parameters 💅 That's on purpose, because the functional requirements are meant to define the features required of the inter-autonomous system routing environment, not the exact nature of that environment ✨ The functional requirements have been loosely grouped according to areas of architectural impact 🦋

3.1. Route Synthesis Requirements ✨

okay bestie, route synthesis is the part of the system that handles BOTH route selection AND path determination 🗺️ (figuring out the sequence of intermediate systems from a source all the way to a destination). These requirements make sure the path can adapt to topology changes, respond to administrative policy, care about quality-of-service, and play nicely with an interconnected world of autonomously managed systems 💅

a) Route around failures dynamically

okay so route synthesis will make a best effort to notice when a routing resource it's currently using breaks 💔 And once it catches a failed one, it'll make a best effort to switch over to other available routing resources so the routing service keeps going 🦋 no drama, just vibes 🫶

b) Provide loop free paths

the path for a datagram, from source to destination, will be free of circuits or loops most of the time 🔁 and when a circuit or loop does pop up, it's supposed to happen with both negligible probability and negligible duration. basically it's a rare moment 🙈

c) Know when a path or destination is unavailable

route synthesis needs to be able to tell when it can't build a path to a destination it already knows about 🚫 it also needs to tell when a destination can't be figured out at all, because the one being asked for is unknown (or the info just isn't available). not knowing is still knowing, ngl 🧚

d) Provide paths sensitive to administrative policies

route synthesis will respect the resource utilization policies of the admin entities that manage the resources on the path 👑 however, it is literally inconceivable to accommodate every policy a managing admin could ever define 💀 like, policies that depend on volatile events happening at lightning speed, or ones that are non-deterministic, just can't be accommodated 🙅‍♀️

e) Provide paths sensitive to user policies

paths produced by route synthesis must be sensitive to the policies the user expresses 🎀 and those policies are described in terms that make sense for the known characteristics of the topology. the path you get has to meet the requirements stated in your user policy. no cap, your rules matter ✨

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

the path should match whatever quality-of-service was asked for 🔥 and when it makes sense, route synthesis should only use resources that can actually support that quality-of-service (bandwidth is the classic example 📶). we're not settling for vibes here, we want receipts 🧾

g) Provide autonomy between inter- and intra-autonomous system route synthesis

the inter- and intra-autonomous system routing environments should operate independently of each other 🦋 the design should be such that route synthesis in one environment does NOT depend on info from the other one to work. specifically, when inter-autonomous system route synthesis is transiting (or delivering to) an autonomous system, it should keep its constraints on the intra-autonomous system decisions to a minimum 💅 boundaries are iconic, bestie 🌸

3.2. Forwarding Requirements 🚚

okay now we're talking about forwarding, which is the actual datagram-moving process 📦 this is where datagrams get pushed on to intermediate or final destinations based on datagram characteristics, environmental characteristics, and whatever route synthesis decided 🧚

a) Decouple inter- and intra-autonomous system forwarding decisions

the goal is to give the inter-autonomous system forwarding decision some independence from the intra-autonomous system one 🫧 the two decisions should be independent of each other, even though the inter-autonomous system delivery process may end up depending on intra-autonomous system route synthesis and forwarding. it's giving complicated, but it's kind of a necessary friendship 🫶

b) Do not forward datagrams deemed administratively inappropriate

forward datagrams according to the route synthesis decision as long as it doesn't clash with known policy 💖 policy-sensitive route synthesis keeps normally routed datagrams away from inappropriate resources 🙅‍♀️ but ngl, a datagram can still get routed weirdly because of unknown events or actions 😭 the only real way to stop unwanted traffic from getting in or out of an autonomous system is policy enforcement inside the forwarding function 🛡️

c) Do not forward datagrams to failed resources

a datagram must not be forwarded to a resource that's known to be unavailable, especially an intermediate system like a gateway 🚧 this means the forwarding process needs some way to detect and react to resource failures. no sending packets into a black hole, bestie 🕳️

d) Forward datagram according to its characteristics

the forwarding function should be sensitive to the datagram's characteristics so it can carry out the right route synthesis decision 🎯 the characteristics to look at are the destination, quality-of-service, precedence, datagram (or user) policy, and security 🔐 fun fact (and this is important!): some of these, like precedence, change the forwarding service you get, while others change which path gets picked 🧩

3.3. Information Requirements 📚

this functional area is all about the general information requirements of the routing environment 🌈 it covers both what routing information actually is and how it gets spread around. the following functional requirements spell out what that information and its distribution should look like ✨

a) Provide a distributed and descriptive information base

the information base must not depend on centralization or exact replication 🙅‍♀️💜 its content has to be enough to support all the routing functionality it's responsible for, specifically route synthesis and forwarding. the stuff that really matters most includes resource characteristics and resource utilization policies 🔍

b) Determine resource availability

we need a way to figure out whether any resource in use is available, and to do it in a timely manner ⏰ how fast "timely" has to be depends on which routing service(s) are being supported 🧚

c) Restrain transmission utilization

the dynamics of routing information flow should be such that it doesn't eat up a big chunk of transmission resources 🍓 it should also adapt to what the environment demands, the capacity of the distribution facilities being used, and what the resource manager wants. being a good citizen of the network is literally the vibe 🫶

d) Allow limited information exchange

information distribution has to be sensitive to administrative policies 📜 a policy can change the content or completeness of the info being distributed, and it can also decide how far that info goes. boundaries again, bestie 🚧💅

3.4. Environmental Requirements 🌍

these are the requirements that come straight from the kind of environment routing has to live in 🏡

a) Support a packet-switching environment

the routing environment should be able to support datagram transfer in a packet-switched networking environment 📦✨

b) Accommodate a connection-less oriented user transport service

the routing environment should be designed so that it fits the model for a connection-less oriented user transport service 🦋

c) Accommodate 10K autonomous systems and 100K networks

this one sets the scale we expect the internetwork to reach in the future 🚀 a routing design that can't handle this order of magnitude is considered inappropriate. so we're thinking BIG, bestie 👑

d) Allow for arbitrary interconnection of autonomous systems

the routing environment should be able to handle autonomous systems connecting to each other in arbitrary ways 🕸️ it's totally acknowledged that a practical solution will probably lean toward one particular interconnection structure, because efficiency 🧠 still, a design that can't allow for and use arbitrary interconnectivity would not be considered feasible 💀

3.5. General Objectives 🎯

these are the big-picture goals the inter-autonomous routing architecture and its protocols should hit 🏆

a) Provide routing services in a timely manner

the routing services covered by the requirements in this document must be delivered in a timely manner ⏱️ the timing has to be reasonable enough to support the services the internetwork provides overall 🌸

b) Minimize constraints on systems with limited resources

autonomous systems or gateways with limited resources should still be able to join the inter-autonomous system routing architecture 🧚 just know that this kind of limited participation isn't necessarily free. it can cost something in responsiveness, path optimization, or some other factor(s) 💸

c) Minimize impact of dissimilarities between autonomous systems

the goal is a design where the differences between autonomous systems don't get in the way of the routing services any of them receive 🤝

d) Accommodate the addressing schemes and protocol mechanisms of the autonomous systems

the routing environment should be able to accommodate each autonomous system's addressing schemes and protocol mechanisms, even when they differ from one system to the next 🎀

e) Must be implementable by network vendors

this basically means the algorithms and complexity of the design must be understandable outside the research community, and implementable by people other than the original designers 🛠️ any feasible design has to be something that can actually be put into practice. no ivory tower stuff, bestie 🗼💅

4. Non-Goals ✨

okay so, a lot of these goals fight each other (classic tradeoff drama 💅), so it's just as important to say what we are not trying to do 🙈. These are the things we've decided aren't reasonable goals or functional requirements right now, and they're better saved for future efforts 🦋. We call them non-goals (or non-requirements). They sit outside the goals and requirements already laid out in this document, and outside what we think can actually be pulled off in practice 🎀.

a) Ubiquity 🌍

It is not a goal to design a routing environment where any participating autonomous system can get routing service to any other participating autonomous system in a ubiquitous way 💫. In a policy-sensitive routing environment, the cooperation of intermediate resources is needed, and it can't be guaranteed to every participant 😭. So the idea of ubiquitous connectivity just won't be a valid one 💀.

b) Congestion control 🚦

Inter-autonomous system routing being able to do congestion control is a non-requirement 🙅‍♀️. More study is needed to figure out which mechanisms fit best, whether congestion control belongs in the inter-AS environment, the intra-AS environment, or both, and if it's both, how the two actually interact 🔍.

c) Load splitting ⚖️

Spreading 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 that the inter-autonomous system routing environment be designed to try to max out how much of the available resources get used 🙃.

e) Schedule to deadline service ⏰

Supporting 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 🤝

Supporting routing policies based on the idea of non-interference is not a requirement 🙅. For example, an autonomous system lets outside users use its excess bandwidth, as long as that doesn't get in the way of local usage of the link 🫶.

5. Considerations 💭

Even though it's not a specific goal or functional requirement, we have to think about the transition from the current operational routing environment to a new one 🚀. Getting every participant of the Internet to coordinate on that would be wildly impractical, given how huge it is 🌐. In particular, transitional coexistence (as opposed to phased upgrading between disjoint systems) is worth addressing as a way to keep service disruption to a minimum 🫠. We also want to think carefully about any changes hosts might need 🖥️. It's very unlikely that every host could be changed, given history, how diverse they are, and how many of them there are 😩.

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 here came before the main body of the document, and it was a big influence on what's in it ✨. It's included as a reference, and to give some insight into the many issues involved in inter-autonomous systems routing 📖.

The following definitions are used:

Boundary Gateway 🚪

A boundary gateway is any autonomous system gateway that has a network interface directly reachable from another autonomous system. As a member of an autonomous system, a boundary gateway takes part in the Interior Gateway Protocol and other protocols used for routing (and other purposes) between other gateways of that same autonomous system, and between those networks directly reachable by this autonomous system. A boundary gateway may also take part in an Inter-Autonomous System Routing Protocol. As a participant in that protocol, a boundary gateway interacts with other boundary gateways in other autonomous systems, either directly or indirectly, to support the operation of the Inter-Autonomous System Routing Protocol.

Interior Gateway 🏠

An interior gateway is any autonomous system gateway that is not a boundary gateway. So an interior gateway has no network interfaces that any other autonomous system can directly reach. 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. That implies 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 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 it hands to the IARP 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 of 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" used by EGP are not acceptable 🙅‍♀️💀.

A.2.4. Routing Firewalls 🧱

okay bestie, we expect AS's to have a certain amount of insulation from other AS's 🫶 like a protective bubble ✨. This protection should cover both the adequacy and stability of the routes the routing scheme produces, AND the amount of overhead traffic and other costs it takes to run the scheme 💅. There are a few forms these "routing firewalls" can 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 🛡️. Here, correct operation means 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 provide 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 it 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 👑.

A.2.5. Boundary Gateways 🚪

Boundary gateways will exchange Inter-AS Routing information with other boundary gateways using the IARP. Each AS that's joining Inter-AS Routing gets one or more boundary gateways, and one or more of those boundary gateways swaps info 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. So, specific designated boundary gateways will 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 ✨.

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 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 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 🏃‍♀️.

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 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 relate 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 🔐.

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 it does address many of those services which are of concern to a significant portion of the community 💜.

A.4.1 Cost on Toll Networks 💸

okay so, toll networks charge you for using them, and routing has to take that into account. They're uncommon on the Internet right now, but they're going to get more common, so we need to figure out how to let them in efficiently and effectively. 💅

There are two places where cost sneaks in 👀 First, the routing info that gets passed around the whole system has to say that certain links cost money, so traffic patterns may account for the cost 🧾 Second, the algorithm's actual operation, meaning the messages it swaps to do its job, has to know that on certain links the exchange may have a cost attached 📨 Both of these are policy questions for the user, so it's a requirement of the algorithm that different groups can answer them in different ways 🫶 The first area is tied to type-of-service routing, which is covered in Section A.4.2 🎀 and the second area is coming up below.

Earlier attempts at these kinds of controls were kinda incomplete because nobody thought them all the way through 😬 A new effort must avoid those pitfalls. Like, even though the Hello rate in EGP may be adjusted, turning it down too low to save money could get the route dropped from databases through timeout. 💀 bestie, that's a whole own goal.

In a large internet, changes are happening constantly 🌈 A simplistic mechanism might mean that a site connected only by toll networks is stuck with an old picture of the network, or has to spend more to keep a fresher one 😭 That's not necessarily the case though, if incomplete knowledge and cache-based techniques get used more. For example, if a site connected only by toll links keeps an incomplete or less up-to-date map, it could make an agreement with a neighbor that doesn't have these restrictions and only grab up-to-date info when it actually needs it. cache energy, iconic ✨

A.4.2 Type-of-Service Routing 🍓

The need for type-of-service (TOS) keeps growing as networks get more heterogeneous in physical channel components, high-level applications, and administrative management 🌸 Some newer fiber cables give us loads of bandwidth 🌊 while old narrow-band channels are going to hang around for a long time. Email traffic tolerates delivery delays and low throughput 📧 New image transmissions are coming up, and they need high bandwidths but aren't effected by a few bit errors 🖼️ Also, some networks may soon start charging users for service, while others may still provide free services 💸

Since a new routing architecture has such a long life span, it is mandatory that it be built with mechanisms to provide TOS routing. Honestly though, we've had very little experience with TOS routing, even on a single network 😅 No TOS routing system has ever been field-tested on a large-scale basis.

We see the need for TOS routing, and we know the design and implementation could get complicated 🧠 New applications may also require novel services that nobody can foresee today 🔮 So a practical approach is to provide a small set of TOS routing functions as a first step ✅ while the architecture itself should be built so that new classes of TOS can be easily added later and deployed incrementally 🦋 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 🔥 Since some networks may soon start charging users for transmission services, cost should also be added as a factor in route selection 💰

Reliability isn't on the list 🙅‍♀️ Different apps with different reliability requirements differ in which Transport Protocol they use. But IP only offers a "moderate" level of reliability, suitable for things like voice, or possibly even less than voice needs 🎙️ That level doesn't differ much from app to app, so the requested reliability won't affect Inter-AS Routing. Thus, no drama there ✨

Delay and throughput get measured from the physical characteristics of communication channels, without looking at instantaneous load 📏 This is necessary for stable routes and to keep the overhead of the Inter-AS Routing scheme low 🧘

A number of TOS service classes may be defined using these metrics, and each class presents defined requirements for each TOS metric. 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 that 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 are useful for loadsplitting 🧩 Multipath routing in the IARP is desirable, but not an absolute requirement 💜

A.5 Performance Issues ⚡

The following paragraphs talk about issues related to the performance of an Inter-AS Routing Protocol 🏎️ This covers size as well as efficiency.

A.5.1 Adaptive Routing 🔄

Inter-AS Routing needs to respond in a timely way to major network problems, like the failure of specific network resources 🚨 So it needs adaptive routing mechanisms similar to the ones commonly used within individual networks and AS's. It's important that the adaptive routing mechanism chosen for Inter-AS Routing achieves rapid convergence after internet topology changes 🌀 with little or none of the serious convergence problems (like "counting to infinity") that some existing dynamic routing protocols have had 🙈

The Inter-AS Routing scheme must provide stability of routes. Routes varying on a frequent basis is totally unacceptable 🙅‍♀️ This requirement isn't meant to limit the algorithm's ability to react rapidly to major topology changes, like the loss of connectivity between two AS's. And the need for adaptive routing does not imply any desire for load-based routing 🚫⚖️

A.5.2 Large Internets 🌐

One key question for the targets is the maximum size of the Internet this algorithm is supposed to support 🤔 That's tied to the timeline for which this protocol is expected to be active, but we need some size targets either way. Techniques that work at one order of size may be impractical in a system ten or twenty times larger 😵

Over the past five years, the Internet has had an approximate doubling each year 📈 In January 1988, there were more than 330 operational networks and more than 700 network assigned numbers. Exact figures for future growth are hard to predict, but 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 it won't keep being able to do that. Plus, there are plans being discussed that will continue or accelerate the current rate of growth 🚀 Still, the number of networks is very important, because networks are the "top level entities" in the current addressing structure.

The implications of the size parameter are pretty serious 😬 The current system has only one level of addressing above subnets. You can adjust certain parameters (for example, the unsolicited or unnecessary retransmission rate) to get a larger but less robust system, but other parameters (for example, the rate of change in the system) can't be adjusted that way. This will eventually put limits on the size of a system that can be handled in a flat address space 🧱

The exact size that makes you move from the current single-level system to a multi-level system isn't clear 🤷‍♀️ Factors include the assumed minimum speed of links in the system (faster links can allocate more bandwidth to routing traffic before it gets obtrusive), speed and memory capacity of routing nodes (needed to store and process routing data), the rate at which topology changes, etc. The maximum size that 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 😱 So it's essential that any new IARP be able to use a new addressing format that 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 the one 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 comparing competing proposals in IARP design ⚖️

The routing architecture will be driven by the expected size of the Internet, the expected memory capacity of the gateways, the capacity of the Inter-AS links, and the computing speed of the gateways 🖥️ Given our experience with the current Internet, it's 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 general issues, including discussion of items that have been considered best left for future efforts 🔮

A.6.1 Implementation 🛠️

The specification of IARP should allow interoperation among multi-vendor implementations 🤝 That 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 with 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 🎀

okay so any IARP is gonna need a certain amount of configuration info stored on the gateways, no cap. but bestie, keeping that config fully correct AND up to date is genuinely hard in practice 😭. config problems have caused real trouble in existing operational networks and internets, so the design of an Inter-AS Routing architecture must simplify config maintenance while still meeting the other requirements 💅. simplifying config can mean minimizing how much config there is, plus using automated or semi-automated config mechanisms 🤖✨

A.6.3 Migration 🦋

okay this section is all about transition plans 🦋. whether the address format changes or not, a viable transition plan that allows for interoperability must be arranged 🫶.

in a system this big that's already running in the wild, a coordinated change is not possible 🙃. where possible, changes should not affect the hosts, because deploying a change on hosts is probably several orders of magnitude harder than changing only the gateways. there are way more host implementations and way more hosts 💀.

two important questions 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 can 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 that is prone to instability 🫠. it's particularly difficult to achieve stability in multi-vendor environments, in large internets, and in environments with 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 that are in effect, or desired to be in effect, based on the concept of non-interference 👀. these policies say that one party can use a given resource as long as that use doesn't disrupt the current or future use of another party. they're often the "you may use the excess capacity of my link" kind, without guaranteeing that any capacity will be available. the expectation is to be able to use the link as needed, perhaps to the exclusion of the other party 💜.

the problem is that supporting a policy like this means keeping track of highly dynamic state information, plus the implicit requirement to adapt to those 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 🚫. no bestie, not like this 💔.

Security Considerations 🚨

security issues are not addressed in this memo 🙈.

Author's Address 💌

meet the author, Mike Little 🧚

Mike Little
Science Applications International Corporation (SAIC)
8619 Westwood Center Drive
Vienna, Virginia  22182

Phone: 703-734-9000

EMail: little@SAIC.COM
📦 where this page comes from