Next: Scaling Internet Technologies to
Up: The Need for Traffic
Previous: Planning of Infrastructural Development
The commercialization of the Internet has not only resulted in
an increase of the number of users. Probably the most important
problem that arises is the accounting of the transferred
data. Traditionally, the Internet was a network between research and
educational institutions. The connected institutions usually payed a
fixed fee for their connection. Nowadays, Internet providers would
like to charge their clients depending on the volume of data they
transfer. To do this, they need powerful tools that are able to count
the transferred amount of data. The higher the line speeds are, the
more difficult this is.
It is still a very common practice for providers to charge fixed
monthly fees for Internet access. Very often the only reason for this
is that they have no means to do an exact accounting for all clients.
Traditional solutions for volume based traffic charging include:
- 1.
- Reading the SNMP Octet Counters from the Routers
Most if not all modern networking equipment offers the possibility to
gather statistics about the amount of data that was transferred via
its interfaces. For this purposes, usually counters for bytes and/or
packets that are transferred over each interface are provided. These
counters can be queried using the SNMP procotol.
The disadvantage of
this is that only the total amount of traffic transferred can be
accounted. It is not possible to apply different prices depending on
the kind of traffic. Additionally, since the SNMP counters are only
maintained once for each hardware port, a separate port is necessary
for each client that is to be accounted. These additional expenses
for hardware make this solution very unattractive.
- 2.
- Using RMON / RMON2 probes
The RMON standard, which is described in RFC1757 [40], was
designed to provide proactive monitoring and diagnostics for
distributed LAN-based networks. Special monitoring devices, called
agents or probes, allow the monitoring of critical network segments
and to set off user-defined alarms. RMON has been implemented in
special stand-alone hardware, embedded in switches and as a program
running on a PC or workstation. Communication with the probes is
implemented using the SNMP protocol.
In theory, the RMON standard
would be suitable for higher line speeds. It has however shown that it
is difficult to adapt RMON to protocols like 100VG-AnyLan or ATM. No
RMON implementations for those protocols are available at this
time. For ATM, a first attempt was AMON (ATM Circuit Steering MIB),
which defines a way to copy traffic from a virtual circuit (VC) to a
location where an external probe can decode it. AMON - which was
proposed by Fore - has been discussed in the ATM Forum since summer
1995. However, progress has been so slow that the forum threatened to
suspend the AMON MIB group's work. In march 1996 Cisco -- although
one of the founder members of the ATM Forum -- has surprised the
networking community by submitting a draft for an ``ATM RMON MIB'' to
the IETF rather than to the ATM Forum. Cisco has developed the ATM
RMON MIB without discussing it with other manufacturers of ATM
hardware. This unusual way of presenting their proposal has been the
reason for controversial discussions. It is therefore not very likely
that their proposal will become a standard in the near future.
- 3.
- Using a PC or Workstation running tcpdump
The tcpdump tool mentioned above can be used to monitor all
traffic that passes through a network adapter in a PC or
workstation. Using it permits as well to count the data that is
received by this network adapter. However as mentioned above the
interrupt load using tcpdump is a problem when the data is being
received at higher line speeds. When the load is getting too high, the
probability for packet losses is growing. This technique is used at a
local Internet provider in Stuttgart, and it was found that
even on transfer rates of about 10 Mbit/s (standard ethernet) there is
already a probability for packet loss in the range of 1%. Obviously
this solution is only practicable for lower line speeds. It
nevertheless offers maximum flexibility since a user-written program
can be used to analyze a trace of all the headers from the packets the
machine receives.
Next: Scaling Internet Technologies to
Up: The Need for Traffic
Previous: Planning of Infrastructural Development
root
8/4/1997