IP Network Structure
The current best practice to carry data from point-to-point without major disturbances is to deploy a switched architecture and to limit routing as much as possible.
Multi-media traffic of different types have different network requirements, and this must be considered when designing the network. All links must be able to carry the additional voice traffic with good margin when added to the existing data traffic. Telephony traffic is symmetrical whereas data communication is fairly asymmetrical, which can easily cause trouble in certain types of network links, that are designed for asymmetrical data traffic.
In the IP network, plan for the extra load of data traffic that is caused by the telephony elements added to the network. The structure should be built in such a way that 80% of the estimated traffic is carried inside the logical network that is supposed to carry the traffic. To realize this target, the recommendation is to implement the telephony service in a Virtual LAN (VLAN) structure. This makes it easier to control the behavior and to avoid heavy traffic collision in the routers.
To reduce the effects of broadcast traffic when deploying IP telephony using the MX-ONE™ Service Node, it is recommended that VLANs are used for IP phones.
It is strongly recommended that the number of IP phones in a subnet is limited to a maximum of 510 devices. The reason is the amount of ARP requests in certain restart situations. For some installations (for example, contact centers) the traffic density may require a lower number of IP phones per subnet.
For an example of a typical IP network with redundancy and Wide Area Networks (WAN) connections, see figure, Typical Large IP Network. The basic principle is a core routing layer and independent distribution layers for clients and servers.
One of the most important and critical factors, when planning for an IP network to include voice and telephony traffic, is Quality of Service (QoS). For an overview of where different QoS policies are derived and deployed, See Figure 5: Needed Quality of Service Policies. Not implementing structured QoS policies may result in degradation of some media services, which is especially critical where low speed WAN links are used.
For more information on QoS, see the description for QUALITY OF SERVICE.
Except for the Call Admission Control (CAC) feature, the MX-ONE is not equipped with any mechanism that limits or blocks incoming or outgoing calls to a Server - Media Gateway depending on the network conditions (temporary or local congestion) or assigned bandwidth. For this reason, it is not recommended to locate MX-ONE Service Nodes in separated LANs, if it cannot be guaranteed that the network (WAN) connecting them has the required parameters (allocated bandwidth, maximum delay, maximum jitter, maximum packet loss) that are necessary for this type of application and the maximum estimated traffic flowing through the connecting WAN.
For routed networks, the standardized technique in computer networking, Path MTU Discovery (PMTUD) must be enabled in the routers. PMTUD is used for determining the maximum transmission unit size on the network path between two IP hosts.
Call Admission Control
The Call Admission Control (CAC) mechanism can be used between IP domains. A maximum bandwidth and the codec priority is set per LAN segment for all outgoing IP calls (H.323 and SIP). The lowest common bandwidth will be used for the communication between the IP domains.
For more information, see the operational directions for CALL ADMISSION CONTROL, and also the description of IP NETWORKING.
Inter-Server Modeling
The signaling between different end-points in the MX-ONE environment can be divided into three different categories; extension, trunk, and background (inter-server + database). This section only covers background signaling.
There is a constant background signaling between the MX-ONE servers (Service Node, Databases and Media Gateways/Media Servers, Management) regardless where the servers are located (LAN or WAN). When MX-ONE system is deployed in Multi Service Node setup including remote sites, the bandwidth required between the MX-ONE servers needs to be calculated.
The background signaling is composed of the inter-server signaling plus the database communication signaling, which is transmitted over an IP network between nodes. The two types of signaling are as follows:
- Inter-server signaling: is the internal signaling used between MX-ONE Service Nodes for call control, management and other common services. This communication is established similarly to a token-ring network.
- Database communication signaling: is the internal signaling used between databases. This communication is established as full-meshed network.
The background signaling requires between 60 kByte/s and 650 kByte/s depending of the system size and number of nodes. These values do not include the voice traffic that needs to be dimensioned separately and based on the max number of simultaneous active calls/codecs required during peak hours in a specific customer site.
For information regarding bandwidth requirements, refer the IOPS Disk and Network bandwidth Requirements, 3/1551-ASP11301.
To estimate the required bandwidth between MX-ONE Service Nodes, it is necessary to make a model of the actual network and define the amount of traffic that will be applied to each Server as well as the assumed traffic pattern that will apply between the Servers. The dedicated bandwidth required between the Service Nodes is calculated as the background (Inter-Server + database) signaling plus the required voice traffic (it depends of the number of simultaneous calls and the codec used for each call).
Remote Branch Node Inter-Server Modelling
The modeling for a remote branch node differs somewhat from the above general inter-server modelling, since the bandwidth is more likely to be limited, so the CAC feature may be more needed. The number of extensions in the branch node is probably rather low (<1000).
Assuming that the remote branch server has 1000 extension users, and 10% of the calls go to/from the main part of the system, with a peak traffic of 0.2 Erlang and standard holding times, you get 1.7 calls/second, i.e. 0.17 calls/second average for the 10% traffic to/from the main site.
That means you need bandwidth enough for 17 simultaneous calls, but the actual needed bandwidth depends on which codecs are used. For example G.711 codecs will require 64*2 (64 kbit/s for each direction) = 128 kbit/s per call, times 17 calls, plus the control signaling, which adds 22 kbit/s, i.e. a maximum bandwidth of circa 2 Mbit/s between the branch node and main site.