IPng Support for ATM Services (RFC1680)
Original Publication Date: 1994-Aug-01
Included in the Prior Art Database: 2000-Sep-12
Internet Society Requests For Comment (RFCs)
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 firstname.lastname@example.org mailing list.
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.
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 email@example.com mailing list.
This white paper describes engineering considerations for IPng as
solicited by RFC 1550 . 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 . However, the ATM virtual circuit
identifier should be efficiently derivable from IPng packet
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 ...