Internetworking over ATM
`
`Proceedings JENC7
`
`A. Schill
`
`Internetworking over ATM:
`Experiences with IP/ IPng and RSVP
`Alexander Schill <schill@ibdr.inf.tu-dresden.de>
`Sabine Kühn <kuehn@ibdr.inf.tu-dresden.de>
`Frank Breiter <breiter@ibdr.inf.tu-dresden.de>
`
`Abstract
`
`This paper describes recent experiences with
`evaluating
`and
`implementing
`advanced
`internetwork communication protocols on top of
`ATM. First, performance results with conventional
`TCP/IP over ATM based on Digital Equipment’s
`Gigaswitch /ATM are reported. It becomes obvious
`that current protocols must be tuned specifically in
`order to exploit ATM performance. In order to
`address advanced quality of service issues based on
`resource reservation,
`the paper describes an
`implementation of IPng (IP next generation) and
`RSVP (Resource Reservation Protocol) over ATM.
`Solutions for mapping quality of service and traffic
`parameters in an adequate way are presented.
`Moreover, the issue of address mapping from IPng
`onto ATM is discussed. Implementation results and
`experiences in these areas are illustrated. Finally,
`ongoing current work on resource reservation in
`advance is presented. It is outlined that longer-term
`resource planning and
`scheduling provides
`additional benefits for selected ATM applications.
`
`I. Introduction
`ATM components for local area networks [21]
`have become widely available as products. With
`the current UNI 3.1 (User Network Interface)
`specification
`and
`the
`emerging UNI
`4.0
`specification of
`the ATM
`forum
`[3, 4],
`interoperability can also be achieved on a broad
`basis. It now becomes more and more important to
`actually support applications on top of ATM with
`sufficient performance, and also in heterogeneous
`network environments. Although
`it
`is already
`possible to run applications directly over AAL5
`(ATM Adaptation Layer 5), additional transport-
`and network-level protocols are
`required
`in
`heterogeneous settings, for example with Ethernet,
`FDDI, and ATM subnetworks being interconnected
`[1, 19] . The typical choice of many vendors is to
`offer the TCP/IP protocol suite [24] over ATM,
`based on the IP over ATM recommendation of the
`ATM Forum [18]. LAN Emulation ([15, 17])
`presents
`another
`alternative, however with
`significant
`limitations. Most
`important,
`compatibility of existing applications with ATM is
`achieved by using IP over ATM.
`
`In section 2 of this paper, we first present
`experiences and performance results for IP over
`ATM based on a local ATM network using DEC
`Gigaswitch/ATM. Comparisons with other standard
`networking
`technologies are also performed
`experimentally. It becomes obvious that current
`transport protocols are not ideally suited for ATM,
`and
`that
`tuning mechanisms and
`functional
`improvements are required.
`
`Meanwhile, the IETF (Internet Engineering
`Task Force) has also specified a follow-on version
`of IP, the IP version 6 (or IPng - IP next generation)
`protocol [13, 14, 20]. The major goal is to enhance
`the IP address space due to the rapid growth of the
`Internet and
`to offer additional functionality.
`Moreover, the resource reservation protocol RSVP
`[5, 11, 27] has been developed. Such a protocol is
`crucial for guaranteeing quality of service (QoS)
`characteristics based on
`explicitly
`reserved
`network, memory and processing resources [6]. It is
`of particular importance in heterogeneous networks
`with partial ATM infrastructures.
`
`Section 3 of the paper therefore addresses IPng
`and RSVP and
`reports concepts and
`first
`experiences with IPng and RSVP over ATM. In
`particular, the problem of mapping QoS and traffic
`parameters in an adequate way is discussed. This is
`of specific
`importance as
`the kind of QoS
`specification differs significantly between RSVP
`and ATM so that the mapping is non-trivial.
`Moreover, concepts for mapping IPng addresses
`onto ATM addresses are also presented, and
`relevant
`implementation-level
`aspects
`are
`discussed. Based on this work, early experiments
`with these new protocols have become possible;
`this way, the new functionality can readily be
`exploited
`by
`emerging ATM
`applications,
`especially in heterogeneous network environments.
`
`Section 4 discusses ongoing research work on
`resource reservation in advance. We present new
`concepts for longer-term management of distributed
`resource requirements
`in ATM settings. The
`requirements and basic concepts of an adequate
`resource scheduling in conjunction with reservation
`protocols are discussed. This way, specific quality
`of service characteristics for important application
`scenarios can be guaranteed at a rather early stage.
`
`161-1
`
`EX.1102.001
`
`DELL
`
`

`

`Internetworking over ATM
`
`Proceedings JENC7
`
`A. Schill
`
`Section 5 presents concluding
`summarizes the major findings.
`
`remarks and
`
`According to the knowledge of the authors, only
`few results in these areas are found in the current
`literature so far. In [16], the transfer of data over
`ATM using available bit rate is examined. Memory
`management is discussed and advanced switching
`concepts are proposed. However, higher-level
`protocols are not investigated yet. [7] presents a
`higher-level
`investigation of application-level
`performance in ATM networks; however, like
`many other similar studies, it is only based on
`analytical and numerical models and does not
`include practical measurements. While many
`research
`efforts
`also
`concentrate on QoS
`specification and supervision [6, 25], the actual
`implementation
`of QoS-related
`reservation
`protocols especially over ATM has hardly been
`addressed yet, with a few exceptions such as the
`ST-II work described in [9] and a rough comparison
`of the IETF and ATM services models [8].
`Although resource reservation in advance has been
`considered by several authors already [22, 23, 26],
`implementation concepts are still at a very early
`stage.
`
`II. IP over ATM: Performance
`Evaluation
`In this section, we present selected performance
`results of conventional TCP/IP over ATM and
`discuss our experiences. First, our experimental
`environment is briefly introduced.
`II.A. Network Structure
`
`Fig. 1 shows our network structure. Several
`multimedia workstations of type DECstation 3000
`AXP 700 and 300 and a server are connected with
`our DEC Gigaswitch/ATM via fibre optic links.
`ATM access is implemented by adapter cards in the
`workstations and by line cards in the switch. The
`adapter cards perform cell generation from input
`packets of variable size and transmit the cells using
`SONET/SDH frames with standard 155 Mbit/s per
`
`channel via multimode fibre. Cell assembly and
`disassembly is done in hardware. Only AAL5 is
`currently implemented.
`
`The switch itself offers a total performance of
`10.4 Gigabit/s and is input-buffered. Possible head-
`of-line-blocking, a potential problem of
`input
`buffering, is reduced by a specific output port
`allocation algorithm (parallel iterative matching).
`Both PVCs (permanent virtual channels) and SVCs
`(switched
`virtual
`channels)
`are
`supported;
`signalling is based on ITU Q.93B with Q.2931 as
`the follow-on version. Moreover, CBR (constant bit
`rate), VBR (variable bit rate), and ABR (available
`bit rate), both with point-to-point and point-to-
`multipoint VCs, are basically possible. However,
`the driver and subsystem software currently does
`not support CBR yet, so that the experiments were
`mainly based on ABR.
`
`The multimedia workstations are also connected
`via Ethernet and have access to another Ethernet
`switch, and also to an FDDI ring and in this way to
`the Internet via a concentrator. Each station is
`equipped with typical devices such as cameras,
`microphones,
`speakers
`etc.,
`using MME
`(Multimedia Environment) as an internal software
`platform. Over all, the installation and maintenance
`of our environment did not create major problems,
`and existing applications could easily be ported to
`run within this infrastructure.
`II.B. Results
`
`the
`Within our experiments, we evaluated
`performance of TCP/IP over ATM. Fig. 2 shows
`the associated protocol structure. On top of the
`ATM hardware, a driver module provides the
`interface to the connection management module
`connection
`(CMM).
`The CMM
`handles
`establishment and coordinates the other modules. It
`
`Fig. 2: Protocol structure: Overview
`
`also has an interface to the signalling module
`(implementation of signalling protocol), to the
`ATM address resolution protocol (ATM ARP with
`dedicated ARP server) and to the IP convergence
`module. This module maps classical IP onto ATM;
`this includes access to the ATM ARP server,
`initiation of connection establishment
`to
`IP
`
`Fig. 1: Experimental environment: structural
`overview
`
`161-2
`
`EX.1102.002
`
`DELL
`
`

`

`Internetworking over ATM
`
`Proceedings JENC7
`
`A. Schill
`
`destinations, and transfer of data.
`
`The application consists of a bidirectional
`client/server
`interaction. A component named
`"netserver" receives data while another component
`at each peer site named "netperf" sends data
`according to a load specification. Then on each site
`performance characteristics are evaluated. The
`components interact via a conventional socket layer
`offered by TCP. In alternative tests, Ethernet and
`FDDI were also used instead of ATM.
`
`Fig. 3 shows a major summary diagram of the
`results. Both the message sizes transferred via
`TCP/IP and the buffer sizes at the receiver’s site
`were varied;
`initial experiments have already
`shown a strong influence of both parameters. The
`major target parameter was the actual throughput
`that could be achieved. First, transmission was
`unidirectional only.
`
`sizes. However, many applications often do not
`deliver messages that are large enough to achieve
`satisfying performance. For example, we also
`observed these problems with bulk data transfer via
`existing remote procedure call protocols over ATM.
`In these cases, the constant part of the overhead of
`protocol processing has increasing influence. Of
`course, especially very small messages resulted in
`very poor performance. Similarly, very small
`buffers lead to very poor performance, too, as
`buffer overflow resulted in loss of data and
`subsequent retransmissions.
`
`Moreover, buffer sizes may be limited by the
`hardware, especially if multiple ATM applications
`coexist on a system. Therefore,
`it can be
`recommended to consider the possible use of ATM
`already during application development,
`for
`example for designing the data transfer phases and
`the mechanisms to be used. Automatic adaptation
`of protocol parameters according to the underlying
`network would also be a reasonable goal.
`
`140
`
`130
`
`120
`
`110
`
`100
`
`90
`
`80
`
`70
`
`60
`
`50
`
`40
`
`30
`
`20
`
`10
`
`Throughput [Mbit/s]
`
`64k
`
`2k
`
`32k
`
`16k
`
`8k
`
`4k
`
`2k
`
`Buffer size [Bytes]
`
`1k
`
`512
`
`256
`
`128
`
`64
`Message size
`[Bytes]
`
`2
`
`140
`
`120
`
`100
`
`80
`
`60
`
`40
`
`20
`
`Throughput [Mbit/s]
`
`0
`128k
`
`64k
`
`Fig. 3: TCP/IP over ATM: Throughput with varying
`buffer and message sizes
`
`0
`128k
`
`64k
`
`32k
`
`16k
`
`8k
`
`4k
`
`2k
`
`1k
`
`512
`
`256
`
`128
`
`64
`
`32
`
`16
`
`8
`
`4
`
`The maximum throughput achieved was 135
`Mbit/s with optimal parameter values. Although
`this equals 87% of the physical bandwidth, it also is
`notable that the CPU load of more than 60% was
`significant then, caused both by the sender and
`receiver applications and by protocol processing.
`Nevertheless, the experiment has shown that the
`bandwidth of ATM can only be exploited based on
`adequate protocol parameter setting and sufficient
`CPU capacity. This means, that without tuning the
`protocol parameters, namely message sizes and
`buffer sizes, higher-level transport and application
`protocols present major performance bottlenecks in
`ATM applications. In any case, it becomes obvious
`that local protocol processing rather than physical
`communication causes
`the major performance
`limits with today´s hardware.
`
`With a buffer size of less than 64 kbytes,
`performance dropped significantly, for example
`down to values between 60 and 90 Mbit/s for
`buffers of 32 kbytes. The higher values (90 Mbit/s)
`could only be achieved with significant message
`
`161-3
`
`ATM uni
`
`ATM bi
`
`Ether uni
`
`Ether bi
`
`2
`
`Message Size [Bytes]
`
`Fig. 4: Throughput comparison among heterogeneous
`networks
`
`Fig. 4 shows the results of further experiments
`with bidirectional
`traffic and with Ethernet,
`compared with ATM, using buffer sizes of 128
`kbyte. First, ATM performance drops to 110 Mbit/s
`and less per connection although a 155 Mbit/s VC
`is available for each direction. This is caused by
`significantly growing CPU load, because of the fact
`that both the sender and receiver applications and
`protocols have to be handled on each machine. The
`comparison with Ethernet shows that much lower
`throughput (a maximum of 8.5 Mbit/s) is achieved
`as expected, and that bidirectional traffic leads to
`even more significant reductions (down to 3 Mbit/s
`per connection) due to the shared medium with
`collisions. For FDDI, similar effects were observed,
`i.e. a more than 50% performance reduction per
`connection for bidirectional traffic. The major
`reason is that the FDDI bandwidth of 100 Mbit/s is
`to be divided among all communication partners
`
`EX.1102.003
`
`DELL
`
`

`

`Internetworking over ATM
`
`Proceedings JENC7
`
`A. Schill
`
`The IPng header (see fig. 5) distinguishes from
`the IP header in such a way, that some elements
`have been reduced and other elements will be
`optional. The distinction of options into difference
`extension headers will reduce
`the bandwidth
`needed for the IPng header. Therefore, the IPng
`basic header size is only the twofold of the IP
`Vers. Prio.
`Flow Label
`Payload Length Next Header Hop Limit
`
`40 Byte
`
`Source Address
`
`Destination Address
`
`32 Bit
`Fig. 5: IPng basic header
`header even though IPng increases the IP address
`size from 32 to 128 bit. In addition, the time of
`packet processing
`in routers will be reduced
`because the extension header generally contains
`information concerning the endsystems. Changes in
`the way IPng header options are encoded allow for
`more efficient forwarding, less stringent limits on
`the length of options, and greater flexibility for
`considering future options.
`
`Addressing
`
`The extension of the IPng addresses provides
`more addressing hierarchy levels and a much
`greater number of
`addressable
`nodes.
`In
`conjunction with these aspects IPng offers new
`address formats. One of these is the Anycast
`Address identifying sets of nodes, whereby a packet
`sent to an Anycast Address is delivered to one of
`the nodes only.
`
`Security and authentication
`
`the
`for
`includes additional options
`IPng
`definition of extensions which provide support for
`authentication, data integrity, and confidentiality.
`These basic elements of IPng will be included in all
`its implementations.
`
`Quality of service aspects
`
`The Flow Label and the Priority fields in the
`IPng header may be used by a host to identify those
`packets for which a special handling by IPng
`routers is requested, such as non-default quality of
`service or "real-time" service. The characteristics of
`this special handling for the corresponding labelled
`packets belonging to the same flow may be
`conveyed by a resource reservation protocol or
`IPng options. This capability is important in order
`to support multimedia and realtime applications
`
`while ATM VCs can be provided exclusively for
`each pair of stations, and also for each direction.
`
`Under normal load conditions (with regular
`background load), we also observed that the quality
`of video transmission varied significantly due to the
`current network and local load conditions. This
`problem can only be addressed by offering CBR
`and VBR mechanisms with guaranteed bandwidth.
`However, this requires resource reservations in the
`end systems and in the active network components
`(i.e. switches, routers, bridges etc.). Important
`resources are bandwidth, memory or buffers, and
`CPU cycles.
`
`For these reasons, we are currently working on
`the implementation of RSVP (resource reservation
`protocol) over ATM. Major problems and concepts
`are discussed below. This work is coupled with the
`implementation of IPng over ATM which is also
`described.
`
`III. IPng and RSVP: Concepts and
`Implementation over ATM
`The deployment of the new Internet Protocol on
`separate data link technologies is very important in
`view of a broad propagation concerning both
`already existent technologies such as Ethernet and
`new technologies such as ATM. This part of the
`paper describes an implemented adaptation of
`Internet Protocol next generation on ATM. Further,
`it introduces an approach to solve the problem of
`mapping QoS parameters required by applications
`onto ATM parameters to utilize the advantages of
`resource reservation in ATM. These considerations
`are especially based on the Resource ReServation
`Protocol (RSVP) as a future constituent of an
`Integrated
`Services
`Internet.
`The major
`characteristic of RSVP is an extended support of
`QoS for the Internet Protocol, whereby IPng is
`especially suitable supporting such reservation
`protocol. Therefore we compare the emerging
`integrated traffic services that are being developed
`by IETF and ATM Forum.
`III.A. Major Concepts of IPng
`
`IPng is a new version of the Internet Protocol
`which is assigned IP version number 6 and is
`formally called
`IPv6. Because
`IPng
`is an
`evolutionary step from the Internet Protocol (IPv4),
`it comprises on one hand numerous mechanisms of
`IP which have been expanded or kept in IPng. On
`the other hand, it contains new mechanisms and
`characteristics. The
`improvements of IPng
`in
`contrast to IPv4 fall primarily into the following
`categories:
`
`Packet structure
`
`161-4
`
`EX.1102.004
`
`DELL
`
`

`

`Internetworking over ATM
`
`Proceedings JENC7
`
`A. Schill
`
`some degree of
`require
`which
`throughput, delay, and/or jitter.
`
`consistent
`
`Transition mechanisms
`
`To facilitate the migration from IP to IPng, IPng
`includes
`transition mechanisms, allowing an
`adoption and deployment of IPng in a highly
`diffuse fashion, and a direct
`interoperability
`between IP and IPng. Examples of such transition
`mechanisms are the dual IP layer, automatic and
`configured tunnelling, and the IP header translation
`as a special case of the communication of pure IPng
`with IP hosts.
`
`In conjunction with the adaptation of IPng onto
`different link layers, IPng hosts need to resolve or
`determine the neighbour link layer address which is
`known to reside on attached links. The neighbour
`discovery protocol will be applied for that, using
`ICMP messages for information interchange. This
`is generally done via multicasting the addresses of
`neighbouring routers, the reachability of neighbour
`hosts, and some additional information. Moving the
`address resolution up to the ICMP/IP layer makes
`IPng more independent from the underlying link
`layer. However, although the neighbour discovery
`protocol was designed for the deployment of
`different
`link
`layers,
`it
`is mainly suited for
`broadcast media like Ethernet.
`III.B. Integrating IPng and ATM
`
`Recently, formats and methods were specified
`for the transmission of IPng packets over different
`networks like Ethernet, FDDI and Token Ring. In
`the following, we outline basic concepts for an
`initial implementation of IPng over ATM. As a
`general basis, the following parameters must be
`derivable from IPng parameters to allow support of
`applications via ATM networks:
`  ATM address of destination,
`  Quality of service and traffic parameters,
`  Connection states and identifier of the ATM
`virtual channel.
`
`The first three parameters represent information
`which are needed for the signalling protocol to
`establish a virtual connection. For making
`reservations for dedicated flows, it is required to
`determine the associated virtual channel identifier.
`Facilitating the assignment of IPng packets to ATM
`VCs, the IPng packet header contains the flow
`label, where packets with flow label zero are sent
`as best effort data.
`
`To determine the ATM destination address
`according to the neighbour discovery protocol, the
`multicast capabilities of ATM must be exploited.
`That is, before sending multicast messages for
`
`neighbour solicitation, an address translation of a
`multicast IPng address into a corresponding ATM
`address has to be performed. To reduce the
`overhead which will occur in conjunction with
`using a central Multicast Address Resolution Server
`(MARS) [2], the IETF currently discusses several
`solutions. Currently, address resolution for our
`implementation of IPng over ATM is realized based
`on the principle of classical IP over ATM.
`
`The specification of QoS and traffic parameters
`for dedicated flows has to be performed by the
`application. However, with the assistance of RSVP,
`application-level QoS and traffic parameters can be
`mapped onto ATM parameters explicitly as
`discussed below.
`III.C. RSVP - Basic Concepts
`
`Proposed as an internet draft, RSVP is a known
`constituent of the Integrated Services Internet. It
`provides especially real-time applications with
`guaranteed, predictable and controlled end-to-end
`performance across networks. It is a receiver-
`oriented protocol, which may be classified as a
`control protocol of the Internet Protocol. Therefore,
`it offers a flexible handling of heterogeneous
`receivers as well as an adaptation to dynamically
`changing multicast groups. The main
`task
`performed by RSVP is signaling of resource
`requirements at connection setup time. To be
`precise, RSVP does not actually reserve or allocate
`resources but rather indicates reservation requests
`to the underlying systems.
`
`Sender
`
`Router
`
`Receiver
`
`Path
`ResvErr
`PathTear
`
`Resv
`PathErr
`ResvTear
`
`Path
`ResvErr
`PathTear
`
`Resv
`PathErr
`ResvTear
`
`downstream
`upstream
`Fig. 6: Exchange of RSVP messages
`
`The transmission of RSVP control information
`is implemented by encapsulating RSVP packets
`into IP or IPng packets. Reservations may be
`performed
`for both unicast
`and multicast
`connections. The basis of a reservation is a detailed
`description of
`the flow
`traffic and
`the QoS
`characteristics. In accordance with this fact, RSVP
`defines the so-called flow and filter specification.
`The flow specification specifies the traffic (TSpec)
`using token bucket parameters for describing bursty
`traffic, and also determines the required QoS
`parameters
`(RSpec). The
`filter
`specification
`contains an identification of the flow for which
`reservations have been performed. Even though the
`
`161-5
`
`EX.1102.005
`
`DELL
`
`

`

`Internetworking over ATM
`
`Proceedings JENC7
`
`A. Schill
`
`reservation is receiver-oriented, the initiator of a
`reservation is the sender, which informs appropriate
`receivers about the characteristics of the flow to be
`sent (see fig. 6 for an example, also giving the main
`protocol elements).
`III.D. Integration of RSVP and ATM
`
`As discussed above, reservation protocols are
`characterized by reservation direction, with RSVP
`as a receiver-oriented protocol. As opposed to that,
`the ATM signalling protocol is sender oriented.
`Moreover, using soft states to manage the state
`information
`in nodes
`(endsystems,
`routers)
`facilitates the renegotiation of resource reservations
`within RSVP. Accordingly to hard states used in
`
`reserves uni-
`possibilities. As RSVP only
`directionally, it seems to be possible to establish an
`ATM connection for sending the RSVP reserve
`message from the receiver to the sender [28]. This
`would be possible as ATM is able to reserve in both
`directions. However, this emulation of a receiver
`oriented establishment of the virtual channel is only
`applicable to unicast VCs and is in conflict with the
`ATM multicast
`environment
`allowing only
`unidirectional allocation.
`
`We propose another, more efficient way;
`receiving
`a
`reservation message
`from
`the
`downstream host, the appropriate router or host
`establishes an ATM connection
`to
`the next
`downstream hop according
`to
`the reservation
`
`ATM
`QoS Class
`CBR
`
`VBR-RT
`
`QoS
`
`Traffic
`
`QoS
`
`Traffic
`
`VBR-NRT
`
`QoS
`
`Traffic
`
`QoS
`Traffic
`
`ABR
`
`UBR
`
`Traffic
`
`CLR
`CDV1
`Max CTD2
`PCR
`CLR
`CDV
`Max CTD
`PCR
`SCR
`MBS
`CLR
`Mean CTD
`PCR
`SCR
`MBS
`CLR
`PCR
`MCR3
`PCR
`
`RSVP
`Service Class
`
`Guaranteed
`Service
`
`Predictive
`Service
`
`Controlled
`Delay
`
`Best Effort
`
`n/a
`n/a
`n/a
`Average Token Rate (RSpec)
`n/a
`n/a
`n/a
`n/a
`Average Token Rate (R of RSpec)
`Token Bucket Depth (TSpec)
`n/a
`Delay as part of RSpec
`n/a
`Average Token Rate (TSpec)
`Token Bucket Depth (TSpec)
`n/a
`n/a
`Average Token Rate (TSpec)
`No declarations are necessary
`
`Table 1: RSVP and ATM service classes with respect to QoS and Traffic parameters
`
`ATM, there is no possibility to change the specified
`QoS parameters after call setup (Q.93b, Q.2931
`signaling). In contrast to the RSVP model, the QoS
`setup
`time
`is
`combined with
`connection
`establishment. These different concepts make an
`integration of RSVP and ATM more difficult. In
`addition to the general functionality differences of
`RSVP and ATM, RSVP supports sessions of several
`senders within a multicast group. ATM does not
`support such kind of behaviour.
`
`In order to map RSVP onto ATM, there are two
`
`
`
`1 Cell Delay Variation - CDV
`
`2 Cell Transfer Delay - CTD
`
`3 Mean Cell Rate - MCR
`
`information. On this basis, it will also be possible
`to establish ATM point-to-multipoint connections,
`at least to homogeneous receivers (as opposed to
`RSVP where
`heterogeneous
`receivers
`are
`supported, too).
`
`The differences between the service classes of
`the Integrated Services IP and ATM also require
`detailed analysis of mapping service classes as well
`as
`traffic and quality of service parameters.
`Considering both ATM and IETF service classes,
`the latter are characterized by delay, whereas, in
`ATM classes of bit rates (ABR, CBR) are specified.
`
`Translating traffic and QoS parameters is an
`additional
`service
`for
`the
`layer-to-layer
`communication during the call establishment phase.
`After the ATM link layer gets its own QoS and
`traffic
`parameters
`through
`negotiation
`and
`
`161-6
`
`EX.1102.006
`
`DELL
`
`

`

`Internetworking over ATM
`
`Proceedings JENC7
`
`A. Schill
`
`translation, the admission control is performed to
`control resource availability. The description of
`data streams by an application should be enabled in
`such a way that the reservation at the ATM layer
`complies with the actual requirements. Therefore,
`overestimating the resource needs of applications
`due to an improper mapping has to be avoided to
`achieve an efficient bandwidth utilization.
`
`Considering the traffic description parameters of
`RSVP and ATM, ATM allows both variable bit rate
`(burst, peak) and constant bit rate for transmission
`of non bursty traffic as opposed to RSVP. The
`traffic parameters of ATM accordingly comprise
`Maximum Burst Size (MBS), Sustainable Cell Rate
`(SCR) and Peak Cell Rate (PCR). The mapping of
`the particular RSVP traffic parameters is discussed
`in conjunction with an assignment of the service
`classes (see table 1). Obviously, it would be
`possible to transmit all IP flows with requested
`guaranteed service over constant bit rate channels,
`however this implies an inefficient utilization of
`resources e.g. for transmission of bursty traffic. In
`such cases, transmission via a variable bit rate
`channel is more convenient.
`
`Moreover, it is apparent that the IP/RSVP
`service classes are not in direct relation to the
`service classes of ATM. The basis of
`this
`consideration are the service classes of ATM
`(specified in the UNI 4.0 draft of the ATM Forum)
`which mapping problems
`that have
`to be
`recognized in the future.
`
`For mapping the guaranteed service class, only
`two ATM classes are possible: the CBR and VBR
`real time due to guaranteed bandwidth and end-to-
`end delays. In conjunction with the token bucket
`depth, the assignment of the appropriate ATM
`service class may be performed. That means, a
`token bucket depth with a value equal to one deals
`with a constant data stream. Considering the CBR
`service class, peak cell rate is the only traffic
`parameter which actually has to be specified.
`However, it can directly be derived from the RSVP
`average token rate, which will be calculated based
`on end-to-end delay.
`
`Variable bit streams combined with guaranteed
`service can be mapped onto the VBR real time
`class, expecting a token bucket depth value greater
`than one. Parameters of RSpec and TSpec could be
`translated onto sustainable cell rate and maximum
`burst size. PCR as a necessary traffic parameter of
`the VBR-RT service is currently not derivable from
`RSVP parameters. Basically, RSVP does not define
`any QoS parameters for the guaranteed service
`class yet.
`
`Considering
`
`the predictive service of
`
`the
`
`Integrated Services Internet, it provides a very high
`probability that the end-to-end delay experienced
`by packets in a flow will not exceed a known limit.
`The VBR non real time class is especially suitable
`for this service class because it expects a bounded
`end-to-end delay, too. The mapping of traffic
`parameters corresponds to that of VBR real time
`with exception of end-to-end delay as a component
`of RSpec.
`
`The controlled delay service imposes relatively
`low requirements on network components and does
`not provide any quantified level of assurance about
`packet delays. Instead, it merely promises to avoid
`overloads by
`turning excess
`traffic away. A
`comparison of both the controlled delay service and
`Available Bit Rate shows that the two classes
`support a best effort service in assistance with
`congestion control. As opposed to RSVP, ATM
`does
`not
`provide
`any
`end-to-end
`delay
`specification. Currently, only the average token rate
`may be mapped onto the mean cell rate. Pure best
`effort service without any requirements on network
`resources may be mapped onto unspecified bit rate
`which offers the same characteristics.
`
`In summary, a full translation or derivation of
`QoS parameters is impossible. For example, the
`cell loss rate (CLR) can generally not be mapped
`from RSVP parameters onto ATM parameters. As
`the traffic parameters of RSVP only consist of
`token bucket depth and average token rate, an
`accurate mapping or
`interpretation of
`traffic
`parameters is even more difficult. Introducing a
`peak rate as part of TSpec may facilitate the
`mapping onto ATM parameters. A problem which
`has to be taken into consideration is the additional
`overhead. Applications have to consider overhead
`calculations of the transport and network layers.
`Introducing a minimum packet size as a component
`of TSpec would facilitate calculation of overhead.
`This overhead occurs within the ATM layers in
`order
`to reserve
`the requested bandwidth of
`applications while considering the actual overhead.
`III.E. IPng over ATM: An Implementation
`
`IPng over ATM has been implemented within
`our group based on the concepts discussed above.
`According to the prototypical implementation of
`IPng and the development stage of ATM, it has first
`been realized for transmission of IPng packets over
`ATM using best effort service. This implies that
`packets are multiplexed over an ABR virtual
`channel, as reservations based on CBR channels are
`not yet supported by the ATM subsystem.
`
`The adaptation of IPng to ATM is realized as a
`kernel module, which
`is
`implemented as a
`convergence module providing an adaptation of
`
`161-7
`
`EX.1102.007
`
`DELL
`
`

`

`Internetworking over ATM
`
`Proceedings JENC7
`
`A. Schill
`
`module and will support real time handling and
`transport of IPng flows (see fig. 7). This API will
`be able to receive reservation information from a
`local daemon
`as
`a part of
`the RSVP
`implementation. Based on information contained in
`a given flow specification, a new ATM VC
`reservation is feasible after performing the mapping
`of service classes and parameters as discussed
`before. In addition to calculating and adding the
`appropriate overhead (e.g. of the AAL5 trailer) to
`traffic parameters and converting RSVP parameters
`[bit/s] into ATM parameters [cells/s], it is necessary
`to consider the granularity of cell reservations in
`ATM. Obviously, a rather fine granularity will be
`necessary between endsystems and ATM switches.
`The
`admission
`control will
`enforce
`the
`implementation of reservations.
`
`flows
`IPng
`Moreover, a classification of
`belonging to a dedicated reserved VC will be done
`in the convergence module, too. This implies the
`fact, that packets which cannot be identified based
`
`Application
`
`User space
`
`data flow
`
`Kernel space
`
`RSVP Daemon
`syscalls to setup
`reservation information
`
`TCP/ UDP
`
`IP/IPng
`
`Classifier RSVP API
`IPng CM
`
`ATM subsystem
`
`Signaling
`Module
`
`Connection Management
`Module
`
`Admission
`Control
`
`Device Driver
`
`ATM Network
`
`Fig 7: ATM subsystem in conjunction with RSVP
`on
`filter
`specification
`information will be
`transmitted over an available bit rate channel only.
`
`IV. Resource Reservation in Advance
`Recently, distributed multimedia applications
`have become more and more popular. In order to
`grant the required QoS for multimedia applications
`(e.g. videoconferencing) and to utilize resources of
`the network effectively, it is necessary to provide