DOI:10.32604/iasc.2022.021458
| Intelligent Automation & Soft Computing DOI:10.32604/iasc.2022.021458 | |
| Article |
Saving the Bandwidth of IPv6 Networks Using the Fields of the Packet Header
Faculty of Information Technology, Al-Ahliyya Amman University, Amman, Jordan
*Corresponding Author: Mosleh M. Abualhaj. Email: m.abualhaj@ammanu.edu.jo
Received: 02 July 2021; Accepted: 03 August 2021
Abstract: IPv6 protocol is the future of IP networks due to its large IP address capacity. One of the key consequences of this large capacity is that the IP protocol header has enlarged from 20-byte in IPv4 to 40-byte in IPv6. This will consume a considerable share of the bandwidth (BW) for VoIP applications, which produce small packets in tens of bytes only. To handle this issue, we have introduced an efficient technique to use the superfluous fields in the VoIP packet header, including the IPv6 header, to hold the voice data of the packet. This introduced technique is called the Eliminator technique because it shortens or eliminates the packet payload. The Eliminator technique has been analyzed against the typical technique of transferring the VoIP data. The BW utilization of the two techniques has been compared with different codecs namely G.726, G.728, and G.723.1 codecs. The analysis showed that the BW wasting has alleviated by 16.4%, 19.1%, and 25% with these codecs respectively. This BW utilization improvement will indirectly boost the quality of the VoIP calls, especially in the wireless environments. Accordingly, the Eliminator technique is a viable solution for alleviating the wasted BW when running VoIP in IPv6 networks.
Keywords: VoIP; IPv6; bandwidth saving; codecs; packet header; IAX protocol
IPv6 protocol is gradually replacing the long-serving IPv4 protocol. The main reason for inventing the IPV6 address is to increase the IP address capacity. The IP address capacity has expanded greatly from 32-bit in IPv4 to 128-bit in IPv6, which theoretically will everlasting. However, this huge capacity has come at the price of increasing the IPv6 protocol header compared to the IPv4 protocol header. Where the minimum size of the IPv4 protocol header is 20-byte while the minimum size of the IPv6 protocol header is 40-byte [1]. This is an important concern for the applications that produce small data sizes such as VoIP and online gaming. The data produced by these two applications is only tens of bytes [2].
VoIP is a myth technology that has ease the telecommunication sector for the people and saves their money. The amount of VoIP traffic is increasing rapidly due to several reasons such as the countless number of VoIP applications, which are runnable on all smart devices (e.g., smartphones). Roughly, 3 billion persons will come to be mobile VoIP users by 2021 [3,4]. Online gaming has also propagated drastically in the last decade. It’s expected that the number of online gaming to reach 2.8 billion by the end of 2021, which will produce a huge amount of traffic on the Internet [5]. In nutshell, the IPv6 protocol header size is very huge for certain applications such as VoIP and online gaming. In addition, these two applications produce a huge amount of traffic on the Internet. Therefore, these two issues justify the study of the consumed bandwidth (BW) of the IP computer networks by IPv6 protocol header with VoIP and online gaming.
The consumed BW by the packet header when running VoIP over IPv6 is vary based on the used codec. VoIP’s codecs produce very small digital voice samples less than a hundred bytes. The voice payload of a packet could be multiple voice samples based on the used codec [6]. Tab. 1 shows some of the most common codecs [7,8]. In addition, it shows the consumed BW when using IPv6 protocol with VoIP applications compared to IPv4 protocol. A massive quantity of wasted BW is obvious with all the codecs, which could be up to 75%. In addition, the wasted BW when using IPv6 protocol is up to 10% more than IPv4 protocol.
VoIP utilizes the IP network protocols to make a successful call. Part of these protocols is used to setup the call between the caller and callee, i.e., the signaling protocols (e.g., SIP protocol). The SIP protocol negotiates the necessary parameters between the call ends to make the call. By the end of this stage, both call ends are recognizing each other IP address and the used codec. The second part of these protocols is used to transfer the digital voice data between the caller and callee, i.e., the media transfer protocols. The 12-byte RTP is the dominant media transfer protocol [9,10]. RTP is typically collaborating with the 8-byte UDP protocol to carry all sorts of real-time data, not only VoIP. Therefore, not all the header fields of RTP/UDP protocols are specified for VoIP, which make some of them unnecessary. Though, these fields are part of every VoIP packet. IPv6 protocol is also used to carry all sorts of data. Therefore, it contains header fields that are unnecessary to transfer the VoIP packets but they are part of every packet too [11–13]. These unnecessary fields in the RTP/UDP and IPv6 header are consumed a considerable BW with no use by VoIP services [11]. This problem has been addressed by proposing a new specialized protocol for VoIP such as internet telephony transport protocol (ITTP) and IAX protocols, compressing the VoIP packet header, or assign a new role to the unnecessary fields of the packet header (i.e., carry the voice data of the VoIP packet) [14,15]. In this paper, we have adopted the last concept of assigning a new role to the unnecessary fields in the header, to handle the dilemma of wasting BW by VoIP. The proposed technique eliminates the VoIP packet payload length or makes it zero, particularly when VoIP runs over IPv6 networks.
The rest of the paper is structured as follows: the next section highlights the related work about BW utilization approaches for VoIP. The introduced technique is presented in Section 3. The expected BW saving of the introduced technique is presented in Section 4. The paper ends with the conclusion in Section 5.
This section discusses the approaches that have been proposed to alleviate the wasted BW resulting from the superfluous fields in the VoIP packet header. One of the first approaches is known as header compression. Compression is an efficient optimization approach to reduce the size of the packet header. Several mechanisms have been proposed under the header compression approach including the work in [16–21]. The work in [21] has standardized a mechanism called Enhanced Compressed RTP (ECRTP). The ECRTP compresses the RTP headers normally down to 2-bytes in the case where no UDP checksum is being transmitted, or 4-byte with Checksum. The ECRTP is an amendment of CRTP for channels with high latency, packet loss, and reordering. This reduces the header size considerably for each packet by 90% or 95%. When compared to the entire packet, the alleviation of BW consuming is vary based on the used codec. For instance, assume the G.729 codec is used with IPv4 header then the BW is saved by 60% or 63.3% for each packet. Though, the ECRTP technique consists of many operations that burden the equipment by extensive processing. This also imposes a processing latency that increases the overall latency and decreases the quality.
The second approach to alleviate the wasted BW resulting from the superfluous fields in the VoIP packet header is designing new specialized multimedia protocols for VoIP. One of these protocols is called IAX which is created for the Asterisk private branch exchange [15]. The IAX was built mainly to carry the voice data but it can also carry the video and other streaming media data. IAX alleviates the BW consumption by merging the data from numerous sessions into one stream of packets. In addition, the 4-byte IAX mini-header works in collaboration with the UDP protocol to carry the voice data. Though IAX reduces the header overhead of RTP, the VoIP packet header still has the UDP and IP protocols with their superfluous fields. Which are still considerably large compared to the size of the VoIP packet and consume a considerable share of the channel BW.
In the third approach, the superfluous fields are assigned a new role which is holding the voice data of the packet. Though the header size is not changed the payload is reduced or even eliminated, which will achieve the target of alleviating the wasted BW. The work in [11] has adopted this concept and introduced a technique called short voice frame (SVF). The SVF technique has imposed several conditions to choose the superfluous fields. Based on these conditions, the SVF technique has assigned a role of holding the voice data to some fields in RTP, UDP, and IPv4 header protocols equal to 17-byte. The saved BW has reached up to 29% in the proposed cases and environment. The work in [12] has proposed the same concept and introduced a technique called zero size payload (ZSP). The ZSP technique very similar to the SVF technique but imposed different conditions to choose the superfluous fields. Doing so allows increasing the size of the superfluous fields to hold the voice data to 19-byte. This proportionally increases the saved BW to 32% in the same proposed cases and environment of SVF.
Researchers have applied awesome exertion to spare the BW when using VoIP. The BW issue gets to be more of a situation when joining VoIP and IPv6 protocol owing to the huge length of the IPv6 header. This work introduces a technique to use the concept of superfluous fields to handle this wasted BW VoIP dilemma. The technique eliminates the VoIP packet payload length or makes it zero, particularly when VoIP runs over IPv6 networks. Consequently, the introduced technique is called the Eliminator. The details of the introduced Eliminator are elaborated in the next section.
The Eliminator technique is intended to maximize the utilization of the BW of the IPv6 networks, particularly for VoIP service. This particularly important for wireless networks. The speed and BW of wireless networks are relatively small compared to the wired networks. Therefore, reducing the size of the transmitted data improve the performance of wireless networks. As stated, the Eliminator technique will do so by using the superfluous fields in the header of the VoIP packet to hold the voice data. In general, the Eliminator technique will shift the voice data to the superfluous fields at the sender agent (SA). At the receiver agent (RA), the voice data will be shifted back as a normal packet payload. Fig. 1 presents a wireless network topology in which the Eliminator technique could be implemented.
Figure 1: Eliminator technique topology
The Eliminator technique will use the superfluous fields to hold the voice data of a packet. Only the header’s fields that do not impact the workability or performance of VoIP service should have utilized to hold the voice data. The first field is the source IPv6 address (SrcIPv6) of the IPv6 protocol. The 16-byte SrcIPv6 is used by the receiver to respond to the sender which not the case of VoIP (i.e., there are no acknowledgment or request/response messages). The other field in the IPv6 protocol header is the 1-byte Next Header (NHdr) [13]. The NHdr value is static and equal to 17 in the case of VoIP for all packets. Therefore, the SA agent can use it to hold the voice data and the RA agent then sets it back to 17. Similar to SrcIPv6, the optional 2-byte source port (SrcPrt) in the UDP protocol header is used by the receiver to respond to the sender which not the case of VoIP for the same aforementioned reasons of SrcIPv6. The 2-byte Checksum in the UDP protocol header is also optional and many VoIP implementations disable it to boost the VoIP quality. Finally, the 2-byte Length (Ln) field in the UDP protocol header keeps the size of the UDP datagram, which can be calculated from the Payload Length (PL) field in the IPv6 header protocol. Thus, the Ln field can be used by the SA agent to hold the voice data then its original value is reverted at the RA agent, as discussed below [11,12,22–25]. All the other RTP/UDP/IPv6 protocol fields are necessary to carry real-time voice data with high quality particularly over IP wireless networks. A detailed discussion on selecting the superfluous fields can be found in [11,12]. The difference in the selected fields from is [11,12] because the Eliminator technique designed for IPv6 networks in the wireless environment. Accordingly, 23-byte of SrcIPv6, NHdr, SrcPrt, Ln, and Checksum fields are allowed to hold the voice data of a VoIP packet, with no harm to the VoIP service.
3.2 SA and RA Agents Operations
The SA agent extracts 23-byte of voice data from the packet and positions them in the superfluous fields discussed above. If the voice data is smaller than 23-byte (e.g., when using the G.723.1 codec) then all voice data extracted and positioned in the superfluous fields and then the superfluous fields are padded with zeros. Due to this operation, the value of the PL field in the IPv6 header should be modified, as discussed below. The algorithm in Fig. 2 shows the operations performed at the SA agent. The RA agent extracts the voice data from the superfluous fields and appends it to the packet. Then, the value of the Ln field is calculated, as discussed below. The remaining superfluous fields are set to zeros to avoid misinterpretation by the RA agent. The algorithm in Fig. 3 shows the operations performed at the SA agent.
Figure 2: The algorithm performed at the SA agent
Figure 3: The algorithm performed at the RA agent
The SA agent should find the new value of the PL field in the IPv6 header. The new value of the PL is equal to 20-byte RTP/UDP plus the remaining voice data (If any). The remaining voice data is the data the exceeded the size of the superfluous fields (23-byte). The remaining voice data is equal to the size of the payload for a voice codec (see Tab. 1) minus the size of the superfluous fields. If the voice data less than or equal to 23-byte then the remaining voice data is equal to zero. For instance, if G.728 is the used codec then the new value of the PL is equal to 57 (20-byte RTP/UDP plus (60-byte payload minus 23-byte superfluous fields)). However, if G.723.1 is the used codec then the new value of the PL is equal to 20 (20-byte RTP/UDP plus zero). On the other hand, the RA agent should reset the original value of the PL field in the IPv6 header. The PL is the size of the RTP/UDP header and the size of the payload for a voice codec (see Tab. 1). For instance, if G.728 is the used codec then the PL is equal to 80-byte (20-byte RTP/UDP plus 60-byte payload). Therefore, the RA agent should keep the payload size of the codec, during the call setup, until the call ends to be able to find the original value of the PL field. In addition, the RA agent should reset the original value of the Length field in the UDP header. The Length field value is the same as PL, i.e., RTP/UDP size plus payload size.
4 Eliminator Technique Performance Analysis
The Eliminator technique performance analysis is discussed in this section. The main goal of the Eliminator technique is to alleviate wasting the BW resulting from the large size of the IPv6 protocol, particularly for packets with a small payload such as VoIP. The voice codecs are generating packets payload with different sizes leading to different sizes of VoIP packets. Thus, the ratio of the wasted BW is differing from one codec to another. Accordingly, the Eliminator technique will be tested with different codecs which gives a better analysis of the BW saving by the Eliminator technique. The chosen codecs are G.726, G.728, and G.723.1 due to the different payload sizes they are generating. The BW will be analyzed based on the call capacity of the channel and the alleviation of the expended BW.
Figs. 4–6 present the call capacity of the Eliminator technique against the typical technique with the G.726, G.728, and G.723.1 codecs, respectively. As we can see, the amount of calls that can be carried is lesser when using the typical technique rather than the Eliminator technique. For instance, the capacity with the G.723.1 codec at 1000kb bandwidth is 62 and 47 calls when running the Eliminator technique and typical technique, respectively. Therefore, the call capacity is promoted by up 132% over the typical technique, when using the Eliminator technique. Therefore, the Eliminator technique boosts the call capacity compared to the typical technique. This is because the needed BW of a single call is reduced, due to hold share or the whole payload of a VoIP packet in the 23-byte of SrcIPv6, NHdr, SrcPrt, Ln, and Checksum fields in the packet header. Fig. 7 presents the alleviation of the expended BW when using the Eliminator technique against the typical technique with the G.726, G.728, and G.723.1 codecs. The alleviation of the expended BW is 16.4%, 19.1%, and 25% when using G.726, G.728, and G.723.1 codecs, respectively. Again, this is because of holding 23-byte (maximum) of voice data in the VoIP packet header. This saving of the BW will boost the quality of the VoIP calls as well. The attained results are different among the codecs because the voice data and the codec bitrate vary from one codec to another, as shown in Tab. 1.
Figure 4: Call capacity (G.726)
Figure 5: Call capacity (G.728)
Figure 6: Call capacity (G.723.1)
Figure 7: Reduction of the expended BW
The integration of VoIP and IPv6 networks is inevitable due to the viable benefits of both standards. The large size of the IPv6 protocol header wastes a considerable share of the available for VoIP applications. In this paper, we have created a novel technique, called Eliminator, to treat the large size of the VoIP packet header, particularly when using IPv6 Protocol. The Eliminator technique succeeded in this by utilizing the SrcIPv6, NHdr, SrcPrt, Ln, and Checksum fields in the packet header, which are superfluous to VoIP. These 23-byte fields are used to hold a share or entire VoIP packet payload. The SA agent extracts up to 23-byte of voice data from the packet and position in these fields. The RA agent extracts the voice data from SrcIPv6, NHdr, SrcPrt, Ln, and Checksum fields and them to the packet. The Eliminator technique has been analyzed against the typical technique of transferring the VoIP data. The BW saving of the Eliminator technique against the typical technique has been compared using G.726, G.728, and G.723.1 codecs. The analysis shows that the alleviation of the wasted BW has reached 16.4%, 19.1%, and 25% with these codecs respectively. Accordingly, the Eliminator technique is capable of working successfully to alleviate the wasted BW when running VoIP in IPv6 networks. In the future, the Eliminator technique will be compared with other techniques in the area. In addition, more performance metrics will be used to investigate the robustness of the Eliminator technique.
Funding Statement: The authors received no specific funding for this study.
Conflicts of Interest: The authors declare that they have no conflicts of interest to report regarding the present study.
1. T. Lammle, Ccna routing and switching complete study guide: Exam 200-125, 2nd ed., Indianapolis, Indiana: John Wiley & Sons, 2016. [Google Scholar]
2. S. Jose, H. David, N. Julian, R. Mas, P. Fernando et al., “Small-packet flows in software defined networks: Traffic profile optimization,” Journal of Networks, vol. 10, no. 4, pp. 176–187, 2015. [Google Scholar]
3. J. Hoffman, “Voip adoption statistics for 2019 and beyond,” 2021. [Online] Available:https://wisdomplexus.com/blogs/voip-adoption-statistics-2019-beyond/. [Google Scholar]
4. M. Abualhaj, A. Hussein, M. Kolhar and M. AbuAlHija, “Survey and analysis of VoIP frame aggregation methods over a-MSDU IEEE 802.11n wireless networks,” Computers, Materials & Continua, vol. 66, no. 2, pp. 1283–1300, 2021. [Google Scholar]
5. Broadbandsearch, “online gaming statistics - 45 facts that will blow you away,” 2021. [Online]. Available: https://www.broadbandsearch.net/blog/online-gaming-statistics. [Google Scholar]
6. N. Gupta, N. Kumar and H. Kumar, “Comparative analysis of voice codecs over different environment scenarios in voip,” in 2nd Int. Conf. on Intelligent Computing and Control Systems, Madurai, India, pp. 540–544, 2018. [Google Scholar]
7. S. Narayan, M. Gordon, C. Branks and L. Fan, “Voip network performance evaluation of operating systems with ipv4 and ipv6 network implementations,” in 3rd Int. Conf. on Computer Science and Information Technology, Chengdu, China, pp. 669–673, 2010. [Google Scholar]
8. N. Gupta, K. Naresh and K. Harish, “Comparative analysis of voice codecs over different environment scenarios in voip,” in Proc. of Second Int. Conf. on Intelligent Computing and Control Systems, Madurai, India, pp. 540–544, 2018. [Google Scholar]
9. M. Abualhaj, Q. Shambour and A. Hussein, “Effective packet multiplexing method to improve bandwidth utilisation,” Int. Journal of Computer Applications in Technology, vol. 63, no. 4, pp. 327–336, 2020. [Google Scholar]
10. K. Abdulrazzaq, “Sip aspects of ipv6 transitions: Current issuesand future directions,” Journal of Engineering Science and Technology, vol. 14, no. 1, pp. 448–463, 2019. [Google Scholar]
11. M. Abualhaj, Q. Shambour, A. Hussein and Q. Kharma, “Down to zero size of VoIP packet payload,” Computers, Materials & Continua, vol. 68, no. 1, pp. 1271–1283, 2021. [Google Scholar]
12. M. Abualhaj, M. Al-Tahrawi and M. Al-Zyoud, “Contracting VoIP packet payload down to zero,” Cybernetics and Information Technologies, vol. 21, no. 1, pp. 137–150, 2021. [Google Scholar]
13. S. Hagen, “Ipv6 essentials: Integrating ipv6 into your ipv4 network,” O'Reilly Media, Sebastopol, California, 3rd ed.,2014. [Google Scholar]
14. M. Abualhaj, S. Al-Khatib and Q. Shambour, “PS-PC: An effective method to improve VoIP technology bandwidth utilization over ITTP protocol,” Cybernetics and Information Technologies, vol. 20, no. 3, pp. 147–158, 2020. [Google Scholar]
15. M. Spencer, B. Capouch, E. Guy, F. Miller and K. Shumard, “IAX: Inter-asterisk exchange version 2,” IETF RFC 5456, 2010. [Google Scholar]
16. P. Fortuna and M. Ricardo, “Header compressed VoIP in IEEE 802.11,” Journal of IEEE Wireless Communications, vol. 16, no. 3, pp. 69–75, 2009. [Google Scholar]
17. W. Flanagan, “Header compression across entire network without internet protocol saves bw and latency,” IEEE 3rd 5G World Forum (5GWF), Bangalore, India, pp. 281–285, 2020. [Google Scholar]
18. S. Jivorasetkul, M. Shimamura and K. Iida, “End-to-end header compression over software-defined networks: A low latency network architecture,” 2012 Fourth Int. Conf. on Intelligent Networking and Collaborative Systems, Bucharest, Romania, pp. 493–494, 2012. [Google Scholar]
19. S. Jivorasetkul, M. Shimamura and K. Iida, “Better network latency with end-to-end header compression in sdn architecture,” in 2013 IEEE Pacific Rim Conf. on Communications, Computers and Signal Processing (PACRIMVictoria, BC, Canada, pp. 183–188, 2013. [Google Scholar]
20. K. Sandlund, G. Pelletier and L. Jonsson, “The robust header compression (ROHC) framework,” IETF RFC 5795, 2010. [Google Scholar]
21. T. Koren, S. Casner, J. Geevarghese, B. Thompson, P. Ruddy et al., “Enhanced compressed RTP (CRTP) for links with high delay, packet loss and reordering,” IETF RFC 3545, 2003. [Google Scholar]
22. G. Tomsho, “Guide to networking essentials,” Cengage Learning, Boston, MA, USA, 8th ed.,2019. [Google Scholar]
23. C. Kozierok, “The tcp/ip guide: A comprehensive, illustrated internet protocols reference,” No Starch Press, ISBN-13: 978-1-59327-047-6,2005. [Google Scholar]
24. A. Sheraz, M. Muhammad, N. Farhan, H. Muhammad and K. Jong-Myon, “Protocols and mechanisms to recover failed packets in wireless networks: history and evolution,” IEEE Access, vol. 4, pp. 4207–4224, 2016. [Google Scholar]
25. S. Stein and E. Rippel, “Efficient double parity forward error correction on a communication network,” U.S. Patent, No. 10,567,102, 2020. [Google Scholar]
 | This work is licensed under a Creative Commons Attribution 4.0 International License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. |