rfc1932.txt

中、英文RFC文档大全打包下载完全版 .

     TULIP changes nothing in the abstract architecture of the IP
     model, since each host or router still has an IP address which is
     resolved to an ATM address.  It simply uses the point-to-point
     property of VCs to allow the elimination of some per-packet
     overhead.  The use of TULIP could in principle be negotiated on a
     per-SVC basis or configured on a per-PVC basis.

   o The second model is "TCP and UDP over a Nonexistent IP
     Connection" (TUNIC). In this case no network-layer information
     is carried in each packet, everything being bound at virtual
     circuit set-up time.  The implicit binding is between two
     applications using either TCP or UDP directly over AAL5 on a
     dedicated VC.  If this can be achieved, the IP protocol field has
     no useful dynamic function.  However, in order to achieve binding
     between two applications, the use of a well-known port number



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


     in classical IP or in TULIP mode may be necessary during call
     set-up.  This is a subject for further study and would require
     significant extensions to the use of SVC signaling described in
     RFC-1755 [10].

    Encapsulation   In setup message            Demultiplexing
    -------------+--------------------------+------------------------
    SNAP/LLC     _ nothing                  _ source and destination
                 _                          _ address, protocol
                 _                          _ family, protocol, ports
                 _                          _
    NULL encaps  _ protocol family          _ source and destination
                 _                          _ address, protocol, ports
                 _                          _
    TULIP        _ source and destination   _ protocol, ports
                 _ address, protocol family _
                 _                          _
    TUNIC - A    _ source and destination   _ ports
                 _ address, protocol family _
                 _ protocol                 _
                 _                          _
    TUNIC - B    _ source and destination   _ nothing
                 _ address, protocol family _
                 _ protocol, ports          _


                Table 1:  Summary of Encapsulation Types

TULIP/TUNIC can be presented as being on one end of a continuum opposite
the SNAP/LLC encapsulation, with various forms of null encapsulation
somewhere in the middle.  The continuum is simply a matter of how much
is moved from in-stream demultiplexing to call setup demultiplexing.
The various encapsulation types are presented in Table 1.

Encapsulations such as TULIP and TUNIC make assumptions with regard to
the desirability to support connection oriented flow.  The tradeoffs
between connection oriented and connectionless are discussed in Section
5.













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


5.  Connection Oriented and Connectionless Tradeoffs

The connection oriented and connectionless approaches each offer
advantages and disadvantages.  In the past, strong advocates of pure
connection oriented and pure connectionless architectures have argued
intensely.  IP over ATM does not need to be purely connectionless or
purely connection oriented.

    APPLICATION       Pure Connection Oriented Approach
    ----------------+-------------------------------------------------
    General         _ Always set up a VC
                    _
    Short Duration  _ Set up a VC.  Either hold the packet during VC
    UDP (DNS)       _ setup or drop it and await a retransmission.
                    _ Teardown on a timer basis.
                    _
    Short Duration  _ Set up a VC.  Either hold packet(s) during VC
    TCP (SMTP)      _ setup or drop them and await retransmission.
                    _ Teardown on detection of FIN-ACK or on a timer
                    _ basis.
                    _
    Elastic (TCP)   _ Set up a VC same as above.  No clear method to
    Bulk Transfer   _ set QoS parameters has emerged.
                    _
    Real Time       _ Set up a VC.  QoS parameters are assumed to
    (audio, video)  _ precede traffic in RSVP or be carried in some
                    _ form within the traffic itself.


      Table 2: Connection Oriented vs. Connectionless - a) a pure
                      connection oriented approach

ATM with basic AAL 5 service is connection oriented.  The IP layer
above ATM is connectionless.  On top of IP much of the traffic is
supported by TCP, a reliable end-to-end connection oriented protocol.
A fundamental question is to what degree is it beneficial to map
different flows above IP into separate connections below IP.  There is
a broad spectrum of opinion on this.

As stated in section 4, at one end of the spectrum, IP would remain
highly connectionless and set up single VCs between routers which are
adjacent on an IP subnet and for which there was active traffic flow.
All traffic between the such routers would be multiplexed on a single
ATM VC. At the other end of the spectrum, a separate ATM VC would be
created for each identifiable flow.  For every unique TCP or UDP
address and port pair encountered a new VC would be required.  Part of
the intensity of early arguments has been over failure to recognize
that there is a middle ground.



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


ATM offers QoS and traffic management capabilities that are well
suited for certain types of services.  It may be advantageous to use
separate ATM VC for such services.  Other IP services such as DNS, are
ill suited for connection oriented delivery, due to their normal very
short duration (typically one packet in each direction).  Short
duration transactions, even many using TCP, may also be poorly suited
for a connection oriented model due to setup and state overhead.  ATM
QoS and traffic management capabilities may be poorly suited for
elastic traffic.

    APPLICATION       Middle Ground
    ----------------+-------------------------------------------------
    General         _ Use RSVP or other indication which clearly
                    _ indicate a VC is needed and what QoS parameters
                    _ are appropriate.
                    _
    Short Duration  _ Forward hop by hop.  RSVP is unlikely to precede
    UDP (DNS)       _ this type of traffic.
                    _
    Short Duration  _ Forward hop by hop unless RSVP indicates
    TCP (SMTP)      _ otherwise.  RSVP is unlikely to precede this
                    _ type of traffic.
                    _
    Elastic (TCP)   _ By default hop by hop forwarding is used.
    Bulk Transfer   _ However, RSVP information, local configuration
                    _ about TCP port number usage, or a locally
                    _ implemented method for passing QoS information
                    _ from the application to the IP/ATM driver may
                    _ allow/suggest the establishment of direct VCs.
                    _
    Real Time       _ Forward hop by hop unless RSVP indicates
    (audio, video)  _ otherwise.  RSVP will indicate QoS requirements.
                    _ It is assumed RSVP will generally be used for
                    _ this case.  A local decision can be made as to
                    _ whether the QoS is better served by a separate
                    _ VC.

 Table 3: Connection Oriented vs.  Connectionless - b) a middle ground
                                approach












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


    APPLICATION       Pure Connectionless Approach
    ----------------+-------------------------------------------------
    General         _ Always forward hop by hop.  Use queueing
                    _ algorithms implemented at the IP layer to
                    _ support reservations such as those specified by
                    _ RSVP.
                    _
    Short Duration  _ Forward hop by hop.
    UDP (DNS)       _
                    _
    Short Duration  _ Forward hop by hop.
    TCP (SMTP)      _
                    _
    Elastic (TCP)   _ Forward hop by hop.  Assume ability of TCP to
    Bulk Transfer   _ share bandwidth (within a VBR VC) works as well
                    _ or better than ATM traffic management.
                    _
    Real Time       _ Forward hop by hop.  Assume that queueing
    (audio, video)  _ algorithms at the IP level can be designed to
                    _ work with sufficiently good performance
                    _ (e.g., due to support for predictive
                    _ reservation).


      Table 4: Connection Oriented vs.  Connectionless - c) a pure
                        connectionless approach

   Work in progress is addressing how QoS requirements might be
   expressed and how the local decisions might be made as to whether
   those requirements are best and/or most cost effectively accomplished
   using ATM or IP capabilities.  Table 2, Table 3, and Table 4 describe
   typical treatment of various types of traffic using a pure connection
   oriented approach, middle ground approach, and pure connectionless
   approach.

   The above qualitative description of connection oriented vs
   connectionless service serve only as examples to illustrate differing
   approaches.  Work in the area of an integrated service model, QoS and
   resource reservation are related to but outside the scope of the IP
   over ATM Work Group.  This work falls under the Integrated Services
   Work Group (int-serv) and Reservation Protocol Work Group (rsvp), and
   will ultimately determine when direct connections will be
   established.  The IP over ATM Work Group can make more rapid progress
   if concentrating solely on how direct connections are established.







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


6.  Crossing IP Subnet Boundaries

   A single IP subnet will not scale well to a large size.  Techniques
   which extend the size of an IP subnet in other media include MAC
   layer bridging, and proxy ARP bridging.

   MAC layer bridging alone does not scale well.  Protocols such as ARP
   rely on the media broadcast to exchange address resolution
   information.  Most bridges improve scaling characteristics by
   capturing ARP packets and retaining the content, and distributing the
   information among bridging peers.  The ARP information gathered from
   ARP replies is broadcast only where explicit ARP requests are made.
   This technique is known as proxy ARP.

   Proxy ARP bridging improves scaling by reducing broadcast traffic,
   but still suffers scaling problems.  If the bridged IP subnet is part
   of a larger internetwork, a routing protocol is required to indicate
   what destinations are beyond the IP subnet unless a statically
   configured default route is used.  A default route is only applicable
   to a very simple topology with respect to the larger internet and
   creates a single point of failure.  Because internets of enormous
   size create scaling problems for routing protocols, the component
   networks of such large internets are often partitioned into areas,
   autonomous systems or routing domains, and routing confederacies.

   The scaling limits of the simple IP subnet require a large network to
   be partitioned into smaller IP subnets.  For NBMA media like ATM,
   there are advantages to creating direct connections across the entire
   underlying NBMA network.  This leads to the need to create direct
   connections across IP subnet boundaries.