RFC 1680 (rfc1680) - Page 1 of 7
IPng Support for ATM Services
Alternative Format: Original Text Document
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 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