COMNET III CACI

3.2.3 Other Protocols over ATM
The above discussion assumes that the end-systems are equipped with ATM modules.
However, in many cases, you may want to model higher layer protocols which make use
of an ATM backbone. This scenario can be modeled in COMNET III using the
transit network building block. This building block would represent the ATM
backbone, to which the other LANs or WANs are connected. Instead of specifying the
ATM transport protocol parameters at a traffic source, you would specify them
at the transit network details. The source would take on the parameter set of the
higher layer protocols, such as TCP/IP, and thus generate traffic corresponding to this
protocol. When the packets are reaching the transit network, they are segmented
to the transit network’s ATM transport protocol and re-assembled to the
higher layer PDU upon leaving the transit network. All the principles about
modeling ATM outlined above now simply have to be applied to the transit
network.
Transit networks in COMNET III introduce an additional level of flexibility. They
contain the concept of service classes and connection types. The incoming
traffic has a service class requirements measured as an integer. The transit
network has a list of service classes dividing the integer range into non-overlapping
bins. This implies that each incoming packet is mapped onto a single service class. The
association with a service class then determines the destinations to which the packet can
be transmitted (and hence which types of links that are available to the packet inside the
network through the transit network routing algorithm). Furthermore, it
determines what protocol is used inside the transit network. These concepts allow
a classification of the traffic and a mapping onto different link speeds and protocol
functions. In case you do not need to make such a distinction, simply enter a single
service class and a single connection type with its respective ATM transport
protocol.
17