rfc1932.txt

RFC 的详细文档！

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


                        .--------.    .--------.
                        : Router :    : Router :
                         --v-v---      ---v-v--
                           : :            : :
   .--------.   .--------. : : .--------. : : .--------.   .--------.
   : Sub-ES :---: Subnet :-/ \-: Subnet :-/ \-: Subnet :---: Sub-ES :
    --------     --------       --------       --------     --------

 Figure 5: The Classical IP model as a concatenation of three separate
                            ATM IP subnets.

   In order for loops to be prevented by special configuration at the
   NBMA border router, that router would need to know all paths that
   could lead back to the NBMA. The same argument that special
   configuration could overcome loss of path information was posed in
   favor of retaining the use of the EGP protocol defined in the now
   historic RFC-904 [11].  This turned out to be unmanageable, with
   routing problems occurring when topology was changed elsewhere.

8.  IP Over ATM Proposals

8.1  The Classical IP Model

   The Classical IP Model was suggested at the Spring 1993 IETF meeting
   [8] and retains the classical IP subnet architecture.  This model
   simply consists of cascading instances of IP subnets with IP-level
   (or L3) routers at IP subnet borders.  An example realization of this
   model consists of a concatenation of three IP subnets.  This is shown
   in Figure 5.  Forwarding IP packets over this Classical IP model is
   straight forward using already well established routing techniques
   and protocols.

   SVC-based ATM IP subnets are simplified in that they:

   o limit the number of hosts which must be directly connected at any
     given time to those that may actually exchange traffic.

   o The ATM network is capable of setting up connections between
     any pair of hosts.  Consistent with the standard IP routing
     algorithm [2] connectivity to the "outside" world is achieved
     only through a router, which may provide firewall functionality
     if so desired.

   o The IP subnet supports an efficient mechanism for address
     resolution.

   Issues addressed by the IP Over ATM Working Group, and some of the
   resolutions, for this model are:



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


   o Methods of encapsulation and multiplexing.  This issue is
     addressed in RFC-1483 [6], in which two methods of encapsulation
     are defined, an LLC/SNAP and a per-VC multiplexing option.

   o The definition of an address resolution server (defined in
     RFC-1577).

   o Defining the default MTU size.  This issue is addressed in
     RFC-1626 [1] which proposes the use of the MTU discovery
     protocol (RFC-1191 [9]).

   o Support for IP multicasting.  In the summer of 1994, work began
     on the issue of supporting IP multicasting over the SVC LATM
     model.  The proposal for IP multicasting is currently defined by
     a set of IP over ATM WG Works in Progress, referred to collectively
     as the IPMC documents.  In order to support IP multicasting the
     ATM subnet must either support point-to- multipoint SVCs, or
     multicast servers, or both.

   o Defining interim SVC parameters, such as QoS parameters and
     time-out values.

   o Signaling and negotiations of parameters such as MTU size
     and method of encapsulation.  RFC-1755 [10] describes an
     implementation agreement for routers signaling the ATM network
     to establish SVCs initially based upon the ATM Forum's UNI
     version 3.0 specification [4], and eventually to be based
     upon the ATM Forum's UNI version 3.1 and later specifications.
     Topics addressed in RFC-1755 include (but are not limited to)
     VC management procedures, e.g., when to time-out SVCs, QOS
     parameters, service classes, explicit setup message formats for
     various encapsulation methods, node (host or router) to node
     negotiations, etc.

   RFC-1577 is also applicable to PVC-based subnets.  Full mesh PVC
   connectivity is required.

   For more information see RFC-1577 [8].

8.2 The ROLC NHRP Model

   The Next Hop Resolution Protocol (NHRP), currently a work in progress
   defined by the Routing Over Large Clouds Working Group (ROLC),
   performs address resolution to accomplish direct connections across
   IP subnet boundaries.  NHRP can supplement RFC-1577 ARP. There has
   been recent discussion of replacing RFC-1577 ARP with NHRP. NHRP can
   also perform a proxy address resolution to provide the address of the
   border router serving a destination off of the NBMA which is only



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


   served by a single router on the NBMA. NHRP as currently defined
   cannot be used in this way to support addresses learned from routers
   for which the same destinations may be heard at other routers,
   without the risk of creating persistent routing loops.

8.3 "Conventional" Model

   The "Conventional Model" assumes that a router can relay IP packets
   cell by cell, with the VPI/VCI identifying a flow between adjacent
   routers rather than a flow between a pair of nodes.  A latency
   advantage can be provided if cell interleaving from multiple IP
   packets is allowed.  Interleaving frames within the same VCI requires
   an ATM AAL such as AAL3/4 rather than AAL5.  Cell forwarding is
   accomplished through a higher level mapping, above the ATM VCI layer.

   The conventional model is not under consideration by the IP/ATM WG.
   The COLIP WG has been formed to develop protocols based on the
   conventional model.

8.4 The Peer Model

   The Peer Model places IP routers/gateways on an addressing peer basis
   with corresponding entities in an ATM cloud (where the ATM cloud may
   consist of a set of ATM networks, inter-connected via UNI or P-NNI
   interfaces).  ATM network entities and the attached IP hosts or
   routers exchange call routing information on a peer basis by
   algorithmically mapping IP addressing into the NSAP space.  Within
   the ATM cloud, ATM network level addressing (NSAP-style), call
   routing and packet formats are used.

   In the Peer Model no provision is made for selection of primary path
   and use of alternate paths in the event of primary path failure in
   reaching multihomed non-ATM destinations.  This will limit the
   topologies for which the peer model alone is applicable to only those
   topologies in which non-ATM networks are singly homed, or where loss
   of backup connectivity is not an issue.  The Peer Model may be used
   to avoid the need for an address resolution protocol and in a proxy-
   ARP mode for stub networks, in conjunction with other mechanisms
   suitable to handle multihomed destinations.

   During the discussions of the IP over ATM working group, it was felt
   that the problems with the end-to-end peer model were much harder
   than any other model, and had more unresolved technical issues.
   While encouraging interested individuals/companies to research this
   area, it was not an initial priority of the working group to address
   these issues.  The ATM Forum Network Layer Multiprotocol Working
   Group has reached a similar conclusion.




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


8.5 The PNNI and the Integrated Models

   The Integrated model (proposed and under study within the
   Multiprotocol group of ATM Forum) considers a single routing protocol
   to be used for both IP and for ATM. A single routing information
   exchange is used to distribute topological information.  The routing
   computation used to calculate routes for IP will take into account
   the topology, including link and node characteristics, of both the IP
   and ATM networks and calculates an optimal route for IP packets over
   the combined topology.

   The PNNI is a hierarchical link state routing protocol with multiple
   link metrics providing various available QoS parameters given current
   loading.  Call route selection takes into account QoS requirements.
   Hysteresis is built into link metric readvertisements in order to
   avoid computational overload and topological hierarchy serves to
   subdivide and summarize complex topologies, helping to bound
   computational requirements.

   Integrated Routing is a proposal to use PNNI routing as an IP routing
   protocol.  There are several sets of technical issues that need to be
   addressed, including the interaction of multiple routing protocols,
   adaptation of PNNI to broadcast media, support for NHRP, and others.
   These are being investigated.  However, the ATM Forum MPOA group is
   not currently performing this investigation.  Concerned individuals
   are, with an expectation of bringing the work to the ATM Forum and
   the IETF.

   PNNI has provisions for carrying uninterpreted information.  While
   not yet defined, a compatible extension of the base PNNI could be
   used to carry external routing attributes and avoid the routing loop
   problems described in Section 7.



















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


               ++++++++++++++++++++++++++++++++++++++++++
               +   .------------.      .------------.   +
   .---------. + .-:            :-.  .-:            :-. +
   : Host or >-+-< : Single ATM : >--< : Single ATM : >-+-----\
   : Router  : + : :   Domain   : :  : :   Domain   : : +     :
    ---------  +  -:            :-    -:            :-  + .---^----.
               +    ------------        ------------    + : Router :
               +                       .------------.   +  ---v----
   .---------. +                     .-:            :-. +     :
   : Host or >-+- ...          ... --< : Single ATM : >-+-----/
   : Router  : +                     : :   Domain   : : +
    ---------  +  ATM Cloud           -:            :-  +
               +                        ------------    +
               ++++++++++++++++++++++++++++++++++++++++++

                  Note: IS within ATM cloud are ATM IS

  Figure 6: The ATM transition model assuming the presence of gateways
     or routers between the ATM networks and the ATM peer networks.

8.6 Transition Models

   Finally, it is useful to consider transition models, lying somewhere
   between the Classical IP Models and the Peer and Integrated Models.
   Some possible architectures for transition models have been suggested
   by Fong Liaw.  Others are possible, for example Figure 6 showing a
   Classical IP transition model which assumes the presence of gateways
   between ATM networks and ATM Peer networks.

   Some of the models described in the prior sections, most notably the
   Integrated Model, anticipate the need for mixed environment with
   complex routing topologies.  These inherently support transition
   (possibly with an indefinite transition period).  Models which
   provide no transition support are primarily of interest to new
   deployments which make exclusive, or near exclusive use of ATM or
   deployments capable of wholesale replacement of existing networks or
   willing to retain only non-ATM stub networks.

   For some models, most notably the Peer Model, the ability to attach
   to a large non-ATM or mixed internetwork is infeasible without
   routing support at a higher level, or at best may pose
   interconnection topology constraints (for example: single point of
   attachment and a static default route).  If a particular model
   requires routing support at a higher level a large deployment will
   need to be subdivided to provide scalability at the higher level,
   which for some models degenerates back to the Classical model.





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


9.  Application of the Working Group's and Related Documents

   The IP Over ATM Working Group has generated several Works in Progress
   and RFCs.  This section identifies the relationship of these and
   other related documents to the various IP Over ATM Models identified
   in this document.  The documents and RFCs produced to date are the
   following references, RFC-1483 [6], RFC-1577 [8]