doc: Add RFC documents

1 files changed, 395 insertions, 0 deletions

diff --git a/doc/rfc/rfc1680.txt b/doc/rfc/rfc1680.txt
new file mode 100644
index 0000000..2cf82c3
--- /dev/null
+++ b/doc/rfc/rfc1680.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                     C. Brazdziunas
+Request for Comments: 1680                                      Bellcore
+Category: Informational                                      August 1994
+
+
+                     IPng Support for ATM Services
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  This memo
+   does not specify an Internet standard of any kind.  Distribution of
+   this memo is unlimited.
+
+Abstract
+
+   This document was submitted to the IETF IPng area in response to RFC
+   1550.  Publication of this document does not imply acceptance by the
+   IPng area of any ideas expressed within.  Comments should be
+   submitted to the big-internet@munnari.oz.au mailing list.
+
+Executive Summary
+
+   This white paper describes engineering considerations for IPng as
+   solicited by RFC 1550 [1].  IPng should provide support for existing
+   and emerging link technologies that it will be transported over. Link
+   technologies like Ethernet simply multiplex traffic from upper layer
+   protocols onto a single channel. "Sophisticated" link technologies
+   like ATM are emerging in the marketplace allowing several virtual
+   channels to be established over a single wire (or fiber) potentially
+   based on an applications' network performance objectives.
+
+   Support for both "sophisticated" (ATM) and existing link technologies
+   needs to be considered in an IPng candidate. End-to-end applications
+   will communicate through a network where IPng packets travel across
+   subnetworks such as Ethernet and Hippi and also more "sophisticated"
+   link levels such as ATM.  Though initial support for IPng over ATM
+   subnetworks will not facilitate a virtual circuit per application,
+   the hooks to provide such a mapping should be in place while also
+   maintaining support for the transport of IPng packets across
+   conventional subnetworks. Application support for QOS-based link
+   level service requires that the  following types of ATM information
+   be mappable (or derivable) from the higher level protocol(s) such as
+   IPng: source and destination(s) addresses, connection quality of
+   service parameters, connection state, and ATM virtual circuit
+   identifier. Some of these mappings may be derivable from information
+   provided by proposed resource reservation protocols supporting an
+   integrated services Internet [4]. However, the ATM virtual circuit
+   identifier should be efficiently derivable from IPng packet
+
+
+
+Brazdziunas                                                     [Page 1]
+
+RFC 1680             IPng Support for ATM Services           August 1994
+
+
+   information.
+
+   An IPng candidate should provide evidence that the mapping from an
+   applications' IPng packets to ATM virtual circuit(s) can be
+   accomplished in a heterogeneous Internet architecture keeping in
+   consideration the gigabit/sec rates that IPng/ATM subnetworks will
+   eventually be operating at.
+
+1.  Introduction
+
+   This paper describes parameters that are needed to map IPng (or any
+   protocol operating above the link level) to ATM services. ATM is a
+   "sophisticated" link level technology which provides the potential
+   capability for applications at the TCP/UDP level to map to a single
+   ATM virtual circuit for transport across an ATM network(s) customized
+   to the network performance and traffic requirements for that
+   application. This is a step above many of today's existing link
+   technologies which can only support a single level of network
+   performance that must be shared by all applications operating on a
+   single endpoint.
+
+   The future Internet will be comprised of both conventional and
+   "sophisticated" link technologies.  The "sophisticated" features of
+   link layers like ATM need to be incorporated into an internet where
+   data travels not only across an ATM network but also several other
+   existing LAN and WAN technologies. Future networks are likely to be a
+   combination of subnetworks providing best-effort link level service
+   such as Ethernet and also sophisticated subnetworks that can support
+   quality of service-based connections like ATM.  One can envision data
+   originating from an Ethernet, passing through an ATM network, FDDI
+   network, another ATM network, and finally arriving at its destination
+   residing on a HIPPI network. IPng packets will travel through such a
+   list of interconnected network technologies as ATM is incorporated as
+   one of the components of the future Internet.
+
+   To support per application customizable link level connections, four
+   types of ATM information should be derivable from the higher level
+   protocol(s) like IPng. This ATM information includes: source and
+   destination ATM addresses, connection quality of service parameters,
+   connection state, and an ATM virtual circuit identifier which maps to
+   a single IPng application (i.e., single TCP/UDP application). Some of
+   these mapping  could potentially be derivable through information
+   provided by proposed resource reservation protocols supporting an
+   integrated services Internet [4].  However, the ATM virtual circuit
+   identifier needs to be efficiently mappable from IPng packet
+   information.
+
+
+
+
+
+Brazdziunas                                                     [Page 2]
+
+RFC 1680             IPng Support for ATM Services           August 1994
+
+
+   Organization of this white paper is as follows. First the
+   characteristics of ATM are described focusing on functions that are
+   not provided in today's LAN technologies. This section provides
+   background information necessary for the following section describing
+   the parameters needed to map IPng services to ATM services.
+
+2.  Terminology
+
+   In this white paper, the term "application" refers to a process or
+   set of collective processes operating at the TCP/UDP level or above
+   in the protocol stack. For example, each instance of "telnet" or
+   "ftp" session running on an end station is a distinct application.
+
+3.  Characteristics of ATM Service
+
+   ATM has several characteristics which differentiates it from current
+   link level technologies.  First of all, ATM has the capability of
+   providing many virtual channels to transmit information over a single
+   wire (or fiber). This is very similar to X.25, where many logical
+   channels can be established over a single physical media. But unlike
+   X.25, ATM allows for each of these channels or circuits to have a
+   customizable set of performance and quality of service
+   characteristics. Link level technologies like Ethernet provide a
+   single channel with a single performance and quality of service
+   characteristic. In a sense,  a single ATM link level media appears
+   like an array of of link level technologies each with customizable
+   characteristics.
+
+   ATM virtual circuits can be established dynamically utilizing its
+   signaling protocol. ATM signaling is a source initiated negotiation
+   process for connection establishment. This protocol informs elements
+   in the network of the characteristics for the desired connection. ATM
+   signaling does not provide any guidelines for how network elements
+   decide whether it can accept a call or where a signaling request
+   should be forwarded if the end destination (from the link level
+   perspective) has not been reached. In short, ATM signaling does not
+   support any routing functionality of network admission control.
+
+   ATM signaling establishes a "hard state" in the network for a call.
+   "Hard state" implies that the state of a connection in intermediate
+   switching equipment can be set and once established it will be
+   maintained until a message is received by one of the ends of the call
+   requesting a change in state for the connection [2]. As a result, an
+   ATM end system (this could be a workstation with an ATM adapter or a
+   router with an ATM interface) receives guaranteed service from the
+   ATM network. The ATM network is responsible for maintaining the
+   connection state. The price the ATM termination points pay for this
+   guarantee is the responsibility of changing the state of the
+
+
+
+Brazdziunas                                                     [Page 3]
+
+RFC 1680             IPng Support for ATM Services           August 1994
+
+
+   connection, specifically informing the ATM network to establish,
+   alter, or tear-down the connection.
+
+   Each ATM end point in a network has an ATM address associated with it
+   to support dynamic connection establishment via signaling. These
+   addresses are hierarchical in structure and globally unique [3]. As a
+   result, these addresses are routable. This allows ATM networks to
+   eventually support a large number of ATM endpoints once a routing
+   architecture and protocols to support it become available.
+
+   The ATM User-Network Interface (UNI) signaling protocol based on
+   ITU-TS Q.93B  allows many different service parameters to be
+   specified for describing connection characteristics. [3] These
+   parameters can be grouped into several categories: ATM adaptation
+   layer (AAL) information, network QOS objectives, connection traffic
+   descriptor, and transit network selector. The AAL information
+   specifies negotiable parameters such as AAL type and maximum packet
+   sizes. The network QOS objectives describe the service that the ATM
+   user expects from the network. Q.93B allows for one of five service
+   classes to be selected by the ATM user. The service classes are
+   defined as general traffic types such as circuit emulation (class A),
+   variable bit rate audio and video (class B), connection-oriented data
+   transfer (class C), connectionless data transfer (class D), best
+   effort service (class X), and unspecified [3]. Each of these
+   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: (201) 829-4173
+   EMail: crb@faline.bellcore.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Brazdziunas                                                     [Page 7]
+