As per Relevance of the word regional, we have this rfc below:
Network Working Group H.W.
Request for Comments: 1093
February 1989
The NSFNET Routing
Status of this
This document describes the routing architecture for the
centered around the new NSFNET Backbone, with specific emphasis
the interface between the backbone and its attached networks
Distribution of this memo is unlimited
This document describes the routing architecture for the
centered around the new NSFNET Backbone, with specific emphasis
the interface between the backbone and its attached networks.
reflects and augments thoughts described in [1], discussions
the Internet Engineering Task Force meeting at the San
Supercomputing Center in March 1988, discussions on mailing lists
especially on a backbone/regional network working group mailing list
and a final discussion held at the IBM T.J. Watson Research Center
Yorktown, NY, on the 21st of March 1988. The Yorktown meeting
attended by Hans-Werner Braun (Merit), Scott Brim (
University), Mark Fedor (NYSERNet), Jeff Honig (Cornell University),
and Jacob Rekhter (IBM). Thanks also to: Milo Medin (NASA), John
(Proteon) and Greg Satz (Cisco) for discussing this document by
and/or phone
Understanding of [1] is highly recommended prior to reading
document
1. Routing
The new NSFNET backbone forms the core of the overall NSFNET,
connects to regional networks (or regional backbones) as well as
peer networks (other backbones like the NASA Science Network or
ARPANET). The NSFNET core uses a SPF based internal
protocol, adapted from the IS-IS protocol submitted by ANSI
standardization to the ISO. The ANSI IS-IS protocol is based
work done at Digital Equipment Corporation. Its adaptation to
Internet environment requires additional definitions, most notably
the addressing structure, which will be described in a
document. This adaptation was largely done by Jacob Rekhter of
Research in Yorktown, NY. The RCP/PSP routing architecture
largely implemented by Rick Boivie and his colleagues at IBM TCS
Braun [Page 1]
RFC 1093 NSFNET Routing Architecture February 1989
Milford, CT. The adaptation of EGP to the NSS routing code and
new requirements was done jointly by Jeff Honig (who spent about
week to work on this at IBM Research) and Jacob Rekhter. Jeff
integrating the changes done for the new EGP requirements into
"gated" distributions
The IGP derives routing tables from Internet address information
This information is flooded throughout the NSFNET core, and
individual NSS nodes create or update their routing information
running the SPF algorithm over the flooded information. A
description of the NSFNET backbone IGP will be documented in a
document
The routing interface between the NSFNET core and regional
as well as peer networks utilizes the Exterior Gateway
(EGP). The EGP/IGP consistency and integrity at the interface
is ensured by filtering mechanisms according to individual
routing policy data bases [1]. EGP is selected as the
interface of choice between the NSFNET backbone and its
attachments due to its widespread implementation as well its
to utilize autonomous system designators and to allow for
firewalls between systems. In the longer run the hope is to
the EGP interface with a new inter Autonomous System protocol. Such
new protocol should also allow to move the filtering of
numbers or Autonomous Network number groups to the regional
in order for the regional gateways to decide as to what
information they wish to receive
A general model is to ensure consistent routing information
peer networks. This means that, e.g., the NSFNET core will have
same sets of Internet network numbers in its routing tables as
present in the ARPANET core. However, the redistribution of
routing information is tightly controlled and based on
System numbers. For example, ARPANET routes with the
Autonomous System number will not be redistributed into regional
other peer networks. If an NSFNET internal path exists to such
network known to the ARPANET it may be redistributed into
networks, subject to further policy verification. Generally it may
necessary to have different trust models for peer and
networks, while giving a greater level of trust to peer networks
The described use of EGP, which is further elaborated on in [1]
requires bidirectional translation of network information between
IGP in use and EGP
2. Conclusions reached during the
The following conclusions were reached during the meeting and
Braun [Page 2]
RFC 1093 NSFNET Routing Architecture February 1989
subsequent discussions
No DDN-only routes (ARPANET/MILNET) shall be announced into
regional backbones. This is a specific case of the ability
suppress information from specific Autonomous Systems,
described later
Regional backbones are required to use an unique Autonomous
number. Announcements from non-sanctioned autonomous systems
relative to a particular site, will not be believed and
instead trigger an alarm to the Network Operations Center
Regional backbone attachments must not require routes to
subnets. This means that the locally attached network needs
use a flat space, without subnet bits, at least from the NSS
of view. The reason for this is that the EGP
exchanged between the regional gateway and the NSS cannot
subnet information. Therefore the NSS has no knowledge of
subnets. The safest way to get around this limitation is to use
non-subnetted network (like a separate Class-C network) at
interface between a regional backbone and the NSFNET backbone
The other way is to use Proxy-ARP while having just the NSS
that the network is not subnetted. In the latter case care must
taken so that the E-PSP uses the proper local IP
address
Routing information received by the NSS from regional
will be verified on both network number and autonomous
number
Metric reconstitution is done on a per-network basis. The
will construct the fixed metric it will use for a given
number from its internal data base. Network metrics given to
NSS via EGP will be ignored. The metrics used are a result of
ordered list of preferred paths as supplied by the
backbones and the attached campuses. This metric is of
only to the NSFNET core itself. The mechanisms are
explained in [1].
Global metric reconstitution by Autonomous System numbers
necessary in specific cases, such as peer networks. An example
that ARPANET routes will be reconstituted to a global metric,
determined by the NSS
EGP announcements into regional networks will use a fixed metric
The metric used shall be "128." The 128-metric is
arbitrarily chosen to be high enough so that a regional
will get a metric high enough from the NSFNET Core AS to allow
Braun [Page 3]
RFC 1093 NSFNET Routing Architecture February 1989
comparison against other (most likely internal) routes. "128"
also consistent with [2].
Peer network routes (e.g., ARPANET routes) are propagated
the NSS structure
No DEFAULT routing information is distributed within the
backbone, as the NSFNET core has the combined routing knowledge
the attached regional and peer networks
We do not expect the requirement for damping of routing
frequencies, at least initially. The frequency of net up/
changes combined with the available bandwidth and CPU capacity
not let the frequency of SPF floodings appear as being a
problem. Simple metric changes as heard by a NSS via EGP will
trigger updates
An allowed list of Source Autonomous System information will
used to convert from the IGP to EGP, on a Destination
System number basis, to allow for specific exclusion of
remote Autonomous System information
EGP must only announce networks for which the preferred path
via the IGP. This means in particular that the EGP peer
never announce via EGP what it learned via EGP on the
interface, not even if the information was received from a
EGP peer. This will avoid the back-distribution of
learned via that same interface. The EGP peers of
gateways must only announce information belonging to their
Autonomous System
EGP will be used in interior mode only
The regional backbones are responsible for generating
routing information at their option. One possibility is
generate an IGP default on a peer base as long as the NSS
connection is working. The EGP information will not include
special indication for DEFAULT
It is highly desirable to have direct peer-peer connections,
ease the implementation of a consistent routing data base
A single Autonomous System number may not be used with two E-
at the same time as long as the two E-PSP's belong to the
NSS. Otherwise the same Autonomous System number can be used
multiple points of attachment to the backbone and therefore
talk to more than one E-PSP. However, this may result
suboptimal routing unless multiple announcements are
Braun [Page 4]
RFC 1093 NSFNET Routing Architecture February 1989
engineered according to [1].
The administrator of the regional networks should be warned
improper routing implementations within the region may
suboptimal regional routing by using this restriction if no
is taken in that
Only networks belonging to their own Autonomous System
preferred over NSFNET backbone paths; this may extend to
larger virtual Autonomous System if backdoor paths
effectively implemented
IGP implementations should not echo back routing
heard via the same path
If two regional networks decide to implement a
connection between themselves, then the backdoor must have
firewall in so that information about their own
System cannot flow in from the other Autonomous System.
is, a regional network must not allow information
networks that are interior to its Autonomous System to
via exterior routes. Likewise, if a regional network
connected to the NSFNET via two NSS connections, the NSS
send back information about the Autonomous System into
Autonomous System where it originated. The end effect is
partitions within an Autonomous System will not be healed
using the NSS system. In addition, if three or more
connect to each other via multiple back-door paths, it
imperative that all back-door paths have firewalls that
that the above restrictions are imposed. These actions
necessary to prevent routing loops that involve the NSS system
Furthermore routing information should only be accepted
another regional backbone via backdoor paths for networks
are positively desired to be reached via this same
path
3. EGP requirements for attached
The following EGP requirements are necessary for attached gateways
they may require changes in existing vendor products
IGP to EGP routing exchanges need to be bidirectional.
feature should be selectable by the gateway administrator, and
default be configured OFF
The metric used when translating from EGP to IGP should
configurable
Braun [Page 5]
RFC 1093 NSFNET Routing Architecture February 1989
It must be possible for IGP information to override
information, so that the internal paths are preferred
external paths. Overriding EGP information on an absolute basis
where an external path would never be used as long as there is
internal one, is acceptable
The ability to do route filtering in the regional gateways on
per net basis is highly desirable to allow the regional
to do a further selection as to what routes they would want
redistribute into their network
The existence of an EGP connection should optionally lead to
generation of a DEFAULT announcement for propagation via the IGP
The DEFAULT metric should be independently configurable
EGP routes with a metric of "128" should be acceptable. In
cases the regional backbone should ignore the EGP metric
The regional gateways must only announce networks known to
own Autonomous System. At the very least they must
redistribute routing information via EGP for routes
learned via EGP
It would be beneficial if the regional IGPs would tag routes
being EGP derived
If the EGP peer (e.g., a NSS) terminates the EGP exchange
previously learned routes should expire in a timely fashion
4.
[1] Rekhter, J., "EGP and Policy Based Routing in the New
Backbone", T.J. Watson Research Center, IBM Corporation,
1988. Also as RFC 1092, February 1989.
[2] Mills, D., "Autonomous Confederations", RFC 975, M/A-
Linkabit, February 1986.
[3] Mills, D., "Exterior Gateway Formal Specification", RFC 904,
M/A-COM Linkabit, April 1984.
[4] "Exterior Gateway Protocol, Version 3, Revisions and Extensions,"
Working Notes of the IETF WG on EGP, Marianne L. Gardner
Mike Karels, February 1988.
[5] "Management and Operation of the NSFNET Backbone Network,"
proposal to the National Science Foundation, Merit
Network, August 1987.
Braun [Page 6]
RFC 1093 NSFNET Routing Architecture February 1989
5.
The following are extensions implemented for the "gated"
implementation, as designed by Jeff Honig of the Cornell
Theory Center. These extensions are still in the design stage
may be changed over time. They are included here as
implementation example
Changes to egpneighbor clause
egpneighbor metricin
egpmetricout
ASin
ASout
defaultout
metricin
If specified, the metric of all nets received from
neighbor are set to .
egpmetricout
If specified, the metric of all nets sent to this neighbor
except default, are set to .
ASin
If specified, EGP packets received from this neighbor
specify this AS number of an EGP error packet is generated
The AS number is only checked at neighbor acquisition time
ASout
If specified, this AS number is used on all EGP packets
to thiqs
If specified, this neighbor is not considered
generating a gateway default
If specified, the default will be accepted from
Braun [Page 7]
RFC 1093 NSFNET Routing Architecture February 1989
neighbor, otherwise it will be explicitly ignored
defaultout
If specified, the internally generated default is send
this neighbor in EGP updates. Default learned from
gateways is not propogated
If specifed, all nets learned from this EGP neighbor
have a corresponding 'validAS' clause or they will
ignored
Addition of a validAS clause
validAS AS metric
This clause specifies which AS a network may be learned from
what internal metric to use when the net is learned.
specifies the 'validate' option. Note that more than one may
learned from more than one AS
Addition of sendAS and donotsendAS clauses
These clauses control the announcement of exterior (currently
EGP) routes. Normally, exterior routes are not considered
announcement. When the 'sendAS' or 'donotsendAS' clauses
used, the announce/donotannounce, egpnetsreachable and
restrictions still apply. The 'sendAS' and 'donotsendAS'
are mutually exclusive by autonomous system
sendAS ASlist ...
This clause specifies that only nets learned from as1, as2, ...
may be propogated to as0.
donotsendAS ASlist ...
This clause specifies that nets learned from as1, as2, ...
not be propogated to , all other nets are propogated
An example of a "/etc/gated.conf" file could include the following
#
RIP
#
autonomousystem (regional AS
Braun [Page 8]
RFC 1093 NSFNET Routing Architecture February 1989
#
egpneighbor (NSS address) ASin (NSS AS)
metricin (metric
#
sendAS (NSS AS) ASlist (regional AS
#
Where
Regional AS Is the AS number of the regional
NSS address Is the IP address of the local
NSS AS Is the AS number the NSFNET
Metric Is the gated internal (time delay) metric
EGP learned routes should have. This is
metric used on output after conversion to a
metric. Some values are
HELLO
100 1
148 2
219 3
325 4
481 5
Author's Address
Hans-Werner
University of
Computing
1075 Beal
Ann Arbor, MI 48109
Phone: (313) 763-4897
Email: HWB@MCR.UMICH.
Braun [Page 9]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
