As per Relevance of the word parameter, we have this rfc below:
Network Working Group C.
Request for Comments: 1680
Category: Informational August 1994
IPng Support for ATM
Status of this
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
This document was submitted to the IETF IPng area in response to
1550. Publication of this document does not imply acceptance by
IPng area of any ideas expressed within. Comments should
submitted to the big-internet@munnari.oz.au mailing list
Executive
This white paper describes engineering considerations for IPng
solicited by RFC 1550 [1]. IPng should provide support for
and emerging link technologies that it will be transported over.
technologies like Ethernet simply multiplex traffic from upper
protocols onto a single channel. "Sophisticated" link
like ATM are emerging in the marketplace allowing several
channels to be established over a single wire (or fiber)
based on an applications' network performance objectives
Support for both "sophisticated" (ATM) and existing link
needs to be considered in an IPng candidate. End-to-end
will communicate through a network where IPng packets travel
subnetworks such as Ethernet and Hippi and also more "sophisticated
link levels such as ATM. Though initial support for IPng over
subnetworks will not facilitate a virtual circuit per application
the hooks to provide such a mapping should be in place while
maintaining support for the transport of IPng packets
conventional subnetworks. Application support for QOS-based
level service requires that the following types of ATM
be mappable (or derivable) from the higher level protocol(s) such
IPng: source and destination(s) addresses, connection quality
service parameters, connection state, and ATM virtual
identifier. Some of these mappings may be derivable from
provided by proposed resource reservation protocols supporting
integrated services Internet [4]. However, the ATM virtual
identifier should be efficiently derivable from IPng
Brazdziunas [Page 1]
RFC 1680 IPng Support for ATM Services August 1994
information
An IPng candidate should provide evidence that the mapping from
applications' IPng packets to ATM virtual circuit(s) can
accomplished in a heterogeneous Internet architecture keeping
consideration the gigabit/sec rates that IPng/ATM subnetworks
eventually be operating at
1.
This paper describes parameters that are needed to map IPng (or
protocol operating above the link level) to ATM services. ATM is
"sophisticated" link level technology which provides the
capability for applications at the TCP/UDP level to map to a
ATM virtual circuit for transport across an ATM network(s)
to the network performance and traffic requirements for
application. This is a step above many of today's existing
technologies which can only support a single level of
performance that must be shared by all applications operating on
single endpoint
The future Internet will be comprised of both conventional
"sophisticated" link technologies. The "sophisticated" features
link layers like ATM need to be incorporated into an internet
data travels not only across an ATM network but also several
existing LAN and WAN technologies. Future networks are likely to be
combination of subnetworks providing best-effort link level
such as Ethernet and also sophisticated subnetworks that can
quality of service-based connections like ATM. One can envision
originating from an Ethernet, passing through an ATM network,
network, another ATM network, and finally arriving at its
residing on a HIPPI network. IPng packets will travel through such
list of interconnected network technologies as ATM is incorporated
one of the components of the future Internet
To support per application customizable link level connections,
types of ATM information should be derivable from the higher
protocol(s) like IPng. This ATM information includes: source
destination ATM addresses, connection quality of service parameters
connection state, and an ATM virtual circuit identifier which maps
a single IPng application (i.e., single TCP/UDP application). Some
these mapping could potentially be derivable through
provided by proposed resource reservation protocols supporting
integrated services Internet [4]. However, the ATM virtual
identifier needs to be efficiently mappable from IPng
information
Brazdziunas [Page 2]
RFC 1680 IPng Support for ATM Services August 1994
Organization of this white paper is as follows. First
characteristics of ATM are described focusing on functions that
not provided in today's LAN technologies. This section
background information necessary for the following section
the parameters needed to map IPng services to ATM services
2.
In this white paper, the term "application" refers to a process
set of collective processes operating at the TCP/UDP level or
in the protocol stack. For example, each instance of "telnet"
"ftp" session running on an end station is a distinct application
3. Characteristics of ATM
ATM has several characteristics which differentiates it from
link level technologies. First of all, ATM has the capability
providing many virtual channels to transmit information over a
wire (or fiber). This is very similar to X.25, where many
channels can be established over a single physical media. But
X.25, ATM allows for each of these channels or circuits to have
customizable set of performance and quality of
characteristics. Link level technologies like Ethernet provide
single channel with a single performance and quality of
characteristic. In a sense, a single ATM link level media
like an array of of link level technologies each with
characteristics
ATM virtual circuits can be established dynamically utilizing
signaling protocol. ATM signaling is a source initiated
process for connection establishment. This protocol informs
in the network of the characteristics for the desired connection.
signaling does not provide any guidelines for how network
decide whether it can accept a call or where a signaling
should be forwarded if the end destination (from the link
perspective) has not been reached. In short, ATM signaling does
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
switching equipment can be set and once established it will
maintained until a message is received by one of the ends of the
requesting a change in state for the connection [2]. As a result,
ATM end system (this could be a workstation with an ATM adapter or
router with an ATM interface) receives guaranteed service from
ATM network. The ATM network is responsible for maintaining
connection state. The price the ATM termination points pay for
guarantee is the responsibility of changing the state of
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
to support dynamic connection establishment via signaling.
addresses are hierarchical in structure and globally unique [3]. As
result, these addresses are routable. This allows ATM networks
eventually support a large number of ATM endpoints once a
architecture and protocols to support it become available
The ATM User-Network Interface (UNI) signaling protocol based
ITU-TS Q.93B allows many different service parameters to
specified for describing connection characteristics. [3]
parameters can be grouped into several categories: ATM
layer (AAL) information, network QOS objectives, connection
descriptor, and transit network selector. The AAL
specifies negotiable parameters such as AAL type and maximum
sizes. The network QOS objectives describe the service that the
user expects from the network. Q.93B allows for one of five
classes to be selected by the ATM user. The service classes
defined as general traffic types such as circuit emulation (class A),
variable bit rate audio and video (class B), connection-oriented
transfer (class C), connectionless data transfer (class D),
effort service (class X), and unspecified [3]. Each of
categories are further specified through network provider
for various ATM performance parameters. These parameters may
cell transfer delay, cell delay variation, and cell loss ratio.
connection traffic descriptor specifies characteristics of the
generated by the user of the connection. This information allows
ATM network to commit the resources necessary to support the
flow with the quality of service the user expects.
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
select a preferred network provider to service the connection [3].
4. Parameters Required to Map IPng to
There are several parameters required to map ATM services from
higher level service like IPng. These ATM parameters can
categorized in the following manner: addressing parameters
connection QOS-related parameters, connection management information
and ATM virtual circuit identifier. The first three
provide support for ATM signaling. The last parameter, a
identifier that maps IPng packets to ATM virtual circuits,
support for an ATM virtual circuit per application when the end-to
end connection travels across an ATM subnetwork(s) (this does
assume that ATM is the only type of subnetwork that this
Brazdziunas [Page 4]
RFC 1680 IPng Support for ATM Services August 1994
travels across). Below, mapping issues for each of these
will be described
4.1.
ATM supports routable addresses to each ATM endpoint to
the dynamic establishment of connections. These addresses need to
derived from a higher level address such as an IPng address and
routing information. This type of mapping is not novel. It is
mapping that is currently done for support of current IP over
technologies such as Ethernet. An IP over ATM address
protocol (ARP) has been described in the Internet Standard
"Classical IP over ATM" [5]. In addition, support for IP routing
large ATM networks is being worked in the IETF's "Routing over
Clouds" working group
4.2. Quality of
As described in section 3, an ATM virtual circuit is
based upon a user's traffic characteristics and network
objectives. These characteristics which include delay and
requirements can only be defined by the application level (at
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
network time application. The former requires a high throughput
low error rate connection whereas the latter could perhaps
adequately serviced utilizing a best-effort service. Current IP
not provide much support for a quality of service specification
provides no support for the specification of link level
needs by an application directly. This is due to the fact that only
single type of link level performance is available with
technologies like Ethernet. As a result, all applications over
today receive the same level of link service
IPng packets need not explicitly contain information
describing an application's traffic characteristics and
performance objectives (e.g., delay = low, throughput = 10 Mb/s).
This information could potentially be mapped from
reservation protocols that operate at the IP (and potentially IPng
level [4].
4.3. Connection
The establishment and release of ATM connections should ultimately
controlled by the applications utilizing the circuits. As
in section 3, ATM signaling establishes a "hard state" in the
which is controlled by the ATM termination points [2]. Currently,
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
accomplished through resource reservation protocols and need
necessarily be supported directly via information contained in
IPng protocol
4.4. Connection
A mapping function needs to exist between IPng packets and ATM
that application flows map one-to-one to ATM virtual circuits
Currently, application traffic flows are identified at the
level by UDP/TCP source and destination ports and IP
identifiers. This level of identification should also be
at the IPng level so that information in the IPng packets identify
application's flow and map to an ATM virtual circuit supporting
flow when the IPng packets travels across an ATM subnetwork(s).
Using the current IP protocol, identifying an application's
flow requires the combination of the following five parameters
source and destination IP addresses, source and destination UDP/
ports, and IP protocol identifier. This application
identifier for IP is complex and could potentially be costly
implement in IP end stations and routers. The IPng
identifier should be large enough so that all application
traffic from an IPng end point can be mapped into the IPng packet
Currently, ATM provides 24 bits for virtual circuit
(VPI and VCI). This provides sufficient capacity for 2^24
(16,777,216) connections [6]. The actual number of bits that are
for the ATM virtual circuit however is established
negotiation between the ATM endpoint and ATM network. This number
useful as an upper bound for the number of mappings that are
to be supported by IPng
An IPng candidate should be able to identify how IPng packets from
application can map to an ATM virtual circuit. In addition,
mapping should be large enough to support a mapping for every
application on an end system to an ATM virtual circuit.
consideration should be given to complexity of this mapping for
to ATM since it needs to eventually support gigabit/sec rates
Brazdziunas [Page 6]
RFC 1680 IPng Support for ATM Services August 1994
[1] Bradner, S., and A. Mankin, "IP: Next Generation (IPng)
Paper Solicitation", RFC 1550, Harvard University, NRL,
1993.
[2] Clark, D., "The Design Philosophy of the DARPA
Protocols", Proc. ATM SIGCOMM '88, August 1988.
[3] "ATM User-Network Interface Specification, Version 3.0",
Forum, September 10, 1993.
[4] Zhang, L., Estrin, D., Herzog, S., and S. Jamin, "
ReSerVation Protocol (RSVP) - Version 1
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
Security issues are not discussed in this memo
Author's
Christina
445 South
Morristown, NJ 07960
Phone: (201) 829-4173
EMail: crb@faline.bellcore.
Brazdziunas [Page 7]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
