rfc1680.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 396 行 · 第 1/2 页

   categories are further specified through network provider objectives
   for various ATM performance parameters. These parameters may include
   cell transfer delay, cell delay variation, and cell loss ratio. The
   connection traffic descriptor specifies characteristics of the data
   generated by the user of the connection. This information allows the
   ATM network to commit the resources necessary to support the traffic
   flow with the quality of service the user expects. Characteristics
   defined in the ATM Forum UNI specification include peak cell rate,
   sustainable cell rate, and maximum and minimum burst sizes [3].
   Lastly, the transit network selection parameter allows an ATM user to
   select a preferred network provider to service the connection [3].

4.  Parameters Required to Map IPng to ATM

   There are several parameters required to map ATM services from a
   higher level service like IPng. These ATM parameters can be
   categorized in the following manner: addressing parameters,
   connection QOS-related parameters, connection management information,
   and ATM virtual circuit identifier. The first three categories
   provide support for ATM signaling. The last parameter, a connection
   identifier that maps IPng packets to ATM virtual circuits, provides
   support for an ATM virtual circuit per application when the end-to-
   end connection travels across an ATM subnetwork(s) (this does not
   assume that ATM is the only type of subnetwork that this connection



Brazdziunas                                                     [Page 4]

RFC 1680             IPng Support for ATM Services           August 1994


   travels across). Below, mapping issues for each of these parameters
   will be described.

4.1.  Addressing

   ATM supports routable addresses to each ATM endpoint to facilitate
   the dynamic establishment of connections. These addresses need to be
   derived from a higher level address such as an IPng address and IPng
   routing information.  This type of mapping is not novel. It is a
   mapping that is currently done for support of current IP over link
   technologies such as Ethernet.  An IP over ATM address resolution
   protocol (ARP) has been described in the Internet Standard,
   "Classical IP over ATM" [5]. In addition, support for IP routing over
   large ATM networks is being worked in the IETF's "Routing over Large
   Clouds" working group.

4.2.  Quality of Service

   As described in section 3, an ATM virtual circuit is established
   based upon a user's traffic characteristics and network performance
   objectives. These characteristics which include delay and throughput
   requirements can only be defined by the application level (at the
   transport level or above) as opposed to the internetworking (IPng)
   level. For instance, a file transfer application transferring a 100
   MB file has very different link level performance requirements than a
   network time application. The former requires a high throughput and
   low error rate connection whereas the latter could perhaps be
   adequately serviced utilizing a best-effort service. Current IP does
   not provide much support for a quality of service specification and
   provides no support for the specification of link level performance
   needs by an application directly. This is due to the fact that only a
   single type of link level performance is available with link
   technologies like Ethernet.  As a result, all applications over IP
   today receive the same level of link service.

   IPng packets need not explicitly contain information parameters
   describing an application's traffic characteristics and network
   performance objectives (e.g., delay = low, throughput = 10 Mb/s).
   This information could potentially be mapped from resource
   reservation protocols that operate at the IP (and potentially IPng)
   level [4].

4.3.  Connection Management

   The establishment and release of ATM connections should ultimately be
   controlled by the applications utilizing the circuits. As described
   in section 3, ATM signaling establishes a "hard state" in the network
   which is controlled by the ATM termination points [2]. Currently, IP



Brazdziunas                                                     [Page 5]

RFC 1680             IPng Support for ATM Services           August 1994


   provides no explicit mechanism for link level connection management.
   Future support for link level connection management could be
   accomplished through resource reservation protocols and need not
   necessarily be supported directly via information contained in the
   IPng protocol.

4.4.  Connection Identifier

   A mapping function needs to exist between IPng packets and ATM so
   that application flows map one-to-one to ATM virtual circuits.
   Currently, application traffic flows are identified at the transport
   level by UDP/TCP source and destination ports and IP protocol
   identifiers.  This level of identification should also be available
   at the IPng level so that information in the IPng packets identify an
   application's flow and map to an ATM virtual circuit supporting that
   flow when the IPng packets travels across an ATM subnetwork(s).

   Using the current IP protocol, identifying an application's traffic
   flow requires the combination of the following five parameters:
   source and destination IP addresses, source and destination UDP/TCP
   ports, and IP protocol identifier. This application connection
   identifier for IP is complex and could potentially be costly to
   implement in IP end stations and routers.  The IPng connection
   identifier should be large enough so that all application level
   traffic from an IPng end point can be mapped into the IPng packet.
   Currently, ATM provides 24 bits for virtual circuit identification
   (VPI and VCI). This provides sufficient capacity for 2^24
   (16,777,216) connections [6]. The actual number of bits that are used
   for the ATM virtual circuit however is established through
   negotiation between the ATM endpoint and ATM network. This number is
   useful as an upper bound for the number of mappings that are needed
   to be supported by IPng.

   An IPng candidate should be able to identify how IPng packets from an
   application can map to an ATM  virtual circuit. In addition, this
   mapping should be large enough to support a mapping for every IPng
   application on an end system to an ATM virtual circuit. Careful
   consideration should be given to complexity of this mapping for IPng
   to ATM since it needs to eventually support gigabit/sec rates.












Brazdziunas                                                     [Page 6]

RFC 1680             IPng Support for ATM Services           August 1994


References

   [1] Bradner, S., and A. Mankin, "IP: Next Generation (IPng) White
       Paper Solicitation", RFC 1550, Harvard University, NRL, December
       1993.

   [2] Clark, D., "The Design Philosophy of the DARPA Internet
       Protocols", Proc.  ATM SIGCOMM '88, August 1988.

   [3] "ATM User-Network Interface Specification, Version 3.0", ATM
       Forum, September 10, 1993.

   [4] Zhang, L., Estrin, D., Herzog, S., and S. Jamin, "Resource
       ReSerVation Protocol (RSVP) - Version 1 Functional
       Specification", Work in Progress, October 1993.

   [5] Laubach, M., "Classical IP and ARP over ATM", RFC 1577, Hewlett-
       Packard Laboratories, January 1994.

   [6] "Asynchronous Transfer Mode (ATM) and ATM Adaptation Layer (AAL)
       Protocols Generic Requirements", Bellcore Technical Advisory TA-
       NWT-001113, Issue 1, June 1993.

Security Considerations

   Security issues are not discussed in this memo.

Author's Address

   Christina Brazdziunas
   Bellcore
   445 South Street
   Morristown, NJ 07960

   Phone: [phone]
   EMail: [e-mail]















Brazdziunas                                                     [Page 7]