Analysis of Load Balancing for a New Approach to Support Traffic Engineering in IPv6 Networks

Objective: To propose a solution to support traffic engineering in IPv6 networks; such proposal is based on IPv6 capabilities. Methods/Analysis: Our proposal uses the IPv6 flow label field for packet switching in IPv6 networks and it also uses extended traffic engineering protocols like RSVP-TE and OSPFv3-TE. An advantage of our approach is that an MPLS transport network is not required to support traffic engineering. Our solution makes use of the tunneling concept, which has a high potential to support traffic engineering because it allows separation of different traffic among service/users in different tunnels. In this paper, we describe the main characteristics of our proposal and also, we present the evaluation of load balancing, which is a typical situation in traffic engineering studies. We compare our approach with MPLS performance because it is a technology commonly used to support traffic engineering. Findings/Results: Results show that load balancing in our solution has similar performance than MPLS when the number of tunnels over links is optimized. Improvements: This evaluation proves that our layer-3 proposal has traffic engineering capabilities in IPv6 networks independently of lower layers.


Introduction
An important problem in the current Internet is the use of the shortest path routing algorithm, which leads to congestion of certain common paths to many communications. One solution to this problem is to use switching technologies that allow traffic engineering support. One of the most used is MPLS 1 ; however, this requires to transport an additional header at 2.5 layer level.
On the other hand, IPv6 2 is the protocol of the next generation networks which offers significant advantages for the current trend technologies such as a great number of addresses and the provision of quality of service, mobility, among others. A complete study of IPv6 deployment is described in 3,4 . A new field in the IPv6 header is the called "flow label". In IETF, several debates were presented regarding the purpose of this field. In RFC6294 5 describes the questions made for the IETF designers, such questions were as follows: "Was it to be key in handling fast switching? Was it to be meaningful to applications and used to specify quality of service? Must it be set by the sending host? Could it be set by routers? Could it be modified in route? Must it be delivered with no change? Because of these uncertainties, as well as more urgent work in other areas, the IPv6 flow label was ignored by implementers and today it is set to zero in almost every IPv6 packet" 5 . Due to this reason, several proposals to use the IPv6 flow label field have been made for different purposes. A study of these proposals is presented in 5 and 6 . The flow label field initially was specified with 28-bit length in RFC1710 7 ; then, it was reduced to 24 bits by RFC1883 8 and finally established as 20 bits by RFC2460 2 . Since the definition of this field, there have been several uncertainties about its use such that, in RFC2460 it was defined as experimental and subject to change 7  The IETF performed several preliminary works to its full specification, such as in [9][10][11][12] , until a more detailed specification was published in RFC3697 13 , which provided useful information for its use and was in force for approximately seven years. During this time, several solutions were published by researchers, proposing methodologies of the use of flow label field for different purposes, such as quality of service support, packet switching and packet filtering, among others, but these solutions violated, in one manner or another, the recommendations given by RFC3697 13 .
Because of the above, the IETF performed a study of use cases for the "flow label, " published in RFC6294 5 . Such a study was performed because they found that, the flow label field was not used in practice. Therefore, RFC6294 5 describes a study of various published proposals focused on the use of the flow label field for different purposes and highlight the inconsistencies found between such proposals and flow label field specification, RFC3697 13 . Then, IETF took into account the minimal practical use of the flow label field at that moment, and IETF was motivated to change that specification to clarify it and introduce some additional flexibility; as a result, RFC6436 14 was published. Then, IETF made a recommendation to update RFC3697 13 and as a consequence, the new specification of the flow label field was published in RFC6437 15 , making RFC3697 13 obsolete.
Several proposals have been published by different researchers; these proposals are described as follows. In 16,17 , the authors describe a proposal called "IPv6 Label Switching Architecture" (6LSA). In this architecture, the flow label field is used to packets switch; every packet identified with the same flow label value must receive the same treatment and should be sent to the same hop. 6LSA works similarly to MPLS since it considers that a label has significance only between components of its architecture and in the manner how it establishes the flow label in every router. Unlike the traditional routing techniques, but similar to MPLS, 6LSA packets are classified within an FEC and routers send packets over different paths depending on the FEC.
In 18 , the authors propose a combination of the flow label and class of service fields as a switching tag and to support QoS, in a similar manner to how MPLS works. This proposal uses the DiffServ Code Point (DSCP) RFC2474 19 to indicate that the flow label is a switching tag. Another similar work based on QoS and packet switching is described in 20 , which was designed as a hop-by-hop option. Alternately, 21 presents a new model of sending packets by flow label to improve IPv6 packet switching, which requires service differentiation and as the author says, it provides more effective functions than MPLS.
On the other side, Internet traffic engineering is responsible for the optimization and evaluation of the performance of IP networks in operation. The aim is to improve the network performance by optimizing the use of resources and traffic by applying technologies and scientific principles to allow the measurement, characterization, modeling and control of Internet traffic. In the last fifteen years, different solutions have been proposed to support Internet traffic engineering. A previous study of traffic engineering proposals is described in 44 . We organized these proposals in five categories: TE based on IP by link weight optimization, TE based on MPLS, TE based on LISP, TE based on Segment Routing and TE based on IPv6 facilities. These categories will be explained as follows.
IP-based proposals are focused on the IGP link weight adjustment. The first IP-based TE solution was proposed by [45][46][47] . The main goals in their approach were to set the link weights of Interior Gateway Protocols (IGPs), such as OSPF and IS-IS, according to the given network topology and traffic demand to control intradomain traffic and meet TE objectives. In [48][49][50][51][52] algorithms and optimization problems to set link weights are proposed. Alternately, a generalized routing framework to realize the optimal TE, which can potentially be implemented via OSPF-or MPLS-based approaches, is presented in 53 .
The concept of traffic engineering in MPLS-based environments was introduced in 54,55 , by setting up dedicated switched paths (LSPs). The MPLS specifications are detailed in RFC3031 1 . TE based on MPLS can provide an efficient paradigm for traffic optimization. The most distinct advantage of MPLS-based TE is its capability of explicit routing and arbitrary splitting of traffic, which is highly flexible for both routing and forwarding optimization purposes. Many solutions have been presented in the literature using MPLS for traffic engineering and QoS purposes; many of them are directed to propose constraint-based routing algorithms, and studies over these proposals have been presented in 56,57 .
In recent years, an entirely different strategy has been proposed by the LISP protocol (Locator/ID Separation Protocol). The LISP Specifications are contemplated in RFC6830 58 . LISP is a network-layer-based protocol that enables separation of IP addresses into two new numbering spaces: Routing Locators (RLOCs) and Endpoint Identifiers (EIDs). RLOCs are topologically assigned to network attachment points; these locators are used for routing and forwarding of packets through the network 58 . EIDs are assigned independently from the network topology; these identifiers are used for numbering devices and are along administrative boundaries 58 . In 59 , the authors describe how LISP re-encapsulating tunnels can be used for traffic engineering purposes. Thus, a packet can take an administratively specified path, a congestion avoidance path, a failure recovery path or multiple load-shared paths as it travels from the ITR (Ingress Tunnel Router) to the ETR (Egress Tunnel Router). By introducing an Explicit Locator Path (ELP), an ITR can encapsulate a packet to a Re-encapsulating Tunnel Router (RTR), which decapsulates the packet and then encapsulates it to the next locator in the ELP. Some documents are dealing with traffic engineering support by LISP include [60][61][62][63][64][65] .
With respect to TE based on Segment Routing (SR), it has been recently proposed as an alternative traffic engineering technology. Enabling relevant simplifications in control plane operations takes advantages of the source routing paradigm. IETF is working on standardizing of the segment routing architecture 66 . In SR a node steers a packet through an ordered list of instructions, called segments. A segment can represent any instruction, topological or service-based and a segment can have a semantic local to an SR node or global within an SR domain 66 . Some works have been proposed to support traffic engineering by segment routing, such as in 67 , which details the segment routing policy for traffic engineering. In 68 , the authors consider the problem of determining the optimal parameters for segment routing in the offline and online cases. Alternately, in 69 a Label Encoding Algorithm for MPLS Segment Routing is proposed. In 70 , the authors present an SR path assignment algorithm for the flow assignment problem. Finally, in 71 , the authors purpose ILP models and heuristics that are successfully utilized to assess the TE performance of SR-based packet networks.
In TE based on IPv6 facilities, are proposals that use IPv6 issues such as the flow label and others. Here, there are allocated 6LSA 72 and IPngls 17 . The main advantage of this category of proposals is that there is no other nec-essary layer 2.5 technology to support TE. Additionally, they try to take advantage of benefits that are not being used for IPv6 yet, which is still in deployment and will be the main protocol for the Internet for a long time. Our proposal PSA-TE6 falls into this category. Because it has some similarities with the other mentioned proposals, we provide a summary of the similarities and differences according to important characteristics for supporting traffic engineering in Section 2.
In this paper, we describe the main characteristics of our proposal which we have called PSA-TE6 and also, we present the evaluation of load balancing, which is a typical situation in traffic engineering studies. We compare our approach with MPLS performance because it is a technology commonly used to support traffic engineering. Both solutions (PSA-TE6 and MPLS) use the tunneling concept (referred as Label Switching Path or LSP), which has a great traffic engineering potential that allows separation of diverse traffic for different service/users in different tunnels. However, in both cases (PSA-TE6 and MPLS) overload difficulties in routers can be presented if the number of tunnels is not limited and the load balancing is not optimized. In consequence, from a management point of view, it may also be desirable to limit the number of tunnels on a router or a link. For this reason, in this paper, we present the PSA-TE6 evaluation by MIP (Mixed-Integer Programming) formulation in order to balance load and to minimize the maximum number of tunnels over all links.
This article is organized as follows: Section 2 explains our PSA-TE6 proposal. Section 3 presents the evaluation of the load balancing in PSA-TE6. Section 4 shows the results. Finally, Section 5 describes conclusions and future works.

Packets Switching Architecture to Support Traffic Engineering in IPv6 Networks (PSA-TE6)
PSA-TE6 is a new solution proposed to support traffic engineering in IPv6 networks. The goal of this architecture is to use the IPv6 flow label field for packet switching in IPv6 networks in a manner similar to how MPLS 1 works but without the need of an MPLS architecture being installed. This proposal is created as a result of the study of the IPv6 flow label field from its creation to the latest recommendations of the IETF, plus the analysis of various proposals for the use of the IPv6 flow label field 5,6 and by observing its structure, which shows a great similarity to the MPLS label regarding size (20 bits) and contents.
In the literature, two proposals for label switching have been presented; these are described in 17,72 . In 72 , the authors propose the forwarding of IPv6 packets using label switching techniques, with similar advantages to the Multiprotocol Label Switching (MPLS) architecture. This forwarding process is performed by means of a map-ping of all MPLS header fields within the IPv6 header. Alternately, 17 introduces an architectural framework to use the IPv6 packet header flow labels to set up labeled paths in a similar manner to how MPLS works. Although our proposal and the two mentioned above use the label switching concept via IPv6 flow label switching in a similar manner to how MPLS works, our proposal presents important differences that strengthen traffic engineering support in IPv6 networks. In Table 1, such differences are described.

Principles of Design of the PSA-TE6 Proposal
Alternately 15 and the use cases of the IPv6 flow label in 5 . Both documents describe three basic rules for the use of the IPv6 flow label field, which are as follows: • IPv6 nodes MUST NOT assume any mathematical or other properties of the flow label values assigned by source nodes 5,15 . • Router performance SHOULD NOT be dependent on the distribution of the flow label values.Specifically, the flow label bits only make poor material for a hash key 5,15 .
The flow label must not be changed in route but allow routers to set the label on behalf of hosts that do not do so 5,15 .
According to the fundamental rules mentioned above, our proposal would violate the first part of the rule (iii), i.e., "not to be changed in route. " However, the second part of the rule (iii) states: "but allow routers to set the label on behalf of hosts that do not do so, " which is an open issue discussed in RFC6294 5 . Additionally, RFC6294 mentioned with respect to rule (iii) that it does not exclude the flow label from being used for switching or routing purposes.
Similarly, RFC6294 5 makes recommendations for designers who use the IPv6 flow label for packet switching. Such recommendations refer to overlooking the rules within a given domain. Within that domain, routers could establish and interpret the IPv6 flow label field as it was designed and then in the router of the last hop of the domain, the label should be set to zero; this rule should be enforced for packets arriving at the domain with the label set as zero.
For the case in which packets arrive at the domain with a label value other than zero, an alternative recommendation given for RFC6294 is to define a hop-by-hop option header to carry the original label through the domain so that it can be restored at the output of the domain. All those recommendations were taken into account in the design of the proposed PSA-TE6 solution. Alternately, OSPF and IS-IS protocols were extended in response to the requirements of RFC2702 and these extensions are also associated with support MPLS traffic engineering (OSPF-TE and IS-IS-TE). Therefore, in the design of PSA-TE6, such protocols also play an important role in the forwarding process since PSA-TE6 uses label switching and its goal is to provide traffic engineering. Thus, our PSA-TE6 proposal includes the use of the OSPFv3-TE protocol 73 , which is the extended protocol for working on IPv6 networks and supporting traffic engineering. Additionally, the RSVP-TE signaling protocol 74 , which was extended to the MPLS label distribution, has been taken and defined as a tool for the distribution of IPv6 flow labels in our proposal.
Finally, in the PSA-TE6 proposal, it is necessary to find appropriate constraint-based paths. This functionality is provided by CBR (Constraint-based Routing) algorithms, which select the best route that corresponds to the constraint set. Restrictions can be imposed by administrative policies, quality of service or traffic engineering requirements 75 . In the last fifteen years, many CBR algorithms have been proposed, and in 56,75,76 , a study is presented. We have selected the CSPF (Constraints Shortest Path First) algorithm for use in our proposal because CSPF is one of the most common algorithms used to address this issue 77 .

Architecture of the PSA-TE6 Proposal
The PSA-TE6 architecture is comprised of the following elements (see Figure 1): Ingress/egress 6DER (Ingress/Egress PSA-TE6 Domain Edge Router); 6DTR (PSA-TE6 Domain Transit Router); and 6DLSP (PSA-TE6 Domain Label Switching Paths). These elements must operate under a PSA-TE6 domain, which we have denominated 6D. The idea of having a domain with PSA-TE6 is referred at RFC6294 5 in Section 4, as a recommendation to proposals using the IPv6 flow labels to switch packets, as stated previously.
To explain the PSA-TE6 proposal, we assume a network with five nodes as in Figure 1. It is a network that works under the IPv6 protocol and it is composed of a 6D domain with routing and signaling protocols as OSPFv3-TE 73 and RSVP-TE 74 respectively. OSPFv3-TE is responsible of routing information flooding, regarding the network topology and traffic engineering information. Meanwhile, RSVP-TE is responsible for the establishment of the label switched paths and the distribution of IPv6 flow label values. It is important to emphasize that the RSVP-TE protocol has an object named "Label" which was created to distribute MPLS labels, however, in our solution we use "Label" object of RSVP-TE to distribute IPv6 flow labels. This can be done because the MPLS labels and IPv6 flow labels have the same length (20 bits). On the other hand, to establish IPv6 label switched paths, it is necessary to find an appropriate path, not necessarily the shortest, but one based on constraints. Several algorithms have been proposed about it, but in this proposal, we assume that PSA-TE6 works with CSPF algorithm (Constrained Shortest Path First), which is one of the most used. CSPF is based on the Dijkstra algorithm with a modification: The addition of a bandwidth constraint; this algorithm is explained in 78 .
In the 6D domain, Ingress/Egress-6DER routers must be able to read the IPv6 header; they also should set the 6DLSPs (IPv6 Flow Label Switching Paths) and perform label insertion and deletion operations (push and pop operations). Meanwhile, 6DTRs routers must be able to read the first 64 bits of the IPv6 header (see Figure 2) to switch and to route packets through exchanges of IPv6 flow labels and they also should be able to do the necessary operations for IPv6 label stacking. The fact that the 6DTRs routers have to read the first 64 bits of the IPv6 header is because the DS (Differentiated Services), IPv6 flow label and TTL (Time to Live) fields of the packet are located in this part of the IPv6 header and must be known to support quality of service and label packet switching (see Figure 2). It is possible to do this in one reading operation with the currently used 64-bit network processors.
When it is necessary to establish a new communication and the first packet reaches the Ingress-6DER, it reads the IPv6 header and captures the source and destination address. Then, by means of RSVP-TE, the establishment of the label switching path and label distribution process are accomplished using the standard procedures of such protocols. The label switching path is found by the constraint-based routing algorithm based on the OSPFv3-TE information. Then, the ingress-6DER puts the label value in the IPv6 flow label field in all the packets belonging to the correspondent flow and sends them to the next hop. This proposal initially assumes that packets come from a domain that does not use the IPv6 flow label so that this value will be zero according to RFC6437 15 . Then, the packet travels on that path and each 6DTR interior router will exchange the label (swap operation) in each packet and then send the packet to the appropriate output interface. When the packet arrives at the Egress-6DER, it removes the label (pop operation) and sends the packet to the destination. The router also returns the flow label field to its original value (or zero) according to RFC6294.
In the packet forwarding process, it is necessary to have information for the operations performed on the IPv6 flow label field, which must be analyzed before packet forwarding to the next hop. For this proposal, routers have an FIB (Forwarding Information Base) that is specific for each router, i.e., if it is 6DER or 6DTR. This FIB can be of two types: one that maps a FEC (Forwarding Equivalent Class) to N6FLD (Next Hop IPv6 Flow Label Forwarding Data), which we have called FTN6 (Forwarding Equivalence Class To Next Hop IPv6 Flow Label Forwarding data) and another FIB that maps an incoming IPv6 flow label to N6FLD, which we have called I6LTN (incoming IPv6 flow label to next Hop IPv6 flow label Forwarding data). These tables are similar in content and function to those used in MPLS 1 . These tables will be available in routers of IPv6 flow label switching according to their roles in the PSA-TE6 domain. In IP networks, a router considers that two packets belong to the same FEC if there is any address prefix X in the routing table such that X prefix is the longest match for each packet's destination address. In the PSA-TE6 architecture, the FEC will be determined in the ingress routers where the 6DLSPs are established.

Evaluation of the Load Balancing in PSA-TE6
In the packet forwarding process, PSA-TE6 establishes label-switching paths and performs packets switching by label swapping in a similar manner as MPLS works. However, in this process, there is a difference with regard to the packet length since MPLS insert a header of 32 bits which contains the label value. On the other hand, PSA-TE6 does not require an additional bit since PSA-TE6 uses the flow label field and this field is contained in the IPv6 header (see Figure 3). It is important to determine whether traffic distribution is affected by such difference in packet length. Therefore, this article has oriented the evaluation of the PSA-TE6 solution towards the analysis of traffic distribution under load balancing, which is a typical situation for traffic engineering. PSA-TE6 uses the tunneling concept (also referred as 6DLSPs) which has a great traffic engineering potential that allows separation of diverse traffic of different service/users in different tunnels in a similar manner as MPLS works. In both technologies (PSA-TE6 and MPLS), overload difficulties in routers can be presented if the number of tunnels is not limited and the load is not balanced. Therefore, from a management point of view, it may also be desirable to limit the number of tunnels on a router or a link. For this reason, we present an MIP formulation whose objective function problem is to carry different traffic classes in a network through the creation of tunnels in such a way that the number of tunnels on each router/link is minimized and load balanced. Network topologies, link capacities, traffic demands and candidate paths are previously specified for the optimization problem. A similar MIP formulation is described in 79 , but we do a modification to that model to compare load balancing in PSA-TE6 versus MPLS. To do this, we introduce a parameter λ, which represents the effect of differences in the traffic demands due to packet lengths for each technology. Such difference is referred to the addition of the MPLS header in IP/MPLS networks and the not existence of the MPLS header when PSA-TE6 is used. Now we introduce a mathematical model of the problem using the notation as in 79 . We use the identifier d = 1,2,…,D to denote a demand associated with a node pair (source and destination nodes) that require bandwidth h d to be routed in the network. The volume h d of demand d can be carried over multiple tunnels (paths) from ingress to egress of the tunnel. We use index p = 1,2,…,P d to denote candidate paths for demand d. The fraction of the demand volume for demand d to be carried on tunnel p is denoted as X dp . Note that X dp is a continuous decision variable. We have the demand constraint, which guarantees that the sum of all fractional flows X dp over all candidate paths p = 1,2,…,P d must add up to the whole demand volume h d in (Equation 1).
Since a flow could be a very small fraction of traffic demand, we establish a lower bound on the fraction of a flow on a path. We use a positive quantity ε to be the lower bound on such fraction of flow on a tunnel (path) and we use the binary variable U dp = 1 to denote the selection of a tunnel if the lower bound is satisfied, and 0, otherwise. We add a parameter λ, which represents a bandwidth percentage of each demand that differentiates one technology from the other according to the length of the packet for each one (see Figure 3). We have the following two constraints: X dp ≤ U dp Constraint (Equation 2) assures that if a tunnel is selected, then the tunnel must have at least the fraction of allocated flow which is set to ε. Constraint (3) guarantees that if a tunnel is not selected, then the flow fraction associated with this tunnel should be forced to be equal to 0.
Since the network topology is given and link capacity is known, we must assure that physical link capacity C e of link e is not exceeded. On the other hand, we use the binary variable δ edp , which is 1 if link e belongs to path p realizing demand d, and 0 otherwise. Thus, the capacity feasibility constraint is the following: The left-hand side of (Equation 4) is the flow on link e, which is calculated taking into account all demands d = 1,2,…,D, the candidate paths p = 1,2,…,P d , whether the given demand d uses path p (δ edp = 1) and the flow fraction X dp . Here, we add λ parameter that represents an additional bandwidth percentage of each demand that differentiates PSA-TE6 of MPLS. The number of tunnels on link e is given by (Equation 5): The complete formulation is described in the Table  2  Such as was mentioned above, we add a parameter λ in constraint 8 and 9 (Table 2), which represents a bandwidth percentage of each demand that differentiates one technology from the other according to the length of the packet for each one. As we said before, such difference is caused in MPLS because it adds a header to establish a label in the packet forwarding process, which is not necessary for PSA-TE6. We assume that applications keep the same packet periodicity and in consequence, a reduction in the packet length results in a reduction in traffic demand for such flow. As we can see in Figure 3, PSA-TE6 packets are shorter than MPLS packets due to additional MPLS header in IP/MPLS networks. Thus, we take as a reference to PSA-TE6 as λ=1 (see Figure 3) and λ>1 for MPLS case.
X dp ≤U dp

Results
As we said before, in order to evaluate PSA-TE6 and compare it with MPLS performance, we assume that bandwidth percentage of each demand that differentiates one technology from the other according to the length of the packetis represented as parameter λ; we take as reference to PSA-TE6 as λ=1 (see Figure 3), and λ>1 for MPLS case.
As we can see in Figure 3, PSA-TE6 packets are shorter than MPLS packets due to additional MPLS header in IP/ MPLS networks. For evaluation purposes, we give several values to λ to analyze the effect of packet length in the traffic distribution over the established paths to compare both technologies. c) The topologies used in this evaluation are shown in Figure 4. Over both topologies, we evaluate traffic distribution by varying the number of demands from 1 to 5, which are sent from an ingress node to egress node for different values of λ. We simulate the path distribution for λ = 1 until λ = 1.1 with steps of 0.01 in each running. In every experiment, each demand can be distributed in five possible candidate paths.
Results for a network of 6 nodes and 1, 3 and 5 demands, are shown in Figure 5. Also, results for a network of 13 nodes for 1, 3 and 5 demands are shown in Figure 6.
As we can observe, in both network topologies the traffic distribution is similar to the same number of demands when we vary lambda values from 1 to 1.1. For example in Figure 5 (6 nodes network), for three demands, the traffic distribution in demand from N1 to N4, is similar for several values of lambda. Similar behavior can be observed in Figure 6 for three demands in a 13 nodes network for demand from N1 to N7. Although the selected paths are different for each network topology, we did not find differences in the proportion of traffic distribution in both topologies for several numbers of demands while the value of lambda is changing. Thus, such traffic distribution variations remain in the same proportion of lambda variation (1% to 10% of the occupation of a link or path).
To support our range of lambda (λ = 1 to λ = 1.1), we take the VoIP service as an example for the worst case in packet length difference between MPLS and PSA-TE6. We calculate a typical packet length for this service as follows. For typical G.729 codec, the packet length is 108 bytes, we should add headers to this payload as: 40 bytes of IPv6 Header, plus 8 bytes of UDP header and 12 bytes of RTP header; if we add the MPLS header (4 bytes), we will take a total length of 172 bytes for the case λ>1. Thus, in PSA-TE6, we will take only 168 bytes (without MPLS header), i.e. λ = 1, which is 2.3% less than MPLS case; this is λ = 1.023 for MPLS.
As a conclusion, we have demonstrated that PSA-TE6 has the same behavior than MPLS in load balancing scenario when the number of tunnels over links is optimized. Also, with PSA-TE6, IPv6 networks have the advantage that they do not require another technology to support traffic engineering. Besides, IPv6 networks would occupy less bandwidth than MPLS.

Conclusions and Future Works
This study presented a new proposal to support traffic engineering based on the use of the IPv6 flow label field for packet switching, which has been called PSA-TE6. For the evaluation of our proposal, we performed an analysis of load balancing and the minimization of the number of tunnels on each link in order to evaluate the behavior of PSA-TE6with respect to MPLS. Results show that small differences in packet length for both technologies (2.3% for the worst case) are not meaningful and the traffic distribution behavior over the links for both technologies is the same when the number of tunnels over links is optimized. Then, our proposal PSA-TE6 is a useful tool to make traffic engineering in IPv6 networks and if PSA-TE6 is implemented in IPv6 networks, MPLS could be not necessary to offer traffic engineering. Besides, IPv6 networks would occupy less bandwidth than MPLS. It is important to highlight that PSA-TE6 solution satisfies the recommendations of the IETF for using the IPv6 flow label field for switching control and such recommendations support that IPv6 flow label can be used for packet switching in combination with routing and signaling protocols (OSPFv3-TE and RSVP-TE respectively) that support traffic engineering. The above allows establishing paths using constraints based routing algorithms such as CSPF without the need to use IPv6 over MPLS. Future works may be related to the behavior of PSA-TE6 in mobile environment related to the handover time and traffic engineering support. Other future works could be focused on the evaluation of our PSA-TE6 proposal with other strategies or in combination with them like Segment Routing or LISP.