|
(11) | EP 2 106 068 A1 |
| (12) | EUROPEAN PATENT APPLICATION |
|
|
|
|
||||||||||||||||||||
| (54) | Measuring data source-specific network metrics |
| (57) Methods and systems for determining origin-specific network metrics in respect of
a data network having at least one ingress node, the method comprising: receiving
data items from outside the network; forwarding the data items with headers comprising
fields for carrying origin information relating to the origin of the data item, and
path metric information indicative of a characteristic being monitored; causing the
data items to traverse the network; updating the fields carrying path metric information
as the data items traverse the network; determining the origin information and path
metric information after the data items have traversed the network and deriving in
dependence thereon an origin-specific path metric relating to the characteristic in
respect of the relevant portion of a path across the network; and combining origin-specific
path metrics derived in respect of different data items if they relate to characteristics
in respect of data items having a common origin.
|
Technical Field
[0001] The present invention relates to measuring network metrics. More specifically, aspects of the present invention relate to methods and apparatus for determining origin-specific network metrics related to one or more characteristics such as network congestion, delay, wireless loss, wireless battery life or others, in respect of a data network having at least one ingress node, where the or each ingress node may be receiving and forwarding data from one or more sources outside the data network in question.
Background to the Invention and Prior Art
[0002] Network owners and operators would like to be able to make customers accountable for any problems they cause to their network. One of the biggest problems for most networks is path congestion. When a network is congested then it is not able to provide good service to any of the customers of that network and thus its reputation may suffer. Accountability is generally done on the basis of the volume of traffic passed into the network by a given customer. Mechanisms allowing for collection of network path characteristics such as level of congestion are useful as such information may be used for more accurate accountability purposes. Such characteristics may also give advance notice of potential problems in the network and may enable the network to react to problems before they become too severe.
[0003] We start by presenting some basic concepts to facilitate the understanding of the mechanisms that are presented further on.
Packets
[0004] Data networks usually split the data they carry into small units known as packets. The actual communication between endpoints is controlled by various communication protocols. Each communication protocol required to carry the data across the Internet adds a header that contains the required information to enable the data exchange between the end hosts (usually a source host and a destination host). In the internet, one of the most common types of packet consists of a payload that contains the data generated by an application running at the source, encapsulated by a Transmission Control Protocol (TCP) header which ensures the reliable delivery of the data, encapsulated again by an Internet Protocol (IP) header, which ensures that the data reaches the destination host for which it is aimed. The TCP header includes a unique sequence number (to allow the data to be reconstructed at the destination) and the IP header includes the IP addresses of the source and destination host.
Distributed bandwidth sharing and congestion
[0005] Data traversing the Internet will follow a path between a series of routers, controlled by various routing protocols. If many paths need to use the same router in the network, this router can get congested (packets experience delays whilst using that network path). If sources persisted sending traffic through that router it may become overloaded or even fail. If sources still persist in sending traffic around this bottleneck it could force more routers to fail, and if the phenomenon keeps spreading, that can lead to a congestion collapse for the whole Internet - which occurred regularly in the mid-eighties.
[0006] The solution to that problem has been to ensure that sources take responsibility for the data-rate they send over the Internet by implementing congestion control mechanisms. Sources monitor path characterisation metrics to detect when the path their data is following is getting congested, in which case they react by reducing their throughput - while they usually slowly increase it when there is no sign of the path getting congested.
[0007] The typical path characterisation metrics sources monitor are the average roundtrip time (RTT) for the data path, the variance of the roundtrip time (referred to as jitter), and the level of congestion on the path, which is the primary parameter influencing the data-rate adaptation of a source sending data over a congested path.
[0008] The congestion level can be signalled either implicitly (through congested routers dropping packets) or explicitly (through mechanisms such as explicit congestion notification - see next subsection). Recently the most common option has been implicit signalling. Historically, routers would drop packets when they got completely saturated (which happens when a traffic burst cannot be accommodated in the buffer of the router). This policy is called "Droptail". The problem with this is that it can lead to a phenomenon known as global synchronisation which reduces the overall efficiency of the network. An improvement has been proposed whereby routers monitor the average queue length in their buffer. When this is higher than a given threshold, the router starts to drop packets with a probability which increases with the excess length of the queue over the threshold. This policy is called Random Early Detection (RED). It is widely used in today's internet because it allows sources to react more promptly to incipient congestion. Sources using TCP are able to detect losses because a packet loss causes a gap in the sequence; whenever a source detects a loss, it halves its data-rate, which alleviates the congestion on the router at the bottleneck.
Explicit Congestion Notification
[0009] Explicit Congestion Notification (ECN) [ECN] further improves on RED by using a two-bit ECN field in the IP header to signal congestion. It runs the same algorithm as RED, but instead of dropping a packet, it sets its ECN field to the Congestion Experienced (CE) codepoint. The ECN standard requires the sender to echo any congestion mark signalled in the data; for instance, a TCP receiver sets the Echo Congestion Experienced (ECE) flag in the TCP header, which the TCP source interprets as if the packet has been dropped for the purpose of its rate control. In turn the source will reduce its data-rate and will set Congestion Window Reduced (CWR) in the TCP header of the next packet.
[0010] The four values of the two-bit ECN field are:
- Not-ECT (Not ECN Capable Transport), which signifies that the packet belongs to a flow that doesn't support ECN
- ECT(0) and ECT(1), which signify that the packet belongs to a flow that supports ECN but and that upstream routers haven't had to mark the packet.
- (CE) Congestion Experienced which signals to the receiver that a packet has experienced congestion along its path.
IP tunnels
[0011] In the context of a data network, tunnelling consists of encapsulating one protocol header inside another protocol header. The aim is to improve the network service, for instance in terms of connectivity (it may allow data to get across a network it couldn't get across otherwise) or of security (the data may be encrypted so it cannot be used if it is intercepted).
[0012] A special case of tunnels are IP-in-IP tunnels where the original header is retained intact, and simply encapsulated in another standard IP header, at the entrance of the tunnel. The outer IP header source and destination addresses identify the "endpoints" of the tunnel while the inner header preserves the original source and destination addresses for the packet. As the packet traverses the tunnel, the outer header may be modified as the header of any other packet on the same path. When the packet reaches the other end of the tunnel, decapsulation occurs: the outer header is stripped off, the original header fields are updated if necessary and the packet is forwarded to its originally-intended destination.
re-Feedback
[0013] The re-Feedback proposal [Briscoe05c] provides a mechanism whereby the congestion information that a receiver sends back to a source can be re-inserted into the forward data path, thus allowing nodes along the path to see downstream congestion information as well as upstream information. This allows network providers to trace the source of any congestion and hold appropriate customers to account for this congestion. The proposal also outlines how a similar mechanism could work for other characterisation metrics such as RTT.
Pre-Congestion Notification
[0014] Pre-Congestion Notification (PCN) [PCN] is a mechanism for protecting the quality of service of certain flows within a given region of the network. Flows are only admitted to the network if they won't cause too much congestion. In order to work out if a flow can be admitted, the incipient congestion inside the network is monitored. This allows the ingress node to predict what the edge-to-edge congestion will be for any given flow asking for admission.
Prior Art
[0015] Congestion signalling has been well documented in many forms: whether it is by using an implicit signal (such as RED) or an explicit binary signal (such as ECN). The generic aspects of traffic tunnelling have also been documented in standard documents, for instance "IP Encapsulation within IP" [RFC 2003] for IP-in-IP tunnels. [Briscoe07] reviews best practice for handling binary congestion marking in tunnels, by building on the recommendations available in the ECN and IPsec RFC documents [ECN, IPsec] and in the IETF Internet Draft on "Explicit Congestion Marking in MPLS" [DBT07]. PCN introduces the idea of recording the congestion (or incipient congestion) across a section of a network in order to decide whether to admit a flow. Re-feedback introduces the idea of using downstream congestion information to trace which flows are causing problems within a network.
References
[0016]
[IPsec] S. Kent & K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, Dec 2005
[RFC 2003] C. Perkins, "IP Encapsulation within IP", RFC 2003, Oct 1996.
[0017] None of the techniques outlined above provide a mechanism that allows one to monitor congestion and other metrics over any section (path) of a network without the need for protocol changes or significant equipment changes. The present inventors have realised that such a technique would potentially allow the information to be used for network monitoring, accountability and control purposes.
[0018] Separately from the above prior art, there have been several proposals for end-to-end congestion information to be aggregated across different flows, of which the following further references are considered to be good examples.
Further References
[0019]
[Balakrishnan99] H. Balakrishnan, H. Rahul and S. Seshan, "An Integrated Congestion Management Architecture for Internet Hosts", ACM SIGCOMM, Sep 1999.
[0020] While these proposals may attempt to deal with the congestion control of the aggregate traffic across a network or across the Internet, they only enable determination of path metrics between a single ingress point and a single egress point.
Summary of the Invention
[0021] According to a first aspect of the present invention, there is provided a method of determining an origin-specific network metric in respect of a data network having at least one ingress node, said method comprising:
receiving data items from one or more sources outside said data network via one or more ingress nodes of said data network;
forwarding each of a plurality of said data items from said one or more ingress nodes with one or more headers comprising fields for carrying the following information:
- origin information indicative of either or both of the source from which the data item has been received and the ingress node via which the data item has been received; and
- path metric information indicative of a characteristic required to be monitored as the data item traverses a portion of a path across the data network;
causing each of said data items to traverse a portion of a path across the data network;
updating the fields carrying path metric information in respect of said data items in dependence on said characteristic as the data items traverse the network;
determining in respect of each of a plurality of data items the origin information and the path metric information after the data item has traversed a portion of a path across the data network, and deriving in dependence on said determined path metric information and on said origin information an origin-specific path metric relating to the characteristic in respect of the portion of the path across the data network from the ingress node via which the data item has been received; and
combining origin-specific path metrics derived in respect of a plurality of different data items in the event that said origin-specific path metrics relate to characteristics in respect of data items having origin information indicative of a common origin, whereby to determine an origin-specific network metric.
[0022] The step of forwarding data items with one or more headers may comprise encapsulating the data items with one or more additional headers. This may be done in order to enable the use of tunnelling to enable the data items to traverse the data network, after which the data items may be decapsulated. The one or more additional headers may include a header comprising a field for carrying path congestion information. According to preferred embodiments, this may be a header comprising an Explicit Congestion Notification (ECN) field, for example, but other fields capable of carrying path congestion information may be used. Encapsulation may not be necessary, however, if the data items already have fields capable of carrying the appropriate information, for example.
[0023] The origin information in respect of a particular data item may be indicative of the source from which the data item has been received. Alternatively or additionally, the origin information may be indicative of the ingress node via which the data item has been received.
[0024] According to preferred embodiments, the path metric information in respect of a particular data item may be indicative of a characteristic such as network congestion on the path traversed by the data item. Alternatively or additionally, the path metric information may be indicative of one or more other characteristics related to the path traversed by the data item such as delay, wireless loss, wireless battery life, etc.
[0025] According to preferred embodiments, the data network may have a plurality of egress nodes. In such embodiments, respective egress nodes may perform the determination of origin information and path metric information in respect of data items that have traversed a portion of a path across the data network to said egress nodes. The respective egress nodes may then also perform the derivation of origin-specific path metrics relating to the characteristic in respect of portions of paths across the data network thereto.
[0026] The method may further comprise providing the origin-specific path metrics to a network control means, which may then perform the step of combining the origin-specific path metrics. This may be performed in respect of origin-specific path metrics derived by a plurality of different egress nodes, for example. Such a network control means may then provide origin-specific network metrics to the one or more ingress nodes via which the data items to which they relate have been received.
[0027] Alternatively or additionally, the method may further comprise providing the origin-specific path metrics to one or more ingress nodes via which the data items to which they relate have been received. The ingress nodes may then perform the step of combining the origin-specific path metrics.
[0028] The method may further comprise forwarding the data items on to one or more destinations outside the network, or to one or more destination networks.
[0029] According to a second aspect of the present invention, there is provided an apparatus for determining an origin-specific network metric in respect of a data network, said apparatus comprising:
one or more ingress nodes for receiving data items from one or more sources outside said data network into said data network, said one or more ingress nodes comprising forwarding means for forwarding each of a plurality of said data items from said one or more ingress nodes with one or more headers comprising fields for carrying the following information:
- origin information indicative of either or both of the source from which the data item has been received and the ingress node via which the data item has been received; and
- path metric information indicative of a characteristic required to be monitored as the data item traverses a portion of a path across the data network;
routing means arranged to cause each of said data items to traverse a portion of a path across the data network;
updating means arranged to update the fields carrying path metric information in respect of said data items in dependence on said characteristic as the data items traverse the network;
path metric deriving means arranged to determine in respect of each of a plurality of data items the origin information and the path metric information after the data item has traversed a portion of a path across the data network, and to derive in dependence on said determined path metric information and on said origin information an origin-specific path metric relating to the characteristic in respect of the portion of the path across the data network from the ingress node via which the data item has been received; and
network metric determining means arranged to combine origin-specific path metrics derived in respect of a plurality of different data items in the event that said origin-specific path metrics relate to characteristics in respect of data items having origin information indicative of a common origin, whereby to determine an origin-specific network metric.
[0030] It will be understood that options and variations listed above in relation to the first aspect are equally applicable in relation to the second aspect.
[0031] Preferred embodiments of the present invention enable determination of a metric for an aggregate of traffic with a common origin, irrespective of the intended destinations of individual flows. It wouldn't be possible to use the mechanisms proposed in the references listed in the previous section relating to aggregation of end-to-end congestion information in this way because the information they provide is only partial, and is simply applicable for (and generally used for) improving the rate control in respect of the aggregate.
[0032] Superficially, preferred embodiments may appear to be related to PCN, however there are a number of clear differences. PCN is designed to admit traffic to a controlled region of a network. As such it measures edge-to-edge metrics such as incipient congestion between ingress and egress pairs. This information is used to decide whether there is sufficient remaining capacity to admit a given new flow. By contrast preferred embodiments may measure a path metric such as the actual congestion level (as given by ECN, for example) across a given section of the network. This information can then be used by the network owner for accounting and planning purposes.
[0033] In contrast with preferred embodiments, the PCN framework doesn't allow monitoring of a network metric for an aggregate defined by its origin: the congestion metrics it monitors also require the definition of an egress point.
[0034] Preferred embodiments may also appear to have similarities with re-feedback. However re-feedback requires both upstream and downstream congestion information to be carried on each packet whereas preferred embodiments require only the upstream information.
[0035] Preferred embodiments may utilise a technique corresponding to IP tunnelling but an adaptation of this is used in order to allow the measurement of path metrics that couldn't have been measured otherwise.
Brief Description of the Drawings
[0036] A preferred embodiment of the present invention will now be described with reference to the appended drawings, in which:
Figure 1 shows a schematic diagram of an example network and illustrates how the origin of data items may be defined with respect to their source address in a given address space;
Figure 2 shows a schematic diagram of an example network and illustrates how the origin of data items may be defined with respect to the border router via which they enter a network;
Figure 3 shows an end-to-end path which passes through a network in relation to which a method according to a preferred embodiment of the invention is performed;
Figures 4(a) and 4(b) illustrate the tunnelling mechanism..
Description of Preferred Embodiments of the Invention
[0037] Preferred embodiments of the present invention provide methods for determining a metric for an aggregate of traffic defined by its common origin.
[0038] With reference to Figures 1 to 4, a method of determining a network metric according to a preferred embodiment will be described.
[0039] The description of this embodiment focuses in particular on one type of metric: the contribution to local congestion, referred to as "k", of a specific aggregate of traffic, defined by its origin. The value of the metric at a node is obtained in the same way as standard congestion: the level of congestion an aggregate of traffic experiences while transiting across a network is the same as its contribution to congestion in that network.
[0040] Other metrics could be monitored in the same or similar ways, such as interference levels in the case of ad hoc wireless networks, or power consumption to apportion the environmental impact of the traffic generated. Embodiments of the invention will be described in the context of contribution to congestion, but it will be understood that the invention is not intended to be limited to congestion metrics; other embodiments may relate to the determination of metrics relation to other types of metric including, but not limited to, those referred to above.
[0041] With reference to Figures 1 and 2, the defining "origin" of data items can be characterised in different ways. Two possible definitions of the origin are of particular interest:
- (i) Traffic coming from a source address belonging to a given address space, for instance a set of IP prefixes; and
- (ii) Traffic entering a network through a given border gateway.
[0042] In the first case, the information may be useful for monitoring potential Denial of Service activity. In the second case, the information may be useful for network operators: the theory of networks economics presents congestion signals as a means to detect network links whose capacity may be worth upgrading. These two definitions of the "origin" for the aggregate lead to two different types of network context, in respect of which methods according to different embodiments may be performed. The network contexts for each of these definitions are illustrated in Figures 1 and 2, as described below. In each of these, the network in respect of which the metric-determining method is to be performed is Network B (indicated by reference numeral 10B).
[0043] Figure 1 illustrates a possible network configuration in relation to which the "origin" of traffic is most usefully defined based on the source address, which is generally outside the network 10B in respect of which the metric-determining method is to be performed. Data items having source addresses belonging to the same address space may be treated as having a "common origin". In that case, Network A (indicated by reference numeral 10A) is referred to as being "multi-homed". Not all traffic originating from Network A and transiting through Network B has to follow the same path between the two: traffic intended to reach a destination in Network D (10D) may transit through Network E (10E), while traffic intended to reach a destination in Network C (10C) may transit through Network F (10F). This may be achieved based on routing tables of Network A.
[0044] Figure 2 illustrates a possible network configuration in relation to which the "origin" of traffic is most usefully defined based on the ingress point through which the traffic enters the network 10B in respect of which the metric-determining method is to be performed. In that case flows may be said to belong to the same aggregate if they enter Network B through the same Border Router R3, even though the respective sources and destinations of the traffic may be completely different.
[0045] It will be noted that in both Figures 1 and 2, traffic is shown crossing Network B (10B) by means of tunnels T1 and T2. These tunnels have been shown for the purposes of facilitating an understanding of certain preferred embodiments of the invention, in which tunnels are used in order to allow the measurement of path metrics that couldn't have been measured otherwise, for example, but it should be noted that the invention is not intended to be limited to embodiments which make use of tunnelling - other preferred embodiments will be described in which data items traverse the network in question without the use of tunnelling.
[0046] An embodiment will principally be described in relation to a case where the origin of the aggregate is defined as a common ingress point to the local network 10B. Adjustments which may be required for embodiments when the origin is defined as the source address space will be outlined briefly later.
[0047] Incoming traffic onto the local network 10B is processed by the ingress gateway (Border Router R3), which ensures that certain required information fields are available in packet headers, namely:
- a field for capturing local congestion
- a field for capturing the origin of the traffic: in this case, the identity of the ingress
[0048] If Internet Protocol version 6 (IPv6) options can be used efficiently (we are not considering the use of IPv4 options as they are not used commonly), a hop-by-hop extension header may be used that includes a congestion level field, and a field for the identity of the ingress point of the traffic. The congestion level in the extension header may then be updated by every node a packet traverses, so that it reflects the contribution to congestion of that packet along the path it has followed across the network. The egress gateway can then retrieve the identity of the ingress point from the extension header. This technique is described below with reference to Figure 3.
[0049] Figure 3 again illustrates the situation where common origin is defined as common ingress point, in the more specific situation where an extension header is used. When packets from a source S1 arrive at an ingress router R3 of the network 10B (which, as before, is the network in respect of which the metric-determining method according to a preferred embodiment is to be performed), a hop-by-hop extension header is added to the packet. The extension header includes a field indicating the origin of the traffic, which remains unchanged, and a field indicating the value of the contribution to congestion within the network 10B. This congestion field may be updated by every node or router R in the local network. Packets may then be forwarded towards the appropriate destination (D1, D2, etc.) via an appropriate egress point (two possible egress points, R1 and R2, are shown in figure 3).
[0050] Each egress point (R1, R2) keeps a table with an entry for each of the aggregates that are monitored. Each entry consists of:
- a description of the origin of the aggregate: either the identity of the ingress point, or the source address space;
- a timestamp indicating the time of start of the validity period;
- a value for the metrics being monitored; and
- a value for the volume of traffic for that aggregate.
[0051] When the packet arrives at the relevant egress point, the origin field is read to identify which entry or entries need updating. For each of those the relevant metrics are updated and the volume of traffic is also updated. The packet is then forwarded to its destination.
[0052] The combination of the partial metrics held by the egress nodes can happen either in "push" mode or in "pull" mode. In push mode, the egresses report periodically to the entities (for instant a network Control Centre C of the network 10B in question) that require the monitored metrics. In pull mode, these entities prompt the egress routers for that information.
[0053] An alternative to the technique described above will now be described with reference to Figures 4(a) and 4(b), which illustrate together the tunnelling mechanism referred to earlier. By virtue of this, a tunnel 42 can be set up from a router or node via which packets from source S1 enter the network 10B in question. This then serves as the tunnel ingress gateway 40 for packets being forwarded towards a tunnel egress gateway 44 on the path to the destination D1 of the traffic. Incoming packets are encapsulated at tunnel ingress gateway 40. With reference to Figure 4(b), the encapsulation may be used to ensure that the packets carry an ECN field in their outer header for example, in which case tunnel 42 may be regarded as an ECN capable tunnel. The congestion field (ECN or otherwise) of the outer header of these packets may be updated along the path by other routers R in network 10B, such that the value of its signal at the end of the path through tunnel 42 represents the contribution to congestion of that packet along the path it has followed across network 10B. The IP address of ingress gateway 40 is used as the source IP address in the outer header, which allows egress gateway 44 to identify to which aggregate each packet belongs.
[0054] In both cases (the IP option outlined with reference to Figure 3, and the tunnelling option outlined with reference to Figures 4(a) and 4(b)), the egress gateway (R1 or 44) may follow the same steps when packets reach it, as set out below:
- 1. It identifies to which aggregate the packet belongs
- 2. It retrieves the congestion information
- 3. It updates the congestion information for that aggregate
- 4. It strips off the outer header or the extension header
- 5. It updates the congestion field of the packet to reflect the congestion experienced across the local network
- 6. It forwards the packet as required to reach its destination.
[0055] As an example, the egress point may keep the following information for each aggregate:
- the identity of the aggregate (as defined by the ingress point, in that case)
- the volume of traffic to date Vegress
- the contribution to congestion to date kegress
- the time of the last packet forwarded
- the time of the first packet forwarded.
[0056] Egress points may keep records for smaller aggregates, for instance the aggregate transiting from a given ingress point, in which case they may also update the congestion estimate for that section of the path.
[0057] Computing the metric for the aggregate may involve a Control Centre (C in Figure 3) to retrieve the information from all the egress gateways. As before, this can be done in "push" mode where egresses report to the control centre on a periodic basis, or in "pull" mode, where the control centre prompts the egress nodes for updates, which can be done over a multicast channel for instance.
[0058] Different aggregates may be monitored by different control centres. It is possible for instance for the control centre for the aggregate of traffic incoming through a given ingress point to be located on that ingress point.
[0059] On receiving records from the egress points, the control centre will update its own record for the aggregate, which may contain the following information
- the identity of the aggregate (as defined by the ingress point, in that case)
- the volume of traffic to date Vaggr
- the contribution to congestion to date kaggr
- the time of the last packet forwarded
- the time of the first packet forwarded.
[0061] The control centre may keep individual records from egresses to monitor the evolution of the contribution to congestion.
[0062] When the definition of an aggregate is given with respect to the address space of the source IP address, the aggregate to which the packet belongs may be determined from the packet header in all cases. This may simplify the embodiment in the case when IPv6 options are used - in that case, the extension header may still be needed to ensure the contribution to congestion in the local network only is duly captured.
receiving data items from one or more sources outside said data network via one or more ingress nodes of said data network;
forwarding each of a plurality of said data items from said one or more ingress nodes with one or more headers comprising fields for carrying the following information:
- origin information indicative of either or both of the source from which the data item has been received and the ingress node via which the data item has been received; and
- path metric information indicative of a characteristic required to be monitored as the data item traverses a portion of a path across the data network;
causing each of said data items to traverse a portion of a path across the data network;
updating the fields carrying path metric information in respect of said data items in dependence on said characteristic as the data items traverse the network;
determining in respect of each of a plurality of data items the origin information and the path metric information after the data item has traversed a portion of a path across the data network, and deriving in dependence on said determined path metric information and on said origin information an origin-specific path metric relating to the characteristic in respect of the portion of the path across the data network from the ingress node via which the data item has been received; and
combining origin-specific path metrics derived in respect of a plurality of different data items in the event that said origin-specific path metrics relate to characteristics in respect of data items having origin information indicative of a common origin, whereby to determine an origin-specific network metric.
one or more ingress nodes for receiving data items from one or more sources outside said data network into said data network, said one or more ingress nodes comprising forwarding means for forwarding each of a plurality of said data items from said one or more ingress nodes with one or more headers comprising fields for carrying the following information:
- origin information indicative of either or both of the source from which the data item has been received and the ingress node via which the data item has been received; and
- path metric information indicative of a characteristic required to be monitored as the data item traverses a portion of a path across the data network;
routing means arranged to cause each of said data items to traverse a portion of a path across the data network;
updating means arranged to update the fields carrying path metric information in respect of said data items in dependence on said characteristic as the data items traverse the network;
path metric deriving means arranged to determine in respect of each of a plurality of data items the origin information and the path metric information after the data item has traversed a portion of a path across the data network, and to derive in dependence on said determined path metric information and on said origin information an origin-specific path metric relating to the characteristic in respect of the portion of the path across the data network from the ingress node via which the data item has been received; and
network metric determining means arranged to combine origin-specific path metrics derived in respect of a plurality of different data items in the event that said origin-specific path metrics relate to characteristics in respect of data items having origin information indicative of a common origin, whereby to determine an origin-specific network metric.
REFERENCES CITED IN THE DESCRIPTION
This list of references cited by the applicant is for the reader's convenience only. It does not form part of the European patent document. Even though great care has been taken in compiling the references, errors or omissions cannot be excluded and the EPO disclaims all liability in this regard.
Non-patent literature cited in the description
- S. KentK. SeoSecurity Architecture for the Internet ProtocolRFC 4301, 2005, [0016]
- B. BriscoeA. JacquetC. Di Cairano-GilfedderA. SalvatoriA. SopperaM. KoyabePolicing Congestion Response in an Internetwork using Re-feedbackProc ACM SIGCOMM'05, Computer Communications Review, 2005, vol. 35, 4 [0016]
- K. RamakrishnanS. FloydD. BlackThe Addition of Explicit Congestion Notification (ECN) to IPRFC 3168, 2001, [0016]
- S. FloydV. JacobsonRandom Early Detection gateways for Congestion AvoidanceIEEE/ACM Transactions on Networking, 1993, vol. 1-4, 397-413 [0016]
- Pre-Congestion Notification ArchitectureIETF internet draft draft-ietf-pcn-architecture20071102 [0016]
- C. PerkinsIP Encapsulation within IPRFC, 1996, [0016]
- Bob Briscoe (BT)Layered Encapsulation of Congestion NotificationIETF I-D, 2007, [0016]
- B. DavieB. BriscoeJ. TayExplicit Congestion Marking in MPLSIETF I-D, 2007, [0016]
- F-C KuoX FuProbe-Aided MulTCP: an aggregate congestion control mechanismACM SIGCOMM Computer Communication Review, 2008, vol. 38, 1 [0019]
- H. BalakrishnanH. RahulS. SeshanAn Integrated Congestion Management Architecture for Internet HostsACM SIGCOMM, 1999, [0019]
- D. OttT. SparksK. Mayer-PatelAggregate congestion control for distributed multimedia applicationsIEEE INFOCOM, 2004, [0019]
- M. SinghP. PradhanP. FrancisMPAT: aggregate TCP congestion management as a building block for Internet QoSIEEE International Conference on Network Protocols, 2004, 129-138 [0019]