⭐ 欢迎来到虫虫下载站! | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站

📄 rfc1932.txt

📁 RFC 的详细文档!
💻 TXT
📖 第 1 页 / 共 5 页
字号:















Cole, Shur & Villamizar      Informational                     [Page 16]

RFC 1932           IP over ATM: A Framework Document          April 1996


                                .----------.
                       ---------<  Non-ATM :
          .-------.   /       /-<  Subnet  >-\
          :Sub-ES >--/        :  ----------  :
           -------            :              :
                              :              :
                           .--^---.       .--^---.
                           :Router:       :Router:
                            -v-v--         -v-v--
                             : :            : :
                  .--------. : : .--------. : : .--------.
      .-------.   :        >-/ \-<        >-/ \-<        :   .-------.
      :Sub-ES :---: Subnet :-----: Subnet :-----: Subnet :---:Sub-ES :
       -------    :        :     :        :     :        :    -------
                   --------       ---v----       --------
                                     :
                                  .--^----.
                                  :Sub-ES :
                                   -------

    Figure 3: A configuration with both ATM-based and non-ATM based
                                subnets.

   For example, figure 3 shows an end-to-end configuration consisting of
   four components, three of which are ATM technology based, while the
   fourth is a standard IP subnet based on non-ATM technology.  End-
   systems (either hosts or routers) attached to the ATM-based networks
   may communicate either using the Classical IP model or directly via
   ATM (subject to policy constraints).  Such nodes may communicate
   directly at the IP level without necessarily needing an intermediate
   router, even if end-systems do not share a common IP-level network
   prefix.  Communication with end-systems on the non-ATM-based
   Classical IP subnet takes place via a router, following the Classical
   IP model (see Section 8.1 below).

   Many of the problems and issues associated with creating such direct
   connections across subnet boundaries were originally being addressed
   in the IETF's IPLPDN working group and the IP over ATM working group.
   This area is now being addressed in the Routing over Large Clouds
   working group.  Examples of work performed in the IPLPDN working
   group include short-cut routing (proposed by P. Tsuchiya) and
   directed ARP RFC-1433 [5] over SMDS networks.  The ROLC working group
   has produced the distributed ARP server architectures and the NBMA
   Address Resolution Protocol (NARP) [7].  The Next Hop Resolution
   Protocol (NHRP) is still work in progress, though the ROLC WG is
   considering advancing the current document.  Questions/issues
   specifically related to defining a capability to cross IP subnet
   boundaries include:



Cole, Shur & Villamizar      Informational                     [Page 17]

RFC 1932           IP over ATM: A Framework Document          April 1996


   o How can routing be optimized across multiple logical IP subnets
     over both a common ATM based and a non-ATM based infrastructure.
     For example, in Figure 3, there are two gateways/routers between
     the non-ATM subnet and the ATM subnets.  The optimal path
     from end-systems on any ATM-based subnet to the non ATM-based
     subnet is a function of the routing state information of the two
     routers.

   o How to incorporate policy routing constraints.

   o What is the proper coupling between routing and address
     resolution particularly with respect to off-subnet communication.

   o What are the local procedures to be followed by hosts and
     routers.

   o Routing between hosts not sharing a common IP-level (or L3)
     network prefix, but able to be directly connected at the NBMA
     media level.

   o Defining the details for an efficient address resolution
     architecture including defining the procedures to be followed by
     clients and servers (see RFC-1433 [5], RFC-1735 [7] and NHRP).

   o How to identify the need for and accommodate special purpose SVCs
     for control or routing and high bandwidth data transfers.

   For ATM (unlike other NBMA media), an additional complexity in
   supporting IP routing over these ATM internets lies in the
   multiplicity of address formats in UNI 3.0 [4].  NSAP modeled address
   formats only are supported on "private ATM" networks, while either 1)
   E.164 only, 2) NSAP modeled formats only, or 3) both are supported on
   "public ATM" networks.  Further, while both the E.164 and NSAP
   modeled address formats are to be considered as network points of
   attachment, it seems that E.164 only networks are to be considered as
   subordinate to "private networks", in some sense.  This leads to some
   confusion in defining an ARP mechanism in supporting all combinations
   of end-to-end scenarios (refer to the discussion in Appendix A on the
   possible scenarios to be supported by ARP).

7.  Extensions to IP Routing

   RFC-1620 [3] describes the problems and issues associated with direct
   connections across IP subnet boundaries in greater detail, as well as
   possible solution approaches.  The ROLC WG has identified persistent
   routing loop problems that can occur if protocols which lose
   information critical to path vector routing protocol loop suppression
   are used to accomplish direct connections across IP subnet



Cole, Shur & Villamizar      Informational                     [Page 18]

RFC 1932           IP over ATM: A Framework Document          April 1996


   boundaries.

   The problems may arise when a destination network which is not on the
   NBMA network is reachable via different routers attached to the NBMA
   network.  This problem occurs with proposals that attempt to carry
   reachability information, but do not carry full path attributes (for
   path vector routing) needed for inter-AS path suppression, or full
   metrics (for distance vector or link state routing even if path
   vector routing is not used) for intra-AS routing.

   For example, the NHRP protocol may be used to support the
   establishment of direct connections across subnetwork boundaries.
   NHRP assumes that routers do run routing protocols (intra and/or
   inter domain) and/or static routing.  NHRP further assumes that
   forwarding tables constructed by these protocols result in a steady
   state loop-free forwarding.  Note that these two assumptions do not
   impose any additional requirements on routers, beyond what is
   required in the absence of NHRP.

   NHRP runs in addition to routing protocols, and provides the
   information that allows the elimination of multiple IP hops (the
   multiple IP hops result from the forwarding tables constructed by the
   routing protocols) when traversing an NBMA network.  The IPATM and
   ROLC WGs have both expended considerable effort in discussing and
   coming to understand these limitations.

   It is well-known that truncating path information in Path Vector
   protocols (e.g., BGP) or losing metric information in Distance Vector
   protocols (e.g., RIP) could result in persistent forwarding loops.
   These loops could occur without ATM and without NHRP.

   The combination of NHRP and static routing alone cannot be used in
   some topologies where some of the destinations are served by multiple
   routers on the NBMA. The combination of NHRP and an intra-AS routing
   protocol that does not carry inter-AS routing path attributes alone
   cannot be used in some topologies in which the NBMA will provide
   inter-AS transit connectivity to destinations from other AS served by
   multiple routers on the NBMA.

   Figure 4 provides an example of the routing loops that may be formed
   in these circumstances.  The example illustrates how the use of NHRP
   in the environment where forwarding loops could exist even without
   NHRP (due to either truncated path information or loss of metric
   information) would still produce forwarding loops.

   There are many potential scenarios for routing loops.  An example is
   given in Figure 4.  It is possible to produce a simpler example where
   a loop can form.  The example in Figure 4 illustrates a loop which



Cole, Shur & Villamizar      Informational                     [Page 19]

RFC 1932           IP over ATM: A Framework Document          April 1996


   will persist even if the protocol on the NBMA supports redirects or
   can invalidate any route which changes in any way, but does not
   support the communication of full metrics or path attributes.

    .----.    .----.
    : H1 >----< S1 :         Notes:
     ----      vvvv        H#n == host #n
               / : \        R#n == router #n
              /  :  \        S#n == subnet #n
      /------/   :   \
      :          :    \        S2 to R3 breaks
   .--^---.   .----. .-^--.
   :      :   : R4 : : R6 :
   : NBMA :    --v-   --v-      See the text for
   :      :      :      :       details of the
    -v--v-       =      =       looping conditions
     :   \       = SLOW =       and mechanisms
     :  .-^--.   = LINK =
     :  : R2 :   =      =
     :   --v-    :      :
     :     :  .--^-. .--^-.
   .-^--.  :  : R5 : : R7 :
   : R8 :  :   --v-   --v-
    --v-    \    :      :
      :      \  /       :
       \    .-^^-.   .--^-.
        \   : S2 :   : S4 :
         \   --v-     --v-
          \     \      /
           \     \    /
            \    .^--^.
             \   : R3 :    path before the break is
              \   -v--    H1->S1->R1->NBMA->R2->S2->R3->H2
               \  /
     .----.   .-^^-.    path after the break is
     : H2 >---< S3 :    H1->S1->R1->NBMA->R2->S2->R5->R4->S1
      ----     ----         \------<--the-loop--<-------/

      Figure 4:  A Routing Loop Due to Lost PV Routing Attributes.

   In the example in Figure 4, Host 1 is sending traffic toward Host 2.
   In practice, host routes would not be used, so the destination for
   the purpose of routing would be Subnet 3.  The traffic travels by way
   of Router 1 which establishes a "cut-through" SVC to the NBMA next-
   hop, shown here as Router 2.  Router 2 forwards traffic destined for
   Subnet 3 through Subnet 2 to Router 3.  Traffic from Host 1 would
   then reach Host 2.




Cole, Shur & Villamizar      Informational                     [Page 20]

RFC 1932           IP over ATM: A Framework Document          April 1996


   Router 1's cut-through routing implementation caches an association
   between Host 2's IP address (or more likely all of Subnet 3) and
   Router 2's NBMA address.  While the cut-through SVC is still up, Link
   1 fails.  Router 5 loses it's preferred route through Router 3 and
   must direct traffic in the other direction.  Router 2 loses a route
   through Router 3, but picks up an alternate route through Router 5.
   Router 1 is still directing traffic toward Router 2 and advertising a
   means of reaching Subnet 3 to Subnet 1.  Router 5 and Router 2 will
   see a route, creating a loop.

   This loop would not form if path information normally carried by
   interdomain routing protocols such as BGP and IDRP were retained
   across the NBMA. Router 2 would reject the initial route from Router
   5 due to the path information.  When Router 2 declares the route to
   Subnet 3 unreachable, Router 1 withdraws the route from routing at
   Subnet 1, leaving the route through Router 4, which would then reach
   Router 5, and would reach Router 2 through both Router 1 and Router
   5.  Similarly, a link state protocol would not form such a loop.

   Two proposals for breaking this form of routing loop have been
   discussed.  Redirect in this example would have no effect, since
   Router 2 still has a route, just has different path attributes.  A
   second proposal is that is that when a route changes in any way, the
   advertising NBMA cut-through router invalidates the advertisement for
   some time period.  This is similar to the notion of Poison Reverse in
   distance vector routing protocols.  In this example, Router 2 would
   eventually readvertise a route since a route through Router 6 exists.
   When Router 1 discovers this route, it will advertise it to Subnet 1
   and form the loop.  Without path information, Router 1 cannot
   distinguish between a loop and restoration of normal service through
   the link L1.

   The loop in Figure 4 can be prevented by configuring Router 4 or
   Router 5 to refuse to use the reverse path.  This would break backup
   connectivity through Router 8 if L1 and L3 failed.  The loop can also
   be broken by configuring Router 2 to refuse to use the path through
   Router 5 unless it could not reach the NBMA. Special configuration of
   Router 2 would work as long as Router 2 was not distanced from Router
   3 and Router 5 by additional subnets such that it could not determine
   which path was in use.  If Subnet 1 is in a different AS or RD than
   Subnet 2 or Subnet 4, then the decision at Router 2 could be based on
   path information.








⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -