Specifications

Chapter 6 Troubleshooting and Diagnostics Installation and Operation Manual
6-32 Frequently Asked Questions IPmux-8/16 Ver. 6.00
while the switches are responsible for giving the priority according to the VLAN
info. Verify that the IPmux traffic has the highest priority in the relevant
Ethernet network.
ToS
There are several RFCs (RFC791, RFC1349, RFC2474) that define how the IP
ToS should be configured. The ToS is a byte located in the IP header (Layer 3).
In general the Type of Service octet, in most cases, consists of three fields:
The first field, labeled "PRECEDENCE", is intended to denote the importance or
priority of the datagram.
The second field, labeled "TOS", denotes how the network should make
tradeoffs between throughput, delay, reliability, and cost.
The last field, labeled "MBZ" (for "must be zero") above, is currently unused.
The IPmux enables configuring the whole IP ToS byte, and therefore it is
adaptable to each RFC in the market. The IP ToS parameter in the IPmux is
user-configured in terms of decimal value. However, on the frame itself it of
course appears in binary format. The decimal value varies between 0 and 255
(8 bits).
A configuration example:
Setting IP precedence of 101 and IP ToS of 1000 will give us the byte
10110000, which means that the IPmux IP ToS parameter should be
configured to 176 decimals.
UDP Destination Port
The IPmux uses the UDP protocol (Layer 4) in order to transfer the TDMoIP
traffic.
In the UDP protocol, the ¿Destination port¿ field is always set to the decimal
value of 2142, hence all the packets leaving the IPmux are tagged accordingly.
This unique value was assigned to RAD by the IANA organization for TDMoIP
applications.
The network elements may be used to give priority to the TDMoIP traffic
according to the UDP destination field.
Q: Does allocating a sufficient bandwidth ensure the proper functionality of an
IPmux-based application?
A: A sufficient bandwidth is not enough to ensure a steady environment for the
IPmux, since networks loaded with additional non-IPmux LAN traffic (e.g. PC
traffic) or incompetent Ethernet/IP network may cause several problems:
 Jitter – The IPmux packets may suffer a delay variation (although all the
traffic will eventually pass through due to that fact that there is sufficient
bandwidth). Packets will be delayed for different periods of time due to
overloaded networks, queuing mechanisms, etc. IPmux can compensate
for some jitter (IPmux-1, IPmux-11 up to 300 msec, IPmux-8/16 up to 32
msec for E1 and 24 msec for T1) but bigger jitter will cause problems.
 Misordering – Packets might be sent in different order than the order in
which they were originally sent from the IPmux.
 Packet Loss – Packets might be dropped/ignored by some elements in the
network (routers/switches) due to insufficient processing power to handle
the load, queuing mechanisms, buffer overflows, etc.