Probing Specific Customer Flow in Layer-2 Multipath Networks

TECHNICAL FIELD

p-0002The present disclosure relates to network performance analysis of multipath networks.

BACKGROUND

p-0003Network monitoring tools have been in use to monitor the performance of a network, e.g., wired networks. For example, one such network monitoring tool, known as “Ping”, works over layer-3 devices.

p-0004Existing network monitoring tools for layer-2 protocols, such as Ethernet, are configured to operate when there is a single distinct forwarding path between any two nodes. There are other networking environments that have multiple possible paths between a source node and a destination node. Monitoring the performance of a multipath network has additional challenges since there are a plurality of paths that can be taken between a source node and a destination node.

BRIEF DESCRIPTION OF THE DRAWINGS

p-0005<figref idrefs="DRAWINGS">FIG. 1</figref> is an example of a block diagram of a multipath network environment where a source router bridge (switch) is configured to generate probe packets from user flow parameters to test for connectivity to a destination router bridge (switch).

p-0006<figref idrefs="DRAWINGS">FIG. 2</figref> is an example of a block diagram of a switch configured to generate probe packets from user flow parameters according to the techniques described herein.

p-0007<figref idrefs="DRAWINGS">FIG. 3</figref> is a diagram depicting an example of a format of user flow packets from which user flow parameters are derived and used in the probe packets.

p-0008<figref idrefs="DRAWINGS">FIG. 4</figref> is an example of a flow chart for a probe packet generation and connectivity test process performed in a switch to generate probe packets from user flow parameters and to test connectivity to a destination switch in a multipath network environment.

p-0009<figref idrefs="DRAWINGS">FIG. 5</figref> is a diagram depicting the generation of probe packets from user flow packets at a switch.

p-0010<figref idrefs="DRAWINGS">FIG. 6</figref> is an example of a diagram illustrating the transmission of probe packets with the user flow parameters from the source switch to the destination switch.

DESCRIPTION OF EXAMPLE EMBODIMENTS

p-0011Overview

p-0012Techniques are provided herein to enable a switch in a layer-2 multipath network to determine connectivity of a path to a destination switch. At a source switch, user flow parameters are determined for user flow packets to be transported in the layer-2 multipath network to a destination switch. The sourced switch determines a number of hops from it to the destination switch based on the user flow parameters. Timestamping is activated for time-to-live expiry packets received at the source switch and for time-to-live expiry packets received at the destination switch. One or more probe packets having user flow parameters matching the user flow parameters of user flow packets are generated so that the probe packets use the same path taken by the user flow packets between the source switch and the destination switch. In addition, a time-to-live value corresponding to the number of hops from the source switch to the destination switch is included in a hop count field of the one or more probe packets. The time-to-live value distinguishes the one or more probe packets from user flow packets. The one or more probe packets are sent in the layer-2 multipath network from the source switch to the destination switch. Connectivity between the source switch and the destination switch is determined based on the one or more probe packets.

Example Embodiments

p-0013Referring first to <figref idrefs="DRAWINGS">FIG. 1</figref>, an example of a multipath network is shown at reference numeral <b>10</b>. The network <b>10</b> is, for example, a Data Center Ethernet (DCE) network or a network that employs the Transparent Interconnect of Lots of Links (TRILL) protocol. The TRILL protocol is an Internet Engineering Task Force (IETF) Protocol implemented by devices called router bridges. To this end, there are router bridges <b>20</b>(<b>1</b>)-<b>20</b>(<b>6</b>) in the simplified example network topology shown in <figref idrefs="DRAWINGS">FIG. 1</figref>. The router bridges <b>20</b>(<b>1</b>)-<b>20</b>(<b>6</b>) are also referred to herein as switches. Also in this example, there is an end station A at <b>30</b>(<b>1</b>) that is a source device of user flow packets to be sent to an end station B at <b>30</b>(<b>2</b>) that is the destination device for the user flow packets. Router bridge <b>20</b>(<b>1</b>) is the edge switch that is coupled to end station <b>30</b>(<b>1</b>) and router bridge <b>20</b>(<b>2</b>) is the edge switch that is coupled to end station <b>30</b>(<b>2</b>). Thus, router bridge <b>20</b>(<b>1</b>) serves as the source switch for a user flow and router bridge <b>20</b>(<b>2</b>) serves as a destination switch for the user flow from router bridge <b>20</b>(<b>1</b>). There are multiple paths in the network <b>10</b> between router bridge <b>20</b>(<b>1</b>) and <b>20</b>(<b>2</b>) as is readily apparent from <figref idrefs="DRAWINGS">FIG. 1</figref>. It should be understood that a real-world multipath network would have a much larger number of router bridges than those shown in <figref idrefs="DRAWINGS">FIG. 1</figref>. The number of router bridges shown in <figref idrefs="DRAWINGS">FIG. 1</figref> is only by way of a simplified example for purposes of this disclosure.

p-0014Currently available network monitoring tools for layer-2 protocols such as Ethernet rely on algorithms such as the Spanning Tree Protocol (STP) to ensure the existence of only a single distinct forwarding path between any two nodes. However, since STP does not guarantee efficient utilization of all links available in the network, variants of IP protocols such as Intermediate System-Intermediate System (IS-IS) have been proposed to find multiple Equal Cost Multiple Paths (ECMPs) between any two nodes in DCE networks.

p-0015The TRILL protocol combines the advantages of bridges and routers and applies link state routing to virtual local area network (VLAN)-aware customer-bridges. Router bridges are compatible with existing IEEE 802.1 customer bridges as well as with IPv4 and IPv6 routers and end nodes. They are invisible to current IP routers and, like routers, router bridges terminate the bridge spanning tree protocol. TRILL capable devices (router bridges) run a link state protocol among each other to broadcast to all the router bridges, so that each router bridge knows about all the other router bridges, and the connectivity between them. Thus, router bridges have sufficient information to compute pair-wise optimal paths for unicast, and to calculate distribution trees for delivery of frames either to destinations whose location is unknown or to multicast/broadcast groups.

p-0016The link state routing protocol used in the TRILL protocol is IS-IS. IS-IS runs directly over layer-2, and therefore can run without the need to assign or configure IP addresses. Router bridges forward packets based on a header with a hop count. Router bridges also specify the next hop router bridge as the frame destination when forwarding unicast frames across a shared-media link. This prevents creation of additional copies of frames during a temporary loop. A Reverse Path Forwarding Check and other checks are performed on multi-destination frames to further control potentially looping traffic.

p-0017The router bridges shown in <figref idrefs="DRAWINGS">FIG. 1</figref> are hardware (or software) configured to perform hashing computations on user flow data packets from a source to a destination to send the user flow packets on a specific one of a plurality of possible paths between the source and destination. A user flow is defined based on parameters in the data packet headers as described hereinafter. Thus, the particular path taken by the user flow packets will depend on parameters in the user flow data packet headers. Each of the switches shown in <figref idrefs="DRAWINGS">FIG. 1</figref>, for example switches <b>20</b>(<b>1</b>) and <b>20</b>(<b>2</b>), are configured to generate probe packets that have the same parameters of the user flow packets that are used to hash the path taken by the user flow parameters so that the probe packets follow the same path from the source switch to the destination switch as the user flow parameters. Consequently, a true measure of the network connectivity for a given user flow between a source switch and a destination switch can be determined from the probe packets.

p-0018For example, as shown in <figref idrefs="DRAWINGS">FIG. 1</figref>, end station <b>30</b>(<b>1</b>) has data to send to end station <b>30</b>(<b>2</b>). The user flow from end station <b>30</b>(<b>1</b>) goes to switch <b>20</b>(<b>1</b>). Based on certain parameters contained in the headers of the user flow data packets, the user flow data packets takes the path from switch <b>20</b>(<b>1</b>) to switch <b>20</b>(<b>4</b>) and then to switch <b>20</b>(<b>2</b>) as shown by the dotted line in <figref idrefs="DRAWINGS">FIG. 1</figref>. The probe packets that switch <b>20</b>(<b>1</b>) generates, according to the techniques described herein, also will take that same path via switch <b>20</b>(<b>4</b>) to switch <b>20</b>(<b>2</b>) so that switch <b>20</b>(<b>1</b>) can measure the connectivity of that path from the probe packets.

p-0019Turning now to <figref idrefs="DRAWINGS">FIG. 2</figref>, an example of a block diagram of a switch that is configured to generate probe packets is now described. The diagram of <figref idrefs="DRAWINGS">FIG. 2</figref> is representative of the general structure of any of the switches (router bridges) <b>20</b>(<b>1</b>)-<b>20</b>(<b>6</b>) shown in <figref idrefs="DRAWINGS">FIG. 1</figref>. Each switch comprises routing circuitry <b>22</b>, a network interface device <b>23</b> (e.g., Ethernet line card), a processor <b>24</b>, a clock synchronization unit <b>26</b> and memory <b>28</b>. The routing circuitry <b>22</b> is, in some examples, implemented by digital logic gates and related circuitry in an application specific integrated circuit (ASIC), and is configured to route packets through a network using a variety of protocols, such as the TRILL protocol referred to above. The network interface device <b>23</b> sends packets from the switch to the network and receives packets from the network that are sent to the switch. The processor <b>24</b> is, for example, a microprocessor, microcontroller, digital signal processor or other similar data processor configured for embedded applications in a switch.

p-0020The clock synchronization unit <b>26</b> is a device that is configured to timestamp packets that are sent and received by the switch. For example, the clock synchronization unit <b>26</b> is configured to operate in compliance with the IEEE 1588 standard for synchronizing clocks of devices across a network.

p-0021The memory <b>28</b> may comprise read only memory (ROM), random access memory (RAM), magnetic disk storage media devices, optical storage media devices, flash memory devices, electrical, optical, acoustical or other physical/tangible memory storage devices. The memory <b>28</b> stores executable software instructions for probe packet generation and connectivity test process logic <b>100</b>. Thus, the memory <b>28</b> may comprise one or more computer readable storage media encoded with software comprising computer executable instructions and when the software is executed operable to perform the operations described herein for the process logic <b>100</b>. The processor <b>22</b> executes the process logic <b>100</b> in order to generate and send probe packets and to test connectivity between a source switch (the switch that sends the probe packets) and a destination switch in a multipath network, such as the network <b>10</b> shown in <figref idrefs="DRAWINGS">FIG. 1</figref>.

p-0022Reference is now made to <figref idrefs="DRAWINGS">FIG. 3</figref> that shows headers of user flow data packets that are to be routed through a multipath network such as the one shown in <figref idrefs="DRAWINGS">FIG. 1</figref> and described herein. In networks that use DCE or TRILL routing protocols, packet forwarding is based on the outer switch address in the hierarchical media access control (MAC)-in-MAC header of the user flow data packets. <figref idrefs="DRAWINGS">FIG. 3</figref> shows a structure of a packet <b>35</b> that is configured for routing using DCE or TRILL routing protocols. The packet <b>35</b> comprises an outer Ethernet header <b>40</b>, a TRILL/DCE header <b>50</b>, an inner Ethernet header <b>60</b> and a payload <b>70</b>. The outer Ethernet header <b>40</b> is the aforementioned MAC-in-MAC header and comprises an outer destination MAC address (ODA) <b>42</b> for the destination switch and an outer source MAC address (OSA) <b>44</b> for the source switch. There is also a field <b>46</b> for the Ethertype and a field <b>48</b> for outer virtual local area network (VLAN) tag information. The Ethertype field is a two-octet field in an Ethernet frame, and is used to indicate which protocol is encapsulated in the payload of the Ethernet Frame, such as Internet Protocol, IEEE 801.1Q VLAN-tagged, and any of a number of protocols that can be encapsulated in an Ethernet frame. IEEE 802.1Q, or VLAN Tagging, is a networking standard promulgated by the IEEE 802.1 work group for the sharing of a physical Ethernet network link by multiple independent logical networks. IEEE 802.1Q defines a VLAN with respect to the bridging at the MAC layer and to the IEEE 802.1D spanning tree protocol. Thus, the IEEE 802.1Q protocol allows individual VLANs to communicate with one another through a network switch with Network layer (layer-3) capabilities, or a router. The outer VLAN tag information field <b>48</b> comprises bits that are used to identify the VLAN to which the frame belongs.

p-0023The first router bridge that a unicast frame encounters in a campus, e.g., router bridge <b>20</b>(<b>1</b>), encapsulates the received frame with a TRILL header that specifies the last router bridge in the campus, e.g., router bridge <b>20</b>(<b>2</b>), where the frame is decapsulated. Router bridge <b>20</b>(<b>1</b>) is referred to as the “ingress router bridge” and router bridge <b>20</b>(<b>2</b>) is referred as the “egress router bridge”. To save room in the TRILL header and simplify forwarding lookups, a dynamic nickname acquisition protocol is run among the router bridges to select 2-octet nicknames for router bridges, unique within the campus, which are an abbreviation for the 6-octet IS-IS system identifier of the router bridge. The 2-octet nicknames are used to specify the ingress and egress router bridges in the TRILL header. The details of the packet headers are described further hereinafter in connection with <figref idrefs="DRAWINGS">FIG. 3</figref>.

p-0024The TRILL header <b>50</b> consists of 6 octets. The first 2 octets include a 6-bit decrementing hop count, plus flags, the next 2 octets contain the egress router bridge nickname, and the final 2 octets contain the ingress router bridge nickname. For multi-destination frames, the “egress router bridge nickname” specifies a distribution tree for the frame, where the nicknamed router bridge is the root of the distribution tree. The ingress router bridge selects which distribution tree the frame should travel along.

p-0025Although router bridges are transparent to layer-3 devices, and all the links interconnected by router bridges appear to layer-3 devices to be a single link, router bridges act as link routers in the sense that, in the forwarding of a frame by a transit router bridge, the outer layer-2 header is replaced at each hop with an appropriate layer-2 header for the next hop, and the hop count is decreased. Despite these modifications of the outer layer-2 header and the hop count in the TRILL Header <b>50</b>, the original encapsulated frame is preserved, including the original frame's VLAN tag.

p-0026More specifically, as shown in <figref idrefs="DRAWINGS">FIG. 3</figref>, the TRILL/DCE header <b>50</b> comprises an Ethertype field <b>52</b>, a Version (V) field <b>53</b>, a Reserved (R) field, a Multi-destination (M) field <b>55</b>, an Options Length (op-length) field <b>56</b>, a hop count field <b>57</b>, an egress nickname field <b>58</b> and an ingress nickname field <b>59</b>. The Ethertype field <b>52</b> is similar to the Ethertype field <b>46</b> in the outer header <b>40</b>. It indicates TRILL or DCE for TRILL or DCE based routing. The V field <b>53</b> is used to track compatibility with different versions of a protocol. The R field <b>54</b> is a reserved field for future extensions to a protocol. The M field <b>55</b> is a field to indicate that the frame is to be delivered to a class of destination end stations via a distribution tree that the egress router bridge nickname field specifies. The op-length field <b>56</b> is a field allocated to express in the header <b>50</b> that a frame is using an optional capability and to encode information into the header for that capability. The hop count field <b>57</b> is a field to store a hop count value. In accordance with the techniques described herein, the hop count field <b>57</b> will be used to store a particular value depending on the number of hops determined to be present on the user flow path from the source switch to the destination switch. This is described further hereinafter. The egress and ingress nickname fields <b>58</b> and <b>59</b> are dynamically assigned quantities that act as abbreviations for router bridges' IS-IS identifiers to achieve a more compact encoding and to potentially specify different trees with the same route.

p-0027The inner Ethernet header <b>60</b> comprises an inner destination MAC address (IDA) field <b>62</b>, an inner source MAC field <b>64</b>, an Ethertype field <b>66</b> and an inner VLAN tag information field <b>68</b>. The Ethertype field <b>66</b> and an inner VLAN tag information field <b>68</b> are similar to fields <b>46</b> and <b>48</b> in the outer header <b>40</b>.

p-0028There is an inner field for a layer-3 (L3) header shown at <b>70</b> and for a layer-4 (L4) header shown at <b>72</b>. The L3 header <b>70</b> includes inner source and destination IP addresses and the L4 header <b>72</b> includes information identifying source and destination Universal Datagram/Transport Control Protocol (UDP)/TCP ports.

p-0029As explained above, when a packet is routed in a multipath network that uses the DCE or TRILL protocol, the packet is forwarded along a particular path based on parameters obtained from the headers of the packet. For example, an ECMP hash computation to determine a path depends on the inner source MAC address and inner destination MAC address (the values of fields <b>62</b> and <b>64</b> shown in <figref idrefs="DRAWINGS">FIG. 3</figref>), the Ethertype field <b>66</b> for layer-2 packets or the inner IP address of field <b>70</b> and UDP/TCP ports of field <b>72</b> for layer-3/layer-4 packets. It is desired to test connectivity between a source switch and destination switch using the same user flow parameters (MAC addresses, IP addresses, Ethertype, UDP/TCP ports) that are used in the hash computation for the user flow data packets. Thus, the probe packets will have the same values for the user flow parameters (MAC addresses, IP addresses, Ethertype, UDP/TCP ports) as those contain in a given user flow so that the probe packets, when a hash computation is performed on them to determine the path to the destination switch, follow the same path as the user flow packets.

p-0030In addition, the probe packets used for testing connectivity need to be distinguishable from the user flow data packets. In accordance with one example, the probe packets are distinguished from the user flow data packets by setting the value of the hop count field <b>57</b> to a time-to-live value equal to the number of hops determined between the source switch and the destination switch, as described further hereinafter.

p-0031Reference is now made to <figref idrefs="DRAWINGS">FIG. 4</figref> for a description of a flow chart depicting operations of the process logic <b>100</b> performed by a switch, acting as source switch with respect to a user flow to be sent to a destination switch. At <b>110</b>, at a switch configured for communication in a layer-2 multipath network, user flow parameters are determined for user flow packets being served by the switch as a source switch (e.g., switch <b>20</b>(<b>1</b>) in the example of <figref idrefs="DRAWINGS">FIG. 1</figref>) for transport in the layer-2 multipath network to a destination switch (e.g., switch <b>20</b>(<b>2</b>) in the example of <figref idrefs="DRAWINGS">FIG. 1</figref>). Operation <b>110</b> thus involves reading the content of certain fields in the headers of a packet as described above in connection with <figref idrefs="DRAWINGS">FIG. 3</figref>, i.e., those parameters used in a hashing computation to determine path routing in the layer-2 multipath network between a source switch and a destination switch. For example, operation <b>110</b> involves determining from user flow packets a MAC address of the source switch, a MAC address of the destination switch, Ethertype and Universal Data Program or Transport Control Protocol ports from a hierarchical MAC-in-MAC header of the user flow packets from which ECMP hash computations are made to determine a path in the layer-2 multipath network from the source switch to the destination switch.

p-0032At <b>120</b>, the source switch determines the number of hops from it to the destination switch for the user flow based on the user flow parameters. There are several ways to determine the number of hops from the source switch to the destination switch. One technique is to employ any of the DCE/TRILL routing protocols, such as the IS-IS protocol, that is running in order to provide multipath route computation functionality. These protocols can also find the number of hops to a given switch because all path information is available locally. Thus, the number of hops may be determined by obtaining path information stored at the source switch (or any other switch in the network) that was obtained (e.g., by the source switch) using one or more protocols that determine the number of hops between two switches in the multipath network, i.e., between the source switch and the destination switch. If this information is not available at the local switch, e.g., source switch, and a best path computation is not based on a minimum number of hops to a destination switch, then a layer-2 traceroute can be employed.

p-0033For a layer-2 traceroute, a test packet using the same flow parameters as the user flow is sent with a TTL value equal to 1. When the TTL expires, an error message is received at the source device based on the test packet. The TTL value for test packets is incremented until the destination switch receives the test packet. Thus, according to this technique, the number of node hops is determined by sending test packets (configured with the user flow parameters so that they follow the same path as the user flow packets) with increasing TTL values until a test packet is received at the destination switch. The smallest TTL value of a test packet that is received at the destination packet is equal to the number of hops from the source switch to the destination switch.

p-0034The number of hops (hop count) between the source switch and destination switch, determined at operation <b>120</b> is included as a TTL value in hop count field <b>57</b> (<figref idrefs="DRAWINGS">FIG. 3</figref>) of probe packets (to be generated as described herein) so as to distinguish the probe backs from user flow data packets. DCE as well as TRILL packets carry a TTL value in the outer header <b>50</b>. Normally, this TTL value is decremented at each layer-2 hop and the packet is discarded or redirected to a supervisor for further error handling, if the TTL reaches a value of 1. When a switch receives a packet with a TTL value of 1 or 0 (zero), the switch should send back a TTL expiry error message to the originating switch (to the switch corresponding to the outer source MAC address in the case of DCE or to the ingress bridge in the case of TRILL). Even if IS-IS or other protocols are employed such that there are some equal cost paths with different numbers of hops, the use of the user flow parameters in the test packet will ensure that the correct number of hops is determined for the user flow parameters. Therefore, when the hop count field <b>57</b> in a probe packet (that has the same flow parameters as the user flow packets) is set to a value corresponding to the hop count determined at operation <b>120</b>, the probe packets will be directed only to the destination switch and will follow the exact same path as the user flow packets.

p-0035At <b>130</b>, the source switch engages in a handshaking message exchange with the destination switch to enable the destination switch to run a layer-2 traceroute to the source switch with the same user flow parameters (such that source and destination fields are interchanged) and a TTL value for the layer-2 traceroute test packets is set to the hop count determined at operation <b>120</b> (and included in the hop count field). In addition, at <b>130</b>, the handshaking exchange between the source switch and the destination switch causes the destination switch to timestamp TTL expiry packets.

p-0036At operation <b>140</b>, the source switch activates or enables its clock synchronization unit <b>26</b> (<figref idrefs="DRAWINGS">FIG. 2</figref>) to activate timestamping of TTL expiry packets received at the source switch (from the destination switch). Thus, at this point, both the source switch and the destination switch are configured to timestamp any TTL expiry packets that they may receive from each other. As a result, whenever the source switch receives a packet (from the destination switch) with a TTL value matching the configured value (included in field <b>57</b> referred to above), it timestamps that packet using the clock synchronization unit <b>26</b>. Likewise, whenever the destination switch receives a packet (from the source switch) with a TTL value matching the configured value, the destination switch also timestamps that packet. The timestamps are then used to evaluate the latency of the path between the source switch and destination switch, in both directions.

p-0037At <b>150</b>, the source switch generates one or more probe packets having user flow parameters matching the user flow parameters (that is, MAC addresses, Ethertype, UDP/TCP ports) of user flow packets so that the probe packets use the same path taken by the user flow packets between the source switch and the destination switch. In generating the one or more probe packets, a time-to-live field value is included in the hop count field <b>57</b> in header <b>50</b> that is equal to the number of hops from the source switch to the destination switch (determined at <b>120</b>) and which value also distinguishes the one or more probe packets from user flow packets. <figref idrefs="DRAWINGS">FIG. 5</figref> depicts the results of operations <b>110</b>, <b>120</b> and <b>140</b> in ultimately generating probe packets from the user flow parameters derived from user flow packets.

p-0038At <b>160</b>, the source switch sends the one or more probe packets in the layer-2 multipath network to the destination switch. The probe packets are sent on the same path as the user flow packets, but are distinguished from the user flow packets based on the TTL value inserted into the hop count field <b>57</b> in the header <b>50</b> as shown in <figref idrefs="DRAWINGS">FIG. 3</figref>. For example, if the number of hops along the path taken by the user flow packets is 6, then the TTL value inserted into hop count field <b>57</b> is the value 6. <figref idrefs="DRAWINGS">FIG. 6</figref> shows how probe packets may be intermingled with user flow packets along the same path between the source switch and destination switch as the user flow packets.

p-0039At <b>170</b>, based on the timestamped TTL expiry packets at the source switch and destination switch, the source switch and determine the connectivity (good connection or no/bad connection) between the source switch and the destination switch on the same path as the user flow packets based on the one or more probe packets. For example, if the probe packets are sent from the source switch to the destination switch and successfully reach the destination switch without any dropped packets (based on acknowledgment packets sent back to the source switch from the destination switch in response to receiving the probe packets), then the source switch determines that the path taken by the user flow packets is a good connection. In addition, at <b>170</b>, the source switch can determine the latency (time period between a probe packet transmission and its reception at the destination switch) in the network using the timestamped probe packets received by the source switch and the destination switch. For example, the source switch receives information about the connectivity using TTL expiry response packets. The destination switch sends back packets with the same user flow parameters, but with the source and destination information fields exchanged. As a result, there are 4 timestamps available to the source switch, 2 in the forward direction (at the source switch and at the destination switch) and 2 in the reverse direction. These 4 timestamps allow the source switch to evaluate the path latency. In the case where the switches have time synchronization capabilities, 2 timestamps are also sufficient.

p-0040The operations <b>110</b>-<b>170</b> can be performed for each of a plurality of user flows that are sourced at any given switch and destined for any other switch in the multipath network <b>10</b> shown in <figref idrefs="DRAWINGS">FIG. 1</figref>. That is, a given switch may run these operations for multiple different users flows (to the same or different destination switches), and each user flow may result in a different path to the same destination switch and to a different destination switch. Thus, multiple sets of probe packets may be generated at a switch using the techniques described herein, where each set of probe packets dedicated to a particular user flow from one switch to any other switch.

p-0041The techniques described herein may be incorporated into the TRILL or DCE protocol specification and thus made part of the requirements of these protocols.

p-0042The above description is intended by way of example only.