Control Dynamic System and Qos Manager Agent Over Ipv6 Networks: Intserv and Diffserv Approach in Access Nodes

doi:10.21203/rs.3.rs-2948805/v1

Download PDF

Research Article

Control Dynamic System and Qos Manager Agent Over Ipv6 Networks: Intserv and Diffserv Approach in Access Nodes

https://doi.org/10.21203/rs.3.rs-2948805/v1

This work is licensed under a CC BY 4.0 License

You are reading this latest preprint version

In the last ten years, the growth of IP-based data networks has led to the creation of new applications, which in turn have led to more data being sent. But the bandwidth of intradomain and interdomain transport networks has not grown at the same rate. In the last decade, the growth of IP-based data networks has led to the development of new applications that have increased the amount of data that can be sent. But the bandwidth of both intra-domain and inter-domain transport networks has not grown at the same rate. The present work is to look at how to provide QoS, which is a problem that is currently being looked into and for which there is no clear process or algorithm for a solution. A model that takes advantage of the features of the IPv6 protocol is also being used to find a solution. IPv6 is a very important protocol for the growth and development of Internet services and for supporting new services. But IPv6 doesn't have QoS in and of itself, even though it has different fields. This research aims to solve the QoS problem by trying to find the best way to combine the areas that IPv6 offers. The QoS manager agent was tested with MPLS in a congestion scenario. As a result, the values for jitter and delay for the highest priority flows got a lot better. High-priority flows are those that carry real-time traffic that can't handle delays or packet loss. The fact that the QoS manager agent didn't lose more than 3% of all packets, no matter how much traffic came into the node, shows that priority traffic is protected against network congestion problems. This feature is not present in the MPLS scenario, and as traffic grows, packet loss also grows. The QoS manager agent makes these characteristics better, but it makes them worse in low-level flows. Low-priority flows, on the other hand, are things like web browsing, file transfers, etc., that don't care much about time. The way these flows work is based on connection-oriented protocols like TCP. When packets are lost, the anti-congestion features of this protocol are turned on. The QoS manager agent doesn't have any way to measure incoming flows. This means that high throughput flows can fill up the classes, which goes against management policies, causes packet loss, and changes delay and jitter parameters. To improve the performance of the QoS manager agent in the future, it is suggested that a QoS provisioning protocol be created between a host and a border router. This would allow the agent to have more control over the flows that enter it and would improve the agent's performance.

QoS Manager

IPv6 networks

Traffic Generator Performance

Edge Router Performance

anti-congestion features

Commercial industry communication systems are giving recommendations on how the development of 6G technology should be even at the beginning of 5G network development [1]. If 6G technology can meet the needs of commercial and mobile communications when it is launched, more innovations will be revealed, while existing systems that require improvement are likely to meet anticipated targets. Consequently, the advancement will transform wireless technology, and the large investments that occur due to today's level of technology will undoubtedly be much more excellently supported. When examining 6G applications, note that the 5G network had a clear vision of penetrating society across the world to bring about a broad user-centric information ecosystem [2]. However, there is a long way to go due to the limited time for standardization and maturity of existing network generations about technology development.

The expansion of IP-based data networks in the last decade has driven the implementation of new applications that have in turn increased the volume of data transfer [3]. However, intra and inter-domain transport networks have not increased their bandwidth at the same speed. The increasing digitization of multimedia services over IP networks such as voice, video and new applications such as telemedicine, industrial control, etc., services subject to certain restrictions, generally associated with their sensitivity, time and errors during transmission. Across networks, services experience congestion or delays, packet arrival time difference (jitter), packet loss, or sequencing errors that affect service behaviour [4]. Such conditions must be respected so that the quality of user experience (QoE) is positive and the restrictions imposed by the time-sensitivity of each service are met.

To comply with these sensitivity specifications, the network must adjust certain parameters or packet admission policies, likewise, the same parameters or policies must be used in transmission management to comply with the throughput1 values and restrictions established depending on the type of service. The set of quantitative and qualitative characteristics of a multimedia distributed system that are necessary to achieve the required functionality of an application is called quality of service (QoS) [5].

but to a greater extent in the network layer protocols. For example, some approaches to achieve QoS by network protocols [6] are based on the Type of Service fields for the IPv4 header or Traffic Class for the IPv6 header [7]. Both aim to provide certain bits that allow differentiating the type of service that is encapsulated in the IP packet [6] [5]. Other lower-layer protocols such as MPLS (Multiprotocol Label Switching) assign a label to each type of traffic so that it is sent by different routes depending on the label that has been assigned. Regardless of the form of traffic classification, the objective of QoS is to assign processing and transmission priorities to transactional traffic, seeking to guarantee the parameters of delay, jitter and errors in sequence. The current disruption in a QoS model is the current worldwide migration towards the IPv6 protocol which gives more options in its headend for handling differentiation of packets and packet flows. IPv6 also provides a large area for the research and development of QoS protocols [3].

This work aims to address QoS provisioning, a current problem and subject of investigation, in which there is currently no definitive process or algorithm that provides a solution [6]. A solution is also sought based on the approach of a model that takes advantage of the characteristics of the IPv6 protocol, IPv6 does not provide QoS per se, although the protocol provides different fields [7]. This proposal intends to address the QoS problem by seeking an optimal integration of the fields provided by IPv6.

2.1 Next-Generation Internet Protocols

Different proposals arose to counteract the weaknesses of IPv4, among the main ones are CNAT, IP Encaps, Nimrod, and Simple CLNP. Proposals such as the P Internet Protocol (PIP), Simple Internet Protocol (SIP) 5, and TP/IX followed. In 1992, after an IETF meeting, CLNP evolved into TCP and UDP Bigger Addresses (TUBA)6, IP Encaps into IP Address Encapsulation (IPAE), the latter together with PIP and SIP formed Simple Internet Protocol Plus (SIPP)7. Finally, TP/IX converged to the Common Architecture for the Internet protocol.

Subsequently, several drafts were consolidated and in 1998 the main IPv6 protocols were published, including the update RFC 2460 that rendered RFC 1883 obsolete [8].

2.2 IPv6

The IPv6 protocol solves all the limitations of IPv4 in terms of scalability and flexibility. The design objective of IPv6 was to create a protocol that could handle the great growth of the Internet and meet the requirements of services, mobility and security.

2.2.1 IPv6 Header: The IPv6 header defined in RFC 2460 has a length of 40 bytes. Unlike IPv4, IPv6 eliminates some fields such as Header Length by always maintaining a fixed header. The Identification, Flags and Fragment Offset fields, in charge of managing fragmentation in IPv4, were also removed. IPv6 recognizes the maximum MTU for the transmission although if a host wants to fragment it must use the extension header provided with the restriction that only the traffic sources can do it, different from what happens in IPv4 with which any router or intermediate element can perform fragmentation. Finally, the Header Checksum field was also suppressed to maintain processing speed and shift responsibility for integrity to higher layers. Other fields such as Type of Services, Time to Live, and Protocol Type were renamed, as shown in Fig. 1. The IPv6 header fields are specified below:

2.3 QoS in IPv6

In the IP world packets are handled in the same way, routers redirect packets they receive from different sources on different interfaces and are processed in the order of arrival; this is called “best effort”. The performance of the networks according to this form of delivery entails certain undesired phenomena in which it is found: the possibility that the packages are delivered in order or out of order; the possibility of packages being delivered softly or in bursts; the possibility that

whether or not they are delivered. These phenomena [9] can occur due to the following causes:

Congestion Transients
Absence of packet differentiation
Independence in the traffic prioritization policies in each router.

The purpose of QoS protocols is to determine an end-to-end differentiation and an allocation of resources according to the needs of the traffic, in such a way that these remain constant throughout the entire route and during the communication time.

Traffic classification is an essential but non-trivial task since the volume of traffic present in a network like the Internet is incredibly high. Detailed processing that classifies each packet requires high processing [7]. In backbone networks that support a high volume of traffic, the processing of each packet and the association of a routing decision for each packet would generate congestion and delays even greater than what is desired to be solved.

QoS provisioning is a limited traffic engineering process, it uses decision criteria based on algorithms. High complexity in the algorithms and decision criteria can mean harmful delays that must be limited as much as possible [7]. The solutions must be highly efficient, especially in the backbone of a network where the greatest number of traffic occurs. Currently, there are different approaches to providing QoS which can be condensed into two large groups: IntServ (Integrated Services) and DiffServ (Differentiated Services). Regardless of the type of approach that is implemented in a QoS solution, each solution has adaptability issues to varying traffic demand and scalability issues where performance is compromised. QoS is still a matter of research [10] and the selection criteria of each solution are determined by its scalability and level of granularity in traffic classification.

2.4 Queue Management and attention algorithms.

Before defining the algorithms, it is necessary to identify the main performance values in a QoS management algorithm, among these are Delay and Jitter. The first defines the time a packet takes to get from a reference point to a specific destination. The jitter defined by RFC 3393 refers to how the variable is the delay of a set of packets with the same source and destination. To calculate this value, the formula of Eq. 2 − 1, defined by RFC 3393, is used.

\(Jitteri = Jitteri-1 + \left(\right|\varDelta t|-Jitteri-1)\) (Eq. 2 − 1)

Where |∆𝑡| is the delay difference between packets, and the Jitter (𝐽i𝑡𝑡𝑒𝑟i) depends on the previous value 𝐽i𝑡𝑡𝑒𝑟i−1.

2.4.1 Weighted Fair Queuing (WFQ)

Fair Queuing algorithms are designed to obtain an equitable distribution of network resources so that no queue has priority over another. The packets are divided and organized in each queue according to the admission and classification scheme that is specified. The attention method is done via the Round Robin method (one packet at a time per queue), however, a pure Fair Queuing algorithm can only reserve the same amount of bandwidth for each queue and is intended so that packets are the same size, a situation that is very rarely true.

where 𝑁 is the number of queues or flows where each queue is assigned a weight 𝜔i and 𝑐 the transmission capacity of the link. Each queue will receive at least one transfer rate 𝑅i.

\({R}_{i}=\left(\frac{{{\omega }}_{i}}{{\sum }_{n=1}^{N}{{\omega }}_{n}}\right)C\) (Eq. 2–2)

The delay 𝐷i in this algorithm is determined as a function of the throughput 𝑅i and the queue length 𝐵i according to equations 2–3.

\({D}_{i}\le \frac{{B}_{i}}{{R}_{i}}\) (Eq. 2–3)

The disadvantage of this scheme is the complexity of the process as the time it uses increases according to the number of flows it processes.

2.4.2 Deficit Round Robin (DRR).

The WFQ algorithm presents difficulties such as high complexity and processing consumption \(\left(O\right(logN\left)\right).\) Deficit Round Robin (DRR) arises since in some applications, the distribution of bandwidth is more important than keeping a low delay without having too high a processing cost \(\left(O\right(1\left)\right)[\)9].

2.4.3 Weighted Random Early Detection (WRED)

Random Early Detection (RED) is one of the algorithms used to avoid Internet congestion by discarding a TCP packet that reduces the burst effect present in TCP transmissions. When discarded, TCP reduces transmission so that a node's buffer does not overflow.

Weighted Random Early Detection (WRED) establishes different types of discard probability for each type of traffic, that is, if a packet arrives at a queue, it can be subjected to different discard probabilities depending on the profile it belongs to.

3.1 QoS Manager Functionality

The agent's main function is to differentiate traffic according to the DSCP and Flow Label codes present in IPv6, perform packet admission processes based on available bandwidth and queuing availability, control flows based on available bandwidth and existence of congestion, finally define the queuing priority of each packet.

IntServ processes demand too many processing resources and time to be processed. Its implementation within the backbone of a routing or switching ISP would be counterproductive due to the large volume of data flows.

3.1.1 Proposed location in the QoS Agent network

Stream processing involves high computational consumption. A point must be sought where control and classification are carried out on the network points that present the lowest flows or traffic demands. At the same time, within a network, all flows must also be controlled and classified for the QoS solution to make sense. The problem demands a distributed and hybrid solution that manages to cover the points that present lower data flows and can cover all the flows present in a network. A hybrid solution involves handling the IntServ and DiffServ approaches within a node. In this sense, IntServ is applied to the points towards the user, classifying the flows and applying the QoS policies to them. On the other hand, apply DiffServ towards the network backbone so as not to overload the nodes within it.

The network points that meet these characteristics are the edge nodes within the access network of the operator or ISP. However, the edge nodes facing the end users are the ones with the lowest traffic and flow numbers.

The edge nodes in the access network (edge routers), having the least amount of flow in the entire network, can carry out the entire process of admission and control of traffic flows by applying IntServ approximations when analyzing by flow-through of the Qos manager agent. The QoS manager agent, when carrying out the entire admission and control process, will allocate resources in such a way that the backbone is used most efficiently.

The QoS manager agent algorithm performs all the analysis of a QoS solution with the exception that it is only used for the classification and definition of flows entering the backbone. The network backbone will only apply a class differentiation solution (DiffServ) due to its high volume of traffic, however, its function is to monitor the occupation of its buffers and apply congestion control algorithms.

3.1.2 DSCP code for handling Differentiated Services

For the application of DiffServ in the backbone, the DSCP encoding is used according to the PHBs defined in RFC 2597 and RFC 3260. The congestion control algorithm implemented within the backbone router model is based on the IPv6 Explicit Congestion Notification (ECN) field. When presenting congestion, the backbone router will return a control message with the highest priority to the edge nodes that are generating the traffic [7]. In this message, the value of the ECN field will be in value 11 (binary) indicating congestion. When receiving congestion messages, edge nodes adjust the flow classification and admission policies in such a way that the services defined with the highest priority are guaranteed.

3.2 Model Constraints.

The transmission rates on the connecting links of the bearer node of the QoS manager agent are symmetric full-duplex. This model does not include within its scope considerations of links with asymmetric rates.

Within the model, users with equal transmission rates are considered in the links towards the edge node that contains the agent.

It is based on the fact that the node has already been assigned a set of IPv6 addresses already defined for each user.

All the processing is analyzed in the network layer of the OSI model (layer 3), algorithms or behavior of lower or higher layers are not considered for the agent's decisions, for which it is assumed that it does not affect the performance of said layers.

Having described the conceptual framework and the specifications of the QoS manager agent, the development and implementation of the project are described below.

4.1 Coding of IPv6 DSCP, ECN and Flow Label fields.

The IPv6 header fields that the QoS manager agent will evaluate are the Traffic Class composed of the DSPC Code and the ECN; and the Flow Label field.

As there are different PHB definitions for DSCP, the proposals made by the IETF were analyzed, among which the best known are: Expedited Forwarding (EF), Assured Forwarding (AF), Class Selector (CS) and Voice Admit (VA). The packet transit network, together with the QoS manager agent, to carry out a good flow differentiation scheme, must use the PHB coding that provides greater differentiation in the flows, for which reason the relevance of each coding was evaluated:

Expedited Forwarding (EF): Defines low latency and jitter, however it only allows priority with a single code, and it does not have intermediate levels of priority.
Class Selector (CS): Its encoding is based on the precedence used in old equipment, which does not support the IPv6 protocol, which is why it is the least viable to use.
Voice Admit (VA): It is designed specifically for voice traffic, which implies the same disadvantage exposed in Expedited Forwarding (EF).
Assured Forwarding (AF): Defines different priorities (4 Classes) for packet handling, additionally specifies 3 packet discard probabilities. This differentiation allows the differentiation of more types of flows, as well as the possibility of handling different discard rates in queues that are useful for the implementation of queue management algorithms such as WRED (Weighted Random Early Detection). Given these characteristics, this encoding is chosen for DSCP differentiation. The other two fields ECN and Flow Label are used as defined by RFC 3168 for ECN for encoding and RFC 6437 for Flow Label, which specifies a 20-bit long label with a pseudorandom value, the flow condition as packets with the same Flow Label, Source Address and Destination Address and management by the nodes (management of active flow states).

4.2 Simulation environment

The QoS manager agent proposed in this paper is evaluated using simulation systems. Within the different simulation methods are continuous time simulations, and discrete event simulators (DES). The first has continuity over time and generally uses approximations and analytical solutions that are not always very precise [11]. The simulation based on discrete events is the simulation method typically used for the study of the performance of a network or network protocols, it can create extremely detailed models, and packet-by-packet descriptions so that all effects are evaluated. DES is considered accurate to provide network queuing analysis, from a simple algorithm to a complex algorithm [11]. The criteria described above are the criteria for the evaluation method of the proposed QoS manager agent.

Among the main simulators that use DES are: NS-2, OMNeT + + and OPNET. This last system allows the implementation of new models and protocols through languages such as C and C++. It also includes a library with models of different network devices among these devices that use MPLS already validated, which is why it is ideal for meeting the last objective of the current project, therefore OPNET is the simulator chosen to carry out the performance study. of the QoS manager agent.

4.2.1 OPNET Modeler simulation environment.

The simulation software poses three development domains for the evaluation of telecommunication network systems [12]. In the network domain, the network topologies to be evaluated are proposed, and networks, subnets, types of nodes, links, and even a graphical location context are defined. Work on this domain is done through the project editor. (Fig. 2).

In the node domain, the internal architecture of functional elements or processes and data flows or statistics between each functional element are defined. The development on this domain is carried out on the node editor (Fig. 3).

The last development domain is the process through the process editor, in which the behaviour of a functional element or process is defined, such as protocols, algorithms, applications, etc. This behaviour is defined using finite state machines and high-level language (C, C + + and Proto C) [7]. (Fig. 4).

OPNET includes other types of editors that complement the development of network topologies, such as link editors, packet format editors, and probability distribution function editors, among others that will not be specified in this document and can be consulted in [12 ].

4.3 Development Methodology.

The design process for each component of the node models and the QoS Manager Agent follows the design methodology outlined in Fig. 5.

In such a methodology each process and function is evaluated and its performance is analyzed based on the initial specification. If the conclusion of the analysis of the model does not correspond to the specification, it is re-specified and implemented again, repeating the cycle. If the simulation-based analysis is successful, the process model within a node model is validated.

4.4 QoS Resource Provisioning Policy Adjustment Control Algorithm.

The QoS manager agent bases its operation on the QoS policy and resource control algorithm. The algorithm manages resources according to provisioning policies to decongest the backbone and better maintain QoS for the highest priority flows that are generated by each user. This control system, which is the fundamental core of the QoS manager agent, aims to improve in cases of backbone network congestion.

4.4.1 System input variables.

The QoS resource provisioning policy control system acts according to the input variables to the policy control system, each of the inputs is originated by different actors determining the behaviour of the system, and then each of the inputs is defined and their respective generating actor.

4.4.2. Active flow state variables

To control which flows are active on a node, the system collects information from the input variables obtained from the headers and organizes it in a data structure. As there are different variables such as IP Source Address, DSCP Code, IP Destination Address and Flow Label, the following organization scheme is proposed: As the root variable in a search process, the IP Source Address variable is chosen, since the agent when proposed in a border node the number of addresses is limited according to the capacity of users that the node has (which is much less than the range of addresses that can be found in IP Destination Address). Subsequently, to have the different priorities or AF classes separated, a separation by AF classes is done within each IP Source Address, and within each class, we add the status of each flow according to its Flow Label, in Fig. 6 the structure is exposed storage of the data structure proposed for handling flow states.

The fields defined as next and streams in Fig. 6 refer to pointers to other data structures according to the Figure. It is important to note that for a flow to match, it must not only comply with the 3 groups previously specified, but it must also comply with the address in the IP Destination Address field.

4.4.3 State machine and functions of the resource control system.

The control system supports its operation in execution processes based on a state machine which in turn is supported in functions that execute specific tasks. The state diagram of the designed control process can be seen in Fig. 7. This state machine bases its operation on the following events:

The arrival of packets by user interfaces (ARRIVAL_FROM_USERS)
Update event of statistics and state variables (STATISTIC_EVENT)
The arrival of interfaces by interface towards the backbone (ARRIVE_FROM_BACKBONE)
Timeout events in congestion state (TIMEOUT)
Congestion resolved in the backbone (CONGESTION_AVOIDED)

These events are generated by the functions and processes of each state based on the inputs and state variables of the system, each state with its support functions whose implementation is described below.

4.5 Complementary Models.

The evaluation of the QoS manager agent requires other models that generate IPv6 packets. Current OPNET models do not use a formal IPv6 header implementation, so it was necessary to implement models that allow agent evaluation, which works with DSCP AF encoding. The implemented nodes are listed below:

4.5.1 IPv6 Traffic Generator.

To generate IPv6 traffic flows, a generator is implemented which can produce N traffic flows. Each flow is generated by the generating process, to which the time between arrival and the size between packets can be defined, as of constant type or according to one of the probability density functions contained in OPNET. Subsequently, the generated packet is received by the encapsulating process, which encapsulates this packet within an IPv6 header. The fields, Source Address, Destination Address, DS Code and Flow Label of IPv6 can be defined for this process.

All the flows created converge in the queue process, which implements a WRED and DRR scheme for transmission to the transmission and reception modules pt_0 and pr_0 respectively. All the WRED and DRR parameters can be defined for the Queue process. The measurement process is a module that obtains statistics from the generator output before being transmitted and determines delays, throughput and jitter for each AF class at the module's output.

4.5.2 Border Router Model: To carry out the comparison against a router that does not use the QoS manager agent module, the following node model was implemented.

The measurement modules have the function of obtaining measurements before and after the queuing process.

4.5.3 Border Router Model with QoS Manager Agent: This node has the same node model as in Fig. 7, only that the process it implements.

4.5.4 Backbone Router Model: The backbone router has the capacity of N entries and implements a q_0 queue model which also has implemented WRED and DRR with variable quantum. to increase the 𝑄𝑚i𝑛 of the queues for class 4, class 3 and class 2 priorities generates a packet with the ECN field value 0b11 indicating the start of congestion. The evaluation of the agent and its performance against the backbone does not take routing into account, so this model uses static routing. Each transmitting and receiving node also has a FIFO (First In First Out) queue [17].

4.5.5 Router Model with MPLS: The node model of this router is equivalent to that shown in Fig. 7, the difference being that the process running on q_0 does not use static routing. By simulating at the layer 3 level, the label routing that is done in MPLS cannot be executed. The solution is to use the Interface Control Information (ICI), this object generated by OPNET allows additional information associated with a packet to be associated without increasing the actual size of the packet. This model is also used as an onboard router, where the MPLS packet marking functionality is added to q_0 through ICI.

4.5.6 Results Node Model: This last node implemented has the objective of acting as the final destination node, its main function (process p_0) is to obtain performance measurements for each of the classes (delay, jitter and throughput) and a single flow.

For the evaluation of the agent and its performance against a routing scheme of best effort and MPLS, the test scenarios that evaluate the implemented nodes are established.

For all scenarios, the following distribution of classes and tunnels is assigned. The evaluation will always be carried out on the same distribution to obtain a delay comparison on the same conditions. The WRED and DRR algorithms are indifferent to the parameters that are defined for them, so the specified values do not affect their behaviour and are taken as a reference.

All devices will work with a nominal buffer size of 200 kbits (average)

5.1 Traffic Generator Performance Test.

For the traffic generator test, a generator node and a result node are established as shown in Fig. 8. To evaluate the maximum delay generated by the queue, the method specified in [13] is used, generating the maximum transfer rate for each queue. The output bandwidth of the generator is specified in 2 Mbits/s. The average value of DSL links. On this test, the validity of the model in the generation and output of its packages is reviewed. The generator, having different input flows, combines the flows using a WRED algorithm and DRR attention algorithm, fulfilling the same parameters of Figs. 8 and 9.

5.2 Edge Router Performance Test

The test scenario uses the same method used by the previous scenario, its purpose is to evaluate the delay introduced by the border router to each class and a specific flow.

5.3 Performance Test of Border Router with QoS Manager Agent

The scenario is equivalent to the previous scenario, where the delay introduced by the border router to each class and a flow are also evaluated.

5.4 Performance Test with Reuse.

In this set of scenarios, other traffic-generating nodes are included for an output bandwidth equal to the sum of all class 4 flows, for the proposed case of 4 Mbits/s. In this scenario, class delays, jitter and throughput are evaluated, and measurements are also made for a particular flow, including the percentage of lost packets. In these scenarios, the efficiency of the QoS manager agent is compared to a normal router. The topology of the set of scenarios can be seen in Fig. 10.

5.5 Test MPLS Scenario

This test (Fig. 11) consists of generating different traffic flows generating congestion in the backbone routers that work with the MPLS protocol, delay measurements per class, jitter and congestion throughput are performed for each AF class and the previously stated measures for a particular flow including the percentage of lost packets. The capacity of each MPLS tunnel corresponds to the same values of Fig. 8

5.6 Test Scenario QoS Manager Agent.

In this last scenario (Fig. 12) under the same traffic conditions as the scenario above, the performance of the network operating with ECN congestion control and the QoS manager agent is evaluated. Each backbone router generates a congestion notifier packet if the queues exceed the minimum threshold 𝑄𝑚i𝑛, if the edge node receives the packet with ECN bits set to 0b11, it limits new flows by users until the congestion ends. The measures in this scenario are the same as those described in the previous scenario.

The analysis and evaluation in its first phase focus on the performance of the network nodes, in each scenario, 40 simulations are carried out modifying the seed of the random number generators. The results presented in these tests refer to the average values of each of the measurements made in each simulation.

6.1 Traffic Generator Performance.

Before analyzing the results, the algorithmic model of the generator is validated. In the first instance, the packet generation processes are based on the standard generation processes offered by OPNET. The IPv6 encapsulation process receives the packets and encapsulates them in their respective IPv6 header. The generation and encapsulation process establish the packet creation time, which is used as a reference for delay calculations.

The inter-arrival times for these processes for both exponential and constant pdfs are shown in Fig. 13.

When calculating the average of the inter-arrival time in Fig. 13 (b), an average of 0.02 seconds is obtained, in this way, we can conclude that the process of generation and encapsulation in the IPv6 header meets the expected characteristics, as well as the packet size values that remain constant

The delay results for each generator class were obtained by placing traffic sources per class with an average transmission rate equal to the maximum capacity in the queue, the average arrival rates follow an exponential probability distribution to emulate behavior. random in the tails of the generator. All the packets were generated with a maximum size of 1500 Bytes, equivalent to the maximum transportable size in an Ethernet network. The results obtained are observed in Figs. 14.

For all queues, the delay is kept below the limit specified in Eq. 2–2. For example, the average delay for traffic with the highest priority (Class 4) for queuing in the generator is approximately 10.5 ms compared to the limit of 3 seconds specified by Eq. 2–2.

To validate the output of the generator of the WRED and DRR algorithms, the traffic generation parameters are configured in such a way that the queues enter into congestion, additionally, the size of the packets is configured in such a way that the independence to the throughput at the output of the generator obtaining:

As can be seen in Figs. 15, the throughput value for each queue is exactly as expected: 400kbps for class 1, 500kbps for class 2, 500kbps for class 3, and 600kbps for class 4. In front of Fig. 16 it can be concluded that the delay remains below the limits of other algorithms such as WFQ (Eq. 2–2) approximately 3 seconds but with lower computational cost. These results validate the behaviour of the DRR algorithm used by the nodes in the following scenarios.

Figure 17 shows the average queue size values that maintain their constant average value during the simulation, which is desirable for the WRED algorithm.

From the results of WRED and DRR, the validity of the implementations can be concluded. The models described in other scenarios contain the same implementation, so the aforementioned validation is applied to the other models.

6.2 Edge Router Performance.

Using the same evaluation method, the delays obtained are listed in Fig. 18

The jitter values obtained are due to the traffic generator as it is generating more traffic than the output throughput. Performing jitter measurements before and after the edge router the values remain constant, therefore the edge router against its maximum throughput values does not affect the jitter. By keeping the maximum throughput values at the input of the border router, the output throughput is kept constant. The DRR algorithm maintains fair use in the attention of queues and although the maximum throughput values for each class is 500kbps (DRR configuration in the node), class 1 only has a maximum of 400kbps, the remaining bandwidth is assigned to class 4 a throughput of 600 kbps. Regarding the delay, the queuing and delay generated by the queuing and packet processing processes are constant for each class. The delay value includes the transmission delays of the link, which is approximately 6 ms for a 12000-bit packet, so the delays obtained are equivalent to delays due to transmission. From these measurements, we can validate the behavior of the border router.

6.3 Performance of the Border Router with QoS Manager Agent

Using the same evaluation method as in numeral 6.1, the delays obtained are listed in Fig. 19, where the delay, jitter and throughput values obtained are obtained compared to the theoretically expected throughput.

The QoS manager agent keeps the delay and throughput values constant, compared to the jitter values, the difference in the highest priority classes has differences in milliseconds concerning the proposed border router model. The results obtained in the previous scenarios validate the models proposed and developed for this project. Next, the models are validated against reuse conditions, subjecting the models to handling throughput greater than the nominal value.

6.4 Performance with Reuse.

6.4.1 Normal Router: During this test, 2 high-priority flows (class 4) and 2 flows with arrival rates with exponential probability density function in the other classes and a test flow with a constant transfer rate are transmitted. The router classifies only by service differentiation with a constant bandwidth for each class. The behaviour of classes and the performance of each of the flows were evaluated using a utilization rate of 105% of the link capacity. Additionally, the number of packets lost for each flow was counted. The results obtained demonstrate the effect of congestion on the flows and the execution of a discard algorithm such as RED, for this system, congestion and packet discard are presented equally to each of the classes. The delay and jitter values remain similar as there is no traffic differentiation. In the following test, the traffic is increased to 125% of the link capacity. The increase in traffic accentuates the level of packet loss in each class even in high-priority flows which can have high packet loss. However, in routing with only service differentiation, the delay and jitter values are constant for each of the classes.

The absence of an admission control congests the traffic by classes increasing the packet loss in each priority queue [16], the implemented admission control improves performance as described in the following test.

6.4.2 Router with QoS manager agent: Performing the same tests now with a router with QoS manager, 105% link capacity and throughput per class give the following results:

In this test, each flow is monitored, and admission control is applied at the input. The application of different throughput for each class generates an inequality in the delay levels, in a more accentuated way in those with lower priorities. This behaviour is expected since class 1 or 2 flows are considered to be elastic, that is, not susceptible to delays and may have variable bandwidth, such as file transfers or some WEB-based protocols, additionally, this type of traffic must be supported by reliable delivery protocols such as TCP to support packet loss.

As for the highest priority class, the QoS manager agent keeps the delay and jitter levels low; packet loss due to buffer overflow equal to zero. This result validates the operation of the quality of service agent against the established design criteria. This behaviour is desired for time-sensitive traffic.

To analyze the behaviour against variations, a test flow is introduced. When the test flow is generated with DS code in classes 1 and 3, the packet loss of said flows increases a little, if the test flow is generated as a flow Class 4 This is guaranteed the same behaviour as other Layer 4 flows, low delay, low jitter and no packet loss due to buffer overflow.

, they quickly reach the user limits designated in the QoS manager agent, so the use of the bandwidth band is prioritized for high-priority traffic. The prioritization of said traffic also generates an increase in the delays of the other classes, which can be counterproductive for applications with these priority levels. In a congestion scenario, the agent rejects traffic that generates congestion as detailed in the results of the following test.

If a flow exceeds the levels allowed by the user, the agent will manage the traffic towards a lower class so as not to degrade the delay, jitter and packet loss of the class to which it belongs. Said behaviour is described in Fig. 20, in which the same class 4 and 3 flows are generated. In class 2, all flows are attributed to the same source IP to exceed the user limit. Class 1 flows are stopped and the test flow is added to the same IP used for class 3 flows. When the user limit is exceeded, the test flow is reclassified to class 1.

In conclusion, the agent presents improvements in the attention to priority flows, increases the rates of attention and causes massive discards in queues of lower priority. However, this scenario lacks either the congestion control that the QoS agent uses to optimize its results.

6.5 MPLS Scenario Performance: In this scenario, the behaviour of the topology with MPLS [15] nodes was evaluated. For this test at the first edge node (MPLS_Router), the traffic described was generated. Under these conditions, the throughput values in the border router that receives the traffic described are observed in Fig. 21a.

The results show that the flows in this node do not present any modification during the entire simulation, even exceeding the limits corresponding to each tunnel capacity. For example, the class 4 tunnel has a capacity of 1200 Kbps and during this test, it reaches 1500 Kbps. Due to this effect, the flows can accumulate in the highest priority categories and generate packet loss as can be seen in Fig. 21b. In this figure it can be seen that from the second 350, the congestion effect begins in the router that concentrates the flows (Router_MPLS2), the immediate effect is the reduction of throughput in the classes that are above the defined limit. Now the results of the throughput, jitter, and delay measurements for this test described in this scenario is equivalent to when all flows are active (after 400 seconds of simulation).

The flows belonging to class 3 and class 1 keep their packets, however, a large decrease is seen in class 4 throughput. From the above, it is concluded that the absence of flow control in each of the classes generates congestion in the backbone routers that results in higher latencies and packet losses.

6.6 Performance Scenario QoS Manager Agent: The QoS manager agent for the same simulation scenario uses the same traffic characteristics described. The traffic generated by the first generator with source IP 431 exceeds the maximum values for class 4, the QoS manager agent organizes the flows in such a way that the flow that exceeds the capacity is redirected to class 3 as seen in Fig. 22(a).

After 325 seconds, the transmission of the second node begins, before that time the other border node (Agent_QoS1) began its transmission (Fig. 6–12(b)). So the backbone router reports congestion. Figure 22 shows a peak in class 3, at 350 seconds, generated by the entry into backbone congestion and corresponds to the transient reorganization of the database by the Qos manager agent. In the same way, in Fig. 22(b) it can be seen how the throughput belonging to class 2 is transferred to class 1 (with lower priority).

As a result of the reorganization of the flows and the new QoS policies applied due to the reorganization, the volume of traffic on the backbone router is reduced until the congestion notification is removed. Figure 22(c) shows the behavior of the throughput for each of the classes.

Flow reduction ensures that backbone routers keep queues for classes greater than one out of congestion, thus reducing the possibility of packet loss on higher-priority flows.

Under the same traffic parameters of the previous scenario, the results obtained in each of the classes are:

According to the results, it is observed that the QoS manager agent slightly improves the results related to delay, jitter and throughput, since the delays in class 4 remain similar despite the increase in throughput. The flow reorganization has an impact on the throughput of the other classes, increasing their values. The results describe the behaviour of each of the flows; it can be concluded that the loss percentage is lower in high-priority flows that are maintained in their respective priority. Flows that exceed capacities are reduced to lower categories in which they experience greater congestion, resulting in increased delay. The congestions experienced in the backbone imply packet losses that in the case of high-priority flows are almost negligible low.

When congestion occurs, the QoS manager agent does not degrade the parameters of delay, jitter, and packet loss, so the flows that are generated after congestion are discarded. Therefore, this behavior allows us to conclude that the ECN notification is efficient in the interruption of incoming traffic, limiting the number of flows allowing for to reduction of the discard levels of the highest priority flows and reducing the flows of the other classes to lower priorities.

An increase in traffic in the MPLS scenario leads directly to congestion in some of the AF classes, further increasing the packet loss values, the loss values tend to increase as the traffic on the congested queue increases due to the WRED algorithm [14]. The QoS manager agent tries to avoid congestion in the higher priority classes by penalizing lower priority flows, this scheme demonstrated an efficiency in packet loss of less than 3% of the total packets, fully complying with its operation. If there is an increase in traffic, the QoS manager agent blocks the reception of flows when the backbone presents congestion so that the existing traffic is not affected, a result that is not possible in MPLS, generating further degradation of the service.

The QoS manager agent, compared to a traditional MPLS solution, tries to guarantee the throughput levels of the priority flows. For this, the levels are based on the information present in the IPv6 header, thanks to the Flow Label, Traffic Class and Explicit Congestion Notification fields. Which allows generating the necessary granularity to classify the flows. To a greater extent the Flow Label field, whose contribution generates greater control over the flow in a node. Flow orchestration is expensive in terms of memory, a solution on a backbone router is counterproductive in terms of QoS as it receives a much higher rate of flows than on edge routers; a larger number of flows has implications for routing times and throughput. The proposed QoS manager agent controls the traffic at the network access points (border routers), leaving only congestion notification tasks to the backbone routers. By receiving a congestion notification thanks to the IPv6 ECN field, the agent reorganizes the traffic admission policies, as well as the priority level of each of them. Under these premises, the QoS manager agent was evaluated concerning MPLS in a congestion scenario; as a result, a notable improvement in jitter and delay values were evidenced for the highest priority flows. Real-time traffic that is sensitive to delay and packet loss is considered a high-priority flow. The packet loss obtained with the QoS manager agent demonstrates priority traffic protection against network congestion problems, as it does not exceed 3% of all packets, regardless of the levels of traffic that enter the node. edge. The MPLS scenario does lack this functionality and as traffic increases, packet loss increases.

The QoS manager agent lacks incoming flow measurement mechanisms, so high throughput flows can saturate the classes, exceeding management policies, generating packet loss and altering delay and jitter parameters. To improve the performance of the QoS manager agent for future work, it is recommended to develop a QoS provisioning protocol between a host and the border router, which allows for regulating the flows that enter it and allows greater control of the agent.

We confirm that the manuscript has been read and approved by all named authors and that there are no other persons who satisfied the criteria for authorship

We further confirm that the order of authors listed in the manuscript has been approved by all of us and all data was collected by all authors.

Taha, Abd-Elhamid. (2021). Quality of Experience in 6G Networks: Outlook and Challenges. Journal of Sensor and Actuator Networks. 10. 11. 10.3390/jsan10010011.
Asghar, Muhammad & Memon, Shafique & Hämäläinen, Jyri. (2022). Evolution of Wireless Communication to 6G: Potential Applications and Research Directions. Sustainability. 14. 6356. 10.3390/su14106356.
Fu, D., & Ping, G. (2010). The Discussions on Implementing QoS for IPv6. International Conference on Multimedia Technology (ICMT), pp.1-4
Ash, G. R., & Farrel, A. (2008). Network Quality of Service: Know It All (p. 330). Elsevier/Morgan Kaufmann Publishers
Joseph, V., & Chapman, B. (2009). Deploying QoS for Cisco IP and Next-Generation Networks: The Definitive Guide (p. 495). Morgan Kaufmann
Szigeti, T., & Hattingh, C. (2005). End-To-End QoS Network Design (p. 734). Cisco Press
Tang, X., Tang, J., Huang, G.-B., & Siew, C.-K. (2003). QoS provisioning using IPv6 flow label in the internet. Fourth International Conference on Information, Communications and Signal Processing, 2003 and the Fourth Pacific Rim Conference on Multimedia. Proceedings of the 2003 Joint (Vol. 2, pp. 1253-1257). IEEE.
Hagen, S. (2006). IPv6 essentials (Second Edition, p. 418). O’Reilly Media, Inc
Medhi.D, & Ramasamy, K. (2007). Network Routing: Algorithms, Protocols, and Architectures (p. 823). Morgan Kaufmann
Marsan, M. A. (2005). Quality of Service in Multiservice IP Networks: Third International Workshop, QoS-IP 2005, Catania, Italy, February 2-4, 2005 : Proceedings (Google eBook) (p. 656). Springer
Zheng, Lu., & Yang, H. (2012). Unlocking the Power of OPNET Modeler (p. 254). Cambridge University Press
OPNET Modeler Documentation Set Version: 14.5. (2008). OPNET Technologies, Inc
Sethi, A., & Hnatyshin, V. (2009). The Practical OPNET User Guide for Computer Network Simulator (p. 527). Chapman and Hall/CRC
Chen, Shanzhi & Liang, Ying-Chang & Sun, Shaohui & Kang, Shaoli & Cheng, Wenchi & Peng, Mugen. (2020). Vision, Requirements, and Technology Trend of 6G: How to Tackle the Challenges of System Coverage, Capacity, User Data-Rate and Movement Speed. IEEE Wireless Communications. PP. 1-11. 10.1109/MWC.001.1900333.
Adamu, Aminu & Shorgin, Vsevolod & Melnikov, Sergey & Gaidamaka, Yuliya. (2020). Flexible Random Early Detection Algorithm for Queue Management in Routers. 196-208. 10.1007/978-3-030-66471-8_16.
Naeem, Ensherah & Abdelaal, Ayman & Eyssa, Asmaa & Maher, Faten & Abdelmordy, Rania & Hassan, Emad & Elashry, Ibrahim & Elkorany, Ahmed & Elsharkawy, Zeinab & Elnaby, Mustafa & Faragallah, Osama & Dessouky, M.I. & Abd-Elnaby, Mohammed & Ahmed, Zeinab & El-Rabaie, El-Sayed & Abd El-Samie, Fathi. (2020). Efficient signal and protocol level security for network communication. International Journal of Speech Technology. 23. 10.1007/s10772-019-09607-8.
Utami, Meinarini & Sabarkhah, Dwi & Fetrina, Elvi & Huda, M.. (2018). The Use of FIFO Method For Analysing and Designing the Inventory Information System. 1-4. 10.1109/CITSM.2018.8674266.

Download PDF

Reviewers agreed at journal
03 Jun, 2023
Reviewers invited by journal
01 Jun, 2023
Editor assigned by journal
28 May, 2023
First submitted to journal
17 May, 2023

You are reading this latest preprint version

Control Dynamic System and Qos Manager Agent Over Ipv6 Networks: Intserv and Diffserv Approach in Access Nodes

Status:

Version 1

Abstract

Figures

1. Introduction

2. THEORETICAL FRAMEWORK

2.1 Next-Generation Internet Protocols

2.2 IPv6

2.3 QoS in IPv6

2.4 Queue Management and attention algorithms.

2.4.1 Weighted Fair Queuing (WFQ)

2.4.2 Deficit Round Robin (DRR).

2.4.3 Weighted Random Early Detection (WRED)

3. SPECIFICATIONS

3.1 QoS Manager Functionality

3.1.1 Proposed location in the QoS Agent network

3.1.2 DSCP code for handling Differentiated Services

3.2 Model Constraints.

4. METHODOLOGY FOR THE DEVELOPMENT OF THE QoS MANAGEMENT AGENT

4.1 Coding of IPv6 DSCP, ECN and Flow Label fields.

4.2 Simulation environment

4.2.1 OPNET Modeler simulation environment.

4.3 Development Methodology.

4.4 QoS Resource Provisioning Policy Adjustment Control Algorithm.

4.4.1 System input variables.

4.4.2. Active flow state variables

4.4.3 State machine and functions of the resource control system.

4.5 Complementary Models.

4.5.1 IPv6 Traffic Generator.

5. TEST SCENARIOS

5.1 Traffic Generator Performance Test.

5.2 Edge Router Performance Test

5.3 Performance Test of Border Router with QoS Manager Agent

5.4 Performance Test with Reuse.

5.5 Test MPLS Scenario

5.6 Test Scenario QoS Manager Agent.

6. RESULTS AND DISCUSSION

6.1 Traffic Generator Performance.

6.2 Edge Router Performance.

6.3 Performance of the Border Router with QoS Manager Agent

6.4 Performance with Reuse.

7. Conclusion

Declarations

References

Status:

Version 1