NSFNET Proposes NSFNET/DDN Routing Improvements
By Ken Horning
Merit/NSFNET
Part II: New means of interconnectivity
The NSFNET backbone, which provides network infrastructure for the National Science Foundation's computer network, interconnects multiple autonomously administered mid-level networks. NSFNET also connects to multiple peers networks consisting of national network infrastructures of other federal agencies.
One of these peer networks is the Defense Data Network (DDN) which can be viewed as the combination of the Defense Department's (DoD) MILNET and ARPANET component networks, both of which are national in scope.
During the first half of 1989, a new means of interconnectivity between NSFNET and the DDN was designed and implemented which allows two mailbridges, which previously had just connected the MILNET and the ARPANET, to interface directly with NSFNET nodes. This direct interconnection, which can be easily disabled from either site when tighter network security precautions are necessary, now makes it possible for NSFNET to exchange routing information directly with DDN route servers without a gateway operated by a mid-level network in the middle.
Routes announced from the DDN to the NSFNET
Routing arrangements for direct mail-bridge connections are also somewhat different from the NSFNET/ARPANET gateways used previously. Instead of a single NSFNET/ARPANET gateway carrying all traffic from the DDN to the NSFNET at any moment, distribution of network numbers is now split between the two mailbridges. This results in a distributed load with specific network numbers always preferring the same mailbridge under normal operating circumstances.
In the case of an outage at one of the mailbridge connections, the other would fully take over the load for all the involved network numbers. For this setup the two DDN links are known as two different Autonomous System numbers by the NSFNET. The routes learned via the NASA-Ames mailbridges are part of Autonomous System "164."
This is also the Autonomous System number which the mailbridges are using by themselves during the EGP session. In the case of EGP sessions with the Mitre mailbridge, the DDN-internal Autonomous System number of "164" is overwritten with a different Autonomous System number (in this case "184"), and the routes learned via the Mitre mailbridge therefore become part of Autonomous System "184" within the NSFNET.
NSFNET-inbound routing is controlled by the distributed policy routing database. In particular the network number is verified against a list of legitimate networks and a metric is associated with an authorized network number for a particular site. For example, the NSSs in Palo Alto, CA. and College Park, MD. both learn net 10 (the ARPANET network number) from the mailbridges they are connected to and with which they have EGP sessions.
The Palo Alto NSS will accept Net 10 with a metric of 10, while the College Park NSS will accept the same network number with a metric of 12. Therefore, traffic directed to net 10 will prefer the path via the Palo Alto NSS and the NASA-Ames mailbridge. If the connection via the NASA-Ames mailbridge is not functioning, the traffic will be rerouted via the mailbridge link in Virginia.
Each of the two NSSs accepts half of the network routes from its co- located mailbridge via EGP at a lower metric and the other half at a higher metric. The half with a lower metric at the Palo Alto NSS will be the same set which uses a higher metric at the College Park NSS and vice versa.
Routing possibilities
There are at least three different possibilities for how NSFNET could then select a path to a DDN network by using a specific mailbridge such as the one at NASA Ames versus the one at Mitre:
The second mailbridge would then function as a backup path. From a NSFNET point of view, this would mean treating the DDN like other NSFNET peer networks such as the NASA Science Network (NSN) or the Department of Energy's (DOE) Energy Science Network (ESNET).
The second alternative is now being used as an interim solution. At this time, however, DDN and NSFNET administrators are discussing the possibility of moving to the third alternative, which would give them control over how the DDN networks would be treated in the NSFNET.
Routes announced from the NSFNET to the DDN
Selection of metrics for announcements of NSFNET networks to the DDN is controlled by the NSFNET. The criteria for these metric decisions is based on the distance between the NSS, which introduces the specific network into the NSFNET, and either of which has a co- located mailbridge. In this context, the distance translates into the hop count between the NSSs in the NSFNET backbone. For example, the Princeton NSS is currently one hop away from the NSS which has the Mitre mailbridge co-located, but is three hops away from the NSS with the NASA-Ames mailbridge.
So, in the case of networks with primary paths via the Princeton NSS, the Mitre mailbridge will receive the announcements for those networks at a lower metric than the NASA-Ames mailbridge. Traffic from the DDN to networks connected to the Princeton NSS will be routed through the mailbridge at Mitre to the College Park NSS, and then through the Princeton NSS to its final destination.
This will guarantee that traffic entering the NSFNET from the DDN will take the shortest path to its NSFNET destination under normal operating conditions. Any of the networks connected via the NSFNET can be provided with the service of connectivity to the DDN via the NSFNET upon request from the mid-level network through which the specific network is connected.
For networks which do not have a DDN connection other than via NSFNET, the NSFNET will announce the nets via one of the mailbridges with a low metric to create a primary path (likely metric "1") and via the second mailbridge as a secondary path (likely metric "3").
For networks which have their own DDN connection and wish to use the NSFNET as a backup connection to DDN, the NSFNET will announce those networks via the two mailbridges at some higher metrics.
Mid-level networks need to make a specific request if they want client networks to be announced to the DDN via the NSFNET. Those requests need to state whether this would be a primary connection for the specific networks. If the request is for a fallback connection, it needs to state the existing metrics in use for announcements of the network to the DDN.
Shortcomings of the current NSFNET/DDN interconnection routing
The current arrangement makes full use of the two mailbridges which connect to the NSFNET directly with regard to redundancy and load sharing. There are some shortcomings, however, with regard to performance optimization such as packet propagation delay between source/destination pairs located on disjoint peer networks. These shortcomings are not easy to overcome due to the currently used architecture and are a worthwhile topic for discussion to facilitate future improvements.
The NSFNET is viewed as a cloud and so is the DDN. The two have two connections, one on the East coast and one on the West coast. To achieve the ideal traffic path will require NSFNET to implement option three which calls for the DDN administration to inform us as to which network on the DDN is closer to a specific mailbridge so that the particular mailbridge would accept this network at a lower metric.
The second mailbridge will then function as a backup path. When this can be accomplished, it will reduce the likelihood of packet traffic unnecessarily traversing national backbones.
Optimizing traffic
One of the best ways to optimize the traffic between two peer networks, and is not necessarily limited to the NSFNET and the DDN, is to try to avoid letting traffic traverse a backbone with a comparatively slower speed and/or traverse a backbone with a rather larger diameter network.
For example, in the case of traffic between the NSFNET and the DDN, the NSFNET has a T1 backbone and a maximum diameter of three hops while the DDN is a relatively slow network running largely at 56Kbps. In this case, the overall performance would be better if traffic would traverse the DDN as little as possible. Specifically, whenever the traffic has to reach a destination network outside of the DDN, it should find the closest mailbridge to exit the DDN.
This cannot be accomplished by means of the current architecture employed for DDN routing. First, the technology is designed based on a core model. It does not expect a single network to be announced by multiple locations. An example of multiple announcements could be two NSSs announcing a single network number to two mailbridges at their different locations. In addition, all existing mailbridges exchange routing information among themselves via a protocol similar to EGP, and that information is then distributed via EGP to the DDN-external networks.
In this case the physical distance information and locations of network numbers is lost, and neither the mailbridges nor the external gateways will be able to do path optimization based on physical distance and/or propagation delay. This is not easy to change because in the DDN, the link level routing information is decoupled from the IP level routing since the IP level routing has no information about the topology of the physical infrastructure.
Thus, even if an external gateway to a DDN network would learn a particular network route from two mailbridges, it will not be able to favor one over the other DDN exit point based on the distance to the mailbridge.
Conclusion
While recent changes in the network architecture between the NSFNET and DDN peer networks have resulted in significant performance and reliability improvements, there are still possibilities for further improvements and rationalization of this inter-peer-network routing. However, to accomplish this it would most likely require significant architectural changes within the DDN.
It is hoped that this overview of the implementation of routing between the NSFNET
and the DDN components (the MILNET and the
ARPANET) can be used to expand towards interconnections of other Administrative
Domains
Editor's Note: The article below is Part Two of a portion of Request for Comment (RFC 1133) by Jessica Yu and Hans-Werner Braun. Part One of this article appeared in the December, 1989 Link Letter.
Taken from The Link Letter, Vol. 2 No. 7, January 1990.