As per Relevance of the word exchange, we have this rfc below:
Network Working Group Y.
Request for Comments: 1520 T.J. Watson Research Center, IBM Corp
Category: Informational C.
September 1993
Exchanging Routing Information Across Provider
in the CIDR
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard. Distribution of this memo
unlimited
1.
Classless Inter-Domain Routing (CIDR) has been adopted as a
to the scaling problem in the Internet. The overall CIDR
is described in [1]. The architecture for IP address assignment
CIDR is covered in [2] and [3]. The inter-domain routing
that are capable of supporting CIDR are covered in [4], [5], and [6].
The purpose of this document is twofold. First, it describes
alternatives for exchanging inter-domain routing information
domain boundaries, where one of the peering domain is CIDR-
and another is not. Second, it addresses the implications of
CIDR-capable inter-domain routing protocols (e.g., BGP-4, IDRP)
intra-domain routing
This document is not intended to cover all the cases (either real
imaginable). Rather, it focuses on what are viewed to be the
common cases. We expect that individual service providers will
this document as guidelines in establishing their
operational plans for the transition to CIDR
The concepts of "network service provider" and "network
subscriber" were introduced in [3]. For the sake of brevity, we
use the term "provider" or "service provider" here to mean
"network service provider" or "network service subscriber", since
the most part, the distinction is not important to this discussion
Furthermore, we use the same terms to refer to the network and to
organization that operates the network. We feel that the
makes it amply clear whether we are talking about hardware or people
and defining different terms would only make this paper harder
read
Rekhter & Topolcic [Page 1]
RFC 1520 CIDR Provider Information Exchange September 1993
This document defines a CIDR-capable provider as the provider
can perform correct IP packet forwarding (both internally and
other adjacent providers) when the inter-domain routing
acquired by the provider is expressed solely in terms of IP
prefixes (with no distinction between A/B/C class of addresses).
This document defines CIDR-capable forwarding as the ability of
router to maintain its forwarding table and to perform
forwarding of IP packets without making any assumptions about
class of IP addresses
This document defines CIDR reachability information as
information that may violate any assumptions about the class of
addresses. For instance, a contiguous block of class C
expressed as a single IP address prefix constitutes CIDR
information
2. Taxonomy of Service
For the purpose of this document we partition all service
into the following categories, based on the type and volume
inter-domain routing information a provider needs to acquire in
to meet its service requirements
- Requirements imposed on a service provider preclude it
using Default inter-domain route(s) -- we'll refer to such
pqrovider as a Type 1 provider
- Requirements imposed on a service provider allow it to rely
using one or more Default routes for inter-domain routing,
this information must be supplemented by requiring the
to acquire a large percentage of total Internet
information -- we'll refer to such a provider as a Type 2
provider
- Requirements imposed on a service provider allow it to rely
using one or more Default routes for inter-domain routing
however, to meet its service requirements the provider
supplement Default route(s) by acquiring a small percentage
total Internet routing information -- we'll refer to such
provider as a Type 3 provider
- Requirements imposed on a service provider allow it to
solely on using one or more Default routes for inter-
routing; no other inter-domain routing information need to
acquired -- we'll refer to such a provider as a Type 4 provider
Rekhter & Topolcic [Page 2]
RFC 1520 CIDR Provider Information Exchange September 1993
3. Assumptions on Deployment of CIDR in the
The document assumes that the CIDR deployment in the Internet
proceed as a three phase process
In the first phase all the major service providers will become CIDR
capable. Specifically, all the providers that can't rely on
Default route(s) for inter-domain routing (Type 1 providers)
expected to deploy BGP-4 and transition to CIDR during this phase.
is expected that CIDR reachability information will first appear
the Internet upon transition of all Type 1 service providers to CIDR
The second phase will commence upon completion of the first phase
During the second phase other service providers that are connected
the service providers that were transitioned to CIDR during the
phase will become CIDR-capable. Specifically, during the
phase it is expected that most of the providers that need to
a large percentage of the total Internet routing information (Type 2
provider) will become CIDR-capable. In addition, during the
phase some of the Type 3 providers may become CIDR-capable as well
This plan was agreed to by a number of major providers [8]. NSFNET'
steps to implement this plan are described in [9].
Finally, during the third phase the rest of the Type 3 providers
most of the Type 4 providers will transition to CIDR
It is expected that the duration of the first phase will
significantly shorter than duration of the second phase. Likewise
the duration of the second phase is expected to be shorter than
duration of the third phase
This document addresses the need for service providers to
inter-domain routing information during the second and third
of this deployment. During these phases, some providers will
CIDR-capable, and others will not. Hence this document
routing exchanges where one of the peers is CIDR-capable and
other is CIDR-incapable
4. Implications of CIDR on Interior
A CIDR-capable service provider can use the following two
to distribute exterior routing information to all of its
(both interior and border):
- utilize internal BGP/IDRP between all the
- use CIDR-capable IGPs (e.g., OSPF, IS-IS, RIP2)
Rekhter & Topolcic [Page 3]
RFC 1520 CIDR Provider Information Exchange September 1993
The first technique doesn't impose any addition requirements on
IGP within the provider. Additional information on implementing
first option is presented in [5] (see Section A.2.4).
The second technique allows the provider to reduce the utilization
internal BGP/IDRP, but imposes specific requirements on the intra
domain routing. It also requires the ability to inject inter-
routing information (acquired either via BGP or IDRP) into
intra-domain routing. Additional details on implementing the
option are provided in [7]. It is not expected that all the
enumerated in [7] will be widely needed. Therefore, it would
highly desirable to prioritize the features
Note that both of these techniques imply that all the routers
a CIDR-capable service provider need to be capable of CIDR-
forwarding
Discussion of which of the two techniques should be preferred
outside the scope of this document
5. Exchanging Inter-Domain Routing
At each phase during the transition to CIDR one of the
aspects of the Internet operations will be the exchange of inter
domain routing information between CIDR-capable providers and CIDR
incapable provider
When exchanging inter-domain routing information between a CIDR
capable provider and a CIDR-incapable provider, it is of
importance to take into account the view each side wants the other
present. This view has two distinct aspects
- the type of routing information exchanged (i.e., Default route
traditional (non-CIDR) reachability information,
reachability information
- routing information processing each side needs to do to
these views (e.g., ability to perform aggregation, ability
perform controlled de-aggregation
The exchange of inter-domain routing information is expected to
controlled by bilateral agreements between the directly
service providers. Consequently, the views each side wants of
other are expected to form an essential component of such agreements
To facilitate troubleshooting and problem isolation, the
agreements should be made accessible to other providers. One way
accomplish this is by placing them in a generally
Rekhter & Topolcic [Page 4]
RFC 1520 CIDR Provider Information Exchange September 1993
database. The details of how this can be implemented are outside
scope of this document. A possible way to accomplish this
described in [9].
Since the exchange of inter-domain routing information
provider boundaries occurs on a per peer basis, a border router
expected to provide necessary mechanisms (e.g., configuration)
will control exchange and processing of this information on a
peer basis
In the following sections we describe possible scenarios
exchanging inter-domain routing information. It is always
that one side is CIDR-capable and the other is not
5.1 Exchanging Inter-Domain Routing Information between CIDR-
providers and CIDR-incapable Type 2 (default with large
of explicit routes)
We expect the border router(s) within a CIDR-capable provider to
capable of aggregating inter-domain routing information they
from a CIDR-incapable Type 2 provider. The aggregation is
to be governed and controlled via a bilateral agreement
Specifically, the CIDR capable provider is expected to aggregate
the information the other side (the CIDR-incapable provider
requests. In other words, the aggregation shall be done by the CIDR
capable provider (the receiver) and only when agreed to by the CIDR
incapable provider (the sender).
Passing inter-domain routing information from a CIDR-capable
to a CIDR-incapable Type 2 provider will require an agreement
the two that would cover the following items
- under what conditions the CIDR-capable provider can pass
inter-domain Default route to the CIDR-incapable
- exchange of specific non-CIDR reachability
- controlled de-aggregation of CIDR reachability
Agreements that cover the first two items are already
within the Internet. Thus, the only additional factor introduced
CIDR is controlled de-aggregation. A CIDR-capable provider may
not to de-aggregate any CIDR reachability information, or to de
aggregate some or all of the CIDR reachability information
If a CIDR-capable provider does not de-aggregate CIDR
information, then its non-CIDR Type 2 peer can obtain
information from it either as non-CIDR reachability
Rekhter & Topolcic [Page 5]
RFC 1520 CIDR Provider Information Exchange September 1993
(explicit Class A/B/C network advertisement) or as an inter-
Default route. Since most of the current reachability information
the Internet is non-CIDR, a Type 2 provider would be able to
this information as explicit Class A/B/C network advertisements
the CIDR-capable provider, as it does now. Further, it is
that at least on a temporary basis (until the completion of
second phase of the transition) in a majority of cases, Type 2
providers should be able to use an inter-domain Default
(acquired from the CIDR-capable provider) as a way of dealing
forwarding to destinations covered by CIDR reachability information
Thus, it is expected that most of the cases involving a CIDR-
Type 2 provider and a CIDR-capable provider that does not
de-aggregation could be addressed by a combination of
specific non-CIDR reachability information and an inter-
Default route. Any inconvenience to a CIDR-incapable provider due
the use of an inter-domain Default route will be removed once
provider transitions to CIDR
On the other hand, a CIDR-capable provider may decide to
controlled de-aggregation of CIDR reachability information
Additional information on performing controlled de-aggregation can
found in [5] (Section 8). Special care must be taken when de
aggregating CIDR reachability information carried by a route with
ATOMIC_AGGREGATE path attribute. It is worth while pointing out
due to the nature of Type 2 provider (it needs to acquire a
percentage of total inter-domain routing information) it is
that the controlled de-aggregation would result in
configuration at the border router that performs the de-aggregation
5.2 Exchanging Inter-Domain Routing Information between CIDR-
providers and CIDR-incapable Type 3 (Default with few
routes)
In this case, as in the case described in Section 5.1, it is
that a border router in a CIDR-capable provider would be able
aggregate routing information it receives from a CIDR-incapable
3 provider. The aggregation is expected to be governed and
via a bilateral agreement. Specifically, the CIDR capable
is expected to aggregate only the information the CIDR-
provider requests
The only difference between this case and the case described
Section 5.1 is the fact that a CIDR-incapable provider requires
a small percentage of total inter-domain routing information. If
information falls into a non-CIDR category, then a Type 3
would be able to acquire it from a CIDR-capable provider. If this
CIDR reachability information, then in a majority of cases it
Rekhter & Topolcic [Page 6]
RFC 1520 CIDR Provider Information Exchange September 1993
expected that forwarding to destinations covered by this
could be handled via an inter-domain Default route
It is still expected that a border router in a CIDR-capable
would be able to aggregate routing information it receives from
CIDR-incapable Type 3 provider. The aggregation is expected to
governed and controlled via a bilateral agreement. Specifically,
CIDR capable provider is expected to aggregate only the
the other side (the CIDR-incapable provider) requests
5.3 Exchanging Inter-Domain Routing Information between CIDR-
providers and CIDR-incapable Type 4 (Default only)
Again, it is still expected that a border router in a CIDR-
provider would be able to aggregate routing information it
from a CIDR-incapable Type 4 provider. The aggregation is expected
be governed and controlled via a bilateral agreement. Specifically
the CIDR capable provider is expected to aggregate only
information the CIDR-incapable provider requests
The only difference between this case and the case described
Section 5.1 is the fact that CIDR-incapable provider would
require any inter-domain routing information, other than the
inter-domain route. Therefore, controlled de-aggregation of
reachability information is not an issue
6.
It is expected that the reduction in the global volume of
information will begin immediately upon completion of the first
of the transition to CIDR. The second phase will allow
bilateral arrangements between connected service providers
shifting the responsibility for routing information
towards the parties that are better suitable for it, and
significantly reducing the need for routing information de
aggregation. Thus, most of the gain achieved during the second
will come from simplifying bilateral agreements. The third phase
intended to complete the goals and objectives of the second phase
7.
This document was largely stimulated by the discussion that
place during the Merit/NSFNET Regional Tech Meeting in Boulder
January 21-22, 1993. We would like specifically
contributions by Peter Ford (Los Alamos National Laboratory),
Gerich (NSFNET/Merit), Susan Hares (NSFNET/Merit), Mark
(NSFNET/Merit), Bill Manning (Sesquinet/Rice University), and
Scudder (NSFNET/Merit).
Rekhter & Topolcic [Page 7]
RFC 1520 CIDR Provider Information Exchange September 1993
8.
[1] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter
Domain Routing (CIDR): An Address Assignment and
Strategy", RFC 1519, BARRNet, cisco, Merit, and OARnet,
1993.
[2] Gerich, E., "Guidelines for Management of IP Address Space",
1466, Merit, May 1993.
[3] Rekhter, Y., and T. Li, "An Architecture for IP
Allocation with CIDR", RFC 1518, T.J. Watson Research Center,
Corp., cisco Systems, September 1993.
[4] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
Work in Progress, June 1993.
[5] Rekhter, Y., and P. Gross, "Application of the Border
Protocol in the Internet", Work in Progress, September 1992.
[6] Hares, S., "IDRP for IP", Work in Progress, March 1993.
[7] Varadhan, K., "BGP4 OSPF Interaction", Work in Progress,
1993.
[8] Topolcic, C., "Notes on BGP-4/CIDR Coordination Meeting of 11
March 93", Informal Notes, March 1993.
[9] Knopper, M., "Aggregation Support in the NSFNET Policy
Database", RFC 1482, Merit, June 1993.
9. Security
Security issues are not discussed in this memo
Rekhter & Topolcic [Page 8]
RFC 1520 CIDR Provider Information Exchange September 1993
10. Authors'
Yakov
T.J. Watson Research Center, IBM
P.O. Box 218
Yorktown Heights, NY 10598
Phone: (914) 945-3896
EMail: yakov@watson.ibm.
Claudio
Corporation for National Research
1895 Preston White Drive, Suite 100
Suite 100
Reston, VA 22091
Phone: (703) 620-8990
EMail: topolcic@CNRI.Reston.VA.
Rekhter & Topolcic [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
