The final component that is required to set up a functional CS1000E System is the Layer 2 switch. This provides data connectivity between the components of the system, including connectivity to IP sets.
A layer 2 switch transmits data packets directly to the targeted device only, rather than broadcasting them to every device on the network (like a hub would do). This prevents collisions and packet loss on the data network. Nortel recommends the use of a Baystack 460 switch with Power over Ethernet (for installations that use PoE), or the Baystack 470-24T switch.
Any third party layer 2 switch can be used with the CS1000 system, as long as it supports VLAN tagging and QoS. A switch that does not support QoS is not suitable for VoIP applications.
For a Power over Ethernet scenario each IP device requires a device that will split the CAT5 cable to add a power connection. PoE is useful in creating a system that will function in the event of a power failure without the use of a UPS at each station.
Showing posts with label QoS. Show all posts
Showing posts with label QoS. Show all posts
Network Policies and Management
A Network Policy is a set of rules governing the network. It can include traffic monitoring and controlling mechanisms. We should implement network policies in order to help implement QoS in a controlled manner. Network policies can also help with security implementations.
A Policy Decision Point (PDP) is the point in the network where decisions about policy are made. This is not to say that the PDP makes the policy – it just enforces them! A PDP can be almost any device in a network, including routers, switches, gateways, and servers. A PDP lets us enable multiple-media applications, WAN efficiency, and alignment of resources to business priorities, just name a few.
Policies are stored in a Policy Repository, which is an LDAP database. These policies are accessed by the PDP (sometimes referred to as a Policy Server). The PDP then distributes the policies to network devices, also referred to as Policy Enforcement Points. Typical policy management functions include:
1. Maximization of current bandwidth usage
2. Mapping network resources for increased performance without bandwidth cost
3. Identifying traffic flows for applications and services
4. Supporting advanced traffic prioritization
5. Administering rules or policies for network behavior
This is not a comprehensive list. There are many more functions of network policies, and I won’t begin to discuss them here. Nearly every corporation with a data or voice network has network policies. Often they are invisible to the end user; sometimes they are put in writing so that users can see them. Network policies are an excellent way to manage network traffic and should almost always be used to ensure Quality of Service.
Network management is also critical to network design. This includes the ability to manage individual devices on the network (with or without being physically present at the device), using fault management techniques, and identifying problems on a proactive basis. Of course, these are not the only things we need to think about when discussing network management, but they are very important. The last one is probably the most important – if we wait for a problem to arise before we fix it, we are asking for trouble. Fixing problems proactively is the key to ensuring network stability.
A Policy Decision Point (PDP) is the point in the network where decisions about policy are made. This is not to say that the PDP makes the policy – it just enforces them! A PDP can be almost any device in a network, including routers, switches, gateways, and servers. A PDP lets us enable multiple-media applications, WAN efficiency, and alignment of resources to business priorities, just name a few.
Policies are stored in a Policy Repository, which is an LDAP database. These policies are accessed by the PDP (sometimes referred to as a Policy Server). The PDP then distributes the policies to network devices, also referred to as Policy Enforcement Points. Typical policy management functions include:
1. Maximization of current bandwidth usage
2. Mapping network resources for increased performance without bandwidth cost
3. Identifying traffic flows for applications and services
4. Supporting advanced traffic prioritization
5. Administering rules or policies for network behavior
This is not a comprehensive list. There are many more functions of network policies, and I won’t begin to discuss them here. Nearly every corporation with a data or voice network has network policies. Often they are invisible to the end user; sometimes they are put in writing so that users can see them. Network policies are an excellent way to manage network traffic and should almost always be used to ensure Quality of Service.
Network management is also critical to network design. This includes the ability to manage individual devices on the network (with or without being physically present at the device), using fault management techniques, and identifying problems on a proactive basis. Of course, these are not the only things we need to think about when discussing network management, but they are very important. The last one is probably the most important – if we wait for a problem to arise before we fix it, we are asking for trouble. Fixing problems proactively is the key to ensuring network stability.
Traffic Flow Design Considerations
Traffic engineering involves the measurement and control of traffic. Main VoIP traffic sources are IP phones and VoIP Trunks. We need to be able to perform traffic engineering on individual nodes and consider the traffic between nodes. Traffic measurement is an analysis of existing traffic flow and the patterns of a network. This will help us to determine how many users and calls a VoIP network can support. Some operational metrics from the system include the number of calls and users, the duration of calls, the number of concurrent calls, call volume profiles, location and call flow, and the number and length of faxes sent and received. In order to assemble this traffic information and make a judgment we need to look at a number of design considerations:
1. System capacity for busy hour
2. Interfaces for critical connections
3. Single points of failure at critical points in the network
4. Is there sufficient power
5. If a device fails, does network design provide redundant paths?
Once again, I will reiterate that we should ONLY use switched media Ethernet networks with VoIP. Shared media, such as hubs, will cause problems. We need to ensure that QoS is being used, such as 802.1p, VLANs, port prioritization, and the rest. If we are fortunate enough to be using Layer 3 switching, we should try to use DiffServ to manage applications with different types of QoS services. And, of course, we should look to increase bandwidth as necessary.
When considering routing across a WAN, we have some additional factors to consider. WANs can require a large amount of memory and processing capacity. When designing WAN traffic flow, we should consider performance, resiliency, stability, and route cost. As always, performance is a large part of WAN design. When considering performance, we should:
1. Be aware of CPU utilization required for router intelligence
2. Move the heavy burden of processing routers to out-of-band processors
3. Use network routers for packet forwarding and handling
4. Deploy Layer 2 QoS Switching between policy switch stacks to reduce policy switch stack and router CPU utilization for LAN-Side traffic
5. Reduce the number of router zones (or areas)
The complexity of a network will dramatically affect its resiliency. Network instability, or Route Flapping, can occur on a more complex network. In addition, we need to consider route cost or metrics that will be applied to a route. In order to guarantee a scalable and reliable enterprise WAN service providers should offer a competitive Service Level Agreement (SLA). The SLA should clearly guarantee the maximum latency and available bandwidth. Increased reliability and performance requirements of converged networks put added pressures for the establishment of strong SLAs with our service providers. If our service provider of choice will not give us an acceptable SLA we should begin the process of looking for another service provider!
1. System capacity for busy hour
2. Interfaces for critical connections
3. Single points of failure at critical points in the network
4. Is there sufficient power
5. If a device fails, does network design provide redundant paths?
Once again, I will reiterate that we should ONLY use switched media Ethernet networks with VoIP. Shared media, such as hubs, will cause problems. We need to ensure that QoS is being used, such as 802.1p, VLANs, port prioritization, and the rest. If we are fortunate enough to be using Layer 3 switching, we should try to use DiffServ to manage applications with different types of QoS services. And, of course, we should look to increase bandwidth as necessary.
When considering routing across a WAN, we have some additional factors to consider. WANs can require a large amount of memory and processing capacity. When designing WAN traffic flow, we should consider performance, resiliency, stability, and route cost. As always, performance is a large part of WAN design. When considering performance, we should:
1. Be aware of CPU utilization required for router intelligence
2. Move the heavy burden of processing routers to out-of-band processors
3. Use network routers for packet forwarding and handling
4. Deploy Layer 2 QoS Switching between policy switch stacks to reduce policy switch stack and router CPU utilization for LAN-Side traffic
5. Reduce the number of router zones (or areas)
The complexity of a network will dramatically affect its resiliency. Network instability, or Route Flapping, can occur on a more complex network. In addition, we need to consider route cost or metrics that will be applied to a route. In order to guarantee a scalable and reliable enterprise WAN service providers should offer a competitive Service Level Agreement (SLA). The SLA should clearly guarantee the maximum latency and available bandwidth. Increased reliability and performance requirements of converged networks put added pressures for the establishment of strong SLAs with our service providers. If our service provider of choice will not give us an acceptable SLA we should begin the process of looking for another service provider!
Traffic Shaping at Level 4 and Above
Best Effort Networks, operating in layers 2, 3, and 4, are prone to delay and packet loss under congestion. These layers are used for IP traffic.
RTP Prioritization provides a strict priority queuing scheme for voice traffic. It identifies voice traffic by RTP port numbers and classifies traffic by specifying an RTP port range. If traffic matches the specified range, it is classified as voice and is placed in low latency queuing Priority Queue. If traffic does not fall within the specified port range it is classified by service policy of low latency queuing scheme.
TCP/IP Classification prioritizes packets by the packet header. There are four fragmentation methods:
1. Frame Relay Fragmentation is limited to Frame Relay connections. It enables data frames to be fragmented into smaller pieces and interleaved with real-time frames. It also enables real-time voice packets and non-real-time data packets to be carried together on lower speed links without causing excessive delay in real-time links.
2. ATM Fragmentation is limited to ATM Connections. It fragments packets into 53-byte cells for the interleaving of real-time and data packets.
3. PPP Fragmentation is limited to PPP links and splits packets into multiple smaller packets and encapsulates them into PPP frames before queuing them for transmission. Higher priority VoIP packets interrupt and transmit ahead of the larger, lower-priority data packets that were already queued and can interleave packets to minimize delay.
4. Protocol (IP) Fragmentation only transmits the layer 4 and higher protocol information in the first packet in a series of fragments.
Policy Management is another method of Layer 4 QoS. You can implement policy management on network components, such as devices, rules, actions, and policies. Policy management can actually be used on any layer of the OSI Model. Policy management controls traffic flow based on traffic conditions, schedules, and actions.
RTP Prioritization provides a strict priority queuing scheme for voice traffic. It identifies voice traffic by RTP port numbers and classifies traffic by specifying an RTP port range. If traffic matches the specified range, it is classified as voice and is placed in low latency queuing Priority Queue. If traffic does not fall within the specified port range it is classified by service policy of low latency queuing scheme.
TCP/IP Classification prioritizes packets by the packet header. There are four fragmentation methods:
1. Frame Relay Fragmentation is limited to Frame Relay connections. It enables data frames to be fragmented into smaller pieces and interleaved with real-time frames. It also enables real-time voice packets and non-real-time data packets to be carried together on lower speed links without causing excessive delay in real-time links.
2. ATM Fragmentation is limited to ATM Connections. It fragments packets into 53-byte cells for the interleaving of real-time and data packets.
3. PPP Fragmentation is limited to PPP links and splits packets into multiple smaller packets and encapsulates them into PPP frames before queuing them for transmission. Higher priority VoIP packets interrupt and transmit ahead of the larger, lower-priority data packets that were already queued and can interleave packets to minimize delay.
4. Protocol (IP) Fragmentation only transmits the layer 4 and higher protocol information in the first packet in a series of fragments.
Policy Management is another method of Layer 4 QoS. You can implement policy management on network components, such as devices, rules, actions, and policies. Policy management can actually be used on any layer of the OSI Model. Policy management controls traffic flow based on traffic conditions, schedules, and actions.
Implementing QoS At Layer 3
At Layer 3, Differentiated Services (DiffServ) provides a scalable mechanism for prioritizing packets and providing QoS on a VoIP network. There are three main levels identified by DiffServ. The highest priority level is Expedited Forwarding (EF). Expedited Forwarding packets get priority over all other packets. Assured Forwarding (AF) is the mid-level prioritization. Anything that is not EF or AF is classified as Default, and receives the lowest priority. The DiffServ identifier is found within the DiffServ Code Point (DSCP) found in the header of the IP packet.
DiffServ identifies Per-Hop Behaviors (PHB) for each packet that is sent through. A packet classified as EF will receive the highest priority, and is ideal for low-latency applications such as VoIP. An EF package will almost never be discarded from a DiffServ-capable device.
Assured Forwarding packets are subdivided into three behavior groups – Low Drop, Medium Drop, and High Drop. Each of these groups is further divided into four classes, Class 1, Class 2, Class 3, and Class 4. This gives us a total of twelve AF classifications. The drop precedence of these classifications is often defined by the queuing methods of QoS defined in the previous post. The most common methods are Fair Queuing or Weighted Fair Queuing. The level of forwarding assurance is determined by the load of the AF class and the drop precedence of the packet (in the case of congestion within a class).
A Default (DE) packet is sent using a best-effort behavior. If no DiffServ argument is included in a packet it is assumed to be part of the default category.
There are multiple points where a package can be marked for DiffServ. It can be marked using the end point within the device or application from which it originates, it can be marked using intelligent switches where the device is connected to a network based on its TCP/UDP Port, IP Address, or VLAN. The packet can be marked at a core or edge router where the packet encounters links. Traffic entering a network is classified, and possibly conditioned, at the boundaries of the network and is assigned to different behavior aggregates identified by a single DSCP. DiffServ edge router and switch interfaces can be configured to trust or distrust previously marked DSCP or 802.1p tagged packets. If the packet is trusted, the DSCP tag will remain the same. If it is distrusted, the DiffServ router will assign a new DSCP tag.
There are three types of nodes on a DiffServ domain: Edge nodes, Boundary Nodes, and Interior Nodes. The Edge node is the first IP Aware device that applies QoS policies. Edge Nodes and Boundary Nodes are configured to trust or distrust the DSCP identification and forward the packets from one node to another.
DiffServ identifies Per-Hop Behaviors (PHB) for each packet that is sent through. A packet classified as EF will receive the highest priority, and is ideal for low-latency applications such as VoIP. An EF package will almost never be discarded from a DiffServ-capable device.
Assured Forwarding packets are subdivided into three behavior groups – Low Drop, Medium Drop, and High Drop. Each of these groups is further divided into four classes, Class 1, Class 2, Class 3, and Class 4. This gives us a total of twelve AF classifications. The drop precedence of these classifications is often defined by the queuing methods of QoS defined in the previous post. The most common methods are Fair Queuing or Weighted Fair Queuing. The level of forwarding assurance is determined by the load of the AF class and the drop precedence of the packet (in the case of congestion within a class).
A Default (DE) packet is sent using a best-effort behavior. If no DiffServ argument is included in a packet it is assumed to be part of the default category.
There are multiple points where a package can be marked for DiffServ. It can be marked using the end point within the device or application from which it originates, it can be marked using intelligent switches where the device is connected to a network based on its TCP/UDP Port, IP Address, or VLAN. The packet can be marked at a core or edge router where the packet encounters links. Traffic entering a network is classified, and possibly conditioned, at the boundaries of the network and is assigned to different behavior aggregates identified by a single DSCP. DiffServ edge router and switch interfaces can be configured to trust or distrust previously marked DSCP or 802.1p tagged packets. If the packet is trusted, the DSCP tag will remain the same. If it is distrusted, the DiffServ router will assign a new DSCP tag.
There are three types of nodes on a DiffServ domain: Edge nodes, Boundary Nodes, and Interior Nodes. The Edge node is the first IP Aware device that applies QoS policies. Edge Nodes and Boundary Nodes are configured to trust or distrust the DSCP identification and forward the packets from one node to another.
QoS At Layer 2
There are methods of implementing quality of service at different layers. I would like to begin by talking about the methods of implementing QoS at Layer 2.
The Ethernet Standard specifies a frame as having a maximum size of 1,518 bytes. The IEEE defined an additional 4-byte tag for Ethernet Headers, increasing the maximum size to 1,522 bytes. This tag contains two valuable pieces of information that pertain to QoS, the 802.1w VLAN ID Field, and the 802.1p Priority Field.
I will begin by discussing the 802.1p Priority field. Three bits in the IEEE Ethernet Protocol Specification can be used to prioritize packets at the user level. The three bits allow for up to eight levels of prioritization (0-7). Any 802.1p switch is capable of reading this field and can then retransmit the packet across the network with the higher priority. The higher the number in the priority field, the higher priority the switch will give to the packet. The IEEE has made some recommendations for the numbering system to be used here, but it is at the discretion of the network administrator. IEEE recommendations are to use 0 for Best Effort, 1 for Background, 2 as a spare, 3 as Excellent Effort, 4 as Controlled Load, 5 as Video, 6 as Voice, and 7 as Network Control.
The 802.1q specification, also known as VLAN Tagging, refers to the process of identifying which VLAN a packet is coming from. A VLAN, or Virtual LAN, makes a physical switch into smaller logical groupings. For example, a 24-port switch may be divided into three smaller 8-port virtual switches to eliminate leakage of data from one section to the next. This is very useful in a VoIP deployment, as data and voice VLANs can be created to minimize the effect of data transmission on the voice network. VLANs work to reduce the number of collisions and lost packets on a network. There are two types of VLAN – Port-based and policy-based. A Port-based VLAN will assign certain ports on a switch to be members of a VLAN. This is the most common type of VLAN. A policy-based VLAN can be based on a variety of information, such as IP Address, MAC Address, or Protocol (i.e. IP vs. IPX). Most new switches support Port-based VLANs. It is possible to improve QoS by putting IP phones on a separate VLAN from data and other devices, thereby avoiding collisions with these devices.
To ensure QoS we can also select queuing methods for the packets that come into our router. There are six methods of queuing for QoS:
1. First-in First-Out is a straight-forward method of queuing. The first packet received by a switch is the first on sent out by the switch
2. Priority Queuing tells the switch to process high priority traffic first
3. Custom Queuing lets the administrator assign traffic to a certain queue to control how much data is sent each time to a particular queue
4. Fair Queuing uses a round-robin approach – each queue receives the same amount of bandwidth
5. Weighted Round Robin lets the administrator allocate different amounts of bandwidth to different priority queues while ensuring that lower priority queues still receive some bandwidth
6. Weighted Fair Queuing identifies logical conversations (high volume traffic between 2 peers) and makes sure that those conversations do not monopolize the link.
The Resource Reservation Protocol (RSVP) is a method used to reserve resources (or bandwidth) on an RSVP-Compliant router. Resources are allocated on a first-come-first-serve basis. A device requests a certain amount of bandwidth, and the router replies that the bandwidth is now reserved. It will not release the bandwidth until the device is done. This protocol does not carry data; it only acts as a control mechanism for RDP packets. It is not very widely used today.
Traffic Shaping is used to help alleviate network congestion. Network congestion can occur when multiple users contend for access to the same resources. Traffic Shaping lets you determine which packets are dropped due to congestion and which packets receive priority. It can take action based on various characteristics of traffic. It also relies on queuing mechanisms.
IP Address prioritization is as simple as it sounds – packets from certain IP addresses are given priority over packets from other IP addresses. This is ideal for devices with static IP Addresses, such as Call Servers, Signaling Servers, VoIP Gateways, etc. A Network Administrator can configure routers to filter and prioritize all packets originating from these IP Addresses and know they are from VoIP devices.
The Ethernet Standard specifies a frame as having a maximum size of 1,518 bytes. The IEEE defined an additional 4-byte tag for Ethernet Headers, increasing the maximum size to 1,522 bytes. This tag contains two valuable pieces of information that pertain to QoS, the 802.1w VLAN ID Field, and the 802.1p Priority Field.
I will begin by discussing the 802.1p Priority field. Three bits in the IEEE Ethernet Protocol Specification can be used to prioritize packets at the user level. The three bits allow for up to eight levels of prioritization (0-7). Any 802.1p switch is capable of reading this field and can then retransmit the packet across the network with the higher priority. The higher the number in the priority field, the higher priority the switch will give to the packet. The IEEE has made some recommendations for the numbering system to be used here, but it is at the discretion of the network administrator. IEEE recommendations are to use 0 for Best Effort, 1 for Background, 2 as a spare, 3 as Excellent Effort, 4 as Controlled Load, 5 as Video, 6 as Voice, and 7 as Network Control.
The 802.1q specification, also known as VLAN Tagging, refers to the process of identifying which VLAN a packet is coming from. A VLAN, or Virtual LAN, makes a physical switch into smaller logical groupings. For example, a 24-port switch may be divided into three smaller 8-port virtual switches to eliminate leakage of data from one section to the next. This is very useful in a VoIP deployment, as data and voice VLANs can be created to minimize the effect of data transmission on the voice network. VLANs work to reduce the number of collisions and lost packets on a network. There are two types of VLAN – Port-based and policy-based. A Port-based VLAN will assign certain ports on a switch to be members of a VLAN. This is the most common type of VLAN. A policy-based VLAN can be based on a variety of information, such as IP Address, MAC Address, or Protocol (i.e. IP vs. IPX). Most new switches support Port-based VLANs. It is possible to improve QoS by putting IP phones on a separate VLAN from data and other devices, thereby avoiding collisions with these devices.
To ensure QoS we can also select queuing methods for the packets that come into our router. There are six methods of queuing for QoS:
1. First-in First-Out is a straight-forward method of queuing. The first packet received by a switch is the first on sent out by the switch
2. Priority Queuing tells the switch to process high priority traffic first
3. Custom Queuing lets the administrator assign traffic to a certain queue to control how much data is sent each time to a particular queue
4. Fair Queuing uses a round-robin approach – each queue receives the same amount of bandwidth
5. Weighted Round Robin lets the administrator allocate different amounts of bandwidth to different priority queues while ensuring that lower priority queues still receive some bandwidth
6. Weighted Fair Queuing identifies logical conversations (high volume traffic between 2 peers) and makes sure that those conversations do not monopolize the link.
The Resource Reservation Protocol (RSVP) is a method used to reserve resources (or bandwidth) on an RSVP-Compliant router. Resources are allocated on a first-come-first-serve basis. A device requests a certain amount of bandwidth, and the router replies that the bandwidth is now reserved. It will not release the bandwidth until the device is done. This protocol does not carry data; it only acts as a control mechanism for RDP packets. It is not very widely used today.
Traffic Shaping is used to help alleviate network congestion. Network congestion can occur when multiple users contend for access to the same resources. Traffic Shaping lets you determine which packets are dropped due to congestion and which packets receive priority. It can take action based on various characteristics of traffic. It also relies on queuing mechanisms.
IP Address prioritization is as simple as it sounds – packets from certain IP addresses are given priority over packets from other IP addresses. This is ideal for devices with static IP Addresses, such as Call Servers, Signaling Servers, VoIP Gateways, etc. A Network Administrator can configure routers to filter and prioritize all packets originating from these IP Addresses and know they are from VoIP devices.
The RTP Header
The Real-Time Transport Protocol header contains a lot of necessary information for a VoIP (or any other real-time) communication. Major components include the RTP Timeclock, the RTP Timestamp, the Synchronization Source, the Contributing Source, the Payload Identification, the Sequence ID, and feedback on jitter.
The RTP Timeclock is an autonomous clock source that determines how many clock ticks have occurred. The RTP timestamp is a counter value that shows when a packet was created, and supports both silence suppression and jitter calculation. The Synchronization source (SSRC) is a unique, randomly-generated identifier that the RTP client uses to identify an RTP session, including which parties are talking and which are silent. The Contributing Source (CSRC) is an identifying list found after the RTP Packet Header, it preserves the identity of the original source. The Payload Identification is a traffic identifier, it identifies the CODEC being used. The Sequence ID is part of the header information, and contains information regarding the order that the packets were sent in. The Feedback on Jitter portion of the RTP header provides potential adjustments that will be required for the possible buffer adjustment.
Since RTP is a connectionless protocol it does not provide feedback to the sending computer. To address this issue the Real Time Control Protocol (RTCP) has been added. RTCP provides end-to-end delivery services for real-time traffic, including monitoring QoS and providing some feedback in QoS reports. It also prvides additional information about the sender, such as the name, telephone number, etc.
The RTP Timeclock is an autonomous clock source that determines how many clock ticks have occurred. The RTP timestamp is a counter value that shows when a packet was created, and supports both silence suppression and jitter calculation. The Synchronization source (SSRC) is a unique, randomly-generated identifier that the RTP client uses to identify an RTP session, including which parties are talking and which are silent. The Contributing Source (CSRC) is an identifying list found after the RTP Packet Header, it preserves the identity of the original source. The Payload Identification is a traffic identifier, it identifies the CODEC being used. The Sequence ID is part of the header information, and contains information regarding the order that the packets were sent in. The Feedback on Jitter portion of the RTP header provides potential adjustments that will be required for the possible buffer adjustment.
Since RTP is a connectionless protocol it does not provide feedback to the sending computer. To address this issue the Real Time Control Protocol (RTCP) has been added. RTCP provides end-to-end delivery services for real-time traffic, including monitoring QoS and providing some feedback in QoS reports. It also prvides additional information about the sender, such as the name, telephone number, etc.
Transport and Session Layer Technologies
Transport and Session are layers 4 and 5 of the OSI model. The Transport Layer (Layer 4) establishes, maintains, and terminates communication between networked machines. The Session Layer (Layer 5) initiates contact between applications and governs the exchange of data between programs. The IP Suite compresses the upper three layers (Application, Presentation, and Session) into one layer called Application. The transport layer remains the same. The Network layer is called the Internet Layer (but performs the same functions), and the bottom two layers, Data Link and Physical, are grouped into one layer called the Network Interface Layer. In the IP suite transport layer there are two methods of delivery: TCP and UDP. TCP stands for Transmission Control Protocol. This is the most common method of delivery in data networks. Each packet sent is acknowledged by the receiving end and missing packets are re-transmitted. UDP, or User Datagram Protocol, is referred to as a connectionless protocol. It does not try to retransmit missing data; instead it assumes that all the data that was sent was received. While this may not sound like the best idea it is an optimal solution for VoIP and other time-sensitive applications, as it does not waste bandwidth with acknowledgements and retransmission of packets. Using this best-effort method, UDP is able to present our VoIP applications with a steady stream of voice packets with minimal delay.
The IP suite is a connectionless Layer 3 protocol with no continuing connection between endpoints. As such, there can be multiple Layer 2 protocols used, including Ethernet, ATM, PPP, Multi-Protocol Label Switching (MPLS), Frame Relay, and Wireless protocols. I would like to take some time now to discuss some of these protocols.
Frame Relay is a cost-effective alternative to a leased line. It can work at speeds from 56kbps to 45Mbps. It provides some QoS capabilities, including prioritization (802.11p) and DiffServ. It exists at Layer 2 so there is less processing to perform at each node. It is considered to be a best-effort protocol, as once a packet enters the network it is not guaranteed any priority over other packets. The delays are higher and more variable than the PSTN. This can lead to an increased chance of serialization delay. Frame relay does offer error correction. When purchasing a Frame Relay connection you purchase a Converted Information Rate (CIR). This is your guaranteed throughput on the relay. If the CIR is too low there is a chance the packets may be dropped, resulting in poor voice quality.
Asynchronous Transfer Mode, or ATM, is available from service providers in four distinct levels of service. The first, Constant Bit Rate (CBR) specifies a fixed bit rate so that data is sent at a constant rate, similar to a leased line. A Variable Bit Rate (VBR) provides a specified throughput capacity, but the data is not sent evenly. VBR is a popular choice for voice and video conferencing data. Unspecified Bit Rate (UBR) does not guarantee throughput rates. It is generally used for applications that can tolerate delays, such as file transfer and other data applications. Available Bit Rate provides a guaranteed minimum capacity and allows for the ability to burst data throughput rates when the network capacity is available. ATM speeds range from 25Mbps to 622Mbps. It has sophisticated QoS services, including DiffServ. Using CBR or VBR you can also receive a guarantee of prioritization. ATM is, unfortunately, not always available and is both difficult to set up and very costly. The equipment required to run ATM is very costly on its own. ATM does have a larger header than many alternatives, and is also subject to serialization delays. ATM will have a lower serialization delay than Frame Relay, however.
Point-to-Point Protocol, or PPP, is used to transmit datagrams between peer routers or other devices over dedicated switched lines. This also the method used to connect dial-up Internet connections. It uses a dedicated link, and therefore can provide the greatest QoS. It is full duplex and can be dedicated or circuit switched.
Wireless LAN is a relatively new technology. WLANs function on radio broadcast frequencies. Devices share the physical layer (the radio band). They must contend for use of the media. There is no collision detection with a WLAN, so collision avoidance methods are used – devices must wait for an inter-frame spacing interval before they transmit, and they must not transmit while other devices are transmitting.
Multi-Protocol Label Switching (MPLS) is a newer transport method. It provides a data transport mechanism for both circuit-based and packet-switched environments, and supports more than one transport method. It can use IP, ATM, SONET, and Ethernet.
Finally, there are common residential connections, namely Cable and DSL. These are best-effort methods, and do not provide and QoS. They are able to provide high-bandwidth Internet access, but minimum transmission speeds are not guaranteed.
The IP suite is a connectionless Layer 3 protocol with no continuing connection between endpoints. As such, there can be multiple Layer 2 protocols used, including Ethernet, ATM, PPP, Multi-Protocol Label Switching (MPLS), Frame Relay, and Wireless protocols. I would like to take some time now to discuss some of these protocols.
Frame Relay is a cost-effective alternative to a leased line. It can work at speeds from 56kbps to 45Mbps. It provides some QoS capabilities, including prioritization (802.11p) and DiffServ. It exists at Layer 2 so there is less processing to perform at each node. It is considered to be a best-effort protocol, as once a packet enters the network it is not guaranteed any priority over other packets. The delays are higher and more variable than the PSTN. This can lead to an increased chance of serialization delay. Frame relay does offer error correction. When purchasing a Frame Relay connection you purchase a Converted Information Rate (CIR). This is your guaranteed throughput on the relay. If the CIR is too low there is a chance the packets may be dropped, resulting in poor voice quality.
Asynchronous Transfer Mode, or ATM, is available from service providers in four distinct levels of service. The first, Constant Bit Rate (CBR) specifies a fixed bit rate so that data is sent at a constant rate, similar to a leased line. A Variable Bit Rate (VBR) provides a specified throughput capacity, but the data is not sent evenly. VBR is a popular choice for voice and video conferencing data. Unspecified Bit Rate (UBR) does not guarantee throughput rates. It is generally used for applications that can tolerate delays, such as file transfer and other data applications. Available Bit Rate provides a guaranteed minimum capacity and allows for the ability to burst data throughput rates when the network capacity is available. ATM speeds range from 25Mbps to 622Mbps. It has sophisticated QoS services, including DiffServ. Using CBR or VBR you can also receive a guarantee of prioritization. ATM is, unfortunately, not always available and is both difficult to set up and very costly. The equipment required to run ATM is very costly on its own. ATM does have a larger header than many alternatives, and is also subject to serialization delays. ATM will have a lower serialization delay than Frame Relay, however.
Point-to-Point Protocol, or PPP, is used to transmit datagrams between peer routers or other devices over dedicated switched lines. This also the method used to connect dial-up Internet connections. It uses a dedicated link, and therefore can provide the greatest QoS. It is full duplex and can be dedicated or circuit switched.
Wireless LAN is a relatively new technology. WLANs function on radio broadcast frequencies. Devices share the physical layer (the radio band). They must contend for use of the media. There is no collision detection with a WLAN, so collision avoidance methods are used – devices must wait for an inter-frame spacing interval before they transmit, and they must not transmit while other devices are transmitting.
Multi-Protocol Label Switching (MPLS) is a newer transport method. It provides a data transport mechanism for both circuit-based and packet-switched environments, and supports more than one transport method. It can use IP, ATM, SONET, and Ethernet.
Finally, there are common residential connections, namely Cable and DSL. These are best-effort methods, and do not provide and QoS. They are able to provide high-bandwidth Internet access, but minimum transmission speeds are not guaranteed.
Bandwidth Requirements
I would like to talk a little bit about the bandwidth requirements for a VoIP network. Bandwidth is a measurement of how much traffic can go through your network.
For lower bandwidth connections (i.e. less than 1Mbps) it is recommended that no more than 50-55% of the total available bandwidth be used for voice traffic. For connections greater than 1 Mbps you can use up to 85% of your available bandwidth for voice traffic. This leaves some headroom on the links to handle bursts of traffic without overloading the link. A bottleneck can occur at any point on the network, including device to switch, switch to switch, switch to gateway, and many more. As such we need to ensure that there is sufficient bandwidth in every pipe on our network to handle the traffic that is being sent.
In addition to the amount of bandwidth required by the data being transmitted, there is additional bandwidth required for every packet sent based on which layer 2 method you are using. For a Frame Relay connection there is a requirement of 6 bytes of overhead. For Point-to-Point Protocol (PPP) there is a requirement for 8 bytes of overhead. Full Duplex Ethernet can be either 38 bytes of 44 bytes – the additional 6 bytes are only used if you have implemented 802.1p, or packet prioritization.
The amount of bandwidth that is required must include the amount of bandwidth required for the CODEC and the amount of bandwidth required for the transport of the packet, including the layer 2 overhead.
Each packet has the following components:
Voice Payload à This is a variable size, and depends on the configuration of your VoIP implementation
RTP Header à 12 bytes, this contains information about the source & destination
UDP Header à 8 bytes, this contains information on the ports used at the source and destination
IPv4 Header à 20 Bytes, included in all IPv4 packets. An IPv6 header is even larger, as the header must include larger addresses and other information
In addition, there are two further components, the Frame Check Sequence of 4 Bytes and the Interframe Gap of 12 Bytes
As we can see, the packet size is 40 bytes plus the size of the payload. As I mentioned earlier, the size of the payload is variable, and depends on the sample length and the CODEC bit rate. The payload size can be calculated using the following formula:
Payload = Bit Rate * Sample Length (s) / 8 bits per byte
This will give us the number of Bytes of payload that needs to be included in the package. We then add to this the amount of overhead from Layer 2 and the amount of IP overhead to give us our total packet size. As an example, let’s take a 20 ms sample size using G.729 (8kbps) over Ethernet using 802.1p:
Payload = 8kbps * 0.02s / 8
Payload = 8000 bps * 0.02s / 8
Payload = 160 bps / 8 = 20 Byte payload size
We then add our overhead to the payload:
Packet size = Payload + Layer 2 overhead + IP Overhead + FCS + IFG
Packet size = 20 Bytes + 44 Bytes + 40 Bytes + 4 Bytes + 12 Bytes
Packet size = 120 Bytes for 20 ms of voice traffic
We can then take this and determine how much bandwidth is required by converting this to bps. We need to determine how many packets per second of voice. As we have seen, 20ms is 0.02 seconds of data, which means that we are using 50 packets per second. So, we multiply our 120 Bytes/packet * 50 packets/second to give us 6000 Bytes per second. We then multiply by 8 to give us bits per second ~ 48000 bps of bandwidth for each direction of a call.
It should also be noted that if we are using the Real-Time Control Protocol we need to add an additional 146 bytes of data to our packet size.
Voice Activity Detection can reduce our bandwidth requirements, as was mentioned before. It enables a data network carrying voice traffic to detect the absence of audio. When audio is absent, it will instead send a signal that indicates that there is no noise, thereby reducing the payload size. A conservative estimate of the bandwidth savings gained using VAD is 30%. VAD is also referred to as Silence Suppression.
EDIT: A Bandwidth calculator is available here.
For lower bandwidth connections (i.e. less than 1Mbps) it is recommended that no more than 50-55% of the total available bandwidth be used for voice traffic. For connections greater than 1 Mbps you can use up to 85% of your available bandwidth for voice traffic. This leaves some headroom on the links to handle bursts of traffic without overloading the link. A bottleneck can occur at any point on the network, including device to switch, switch to switch, switch to gateway, and many more. As such we need to ensure that there is sufficient bandwidth in every pipe on our network to handle the traffic that is being sent.
In addition to the amount of bandwidth required by the data being transmitted, there is additional bandwidth required for every packet sent based on which layer 2 method you are using. For a Frame Relay connection there is a requirement of 6 bytes of overhead. For Point-to-Point Protocol (PPP) there is a requirement for 8 bytes of overhead. Full Duplex Ethernet can be either 38 bytes of 44 bytes – the additional 6 bytes are only used if you have implemented 802.1p, or packet prioritization.
The amount of bandwidth that is required must include the amount of bandwidth required for the CODEC and the amount of bandwidth required for the transport of the packet, including the layer 2 overhead.
Each packet has the following components:
Voice Payload à This is a variable size, and depends on the configuration of your VoIP implementation
RTP Header à 12 bytes, this contains information about the source & destination
UDP Header à 8 bytes, this contains information on the ports used at the source and destination
IPv4 Header à 20 Bytes, included in all IPv4 packets. An IPv6 header is even larger, as the header must include larger addresses and other information
In addition, there are two further components, the Frame Check Sequence of 4 Bytes and the Interframe Gap of 12 Bytes
As we can see, the packet size is 40 bytes plus the size of the payload. As I mentioned earlier, the size of the payload is variable, and depends on the sample length and the CODEC bit rate. The payload size can be calculated using the following formula:
Payload = Bit Rate * Sample Length (s) / 8 bits per byte
This will give us the number of Bytes of payload that needs to be included in the package. We then add to this the amount of overhead from Layer 2 and the amount of IP overhead to give us our total packet size. As an example, let’s take a 20 ms sample size using G.729 (8kbps) over Ethernet using 802.1p:
Payload = 8kbps * 0.02s / 8
Payload = 8000 bps * 0.02s / 8
Payload = 160 bps / 8 = 20 Byte payload size
We then add our overhead to the payload:
Packet size = Payload + Layer 2 overhead + IP Overhead + FCS + IFG
Packet size = 20 Bytes + 44 Bytes + 40 Bytes + 4 Bytes + 12 Bytes
Packet size = 120 Bytes for 20 ms of voice traffic
We can then take this and determine how much bandwidth is required by converting this to bps. We need to determine how many packets per second of voice. As we have seen, 20ms is 0.02 seconds of data, which means that we are using 50 packets per second. So, we multiply our 120 Bytes/packet * 50 packets/second to give us 6000 Bytes per second. We then multiply by 8 to give us bits per second ~ 48000 bps of bandwidth for each direction of a call.
It should also be noted that if we are using the Real-Time Control Protocol we need to add an additional 146 bytes of data to our packet size.
Voice Activity Detection can reduce our bandwidth requirements, as was mentioned before. It enables a data network carrying voice traffic to detect the absence of audio. When audio is absent, it will instead send a signal that indicates that there is no noise, thereby reducing the payload size. A conservative estimate of the bandwidth savings gained using VAD is 30%. VAD is also referred to as Silence Suppression.
EDIT: A Bandwidth calculator is available here.
Quality of Service
As I have mentioned before, packets are transmitted from one end and recompiled at the destination. Not all packets will necessarily take the same path to their destination, which means that they may not all arrive in the same order they were sent in. We can also experience packet loss. In a data network, if a packet is lost or discarded, it is simply re-sent. In a VoIP environment this is not an option. All packets are time-critical and must be received in a timely fashion. We can’t wait for a packet to be re-sent! Quality of Services tries to ensure that time-sensitive packets are given priority over data packets. Other considerations include the amount of packet overhead and the size of the packets. A smaller packet size is more tolerant to packet loss, but every packet has a fixed amount of overhead. For Ethernet, this is 40 bytes. Packet size must be considered when we calculate the bandwidth requirements for our network.
There are several methods that can be used to ensure quality of service in a VoIP network. First I would like to look at Call Admission Control (CAC). CAC can help prevent network congestion by limiting the number of calls that can be active through various nodes in the network. Without CAC, voice quality in the network will decline as the number of calls increases above the recommended utilization. CAC can be defined by a number of rules, including (but not limited to) time of day restrictions, user-level restrictions, VLAN restrictions, IP restrictions, and many more. Policies regarding CAC should be developed at the time of implementation to ensure that problems do not arise down the road. If an organization outgrows it’s CAC policy more bandwidth may be required to grow the voice network.
A firewall may be another factor that affects Quality of Service. Firewalls restrict traffic coming onto and leaving the network based on security rules. An improperly configured firewall may block voice traffic in one direction or another, or both. This can result in one-way speech or no-way speech. It is necessary to open the required ports on the firewall to allow voice traffic to pass through. An even more effective method of managing your firewall would be to have a firewall that specifically recognizes VoIP packets and allows them through.
Network Address Translation (NAT) is another common problem with VoIP implementations. NAT allows multiple devices on a private network to have access to a public network through a single public IP address. VoIP does not work well with NAT, as the originating IP address does not correspond with the external IP address, and the originator is deeply embedded into the packet when it is sent through the NAT server. When the packet is returned to the NAT server, the server is unable to identify where the packet should be sent, resulting in one-way speech. Some new NAT servers are able to understand and process VoIP communications, however.
Packet Delay is also another important consideration with regards to Quality of Service. As delay increases users will start to experience loss, delay, and jitter. With any VoIP implementation there is a fixed delay as the packets cross the network. Fixed delay is also referred to as latency, and is defined as the minimum time it takes from speaking at one end to being heard at the other end. There are many factors that affect packet delay, including the CODEC, network topology, serialization delay, propagation distance, and link delay. As delay increases, the usability of the voice signal decreases. A general rule of thumb with regards to delay is:
Toll Quality < 100 ms < Good Quality < 150 ms < Potentially Useful < 400 ms < Poor Quality
Additionally, Serialization Delay is an issue caused when data is going from a high-speed pipe to a low-speed pipe. The high speed pipe can quickly overwhelm the low speed pipe with information, particularly if QoS policies are not maintained. This can result in jitter and packet loss as the low speed pipe tries to handle all of the data that the high speed pipe is feeding through to it. Serialization delay issues can be solved fairly easily. First you must implement fragmentation. This divides the large frames into smaller frames, which allows for interleaving. Interleaving is the process of allowing smaller frames to be transmitted in between the fragments of the larger frames. If you fragment without interleaving you will actually increase serialization delay, however, as each packet will still have a fixed amount of overhead. Additional overhead will cause more data to be transmitted across the network, resulting in further serialization delay. Nortel recommends only implementing fragmentation on links that require it, primarily links with less than 1Mbps of bandwidth. Fragmentation is set by using the Maximum Transmission Unit (MTU) setting. There are a few formulas for calculating MTU and serialization delay:
Serialization Delay: MTU (B) x 8 / link speed (bps) = Delay (s)
Serialization Delay: MTU (b) / link speed (bps) = Delay (s)
Ideal MTU: link speed (bps) * 0.01s / 8 = Ideal MTU (b)
Packet Loss Concealment is another solution for QoS. Packet Loss Concealment is a method by which the CODEC will guess as to what the missing packet contains. It is not supported by all CODECs, but is an effective way to ignore lost packets without sacrificing much call quality. G.711 does not support PLC, as it transmits PCM data, but G.729 does.
Finally, there is a single solution to a large number of QoS issues: Increase bandwidth. When more bandwidth becomes available, almost all QoS issues disappear.
There are several methods that can be used to ensure quality of service in a VoIP network. First I would like to look at Call Admission Control (CAC). CAC can help prevent network congestion by limiting the number of calls that can be active through various nodes in the network. Without CAC, voice quality in the network will decline as the number of calls increases above the recommended utilization. CAC can be defined by a number of rules, including (but not limited to) time of day restrictions, user-level restrictions, VLAN restrictions, IP restrictions, and many more. Policies regarding CAC should be developed at the time of implementation to ensure that problems do not arise down the road. If an organization outgrows it’s CAC policy more bandwidth may be required to grow the voice network.
A firewall may be another factor that affects Quality of Service. Firewalls restrict traffic coming onto and leaving the network based on security rules. An improperly configured firewall may block voice traffic in one direction or another, or both. This can result in one-way speech or no-way speech. It is necessary to open the required ports on the firewall to allow voice traffic to pass through. An even more effective method of managing your firewall would be to have a firewall that specifically recognizes VoIP packets and allows them through.
Network Address Translation (NAT) is another common problem with VoIP implementations. NAT allows multiple devices on a private network to have access to a public network through a single public IP address. VoIP does not work well with NAT, as the originating IP address does not correspond with the external IP address, and the originator is deeply embedded into the packet when it is sent through the NAT server. When the packet is returned to the NAT server, the server is unable to identify where the packet should be sent, resulting in one-way speech. Some new NAT servers are able to understand and process VoIP communications, however.
Packet Delay is also another important consideration with regards to Quality of Service. As delay increases users will start to experience loss, delay, and jitter. With any VoIP implementation there is a fixed delay as the packets cross the network. Fixed delay is also referred to as latency, and is defined as the minimum time it takes from speaking at one end to being heard at the other end. There are many factors that affect packet delay, including the CODEC, network topology, serialization delay, propagation distance, and link delay. As delay increases, the usability of the voice signal decreases. A general rule of thumb with regards to delay is:
Toll Quality < 100 ms < Good Quality < 150 ms < Potentially Useful < 400 ms < Poor Quality
Additionally, Serialization Delay is an issue caused when data is going from a high-speed pipe to a low-speed pipe. The high speed pipe can quickly overwhelm the low speed pipe with information, particularly if QoS policies are not maintained. This can result in jitter and packet loss as the low speed pipe tries to handle all of the data that the high speed pipe is feeding through to it. Serialization delay issues can be solved fairly easily. First you must implement fragmentation. This divides the large frames into smaller frames, which allows for interleaving. Interleaving is the process of allowing smaller frames to be transmitted in between the fragments of the larger frames. If you fragment without interleaving you will actually increase serialization delay, however, as each packet will still have a fixed amount of overhead. Additional overhead will cause more data to be transmitted across the network, resulting in further serialization delay. Nortel recommends only implementing fragmentation on links that require it, primarily links with less than 1Mbps of bandwidth. Fragmentation is set by using the Maximum Transmission Unit (MTU) setting. There are a few formulas for calculating MTU and serialization delay:
Serialization Delay: MTU (B) x 8 / link speed (bps) = Delay (s)
Serialization Delay: MTU (b) / link speed (bps) = Delay (s)
Ideal MTU: link speed (bps) * 0.01s / 8 = Ideal MTU (b)
Packet Loss Concealment is another solution for QoS. Packet Loss Concealment is a method by which the CODEC will guess as to what the missing packet contains. It is not supported by all CODECs, but is an effective way to ignore lost packets without sacrificing much call quality. G.711 does not support PLC, as it transmits PCM data, but G.729 does.
Finally, there is a single solution to a large number of QoS issues: Increase bandwidth. When more bandwidth becomes available, almost all QoS issues disappear.
Subscribe to:
Posts (Atom)