As per Relevance of the word aggregation, we have this rfc below:
Network Working Group Mark
Request for Comments: 1482 Steven J.
Merit/
June 1993
Aggregation Support in the NSFNET Policy-Based Routing
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard. Distribution of this memo
unlimited
This document describes plans for support of route aggregation,
specified in the descriptions of Classless Inter-Domain
(CIDR) [1] and the BGP-4 protocol [2], by the NSFNET Backbone
Service. Mechanisms for exchange of route aggregates between
backbone service and regional/midlevel networks are specified
Additionally, the memo proposes the implementation of an
Registry which can be used by network service providers to
information about the use of aggregation. Finally, the
impact of incorporating CIDR and aggregation is considered,
an analysis of how routing table size will be affected. This
analysis will be used to modify the deployment plan, if necessary,
maximize operational stability
1.
The Internet network service provider community and router
(as well as the IESG and various IETF working groups) have
that the time for deployment of route aggregation is upon us.
topic has been discussed in the BGP-D, NJM and ORAD working groups
several IETF meetings; it was a discussion topic of the
Regional Techs' Meetings in January and June, 1993; and it was also
topic of several meetings of the Federal Engineering Planning
and Engineering and Operations Working Group of the Federal
Council
All have generally agreed that Summer, 1993 is the time to
BGP-4 and CIDR aggregation. Each of the parties is responsible
its own aspect of CIDR implementation and practice. This
describes Merit's plans for support of route aggregation on
NSFNET, and a proposal for implementing a database of
information for use by network providers
Knopper & Richardson [Page 1]
RFC 1482 Routing Aggregation Support July 1993
2. Aggregation Support by the Backbone
The NSFNET backbone service includes a Policy-Based Routing
system which currently holds the set of network numbers that
accepted by the backbone service with a list of Autonomous
numbers from which announcements of these network numbers
expected. In order to implement CIDR, the database system will
modified to allow aggregation of routing information to
configured
The NSFNET will (initially) not support de-aggregation on
outbound announcements. See section 2.3.
2.1 Current Configuration
2.1.1 Inbound
An example of the way a network number is currently configured is
follows
35 1:237 2:233 3:183 4:266 5:267 6:1225
This shows that network number 35 (ie. 35.0.0.0, a class A
number) is configured on the T3 backbone such that
announcements are expected from up to 6 autonomous systems.
primary path is via AS 237, secondary is via AS 233, etc
2.1.2 Outbound
Currently the NSFNET database has a list of AS's or network
for each neighbor AS that are announced by the backbone to that AS
These announcements are specified currently by "announcetoAS
statements--which implement policies submitted by midlevels
Merit--and then included in the ANSnet router configuration files
There are two forms of these statements. The first form uses
"norestrict" clause and indicates that all of the network
within each AS in the list should be announced to the
midlevel AS. For example
announcetoAS 42 norestrict ASlist 22 26 38 60 68
In this example, the NSFNET is configured to announce to
midlevel AS 42, all networks in the routing table that were
from AS's 22, 26, 38, 60 and 68.
If the "norestrict" keyword is changed to "restrict", this
that an explicit announce list of network numbers for the AS
specified in the configuration file. The NSFNET will only
Knopper & Richardson [Page 2]
RFC 1482 Routing Aggregation Support July 1993
network numbers that were announced by the AS's in the list, *AND
which appear in the "restrict list" of network numbers
separately by the midlevel
For example
announcetoAS 42 restrict ASlist 22
announce 192.135.237
These statements mean that AS 42 only wishes to hear
from the backbone about the nets in AS 22 which are explicitly
here (i.e., net 192.135.237).
It is also possible, when using the "restrict" keyword, to
specific "noannounce" lines. Those indicate that all of the
listed in the routing table for the AS should be announced
those listed on the noannounce clauses. (There is also
"noannouncetoAS" statement[4].)
2.2 New Configuration Features for
There will be three new capabilities for which the backbone
can be configured to support aggregation. The first two
aggregates to be accepted and stored in the backbone routing
based on announcements by the regional network (autonomous system
AS) peers. The third allows the announcement of aggregates to the
neighbor peers. The following sections give examples of the
features
We use the notation to describe an aggregate
This refers to the IP prefix "net-IP", with a mask which
"prefix-length" 1's as counted from the high-order end. For example
<192.64.128 17> is equivalent to <192.64.128, 255.255.128.0> [5].
(The form using prefix-length rather than the mask is more compact.)
2.2.1 NSFNET accepts
In this case the regional peer router is CIDR-capable (i.e.,
BGP-4) and the announcement comes into the backbone as an IP
prefix
To illustrate this in the spirit of sec. 2.1.1:
<192.64.128 17> 1:189 2:24 3:267
In this example, independent of the "class" of IP network number,
aggregate containing network addresses matching a pattern in
Knopper & Richardson [Page 3]
RFC 1482 Routing Aggregation Support July 1993
the first 17 bits match the prefix 192.64.128 will be accepted
announcements to the NSFNET service. The primary path
destinations covered by the prefix is expected via AS 189,
secondary, via AS 24, etc
2.2.2 NSFNET aggregates by
The other method of incorporating CIDR aggregate announcements
the backbone routing tables is that of aggregation by proxy. In
case, the backbone is configured to perform aggregation on behalf
a peer AS which is not configured to announce the aggregate to
backbone (i.e., an AS which does not connect to the backbone via
CIDR-capable peer).
An example of this aggregation technique is
proxy <192.64.128 17> 1:189 2:24 3:267
if <192.64.192 24>
or <192.64.129 24>
or <192.64.167 24>
(Note: the syntax used in this document is arbitrary and is only
to illustrate the method. The syntax to be used in actual
requests is to be determined.)
In this example, the aggregate <192.64.128 17> will be stored
propagated within the backbone as an aggregate under a set
conditions. Initially, the GateD support will allow an "OR" list
conditions such that if one of the aggregates in the list matches
proxy aggregate will be stored[6]. For the case above, this
that, if any of the CIDR aggregates
<192.64.192 24>
<192.64.129 24>
<192.64.167 24>
(which--under the current, class-based IP address system--
equivalent to the class C net numbers 192.64.192, 192.64.129,
192.64.167, respectively) is heard, the backbone router will act
though it heard the announcement of the single CIDR
<192.64.128 17>.
2.2.3 NSFNET announces
The functionality of the current system, as outlined in sec. 2.1.2,
above, will continue to exist once CIDR is implemented.
"norestrict" function (or its equivalent in the new software)
specify that all network reachability information received from a
Knopper & Richardson [Page 4]
RFC 1482 Routing Aggregation Support July 1993
of Autonomous Systems, including any aggregates, will be announced
It should also be possible to use to the equivalents of
"restrict" keyword and the "announce" (or "noannounce") statement
order to limit the announcements of the aggregations within an AS
any desired subset
2.3 Specifically Unsupported Capabilities, Limits of Initial
There are some aspects of aggregation which will specifically not
supported in the initial deployment of CIDR capabilities on
NSFNET backbone. In particular, when the NSFNET service
routes to midlevel peers, de-aggregation will not be performed [3].
Therefore, a peer which needs to receive full routing
should run a protocol which supports CIDR (initially, BGP-4; later
IDRP). Peer networks using default routing will be able to
networks that are part of aggregated routing information across
backbone (as in section 6.4 of [3]).
3. CIDR Aggregate
In discussions with network service providers, it has become
that there is a great need for sharing of aggregate information;
is necessary to fulfill the coordination referred to in sec. 2.3.
Beyond the need to implement CIDR aggregation facilities in
NSFNET Policy-Based Routing Database (as described in section 2),
there is a clear need to have a separate database which will
aggregate information from any Autonomous System to be stored
made available for easy electronic retrieval. This information can
used for routing coordination and policy configuration in the larger
non-NSFNET-centric, inter-domain context
One of the expected uses of such a database is to help determine,
CIDR matures, the granularity of aggregation of network
information with respect to policy. The useful scope of
is the subject of much discussion[5][7], and will be influenced
such considerations as how network number allocation has
handled, and whether the network provider has renumbered its
networks to conform to CIDR aggregation boundaries. Rules and
regarding network number allocation with CIDR are discussed in [8]
and [7].
In order further these goals, Merit proposes to implement a "
Aggregate Registry" to provide sharing of aggregate information
the Internet inter-domain routing community. Initially, this will
a simple database without much structure. It is not intended to
only aggregates which are announced or accepted by the
service; rather, it should be a community registry that all will
invited to use and make use of
Knopper & Richardson [Page 5]
RFC 1482 Routing Aggregation Support July 1993
The Aggregate Registry will consist of a list of
announcement statements. Each statement consists of four types
information, along with contact information
1) CIDR Aggregate: The aggregate identifier, consisting of
network number prefix and the prefix length. For example
<192.29.128 16>.
2) Home AS: The source AS number for the aggregate. That is,
AS number of the network service provider that
aggregates the network reachability information into the
for announcement to its neighbors
3a) Announcing AS: An AS number that announces this aggregate
its neighbor AS's
3b) Neighbor AS list: A list of neighbor AS's to whom
aggregate will be announced by the AS named in 3a
4) Contact information: eg. e-mail address and name or NIC
of the administrative and technical contacts for the source AS
Thus, a given aggregate is listed once as announced by its source AS
It may then be listed once again per transit AS which announces
aggregate downstream to its neighbors. For example, the
aggregate <199.29.128 16> could be listed as
CIDR aggregate home ann
(prefix-length) AS AS AS list
-----------------------------------------------------------
<199.29.128 16> 100 100 200 201 690 fred@nowhere.
<199.29.128 16> 100 690 266 267 1225...
<199.29.128 16> 100 200 297 372
<199.29.128 16> 100 201 771 1262
Note: This can be represented using the syntax used for
in the RIPE-81 paper[9].
Here, AS 100 (the source AS) performs any aggregation and
the CIDR aggregate <199.29.128 16> to neighbor ASs 200, 201, and 690.
In turn, AS 200 announces this same aggregate to its neighbor ASs 297
and 372; further lines show announcements of the given aggregate
AS 690 and AS 201.
Note that this registry reflects both the simple list of
that are supported by the union of network providers, as well
information on inter-domain topology for the Internet. Merit
implement procedures for registering any network provider'
Knopper & Richardson [Page 6]
RFC 1482 Routing Aggregation Support July 1993
aggregates in the Registry; for those CIDR aggregates carried
the NSFNET backbone, Merit will implement procedures for
this Registry with the process of updating the aggregate
announcements. Requests to update the information will be
via e-mail or on-line registration tools
4. Effects of CIDR on Operational Aspects of the
The introduction of CIDR will clearly necessitate various
beyond the introduction of new router software. In particular,
and other network service providers will have to adjust tools
reports, and procedures as CIDR is implemented and evolved, and
changes will have to be coordinated in order to ensure a
transition to the CIDR-capable Internet
While this document is by no means exhaustive, some of the
affected are discussed briefly below; what is intended is to
an awareness of some these changes, so as to initiate thinking
and planning for this transition. While it is obvious that CIDR
policy routing imply greater coordination of many
matters, it is not clear how profoundly this will affect the day-to
day running of the Internet
(Note: Aspects of the actual phased deployement of CIDR are
in [3] and [10].)
4.1 NSFNET Configuration Files and Reports; Neighbor AS
The addition of CIDR capability to the NSFNET Policy-Based
Database, as outlined in sec. 2, will require the updating of
least the following reports which are currently produced by
(and available via anonymous FTP from nic.merit.edu):
ans_core.now as-site.now country.now net-comp.now net-net.
net-ter.now non-us.
Any tools which access this information, such as the various
or scripts released by Merit or developed by others, will have to
changed
However, the most striking change will be in the transition
rcp_routed to GateD; it is very different in important particulars
and follows different conceptual principles [11].
Network providers which develop any part of their configuration
from parsing the NSFNET configuration files or reports *MUST*
for these changes in order to help themselves and the
community achieve a smooth transition to CIDR
Knopper & Richardson [Page 7]
RFC 1482 Routing Aggregation Support July 1993
4.2 Routing and Administrative
In this document, Merit has stated its commitment to supporting
through both changing policies related to administering the
and developing a CIDR Aggregate Registry for the broader
community
In addition to these changes, here are some of the other policies
administrative and routing, which must to be coodinated in order
achieve optimum benefits of CIDR
- policies of the InterNIC and of network service providers
assigning (CIDR) IP nets and blocks, as mentioned above
- policies of the various ASs in coordination of transit and
routing policies
- policies of registration of new networks, from the InterNIC
network provider, through the CIDR Aggregate Registry, etc.;
- policies related to coordination of routing changes
- coordination of routing policies, in general, to avoid
classes of routing problems due to new methods of routing
4.3 Realtime
Issues which have not been examined in detail are
- debugging of routing/connectivity problems
- stability and other properties of routing under
scenarios of CIDR configuration and network topology
- explicit specification of routing decision algorithms to
routing anomalies
- increased network load due to packets traversing an AS, such
the NSFNET backbone, before being discarded due to addressing
"hole" in a CIDR aggregate
4.4 Estimate of Reductions in Routing
An argument in favor of the implementation CIDR is the effect
it should have upon the NSFNET and other routing tables [1] [5].
burning question is: What is the magnitude of this effect? In
of the various issues to be dealt with, this is an
consideration
Knopper & Richardson [Page 8]
RFC 1482 Routing Aggregation Support July 1993
In terms of the immediate savings in reduction of the NSFNET
routing tables, if a set of aggregates were done all at once,
recent calculation--which might be characterized as an
estimate using a pessimistic algorithm (it looks for the
continuous block of addresses announced to the NSFNET backbone)--
yields [12]:
861 size 2 saving 861
286 size 4 saving 858
117 size 8 saving 819
67 size 16 saving 1005
13 size 32 saving 403
3 size 64 saving 189
1347 total saving 4135 announcements of 12348 (33%).
Here, the first column represents the number of CIDR aggregates
the given "size," and shows the corresponding reduction in
announcements due to the adoption of this aggregate. (A
aggregate of "size " is one which encompasses class A, B, or
networks; the 67 "size 16" CIDR aggregates actually
announcements for 16 separate networks into a single net aggregate.)
It is unclear, at this time, whether or not the true savings would
of this magnitude, but the extended report provides a basis
discussion [12].
The other aspect of impact upon the routing tables, the reduction
the rate of growth (and the concomitant slowing of the rate
exhaustion of IP address space), is an entirely different matter
Simple calculations related to the rate of class B address
exhaustion indicate that CIDR-conformant policies of the
with respect to address assignment is helping [1].
Clearly, more detailed analysis is desirable in order to
understand the realistic gains of the CIDR deployment process,
initially and in the longer term
5. Conclusions and Next
Implementation of CIDR is underway, but there is still a fair
of planning and discussion that is needed for a
transition. Merit is proposing specific functions for
aggregation that will be supported by the NSFNET, as well as a
Aggregate Registry that can serve as the basis for inter-
routing coordination
The Aggregate Registry will allow a set of tools to be developed
can facilitate the design of aggregation policy. A query tool
allow lookup of aggregation information for a given network
Knopper & Richardson [Page 9]
RFC 1482 Routing Aggregation Support July 1993
aggregate would be very useful. Additional database
will also be desired for more powerful queries. It is specifically
goal to work with RIPE to make sure that the Merit and RIPE
approaches are compatible and allow interworking of tools. An
topology database would be most useful in routing
determination and coordination as well
In addition to these areas, many other issues require further work
order to develop the operational framework necessary for
successful use of CIDR on the Internet. It is critical that
deployment of CIDR and related tools to preserve address and
table space must not compromise the operational stability of
NSFNET and the wider Internet
6. Security
Security issues are not discussed in this document
7.
The authors would like to acknowledge the following persons,
comments and discussions have helped to shape this document
Dennis Ferguson, Advanced Network and Services, Inc
Jeffrey Honig, Cornell
William Manning, Rice University/
The Merit Internet Engineering and Network
Systems groups
8. Authors'
Knopper, Mark A
Merit Network, Inc
1071 Beal Ave
Ann Arbor, MI 48109-2103
e-mail: mak@merit.
phone: (313) 763-6061
fax: (313) 747-3745
Richardson, Steven J
Merit Network, Inc
1071 Beal Ave
Ann Arbor, MI 48109-2103
e-mail: sjr@merit.
phone: (313) 747-4813
fax: (313) 747-3745
Knopper & Richardson [Page 10]
RFC 1482 Routing Aggregation Support July 1993
9.
[1] Fuller, V., Li, T., Yu, J., and Varadhan, K., "Supernetting:
Address Assignment and Aggregation Strategy", RFC1338, Update
Work in Progress, June 1992.
[2] Rekhter, Y., and Li, T., "A Border Gateway Protocol 4", Work
Progress, April 1993.
[3] Topolcic, C., "Notes of BGP-4/CIDR Coordination Meeting of 11
March 93", Work in Progress, March 1993.
[4] Villamizer, C., in a document describing rcp_routed.conf
and syntax, May, 1993.
[5] Syntax used in Ford, P., Rekhter, Y., Braun, H-W., "
the Routing and Addressing of IP", IEEE Network, pp. 10-15,
1993.
[6] Ferguson, D., private correspondence, March, 1993.
[7] Rekhter, Y., and Li, T., "An Architecture for IP
Allocation with CIDR", Work in Progress, February, 1993.
[8] Gerich, E., "Guidelines for Management of IP Address Space",
RFC1466, May 1993.
[9] Bates, T., Jouanigot, J-M., Karrenberg, D., Lothberg, P.,
Terpstra, M., "Representation of IP Routing Policies in the
Database" (ripe-81), Work in Progress, February, 1993.
[10] Rekhter, Y., and Topolcic, C., "Exchanging Routing
Across Provider/Subscriber Boundaries in the CIDR Environment",
Work in Progress, April 1993.
[11] Fedor, M., Honig, J., Coltun, R., Ferguson, D., "gated
config(5)" manpage, from the "gated-R3_0Beta_2" distribution, 7
October 1992.
[12] Johnson, D., analysis available via anonymous FTP
merit.edu:/pub/nsfnet/cidr/auto-aggregates, June 1993.
[13] Topolcic, C., "Schedule for IP Address Space
Guidelines", RFC1367, October, 1993.
Knopper & Richardson [Page 11]
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
