Browse Prior Art Database

IPng Support for ATM Services (RFC1680)

IP.com Disclosure Number: IPCOM000002518D
Original Publication Date: 1994-Aug-01
Included in the Prior Art Database: 2000-Sep-12
Document File: 6 page(s) / 17K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

C. Brazdziunas: AUTHOR

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.

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 18% of the total text.

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

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

capabi...