GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc1680

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc1680.txt · Last modified: 1994/08/04 23:53 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki