As per Relevance of the word subscriber, we have this rfc below:
Network Working Group H-W.
Request for Comments: 1222 San Diego Supercomputer
Y.
IBM T.J. Watson Research
May 1991
Advancing the NSFNET Routing
Status of this
This RFC suggests improvements in the NSFNET routing architecture
accommodate a more flexible interface to the Backbone clients.
memo provides information for the Internet community. It does
specify an Internet standard. Distribution of this memo
unlimited
This memo describes the history of NSFNET Backbone routing
outlines two suggested phases for further evolution of the Backbone'
routing interface. The intent is to provide a more
interface for NSFNET Backbone service subscribers, by providing
attachment option that is simpler and lower-cost than the
one
The authors would like to thank Scott Brim (Cornell University),
Bilal Chinoy (Merit), Elise Gerich (Merit), Paul Love (SDSC),
Wolff (NSF), Bob Braden (ISI), and Joyce K. Reynolds (ISI) for
review and constructive comments
1. NSFNET Phase 1 Routing
In the first phase of the NSFNET Backbone, a 56Kbps
utilized routers based on Fuzzball software [2]. The Phase 1
Backbone used the Hello Protocol for interior routing. At
periphery of the Backbone, the client networks were
connected by using a gatedaemon ("gated") interface to
between the Backbone's Hello Protocol and the interior
protocol (IGP) of the mid-level network
Mid-level networks primarily used the Routing Information
(RIP) [3] for their IGP. The gatedaemon system acted as an
between the Hello and RIP environments. The overall appearance
that the Backbone, mid-level networks, and the campus networks
a single routing system in which information was freely exchanged
Braun & Rekhter [Page 1]
RFC 1222 Advancing the NSFNET Routing Architecture May 1991
Network metrics were translated among the three network
(backbone, mid-level networks, and campuses).
With the development of the gatedaemon, sites were able to
filtering based on IP network numbers. This process was
by the staff at each individual site
Once specific network routes were learned, the
forwarded metric changes throughout the interconnected network.
end-result was that a metric fluctuation on one end of
interconnected network could permeate all the way to the other end
crossing multiple network administrations. The frequency of
fluctuations within the Backbone itself was further increased
event-driven updates (e.g., metric changes) were introduced. Later
damping of the event driven updates lessened their frequency, but
overall routing environment still appeared to be quite unstable
Given that only limited tools and protocols were available
engineer the flow of dynamic routing information, it was fairly
for routing loops to form. This was amplified as the topology
more fully connected without insulation of routing components
each other
All six nodes of the Phase 1 Backbone were located at client sites
specifically NSF funded supercomputer centers
2. NSFNET Phase 2 Routing
The routing architecture for the second phase of the NSFNET Backbone
implemented on T1 (1.5Mbps) lines, focused on the lessons learned
the first NSFNET phase. This resulted in a strong decoupling of
IGP environments of the backbone network and its attached
[5]. Specifically, each of the administrative entities was able
use its own IGP in any way appropriate for the specific network.
interface between the backbone network and its attached client
built by means of exterior routing, initially via the
Gateway Protocol (EGP) [1,4].
EGP improved provided routing isolation in two ways. First,
signals only up/down transitions for individual network numbers,
the fluctuations of metrics (with the exception of metric
of local relevance to a single Nodal Switching System (NSS) only
inbound routing information, in the case of multiple EGP peers at
NSS). Second, it allowed engineering of the dynamic distribution
routing information. That is, primary, secondary, etc., paths can
determined, as long as dynamic externally learned routing
is available. This allows creation of a spanning tree
Braun & Rekhter [Page 2]
RFC 1222 Advancing the NSFNET Routing Architecture May 1991
topology, satisfying the constraints of EGP
The pre-engineering of routes is accomplished by means of a
configuration database that is centrally controlled and created,
a subsequent distribution of individual configuration information
all the NSFNET Backbone nodes. A computer controlled central
ensures the correctness of the database prior to its distribution
the nodes
All nodes of the 1.5Mbps NSFNET Backbone (currently fourteen)
located at client sites, such as NSF funded supercomputer centers
mid-level network attachment points
3. T3 Phase of the NSFNET
The T3 (45Mbps) phase of the NSFNET Backbone is implemented by
of a new architectural model, in which the principal
nodes (core nodes) are co-located with major phone company
facilities. Those co-located nodes then form a two-
networking infrastructure "cloud". Individual sites are
via exterior nodes (E-NSS) and typically have a single T3 access
to a core node (C-NSS). That is, an exterior node is physically
the service subscriber site
With respect to routing, this structure is invisible to client sites
as the routing interface uses the same techniques as the T1
Backbone. The two backbones will remain independent infrastructures
overlaying each other and interconnected by exterior routing, and
T1 Backbone will eventually be phased out as a separate network
4. A Near-term Routing
The experience with the T1/T3 NSFNET routing demonstrated
advantages of this routing architecture in which the
infrastructure is strongly compartmentalized. Previous
also showed that the architecture imposes certain obligations
the attached client networks. Among them is the requirement that
service subscriber must deploy its own routing protocol peer
participating in the IGP of the service subscriber and connected
a common subnet to the subscriber-site NSFNET node. The router
the NSFNET Backbone exchange routing information via an EGP or
[7] session
The drawbacks imposed by this requirement will become more
with the transition to the new architecture that is employed by
T3 phase of the NSFNET Backbone. This will allow rapid expansion
many and smaller sites for which a very simple routing interface
be needed
Braun & Rekhter [Page 3]
RFC 1222 Advancing the NSFNET Routing Architecture May 1991
We strongly believe that separating the routing of the
subscriber from the NSFNET Backbone routing via some kind of EGP
the correct routing architecture. However, it should not
necessary to translate this architecture into a requirement for
service subscriber to install and maintain additional equipment,
for the subscriber to deal with more complicated
environments. In other words, while maintaining that the concept
routing isolation is correct, we view the present implementation
the concept as more restrictive than necessary
An alternative implementation of this concept may be realized
separating the requirement for an EGP/BGP session, as the
for exchanging routing information between the service
network and the backbone, from the actual equipment that has to
deployed and maintained to support such a requirement. The
essential requirement for routing isolation is the presence of
logical routing entities. The first logical entity participates
the service subscriber's IGP, the second logical entity
in the NSFNET Backbone IGP, and the two logical entities
information with each other by means of inter-domain mechanisms.
suggest that these two logical entities could exist within a
physical entity
In terms of implementation, this would be no different from
gatedaemon system interfacing with the previous 56Kbps
Backbone from the regional clients, except that we want to
the strong routing and administrative control that decouple the
IGP domains. Retaining an inter-domain mechanism (e.g., BGP)
connect the two IGP domains within the single physical entity
the use of a well defined and understood interface. At the
time, care must be taken in the implementation that the two
will not simultaneously interact with the system kernel in
ways
The possibility of interfacing two IGP domains within a single
has also been noted in [8]. For the NSFNET Backbone case, we
in addition to retain strong firewalls between the IGP domains.
IGP information would need to be tagged with exterior
information at its entry into the other IGP. It would also
important to allow distributed control of the configuration.
NSFNET Backbone organization and the provider of the attached
network are each responsible for the integrity of their own
information
An example implementation might be a single routing engine
executed two instances of routing daemons. In the NSFNET
case, one of the daemons would participate in the
subscriber's IGP, and the other would participate in the
Braun & Rekhter [Page 4]
RFC 1222 Advancing the NSFNET Routing Architecture May 1991
Backbone IGP. These two instances could converse with each other
running EGP/BGP via a local loopback mechanism or internal IPC.
the NSFNET Backbone implementation, the NSFNET T1 E-PSP or T3 E-
are UNIX machines, so the local loopback interface (lo0) of the
operating system may be used
Putting both entities into the same physical machine means that
E-PSP/E-NSS would participate in the regional IGP on its
interface. We would still envision the Ethernet attachment to be
demarcation point for the administrative control and
responsibility. However, the regional client could provide
configuration information for the routing daemon that interfaced
the regional IGP, allowing the regional to continue to
control over the introduction of routing information into its IGP
5. Long-Term
As technology employed by the NSFNET Backbone evolves, one
envision the demarcation line between the Backbone and the
subscribers moving in the direction of the "C-NSS cloud", so that
NSFNET IGP will be confined to the C-NSS, while the E-NSS will be
full participant in the IGP of the service subscriber
Clearly, one of the major prerequisites for such an evolution is
ability for operational management of the physical medium
a C-NSS with an E-NSS by two different administrative entities (i.e.,
the NSFNET Backbone provider as well as the service subscriber).
will also have to be manageable enough to be comparable in ease
use to an Ethernet interface, as a well-defined demarcation point
The evolution of the Point-to-Point Protocol, as well as
significantly enhanced capability for managing serial lines
standard network management protocols, will clearly help. This
not be the complete answer, as a variety of equipment is used
serial lines, making it difficult to isolate a hardware problem
Similar issues may arise for future demarcation interfaces
Internet infrastructure (e.g., SMDS interfaces).
In summary, there is an opportunity to simplify the management
administration, and exchange of routing information by collapsing
number of physical entities involved
6.
[1] Mills, D., "Exterior Gateway Protocol Formal Specification",
904, BBN, April 1984.
[2] Mills, D., and H-W. Braun, "The NSFNET Backbone Network",
Braun & Rekhter [Page 5]
RFC 1222 Advancing the NSFNET Routing Architecture May 1991
1987, August 1987.
[3] Hedrick, C., "Routing Information Protocol", RFC 1058,
University, June 1988.
[4] Rekhter, Y., "EGP and Policy Based Routing in the New
Backbone", RFC 1092, IBM T.J. Watson Research Center,
1989.
[5] Braun, H-W., "The NSFNET Routing Architecture", RFC 1093,
Merit/NSFNET, February 1989.
[6] Braun, H-W., "Models of Policy Based Routing", RFC 1104,
Merit/NSFNET, June 1989.
[7] Lougheed, K., and Y. Rekhter, "A Border Gateway Protocol (BGP)",
RFC 1163, cisco Systems, IBM T.J. Watson Research Center,
1990.
[8] Almquist, P., "Requirements for Internet IP Routers", to
published as a RFC
7. Security
Security issues are not discussed in this memo
8. Authors'
Hans-Werner
San Diego Supercomputer
P.O. Box 85608
La Jolla, CA 92186-9784
Phone: (619) 534-5035
Fax: (619) 534-5113
EMail: HWB@SDSC.
Yakov
T.J. Watson Research
IBM
P.O. Box 218
Yorktown Heights, NY 10598
Phone: (914) 945-3896
EMail: Yakov@Watson.IBM.
Braun & Rekhter [Page 6]
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
