Mitel SX 200 IP NODE Instructions Guide

							11
•  Ports should be configurable to accept untagged information, pass this on to a specified VLAN, as well as accepting
tagged information. The port should also strip off tagging for data from a specific VLAN, but not strip data from other
VLANs. This is used when connecting the dual port phones and PCs to the network.
Some other VLAN guidelines for use with voice include:
•  Additional bandwidth is always good!
•  Use full duplex wherever possible
•  Don’t use VLAN 0
•  Set Priority to value 6 for voice
•  Set Priority for untagged VLAN/native VLAN/default_vlan to 0
•  Hubs don’t support priority queuing, so use Layer2 switches with 802.1p/Q support
3.8.1.1  Cisco Port Examples
This is data collected from the command line interface (RS232 connection)
3.8.1.1.1  Dual Mode / Trunk
This mode allows untagged information to be placed onto a specific VLAN as well as passing VLAN tagged data for other
VLAN. Typically this configuration would be used to connect to a dual port phone with an attached PC (no VLAN).
>switchport trunk encapsulation dot1q
>switchport trunk native vlan 193
>switchport mode trunk
>spanning-tree portfast
1.  This configuration is for the dual port phones. It can be seen that the port will provide VLAN tagging through the first
command line, and that the encapsulation type is to IEEE802.1Q (dot1q). Cisco also supports a similar scheme of
priority with ISL encapsulation, but this is proprietary so will not inter-work with other vendor equipment.
2.  The port is configured such that untagged information will be directed to (native) VLAN193.
3.  The port is considered as a trunk due to the fact that it handles multiple VLAN connections.
4.  The last command indicates that this port will not be closed down during spanning tree operations. It is left to the
network engineer to ensure that there are no network loops behind this connection. (This command would typically
be used when connection is to a server or the main controller, i.e. IP-Node).
3.8.1.1.2  Access Port / Non-VLAN aware device
This interface will not accept VLAN tagged information, but will add tagging information to data between the access port
and VLAN712 (in this case the voice VLAN). This would be used for the SX-200 IP NODE, or for an application server
such as Speak at Ease. This port should nto be shared with other devices and should be dedicated to the server or IP-
Node.
>interface FastEthernet0/19
>switchport access vlan 712
>spanning-tree portfast
Other commands will allow the individual port priority to be specified. In the case of the access port, the ‘encapsulation’
method is specified elsewhere.
Whilst, the IEEE specification allows for VLANs from 0 to 4095 not all vendors support this range. As a general rule VLAN
0 is treated in different ways by different vendors. The recommendation is not to use VLAN0. Cisco also reserves VLAN
1000 upwards for its own purposes, so these are also not recommended for use.
3.8.1.1.3 Multi-VLAN Port
Cisco devices provide this as another port configuration. However on some of the devices it is not possible to use this and
‘Trunk’ ports on the same unit. Unfortunately, the multi-VLAN port type is needed in order to work with other vendor
products. A ‘Trunk’ port can be used, but it will also remove tagging from the configured native VLAN, which may not be
what is required. There are two possible ways out of this situation:
•  Run ISL between the two units, but then they both need to be Cisco
•  Create a dummy VLAN that is not used anywhere else in the network. This will ensure compatibility with other vendor
units and allow products to be mixed.
3.8.1.2  HP Port Examples
The HP switch uses a similar RS232 connection, but the user interface is more menu-driven. This makes the configuration
much more intuitive. A typical screen display is shown: 
						

							12
Actions->   Back     Add     Edit     Delete     Help
Port    DEFAULT_VLAN  voice_vlan    data_vlan     test4
----- + ------------  ------------  ------------  ------------
  1   | Untagged      Tagged        No            No
  2   | Untagged      Tagged        No            No
  3   | Untagged      Tagged        No            No
  4   | Untagged      Tagged        No            No
  5   | Tagged        Tagged        Tagged        No
  6   | No            No            No            Untagged
  7   | No            Untagged      No            No
  8   | Untagged      No            No            No
  9   | Untagged      No            No            No
  10  | Untagged      No            No            No
  11  | Untagged      No            No            No
  12  | Untagged      No            No            No
The default_vlan is VLAN1. The VLAN numbers have been assigned names to help follow which function is assigned to
which VLAN. The ‘voice_vlan’ is VLAN2, the ‘data_vlan’ is VLAN3 and ‘test4’ is VLAN4.
The IP devices that would be connected to the port examples above would be:
•  Ports 1 to 4: Dual port phones with PCs.
•  Port 5: Interconnect between network switches.
•  Port 7: MITEL SX-200 IP NODE, or similar voice applications such a Speak at Ease.
•  Ports 8 to 12: Connect only to PCs.
In common with many switch vendors it is not recommended to use VLAN0 with HP. However it is possible to extend the
VLAN numbering up to the maximum of 4095.
3.8.2  WAN Layer 3 Priority
There are a number of different WAN technologies to provide data routing with different priorities and service level
agreements. Most of these deal with the WAN technology, but most rely on information being presented in the Layer 3
Type of Service field.
The Type of  Service field has undergone some name changes as well as additional functions. This field is now also
covered as DiffServ, or Differentiated Services. The DiffServ uses the precedence and some of the TOS bits (TOS instead
of Type of Service field) to provide 64 different services. See the diagram in section 3.8 above to find the location of Type
of Service field.
The MITEL IP NODE and IP-Phones use the Type of Service format for priority and TOS. This complies with RFC791, but
also by choice of value, RFC1122 and RFC1349.
The precedence field is similar in operation to the IEEE802.1p field, and in fact many routers offer the capability of
mapping between the two schemes. Once a TOS and precedence is chosen it never changes. Therefore the voice
application sets the appropriate values before data is sent. Voice applications are fixed with a value of 0xB0 for the Type
of Service field. This provides a precedence of 5 with minimum delay. This is equivalent to a DiffServ value of 44 decimal.
All that is required is that the router device support priority queuing mechanisms, such as Weighted Fair Queuing.
DT RC 0
10110000T
ype of Service Field
Precedence
TOS 
						

							13
With a Layer 3 device, such as a router, the packet per second (PPS) throughput is also important. With an IP-Phone the
frame rate is every 20ms. This means that the phone will send 50 packets per second and will also receive 50 packets per
second. Beware though how vendors might specify the PPS rating. For example, with two phones connected to a router
each port will send and receive 50PPS. That’s 100PPS per port, requiring that 200PPS to be handled. However, between
the phones only 50PPS went one way and 50PPS in the return direction. So, throughput was 100PPS.
In this diagram the Router has a handling capacity of 15,000PPS. Throughput would be half this number.
3.8.3  Network Topology with Priority
The following network diagram highlights the use of the Dual Port Phones and the configuration of a network including
VLAN priority and also the use of DiffServ/TOS in the WAN connection.
Router
IP
Phone
Router
IP
Phone
15,000PPS 15,000PPS
100PPS
100PPS 100PPS
50PPS 50PPS
50PPS 50PPS50 (in) + 50 (out) = 100PPS
50 (in) + 50 (out) = 100PPS
Router handles upto
15,000 / 200 =
75 conversations
Total = 200 
						

							14
In the diagram, the network switch ports connected to the Dual Port Phones must be able to accept both untagged
information and tagged information. The untagged data will then be translated to a ‘data’ VLAN (1), whereas the voice will
be destined for a Voice VLAN (2). In the outgoing direction, these ports must also pass information from the Voice VLAN
still tagged, but traffic from the ‘data’ VLAN must be sent untagged for the devices that are incapable of handling VLAN
information.
The requirement to use VLAN and priority queuing becomes obvious when both ‘data’ and Voice information must share a
link between units within the network. In this case it is important that the deterministic voice information gets priority over
the non-deterministic ‘data’ traffic. This is where the IEEE802.1p comes into play, and IEEE802.1p is a subset within
IEEE802.1Q.
Routers, or Layer3 switches, involved in segmenting the network will also need connections into the different VLANs.
Each VLAN will be identified by a VLAN number, but also by the unique sub-net address. In this way the routers and
Layer3 switches that are unaware of VLAN can still pass data between the VLANs. In this case it is required that a
separate physical connection be made to each VLAN, and that the ports on the Layer2 switch only pass information to
and from one specific VLAN. At the Layer2 port, the VLAN information is removed on egress and added on ingress
according to the port or VLAN configurations.
Some routers are VLAN aware. These can be considered to include a virtual Layer2 switch within the unit, which then
directs data according to the VLAN information. These devices are often referred to as including ‘Virtual Ports’. The
advantage is that only one physical connection is needed to handle multiple VLANs.
3.8.4  Use of Subnets
Generally this is a good thing to do, irrespective of whether a voice over IP installation is being used.
Creating a flat network may appear to speed up transactions due to the high link speed, but Layer3 switches are very
much hardware oriented today, and give equally good performance as their Layer2 counterparts.
Remember that in the Layer2 switch environment, data can be addressed directly to a specific port hence reducing
loading on links not used. However, where the Layer2 devices are unable to identify an address, or port location to use,
additional protocols are needed to get this information. These additional protocols generally broadcast data to every port
Router
Router
IP PhoneIP PhoneIP Phone
Access
VLAN(1),2
Access
VLAN(1),2
Access
VLAN1,2
Access
VLAN(1),2
Access
VLAN1,2
Access
VLAN(1)
Access
VLAN(2)
YIELDRouter with Virtual
Ports QoS enabled
Key:   VLAN(1),2 means:
Untagged data on VLAN 1.
VLAN2 accepted in 802.1Q format
These ports DONT
work on untagged
data 
						

							15
and device. In this instance, the loading on the network is almost back to that of a shared environment. The Layer 2
devices maintain a list of addresses and port location in internal memory. If the list is small, then the level of broadcasts
can also increase since new information is rapidly ‘aged’ out of the list.
Hence a large flat network can potentially grind to halt, not because of genuine traffic loading, but simply due to the
amount of broadcast traffic that will be needed. Using subnets helps by segmenting broadcast domains. The Layer2
devices subsequently need to hold less information, and so broadcast less often.
Therefore including Layer3 devices will improve speed within communities of interest and the overall network, as well as
reducing the burden on the system to all the broadcast traffic. It is also a requirement for VLANs to operate correctly and
provide the voice priority that is required when using Dual Port Phones.
4. Maintaining Availability of Connections
This area could be considered as the signalling quality of service. It is a measure of how long a user needs to wait before
a service becomes available, or whether the user becomes blocked from using a function. Examples of this would be
delay in receiving dial tone, or blocking that could occur if there are insufficient PSTN trunks.
4.1 System Capabilities
As the system grows, and more traffic is presented, it has to deal with an ever-increasing number of tasks. The end result
of this is that feature interaction becomes slower. The ICP systems are engineered to ensure that with different
combinations of devices services are still maintained within normal working parameters. The exact details are not
captured here, but are specific to particular releases, since changes in software or hardware have a bearing on the
results.
In terms of calculating some of these limitations a good guideline has been to use the PI numbers from SX200 and add
10% overhead for IP devices.
4.2 Traffic
The largest effect on performance and availability is the level of traffic that the units need to handle. There are a number
of areas that are affected by traffic. These include:
•  Trunks to PSTN
•  E2T (Gateway) channels
• DSP channels
•  LAN blocking between devices
•  WAN blocking between end points
The traffic guidelines used in calculating the system performance are based on:
•  Standard busy office traffic : 6CCS (about 6 calls per hour)
•  ACD : 27CCS (about 27 calls per hour)
•  36CCS = 1 erlang = 3600 call seconds during the busy hour.
•  Traffic is split roughly 65% to and from trunks, with the remainder internal or intercom traffic.
•  Traffic blocking is calculated using ErlangB formula
•  Traffic blocking probability for internal/intercom traffic is P.001 (1 in 1000 calls blocked)
•  Traffic blocking probability for trunk traffic is P.01 (1 in 100 calls blocked)
For TDM traffic it is possible to calculate the amount of traffic that needs to be presented in terms of CCS and match this
to a number of trunk channels. In the IP world fixed channels do not exist, so this calculation becomes a little trickier.
In calculating the amount of traffic that can be handled over a LAN or WAN link, the bandwidth calculations in section 3.6
Available Bandwidth can be applied. From these it is possible to work out a number of ‘voice channels’ and hence assign
a particular CCS rating.
4.2.1  WAN traffic worked example
In this example we will assume the following configuration:
•  There are 50 IP Phones at the corporate centre
•  There are 10 IP phones over a T1 link at a remote site
•  Trunk traffic is 65% of all traffic 
						

							16
CalculationFormulaResult
Remote Phones10Total CCS at remote site Remote phones x 6CCS 60CCSPercentage trunk traffic Total CCS x 65% 39CCSPercentage intercom traffic Total CCS x (100 – trunk traffic)% 21CCS
Total traffic over WANTotal traffic – local traffic60.0CCS
Thus:
•  The total traffic handled is 60CCS.
From an earlier calculation it was highlighted that a T1 WAN link, without QoS, could handle 6 G.711 ‘voice channels’.
From ErlangB tables with P.001 blocking such a link can handle 41.1CCS. There is therefore a mismatch between
presented traffic and carrying capacity.
Solutions that come from this can then be covered by:
•  Use compression (G.729) to the remote phones. This increases the ‘voice channel’ capability. However it also
reduces voice quality, which may not be acceptable.
•  The WAN link bandwidth could be increased
•  Enabling QoS support on the WAN link will allow an increase in capacity, in this case to 10 channels or 111CCS
•  The blocking ratio could be changed to P.01, such a link would handle 68.8CCS
•  The number of remote phones could be reduced, or the overall number of phones could be reduced.
These are all potential solutions and each may have to be investigated to understand the nature of the installation. Doing
this calculation up front ensures that such issues are highlighted before equipment is bought and installed.
4.3  IP Trunking limits
The IP-Trunking is a form of networking that allows traffic from different NODES to be passed between them. This
provides the ability to build larger systems, as well as combining systems in different geographic locations as a single
system.
Where LAN/WAN connections exist between nodes, then this medium can be used to pass traffic. A limit on the number
of conversations is set on this connection. In the event this limit is exceeded, an alternative path will be tried, be it via a
different node connected via IP, or alternatively through the PSTN TDM network.
The issue is what trunk restriction value to set for a particular connection. This relies very much on traffic and also the
bandwidth calculations, such as those carried out in earlier sections.
Since the bandwidth is derived from the number of conversations it is important to understand which CODEC will be used
across the link. Is it exclusively G.729, or G.711 or a combination of both?
Also, the level of networking between nodes needs to be understood and whether this includes PSTN trunk traffic or only
internal intercom traffic.
As a general guideline we can consider that a single node might have a high networking traffic ratio of 15%. For a
particular node with a number of devices, the amount of traffic to and from this node will remain essentially constant. In a
Multi-Node system, what will differ, will be the level of traffic destined for another particular node. For example, 15% of
traffic might be destined for the second node in a two-node system, but in a three node system, 7.5% will be destined for
Ethernet S witch
RouterRouter
LAN Segment
1
IP
Phone
(Remote) LAN
Segment 2
WAN3SX-200 IP NODE
Ethernet S witchIP
Phone
50 Phones10 Phones 
						

							17
each the other two nodes. Obviously in the second scenario less bandwidth will be needed per node to and from a
particular node, but the total per node will remain about the same, i.e. 7.5% + 7.5% = 15%.
4.3.1  IP Trunk Limit working example
Consider the following example:
•  Two equal sized systems
•  Exclusively 120 IP Trunks/phones
•  Calls from TDM, or to TDM devices including trunks, use G.711 CODEC
•  Calls between IP devices use the G.729 CODEC
•  Traffic is typically 35% internal, the remainder 65% to and from PSTN trunks
•  Calls internally are typically 50% outgoing and 50% incoming
•  Traffic is rated at 6CCS per device
•  Traffic between nodes is 15%
Doing some simple calculations below:
CalculationFormulaResult
Traffic from IP sets Number of sets (250) x 6CCS 1500CCSPercentage networked Total traffic  x 15% 225CCSPercentage traffic intercom Networked traffic  x 35% 79CCSPercentage traffic trunk to PSTN Networked traffic – intercom traffic 146CCSTotal Number of IP Trunk channels
neededErlangB on total IP trunk traffic (225CCS) 13 Channels (P.01)
Number of  channels needed for PSTN
Trunks (G.711)ErlangB on PSTN trunk traffic (146CCS) 10 Channels *1 (P.01)
Number of channels needed for
Intercom/Internal  traffic (G.729)ErlangB on Intercom traffic (79CCS) 7 Channels *1 (P.01)
Bandwidth needed (use worse case) Number of G.711 channels (10) x 100k +
[Total number of channels (13) – PSTN
trunk channels(10)] x 40k           *21120kbits/s
WAN Bandwidth RequiredAssume with QoS so / 70%1600kbits/sNumber of channels for IP TrunkTotal number of channels13 Channels
IP
PSTN
IP
PhoneIP
Phone
IP Trunking
G.711
G.729
IP-NodeIP-Node
SX200SX200 
						

							18
*1 Note: The number of channels needed purely for internal traffic is 7. For external traffic the total number is 10.
However, together the total is only 13. How is this so? The reason is that a number of channels will have shared use, in
this case it must be 4 (10+7-13). The higher G.711 rate is used to ensure adequate bandwidth at all times.
*2 Note: The bandwidths of 100k and 40k are used assuming that Ethernet is used between the two nodes. For example if
PPP were used between the two nodes then the bandwidths would reduce to 84k and 24k respectively reducing the
overall bandwidth requirement to 912kbits/s or a WAN bandwidth of 1300kbits/s.
Thus it can be seen that this data rate is pretty close to a typical T1 rate. The option could be to increase the available link
rate by upgrading to an E1 link, or multiple T1 links, or accept a lower quantity of IP Trunk calls, i.e. slight reduction in
inter-node traffic. 
						

							19
5. Getting Started
The above two sections have dealt with network conditions and call traffic. However, before any of this can occur, the
system needs to be installed and the end devices need some code to get them running.
5.1  Start-up sequence for phones:
This is the normal sequence of events for a dual port IP Phone, where VLANs are implemented:• Power up•  Run ‘Boot’ code•  Request IP address (untagged) through DHCP•  Receive IP address from default VLAN (data VLAN) and specific phone and system options•  Check VLAN information•  Relinquish/Release IP address (untagged)•  Request IP address on voice VLAN (tagged)•  Receive IP address from voice VLAN and specific phone and system options again•  Check VLAN information matches, if not repeat until it is.•  Locate TFTP server•  Get running code•  Register with call control• Go!
The phone does a double fetch of information, so it is important to have the same VLAN and priority information in the
DHCP server associated with the data VLAN as it is for the DHCP server associated with the voice VLAN, i.e. copy the
option data.
The engineering guideline that can be highlighted here is that this sequence works with either multiple DHCP servers on
each VLAN, or that the 
router/Layer3 switch connecting the VLANs has DHCP forwarding capability.
Some options also exist to improve system start-up time. To improve phone download time, especially when a number
(currently more than 400) of IP-Phones are associated with a controller, an external TFTP server, such as an NT server
can be used. In the DHCP server, used by the phones, just alter the TFTP IP address to match and copy the download
files onto the TFTP server. In this way multiple downloads can occur in parallel reducing system start-up time after a re-
boot.
The sequence above assumes that the phones will get information from a DHCP server. There is also the possibility to
manually programme up the IP-Phone with the same information as it starts to boot up. In this way the information is fixed,
and requires little DHCP intervention. This method can be particularly useful where a phone is used on a remote WAN link
and the router cannot forward DHCP requests, or where a local DHCP server does not exist. It can also be useful where
VPNs are employed, for much the same reasons, that DHCP forwarding may not be available.
5.2  Start-up Sequence for the Controller
The sequence involves bringing up the RTC with call control. and including the DHCP and TFTP servers. In parallel the
E2T (gateway) is also ‘brought into life’ and a couple of the DHCP of options are used to identify the download code for
this unit.
It is recommended that the IP NODE DHCP server be used locally within the NODE for devices on the voice VLAN. This
can be disabled, but would then require an external DHCP server to service devices on the voice VLAN.
5.3 DHCP Options
The DHCP options to use within the DHCP server may differ from product release to product release, so it is
recommended that the associated documentation for the product and release be consulted.
As an overview, the options currently used are shown here (product documentation is master):
DHCP Option Information
003 – Router Address IP Address, e.g. 192.167.22.251066 – FTP IP address (same as option 129), for E2T IP Address, e.g. 192.167.22.10067 –Name of file on FTP server “bootfile”128 – (Specific) TFTP Server IP Address, e.g. 192.167.22.10129 – (Specific) RTC IP Address, e.g. 192.167.22.10130 – (Specific) IP Phone Load “MITEL IP PHONE”132 – (Specific) VLAN ID (32 bit) 0x2133 – (Specific) Priority (32 bit) 0x6 
						

							20
5.4  DHCP Lease Time
To allow users to move off the local sub-net, or to let new people join a subnet, a method is needed to give up an IP
address and also obtain a new address. If a phone is disconnected it obviously cannot talk to the DHCP server, so
another method is needed to free up unused addresses. This is the DHCP lease time. This helps provide the Dynamic in
DHCP by clearing out unused IP addresses and making them available for new requests.
The timer can be set from a few minutes to weeks. Typically 
30 minutes is a good time. It reduces the amount of
checking to see if an IP address is still in use, as well as providing a reasonable recovery time to free up any unused
addresses.