rfc1520.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                         Y. Rekhter
Request for Comments: 1520        T.J. Watson Research Center, IBM Corp.
Category: Informational                                      C. Topolcic
                                                                    CNRI
                                                          September 1993


       Exchanging Routing Information Across Provider Boundaries
                        in the CIDR Environment

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard.  Distribution of this memo is
   unlimited.

1.  Introduction

   Classless Inter-Domain Routing (CIDR) has been adopted as a solution
   to the scaling problem in the Internet. The overall CIDR architecture
   is described in [1]. The architecture for IP address assignment with
   CIDR is covered in [2] and [3]. The inter-domain routing protocols
   that are capable of supporting CIDR are covered in [4], [5], and [6].

   The purpose of this document is twofold. First, it describes various
   alternatives for exchanging inter-domain routing information across
   domain boundaries, where one of the peering domain is CIDR-capable
   and another is not.  Second, it addresses the implications of running
   CIDR-capable inter-domain routing protocols (e.g., BGP-4, IDRP) on
   intra-domain routing.

   This document is not intended to cover all the cases (either real or
   imaginable). Rather, it focuses on what are viewed to be the most
   common cases.  We expect that individual service providers will use
   this document as guidelines in establishing their specific
   operational plans for the transition to CIDR.

   The concepts of "network service provider" and "network service
   subscriber" were introduced in [3]. For the sake of brevity, we will
   use the term "provider"  or "service provider" here to mean either
   "network service provider" or "network service subscriber", since for
   the most part, the distinction is not important to this discussion.
   Furthermore, we use the same terms to refer to the network and to the
   organization that operates the network. We feel that the context
   makes it amply clear whether we are talking about hardware or people,
   and defining different terms would only make this paper harder to
   read.




Rekhter & Topolcic                                              [Page 1]

RFC 1520           CIDR Provider Information Exchange     September 1993


   This document defines a CIDR-capable provider as the provider that
   can perform correct IP packet forwarding (both internally and to
   other adjacent providers) when the inter-domain routing information
   acquired by the provider is expressed solely in terms of IP address
   prefixes (with no distinction between A/B/C class of addresses).

   This document defines CIDR-capable forwarding as the ability of a
   router to maintain its forwarding table and to perform correct
   forwarding of IP packets without making any assumptions about the
   class of IP addresses.

   This document defines CIDR reachability information as reachability
   information that may violate any assumptions about the class of IP
   addresses. For instance, a contiguous block of class C networks
   expressed as a single IP address prefix constitutes CIDR reachability
   information.

2.  Taxonomy of Service Providers

   For the purpose of this document we partition all service providers
   into the following categories, based on the type and volume of
   inter-domain routing information a provider needs to acquire in order
   to meet its service requirements:

      - Requirements imposed on a service provider preclude it from
        using Default inter-domain route(s) -- we'll refer to such a
        pqrovider as a Type 1 provider.

      - Requirements imposed on a service provider allow it to rely on
        using one or more Default routes for inter-domain routing, but
        this information must be supplemented by requiring the provider
        to acquire a large percentage of total Internet routing
        information -- we'll refer to such a provider as a Type 2
        provider.

      - Requirements imposed on a service provider allow it to rely on
        using one or more Default routes for inter-domain routing;
        however, to meet its service requirements the provider must
        supplement Default route(s) by acquiring a small percentage of
        total Internet routing information -- we'll refer to such a
        provider as a Type 3 provider.

      - Requirements imposed on a service provider allow it to rely
        solely on using one or more Default routes for inter-domain
        routing; no other inter-domain routing information need to be
        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 Internet

   The document assumes that the CIDR deployment in the Internet will
   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 using
   Default route(s) for inter-domain routing (Type 1 providers) are
   expected to deploy BGP-4 and transition to CIDR during this phase. It
   is expected that CIDR reachability information will first appear in
   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 to
   the service providers that were transitioned to CIDR during the first
   phase will become CIDR-capable.  Specifically, during the second
   phase it is expected that most of the providers that need to acquire
   a large percentage of the total Internet routing information (Type 2
   provider) will become CIDR-capable.  In addition, during the second
   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's
   steps to implement this plan are described in [9].

   Finally, during the third phase the rest of the Type 3 providers and
   most of the Type 4 providers will transition to CIDR.

   It is expected that the duration of the first phase will be
   significantly shorter than duration of the second phase.  Likewise,
   the duration of the second phase is expected to be shorter than the
   duration of the third phase.

   This document addresses the need for service providers to exchange
   inter-domain routing information during the second and third phases
   of this deployment. During these phases, some providers will be
   CIDR-capable, and others will not. Hence this document considers
   routing exchanges where one of the peers is CIDR-capable and the
   other is CIDR-incapable.

4.  Implications of CIDR on Interior Routing

   A CIDR-capable service provider can use the following two techniques
   to distribute exterior routing information to all of its routers
   (both interior and border):

      - utilize internal BGP/IDRP between all the routers

      - 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 the
   IGP within the provider. Additional information on implementing the
   first option is presented in [5] (see Section A.2.4).

   The second technique allows the provider to reduce the utilization of
   internal BGP/IDRP, but imposes specific requirements on the intra-
   domain routing. It also requires the ability to inject inter-domain
   routing information (acquired either via BGP or IDRP) into the
   intra-domain routing. Additional details on implementing the second
   option are provided in [7]. It is not expected that all the features
   enumerated in [7] will be widely needed. Therefore, it would be
   highly desirable to prioritize the features.

   Note that both of these techniques imply that all the routers within
   a CIDR-capable service provider need to be capable of CIDR-based
   forwarding.

   Discussion of which of the two techniques should be preferred is
   outside the scope of this document.

5.  Exchanging Inter-Domain Routing Information

   At each phase during the transition to CIDR one of the essential
   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 utmost
   importance to take into account the view each side wants the other to
   present. This view has two distinct aspects:

      - the type of routing information exchanged (i.e., Default route,
        traditional (non-CIDR) reachability information, CIDR
        reachability information)

      - routing information processing each side needs to do to maintain
        these views (e.g., ability to perform aggregation, ability to
        perform controlled de-aggregation)

   The exchange of inter-domain routing information is expected to be
   controlled by bilateral agreements between the directly connected
   service providers. Consequently, the views each side wants of the
   other are expected to form an essential component of such agreements.

   To facilitate troubleshooting and problem isolation, the bilateral
   agreements should be made accessible to other providers.  One way to
   accomplish this is by placing them in a generally accessible



Rekhter & Topolcic                                              [Page 4]

RFC 1520           CIDR Provider Information Exchange     September 1993


   database. The details of how this can be implemented are outside the
   scope of this document. A possible way to accomplish this is
   described in [9].

   Since the exchange of inter-domain routing information across
   provider boundaries occurs on a per peer basis, a border router is
   expected to provide necessary mechanisms (e.g., configuration) that
   will control exchange and processing of this information on a per
   peer basis.

   In the following sections we describe possible scenarios for
   exchanging inter-domain routing information. It is always assumed
   that one side is CIDR-capable and the other is not.

5.1  Exchanging Inter-Domain Routing Information between CIDR-capable
     providers and CIDR-incapable Type 2 (default with large proportion
     of explicit routes) providers

   We expect the border router(s) within a CIDR-capable provider to be
   capable of aggregating inter-domain routing information they receive
   from a CIDR-incapable Type 2 provider.  The aggregation is expected
   to be governed and controlled via a bilateral agreement.
   Specifically, the CIDR capable provider is expected to aggregate only
   the information the other side (the CIDR-incapable provider)