WO2015028561A1

WO2015028561A1 - Re-routing methods, elements and systems

Info

Publication number: WO2015028561A1
Application number: PCT/EP2014/068288
Authority: WO
Inventors: Manuel Julian Lopez Morillo; Jose Angel Perez De La Rosa; Luis Angel MUNOZ MARIN
Original assignee: Vodafone Ip Licensing Limited; Vodafone Espana S.A.U.
Priority date: 2013-08-29
Filing date: 2014-08-28
Publication date: 2015-03-05
Also published as: ES2530592A1; ES2530592B1

Abstract

A system and method for increasing the number of service classes available in MPLS, by enabling three EXP bits in a first label to be combined with 3 EXP bits in a second label. In a particular aspect of the invention, these 6 service class bits are 5 additionally made available during a Fast Re-Route (FRR) procedure, by shifting the three EXP bits from the outer label to the FRR label, as well as the three EXP bits from the inner label to the outer label. In this configuration, the 6 bits are usable by routers on the alternative route. At the end of the re-routing procedure, the EXP bits are shifted back to their original positions.

Description

RE-ROUTING METHODS, ELEMENTS AND SYSTEMS

Field of the Invention

The present invention relates to the transmission of data across networks of different types. In particular, the present invention relates to the transmission of data across networks of different types, in a manner that retains quality of service parameters. Even more particularly, the present invention relates to the transmission of data from an Internet Protocol (IP) network to a network with a different data-carrying mechanism, such as Multiprotocol Label Switching (MPLS) in a manner which retains all or at least the majority of traffic classes used by the Internet Protocol. Still more particularly, the present invention relate to the transmission of data originating in an IP network, across an MPLS network whilst retaining all or at least the majority of service classes used by the Internet Protocol, even when implementing MPLS specific procedures, such as Fast Re-Route (FRR).

Background

Transport network quality of service requirements are important for many products and services utilising communication networks, particularly products and services in the fields of M2M, Automotive, mHealth, Cloud Computing and Network Virtualisation.

The Internet Protocol (IP) is an extensively deployed protocol for transmitting data across networks. It is a routing protocol that encapsulates data packets with source and destination addresses in order to route the packets across the network.

Quality of Service is typically provided in the Internet Protocol via the Differentiated Service (DiffServ) mechanism. DiffServ classifies data traffic, by placing each data packet into a limited number of traffic classes. Each router in the network is configured to differentiate traffic based on the designated class of each packet, rather than differentiating network traffic based on the requirements of an individual flow. Each traffic class can be managed differently, ensuring preferential treatment for higher-priority traffic. DiffServ uses a 6-bit field (DS field) in the header of an IP encapsulated packet for quality of service classification purposes. This 6 bit field enables up to 64 different classes to be supported. In this regard, the DiffServ Code Point (DSCP) is an 8 bit field, where three bits are the Class Selector (CS) code points, another 3 bits are the Drop Precedence (DP) and two bits designated as either Currently Unused (CU) or, for IPv4 and IPv6, as an Explicit Congestion Notification (ECN).

Applications and usage of the 64 different traffic categories of the Internet Protocol are defined in the standards RFC 2597, RFC 2598 and RFC 2474.

The Internet Protocol has been used by extensively by telecommunications network providers in their terrestrial networks for the transmission of data, however there is presently a move away from the Internet Protocol to Multiprotocol Label Switching (MPLS). As the Internet Protocol will continue to be used in many concurrent networks, there is a need to be able to effectively transfer data between IP networks and MPLS networks.

In MPLS, a four byte label is attached to data packets, where an unstructured label value field of 20 bits is provided, as well as 3 bits for Experimental use (EXP), one bit to designate a stack bottom (S) and 8 bits for a Time to Live (TTL) field. An illustration of this label is provided in Figure 1 .

Presently, the 3 bit EXP field is used as a Class of Service field in the MPLS label. Where IP packets are mapped to such an MPLS label, it is only possible for a portion of the DSCP to be mapped, typically the CS code point field. Therefore, whilst the Internet Protocol supports up to 64 different classes of service (i.e. the 6 bit DSCP field enables 2⁶= 64 different classes), MPLS only supports 8 (i.e. the three bit field only enables 2³=8 classes). Therefore, MPLS is essentially only able to directly map the Class Selector code points, but not the Drop Precedent codepoints. Therefore service differentiation capability is lost when mapping packets from IP to MPLS as the 64 different classes of service must be reduced to only 8.

There is therefore a need to improve the Quality of Service when mapping between data-carrying mechanisms, and particularly when mapping from IP to a data carrying mechanism that provides for fewer service classes. Most specifically, this need applies to mappings for IP/MPLS networks.

Summary of the Invention

According to a first aspect, the present invention provides systems and method as set out in the attached claims.

According to a second aspect, the present invention provides a method for facilitating routing of a data packet using a network element located in a second data network, where the received data packet has been transmitted across a first data network which uses a first data-carrying mechanism to the second data network which uses a second data-carrying mechanism, and the received packet has been adapted for use by the second data network, such that the method includes the network element: reading a first field of a first label associated with the data packet; and where the first field indicates that the data packet is being transmitted according to a given service quality arrangement, reading a second field of a second label; and utilising the data from the first and second fields in combination in order to provide an enhanced service quality for the data packet. Preferably the given service quality arrangement is Assured Forwarding and the method further includes recognising the first field as defining an Assured Forwarding class by virtue of a value of the first field, such that the recognition serves as a trigger to read the second field of the second label. Advantageously, the present invention enables an increased number of QoS fields to be associated with a data packet in order to provide an enhanced quality of service for that packet. Minimal changes need to be made to network nodes/elements in order to support this aspect of the invention: network nodes need only be programmed so as to recognise an entry or value in the first field of the first data packet as defining an Assured Forwarding class.

According to a further aspect, the present invention provides a network element located in a second data network, and adapted to interpret a received data packet, where the received data packet has been transmitted across a first data network which uses a first data-carrying mechanism to the second data network which uses a second data-carrying mechanism, and the received packet has been adapted for use by the second data network, the network element being configured to: read a first field of a first label associated with the data packet; and where the first field indicates that the data packet is being transmitted according to a given service quality arrangement, reading a second field of a second label; and utilising the data from the first and second fields in combination in order to provide an enhanced service quality for the data packet.

According to a still further aspect, the present invention provides a method of facilitating data transmission from a first data network using a first data-carrying mechanism to a second data network using a second data-carrying mechanism, including: mapping a data packet from the first data network to the second data network by allocating first and second labels to the data packet; mapping a first portion of quality of service information relating to the first network data packet to a field in the first label; and mapping a second portion of the quality of service information for the first network data packet to a field in the second label.

Preferably the first data carrying mechanism is IP. The second data carrying mechanism is one that is configured to accommodate fewer classes of service than the first data carrying mechanism. Where the first data carrying mechanism is IP, the second data carrying mechanism may be MPLS.

These aspects of the invention advantageously utilises the ability of MPLS to allocate multiple headers/labels to packets being transmitted. In this regard in MPLS the label stacking concept is defined in RFC3032 (i.e. it defines the use of the S bit value (see Figure 1 ) to know if a given MPLS label is the last label or not).

Where two or more labels, are utilised, one is typically defined as an outer/service label and the other an inner/customer label. In this configuration, and where IP is the first data-carrying mechanism, a 3-bit component of the 6-bit DSCP CS segment is copied to an appropriate 3-bit segment of the inner label (e.g. the first three bits) and a different 3-bit component of the DSCP CS segment is copied to an appropriate 3- bit segment of the outer label (e.g. the last three bits). The core network is then able to extract all 6 bits and determine which of the 64 possible service classes applies to the packet (i.e. 2⁶ = 64).

This aspect of the invention therefore advantageously provides a straight way to map the Internet Protocol Quality of Service, QoS, parameters, based on Differentiated Services, which are capable of supporting up to 64 different traffic categories, onto an IP/MPLS network.

It enables the level of network quality tiers to be enriched, and also increases the granularity of the Quality of Service mapping. It is a feature that has particular application for transport network modernization for evolution towards all-IP.

Brief Description of the Drawings

A detailed description of the embodiments of the invention will now be described with reference to the Figures, where:

Figure 1 illustrates an example of an MPLS label;

Figure 2 illustrates a first embodiment of the invention, relating to mapping data from an IP network to an MPLS network;

Figure 3 illustrates an example of FRR routing according to an embodiment of the invention. Detailed Description

Multiprotocol Label Switching (MPLS) is a mechanism used in such high- performance telecommunications networks which directs and carries data from one network node to the next. It can encapsulate packets of various network protocols. MPLS is a highly scalable, protocol agnostic, data-carrying mechanism.

In an MPLS network, data packets are assigned labels (see Figure 1 ). Packet- forwarding decisions are made solely on the contents of this label, without the need to examine the packet itself. This allows one to create end-to-end circuits across any type of transport medium, using any protocol. Accordingly, MPLS essentially creates "virtual links" between distant nodes.

MPLS is an important advance for telecommunications companies, as it enables voice, data and multimedia traffic to be converged onto a single, secure network. Communications on an MPLS network can be prioritised so that activities such as sending an email can be given lower priority than business-critical or delay-sensitive applications such as IP voice. As indicated above, however, a transitional problem exists in relation to sending a data packet from a network supported by IP, to a network supported by MPLS, since MPLS does not support QoS classes to the same degree as IP.

According to a first embodiment of the invention, however, MPLS is adapted in order to enable the 64 service classes to be retained upon a packet transitioning from a network supported by IP to a network supported by MPLS. This embodiment of the invention will be described in relation to Figure 2.

In this regard, Figure 2 shows schematically some of the network elements utilised in a network supported by MPLS. An IP packet being routed towards its destination, being that of an Enhanced Packet Core (EPC) server, would be received by an I P network element, in this case being LTE Node B, and forwarded towards the EPC server. The route to this EPC server passes at least partially through a network supporting MPLS. In Figure 2, this entry to the MPLS network is the Ingress Provider Edge (PE) router, and the LTE Node B accordingly passes the IP packet to the Ingress PE router.

The network element responsible for adapting the packet to accommodate MPLS, in this instance, is the Ingress PE Router. The Ingress PE Router performs this modification, and then forwards the adapted packet across the MPLS network, via one or more Provider Routers (P). In this instance, the exit point from the MPLS network for the destination point is the Egress PE router. To adapt the packet, the Ingress PE router creates two MPLS labels for the data packet, being an MPLS Service Label and an MPLS Trunk label. The three DSCP DP bits from the IP data packet are copied to the EXP field of one of the labels, typically the MPLS Service label. The three DSCP CS bits are copied to the EXP field of the other label, typically the MPLS Trunk label.

These two labels are then able to be used by each router through the MPLS network. For instance, the following is an example of an algorithm that may be used by routers throughout the MPLS network in order to accommodate the 64 different service classes now designated in the MPLS packets:

IF "Trunk MPLS EXP 3-bits" FIXES AFxy Pattern THEN

LOOK UP "Service MPLS Label EXP 3-bits"

DETERMINE Drop Precedence

ELSE

Do Nothing

END

The AFxy pattern relates to the Assured Forwarding (AF) per hop behaviour as defined in RCF2597 and later updated by RFC3260. Assured Forwarding allows the operator to provide assurance of delivery as long as the traffic does not exceed a predefined rate. Traffic that exceeds the predefined rate faces a higher probability of being dropped if congestion occurs. Assured Forwarding defines four separate AF classes with Class 4 having the highest priority. It also defines 3 drop precedence values, so within each class, packets are given a high, medium or low drop precedence. Therefore the combination of classes and drop precedence yields twelve separate DSCP encodings from AF1 1 through AF43 as per TABLE 1 :

Class 1 Class 4

Class 2 Class 3

(lowest) (highest)

Low Drop AF1 1 AF21 AF31 AF41 Medium Drop AF12 AF22 AF32 AF42

High Drop AF13 AF23 AF33 AF43

TABLE 1

Therefore, from this table it can be seen that the Assured Forwarding concept can be defined as AFxy where x(1 ..4) defines the class and y(1 .3) defines the drop precedence.

To implement Assured Forwarding, each node extracts and uses the AF data for giving different forwarding assurances, when needed. The AF data can be used to decide what class of service (e.g. AF1 , AF2, etc.) will be penalized or dropped in case of link bandwidth congestion or when traffic exceeds the assigned buffer space and link bandwidth agreed (i.e. as per the Service Level Agreement). It also applies within each AFx class (e.g. AF13 packets will get dropped before packets in AF12 and before packets in AF1 1 ).

The present invention implemented in MPLS maps the class encodings onto the Trunk MPLS EXP 3 bits, that it is the X(1 ..4). The algorithm of the present invention recognises these bits in the MPLS label as relating to Assured Forwarding by virtue of having a value of 1 to 4. This can be achieved by reference to a comparison table having the recognised Assured Forwarding values. Where a comparison shows the MPLS label value to be an AF class, this recognition serves as the criteria to trigger the look up process (i.e. IF "Trunk MPLS EXP 3-bits" FIXES AFxy Pattern, THEN LOOK UP "Service MPLS Label EXP 3-bits ", DETERMINE Drop Precedence). That is, the network element/router will then refer to the EXP field of the Service MPLS label and use the value therefrom in order to implement drop precedence, if needed. Therefore, overall, where a router recognises the value in the Trunk EXP as defining an AF class, the packet will be allocated to an appropriate queue (i.e. preferably a queue is reserved for each AF class). By virtue of the router determining the Trunk EXP value to be an AF class, the router will know it can access the Service EXP field to obtain a Drop Precedence value. The router can extract this value for its use until a packet is dispensed with (i.e. either forwarded or dropped). The drop precedence value is typically temporarily stored relative to the AF service class, so that the two fields are combined or at least utilised in combination. Alternatively the router may access the Service EXP field when needed (e.g. upon a given queue becoming congested, in order to make a determination of which packet or packets to drop in order to relieve queue congestion).

The routers on the MPLS network are accordingly able to utilise both EXP fields by using this algorithm, and accordingly base a quality of service decision on both fields (i.e. according to a possible 64 different classes of service). A small adaptation to the intermediate routers may be required in order to enable them to implement this algorithm.

It is to be appreciated that this solution is backwards compatible with the current IP/MPLS QoS implementation, where only the Trunk MPLS label is analysed.

Advantageously this embodiment of the invention enables 64 different classes of service to be provided whilst only using a single trunk across the MPLS network from the Ingress PE router to the Egress PE router. In other words, only one trunk need be used for transporting different services with different experimental bit values.

A second embodiment of the invention will now be described in relation to Figure 3. This Figure illustrates an embodiment where MPLS implements Fast Reroute (FRR) as defined in RFC4090. FRR is based upon the use of Resource Reservation Protocol - Traffic Engineering (RSVP-TE) as outlined in RFC3209. This standard defines various extensions that can be used to establish label-switched paths (LSPs) in MPLS. In this standard, the flow along an LSP is completely identified by the label applied at the ingress node of the path.

FRR is an MPLS resiliency technology that is able to provide fast traffic recovery upon link or router failures. It does this by creating a back-up transport tunnel to enable traffic redirection in the event of a failure. It does this by adding an extra label to the MPLS stack to perform a path bypass. FRR is based upon MPLS, and accordingly the current implementation of FRR inherits the capacity to only support 8 different Classes of Service (i.e. via only 3 EXP bits). Accordingly, like standard MPLS, this procedure also is not able to accommodate the 6-bits provided for service classes in the DiffServ codepoint.

In fact it, the FRR mechanism would benefit by increased service classifications, as it is implemented in situations where there is a failure situation, which naturally increases the possibility of traffic congestion. Accordingly a more precise granularity of traffic classes, particularly in regard to priorities for dropping traffic, would be beneficial.

Therefore, a second embodiment of the invention will now be described with reference to Figure 3, which enables an increased number of traffic classes to be utilised during the FRR mechanism.

As shown in Figure 2, a packet is being transmitted across the network with an outer trunk label and an inner service label, and both of those labels include different 3 EXP bits which can be combined to provide up to 64 different Quality of Service classes.

With reference to Figure 3, such a packet is created at PE1 , the Ingress point of the MPLS network, such that the Trunk label defines the route to the ultimate destination point, PE2, via P1 and P2. That packet is therefore first passed to node P1 . P1 reads the packet and would have adjusted the next hop address to that of P2, but a link failure has occurred between P1 and P2. P1 therefore implements FRR in order to reroute the packet around the link failure. Therefore, rather than forwarding the packet directly to P2, it is forwarded via nodes/routers P3 and P4. To do this, P1 , which is typically referred to as the "Point of Local Repair" (PLR), pushes a new label onto the packet, being an FRR MPLS label. This label essentially defines the new route between P1 and P2, as being that via P3 and P4. It also swaps the label portion of the trunk label so as to indicate the next hop as being P3. Now, according to this embodiment of the invention, in order to enable all six QoS bits in the MPLS labels to be utilised during the FRR procedure, a transitory procedure takes place in conjunction to the procedure described above. That is, upon the new FRR label being pushed onto packet, the three EXP bits from the MPLS trunk/outer label are copied to the new FRR label. Also, the three EXP bits from the MPLS service/inner label are copied to the MPLS trunk/outer label. In this way, the six QoS bits are now located in the FRR label and the MPLS trunk label and are accordingly usable to administer up to 64 Quality of Service classes to the packets. In other words, this embodiment of the invention takes advantage of the third MPLS label added by the FRR mechanism. It is also to be appreciated that it is preferable that the fields are ordered in this way because in a typical MPLS bypass tunnel the routers will look first to the FRR label as the outer label, and based on the field value it will decide to look up or not the other label for drop precedence. In other words, in the typical bypass MPLS tunnel across the protection path, the FRR MPLS label takes the role of the former TRUNK label and the TRUNK label takes the role of the former service label in terms of QoS mapping.

This packet with the three labels is then transmitted towards router P3. Upon P3 receiving the packet, it will note the route being taken by referring to the FRR label, and accordingly update the Trunk label so that the next hop is towards P4. Upon the packet being received at P4, upon reading the FRR label, P4 will appreciate that it is the penultimate node before P2, which ends the rerouting procedure. Therefore, according to the standard FRR procedure, P4 "pops" the FRR label off from the packet. The penultimate node that performs this procedure is typically referred to as the "Merge Point".

According to this embodiment of the invention, however, before the packet is popped, the 6 QoS bits in the FRR and outer labels are returned to their original positions. Therefore, the 3 EXP bits in the MPLS Trunk/Outer label are copied to the MPLS Service/Inner label. Then the 3 EXP bits in the FRR label are copied to the 3 EXP bits in the MPLS Trunk/Outer label. This therefore returns the EXP bits to their positions usable in a standard MPLS network implementation (i.e. without FRR) in order to allow up to 64 QoS classes to be provided for. The P4 router than forwards this packet, with just the two MPLS labels (i.e. Service and Trunk and not the FRR label), towards P2. Upon P2 receiving the packet, the packet is again essentially of the form in which P2 would have received the packet if it had arrived via the primary route. The trunk label will indicate that the packet is to be forwarded to PE2, the Egress point from the network.

Therefore, in this way, whilst the packet is being forwarded along the primary route (i.e. PE1 to PE2 via P1 and P2), with the 3 QoS bits in each of the trunk and service labels, the intermediary routers are able to implement a 64 bit quality of service using the EXP bits from both the service and trunk labels. This quality of service level may be continued in FRR by the present embodiment of the invention, such that nodes on a secondary FRR detour route (i.e. P1 to P2 via P3 and P4) are able to use the EXP bits from the FRR and Trunk labels to implement the 64 bit quality of service.

As with the previous embodiment of the invention, this embodiment is backwards compatible with legacy routers. Therefore, for instance, if P3 were a legacy node, it would only utilise the 3 QoS bits in the FRR label and not refer to the 3 EXP bits in the Trunk label. Also, its actions on the packet would not affect subsequent nodes, so that subsequent nodes such as P4 could utilise all 6 QoS bits, if able. Advantageously, this embodiment of the invention proposes a solution that enables the number of classes of service to be extended even after transport link or node failures.

It is to be appreciated that in both these embodiments, were the logical criteria of the DSCP to be changed in any way, these embodiments of the invention would be able to accommodate those changes simply by changing a mapping table associated with the MPLS EXP bits, so that the new DSCP definitions would be reflected in the mapping table for the MPLS EXP bits. Further it is to be appreciated that it is preferable for the field mapping to be undertaken in the manner described (i.e. from trunk to FRR and then service to trunk). It is possible to vary this, however this would be less preferable as it would require additional changes to be made to the functionality of the P routers. In other words, the preferred embodiment described above is consistent with the algorithm defined in the general MPLS QoS extension. If we were to instead to map the service label field to the FRR label, the functionality of the P routers would have a different behaviour than for the normal MPLS network or in MPLS FRR conditions (i.e. they would need to read the third label instead of the second). As this logic is typically performed at hardware level and because it is preferable for the overall mechanism to be as simple and homogenous as possible, this is a less preferable approach. So in summary, the approach described in the detailed embodiments is most preferable as it leaves the P routers as simple as possible and moves the complexity to the edge router as the network element starting the bypass tunnel for protection.

Further, the inventive concept has been described in relation to accommodating 64 different service classes, using two different MPLS/FRR labels. If however more than 6 bits were needed in the future, to accommodate further data and/or service classes, additional MPLS labels could be used in a corresponding manner.

Also, the inventive concept has principally been described in relation to its use in relation to Assured Forwarding. Whilst this is a preferred embodiment, the invention could also be applied to other 6-bit QoS implementations. For example, if in the future a new QoS logic was defined based on 6 bits, the inventive concept could also be adapted to apply to the new logic, so as to provide QoS values of 6 bits in MPLS and Ethernet. As a specific example, if in the future it was decided to put drop precedence 1 , 2 and 3 in BE (Best Effort) Class of Service, the drop precedence of BE (e.g. BE1 , BE2, BE3) could be adapted in a similar way to the preferred embodiment for AF classes of service.

The embodiments of the invention above have been described in relation to MPLS FRR based on RSVP, however it is to be appreciated that the invention is applicable to any MPLS mechanism that uses an extra MPLS label to create a bypass tunnel, particularly for repairing a failure. For instance, the present invention may also be readily applied to the remote Loop Free Alternate (r-LFA) approach which also creates a bypass MPLS tunnel for fault protection (defined in http://tools.ietf.org/html/draft-shand-remote-lfa-01 ). The invention is not to be considered as limited to either mechanism and can readily be applied to other approaches as may be devised in the future.

The embodiments of the invention also apply to newly developed network configurations, as well as upgrades made to existing network configurations. The embodiments of the invention have particular application to data sent at least partially across a mobile network, particularly mobile networks implementing Long Term Evolution, LTE. In this regard, network quality is of particular importance when developing mobile networks, both in terms of speed and coverage reliability.

Claims

1 . A method for facilitating routing of a data packet using a network element located in a first data network, where the received data packet is associated with a first label including a first quality of service field and a second label including a second quality of service field, such that the method includes the network element: determining that a fault has occurred on a predetermined route applicable to the received data packet;

applying a reroute label to the received data packet defining an alternative route for the received data packet;

copying the first quality of service field from the first label to the reroute label; copying the second quality of service field from the second label to the first label ;

such that the quality of service fields in the reroute label and the first label are usable in combination by routers on the alternative route in order to provide an enhanced service quality for the data packet.

2. A method for facilitating routing of a data packet using a network element located in a first data network, where the received data packet is associated with first and second labels and a reroute label, such that the reroute label defines an alternative route around a fault, and the method includes the network element:

determining that the network element is the penultimate node on the alternative route around the fault;

copying a second quality of service field from the first label to the second label ;

copying a first quality of service field from the reroute label to the first label; removing the reroute label ;

such that the quality of service fields in the first and second label are usable in combination by subsequent routers in order to provide an enhanced service quality for the data packet.

3. A method for facilitating routing of a data packet using a network element located in a first data network, where the received data packet is associated with at least two labels being a first label and a reroute label defining an alternative route around a fault, such that the method includes the network element:

using the reroute label to determine the alternative route being taken by the packet;

amending the first label to forward the packet to the next network node on the alternative route;

determining a first quality of service field in the reroute route label ;

determining a second quality of service field in the first label;

utilising the first and second quality of service fields in combination and apply a resultant quality of service to the packet in relation to forwarding the packet towards the next network node.

4. The method of any one preceding claim wherein the first data network utilises an MPLS data-carrying mechanism, and the data packet has been transmitted from another network utilising an Internet Protocol data-carrying mechanism, and adapted for use by the first data network, such that the first and second quality of service fields correspond to quality of service fields from the Internet Protocol.

5. The method of any one preceding claim wherein the first label is trunk/outer label and the second label is a service/inner label and the network element applies the alternative route to the received data packet according to a Fast Re-Route, FRR, mechanism so that the reroute label is an FRR reroute label.

6. A network node configured to perform the method according to any one of claims 1 to 5.

7. A network element located in a second data network, and adapted to facilitate routing a received data packet, where the received data packet has been transmitted across a first data network which uses a first data-carrying mechanism to the second data network which uses a second data-carrying mechanism, and the received packet has been adapted for use by the second data network, the network element being configured to: determine that a fault has occurred on a predetermined route applicable to the received data packet;

apply a reroute label to the received data packet defining an alternative route for the received data packet;

copy a first quality of service field from an existing first label associated with the packet to the reroute label ;

copy a second quality of service field from an existing second label associated with the packet to the existing first label ;

such that the first and second quality of service fields in the reroute label and the existing first label are usable in combination by routers on the alternative route in order to provide an enhanced service quality for the data packet.

8. A network element located in a second data network, and adapted to facilitate routing of a received data packet, where the received data packet has been transmitted across a first data network which uses a first data-carrying mechanism to the second data network which uses a second data-carrying mechanism, and the received packet has been adapted for use by the second data network and is associated with first and second labels and a reroute label, such that the reroute label defines an alternative route around a fault, the network element being configured to:

determine that the network element is the penultimate node on the alternative route around the fault;

copy a second quality of service field from the first label to the second label; copy a first quality of service field from the reroute label to the first label ;

remove the reroute label;

9. A network element located in a second data network, and adapted to facilitate routing of a received data packet, where the received data packet has been transmitted across a first data network which uses a first data-carrying mechanism to the second data network which uses a second data-carrying mechanism, and the received packet has been adapted for use by the second data network and is associated with at least a first label and a reroute label defining an alternative route around a fault, the network element being configured to:

use the reroute label to determine the alternative route being taken by the packet;

amend the first label to forward the packet to the next network node on the alternative route;

determine a first quality of service field in the reroute route label;

determine a second quality of service field in the first label;

utilise the first and second quality of service fields in combination and apply a resultant quality of service to the packet in relation to forwarding the packet towards the next network node.

10. The network node of any one of claims 7 to 9 wherein the second data network utilises an MPLS data-carrying mechanism, and the data packet has been transmitted from another network utilising an Internet Protocol data-carrying mechanism, and adapted for use by the first data network, such that the first and second quality of service fields correspond to quality of service fields from the Internet Protocol.

1 1 . The network node of any one of claims 7 to 10 wherein the first label is trunk/outer label and the second label is a service/inner label and the reroute label defines the alternative route for the received data packet according to a Fast Re- Route, FRR, mechanism so that the reroute label is an FRR reroute label.

12. A communications system including at least first and second network elements located in a second data network, and adapted to facilitate routing of a received data packet, where the received data packet has been transmitted across a first data network which uses a first data-carrying mechanism to the second data network which uses a second data-carrying mechanism, and the received packet has been adapted for use by the second data network and is associated with first and second labels, such that:

the first network element is configured to: determine that a fault has occurred on a predetermined route applicable to the received data packet;

copy a first quality of service field from an existing first label associated with the packet to the reroute label;

copy a second quality of service field from an existing second label associated with the packet to the existing first label; and the second network element is configured to:

determine that the second network element is the penultimate node on the alternative route around the fault;

copy the second quality of service field from the first label to the second label ;

copy the first quality of service field from the reroute label to the first label ;

remove the reroute label;

13. The communication system of claim 12 further including a third network element configured to:

determine a first quality of service field in the reroute route label;

determine a second quality of service field in the first label;

use the first and second quality of service fields in combination and applying a resultant quality of service to the packet in relation to forwarding the packet towards the next network node.

14. The communication system of claim 12 or 13 wherein the first data network utilises an MPLS data-carrying mechanism, and the data packet has been transmitted from another network utilising an Internet Protocol data-carrying mechanism, and adapted for use by the first data network, such that the first and second quality of service fields correspond to quality of service fields from the Internet Protocol.

15. The communication system of any one of claims 12 to 14 wherein the first label is trunk/outer label and the second label is a service/inner label and the reroute label defines the alternative route for the received data packet according to a Fast Re-Route, FRR, mechanism so that the reroute label is an FRR reroute label.