Path maximum transmission unit determination

Disclosed are techniques for determining a path maximum transmission unit (MTU) of a communication path connecting two or more nodes of a network. A node initiates a connection with a remote node by repeatedly transmitting increasingly-larger path MTU discovery messages until the size of a path MTU discovery message exceeds the link MTU of a link within the communication path. This results in the generation and transmission of an MTU error message back to the initiating node. The edge router linked to the initiating node generates a MTU change message in response to receiving the MTU error message and multicasts the MTU change message to all local nodes to which it is linked. The MTU change message directs the receiving nodes to update their destination caches to reflect the path MTU discovered through the use of the increasing-size path MTU discovery messages and the resulting MTU error message.

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims priority under 35 U.S.C. §119 to Indian Patent Application No. 1494/DEL/2008, entitled “PATH MAXIMUM TRANSMISSION UNIT DETERMINATION,” filed on Jun. 23, 2008.

FIELD OF THE DISCLOSURE

This disclosure relates generally to information handling systems, and more particularly to path maximum transmission unit (MTU) for packet-switched data transmissions for information handling systems.

BACKGROUND

Information handling systems often make use of packet-switched networks, such as Internet Protocol (IP)-based networks, to transfer data. Typically, the data to be transmitted is segmented into a series of datagrams, or packets, of a fixed or variable size for transmission. However, many packet-switched networks utilize a series of separate links that connect two devices, and each link may be capable of a different maximum packet size (or maximum transmission unit (MTU)). Thus, a transmitting device typically employs a path MTU discovery process whereby a series of progressively-larger path MTU discovery messages are transmitted by the transmitting device until an error message is generated due to the path MTU discovery message exceeding the link MTU of a particular link in the communication path between the transmitting device and the receiving device. The transmitting device then identifies the size of this path MTU discovery message as the MTU for the communication path. In conventional systems, this path MTU discovery process is separately repeated by each transmitting device on the network or subnetwork, thereby resulting in the use of a considerable portion of the network resources solely for the determination of the MTUs for the various paths between transmitting devices and receiving devices.

DETAILED DESCRIPTION OF DRAWINGS

The following description in combination with the Figures is provided to assist in understanding the teachings disclosed herein. The following discussion will focus on specific implementations and embodiments of the teachings. This focus is provided to assist in describing the teachings and should not be interpreted as a limitation on the scope or applicability of the teachings. However, other teachings can certainly be utilized in this application. The teachings can also be utilized in other applications and with several different types of architectures such as distributed computing architectures, client/server architectures, or middleware server architectures and associated components.

For purposes of this disclosure, an information handling device can include any instrumentality or aggregate of instrumentalities operable to compute, classify, process, transmit, receive, retrieve, originate, switch, store, display, manifest, detect, record, reproduce, handle, or utilize any form of information, intelligence, or data for business, scientific, control, entertainment, or other purposes. For example, an information handling device can be a personal computer, a PDA, a consumer electronic device, a network server or storage device, a switch router, wireless router, or other network communication device, or any other suitable device and can vary in size, shape, performance, functionality, and price. The information handling device can include memory, one or more processing resources such as a central processing unit (CPU) or hardware or software control logic. Additional components of the information handling device can include one or more storage devices, one or more communications ports for communicating with external devices as well as various input and output (I/O) devices, such as a keyboard, a mouse, and a video display. The information handling device can also include one or more buses operable to transmit communications between the various hardware components.

FIGS. 1-4illustrate example networks and techniques for determining the path maximum transmission unit (MTU) (i.e., the maximum packet size) of a communication path connecting two or more nodes of a network. A node initiates a connection with a remote node by repeatedly transmitting increasingly-larger path MTU discovery messages until the size of a path MTU discovery message exceeds the link MTU of a link within the communication path. This situation results in the generation and transmission of an MTU error message back to the initiating node. In one embodiment, the edge router linked to the initiating node is configured to generate a MTU change message in response to receiving the MTU error message and then multicast the MTU change message to all local nodes to which it is linked. The MTU change message directs the receiving nodes to update their destination caches to reflect the path MTU discovered through the use of the increasing-size path MTU discovery messages and the resulting MTU error message. By multicasting the MTU change message to some or all of the nodes linked to the edge router so as to update each of these nodes with the same path MTU information, duplicative performance of the path MTU discovery process by each node individually can be avoided, thereby reducing unnecessary traffic on the network. Example techniques for updating the path MTU responsive to routing changes in the communication path and for periodically refreshing the path MTU are also disclosed.

For ease of illustration, the example techniques are described in the context of an Internet Protocol version 6 (IPv6)-based network utilizing path MTU discovery messaging substantially as described in the Internet Engineering Task Force (IETF) Request for Comments (RFC) 1981 specification and the IETF RFC 4821 specification and the neighbor discovery messaging described in the IETF RFC 2461 specification, which can be adapted as described below. However, the disclosed techniques are not limited to such configurations and instead may be implemented in any of a variety of packetized networks, particularly those that prevent or discourage packet fragmentation, without departing from the scope of the present disclosure. To illustrate, these techniques can be adapted for use in an IP version 4 (IPv4)-based network utilizing path MTU discovery messaging as described in the IETF RFC 1191 specification.

FIG. 1illustrates an information handling device100in accordance with at least one embodiment of the present disclosure. In one form, the information handling device100can be a computer system such as a server. As shown inFIG. 1, the information handling device100can include a first physical processor102coupled to a first host bus104and can further include additional processors generally designated as nthphysical processor106coupled to a second host bus108. The first physical processor102can be coupled to a chipset110via the first host bus104. Further, the nthphysical processor106can be coupled to the chipset110via the second host bus108. The chipset110can support multiple processors and can allow for simultaneous processing of multiple processors and support the exchange of information within information handling device100during multiple processing operations.

According to one aspect, the chipset110can be referred to as a memory hub or a memory controller. For example, the chipset110can include an Accelerated Hub Architecture (AHA) that uses a dedicated bus to transfer data between first physical processor102and the nthphysical processor106. For example, the chipset110, including an AHA enabled-chipset, can include a memory controller hub and an input/output (I/O) controller hub. As a memory controller hub, the chipset110can function to provide access to first physical processor102using first bus104and nthphysical processor106using the second host bus108. The chipset110can also provide a memory interface for accessing memory112using a memory bus114. In a particular embodiment, the buses104,108, and114can be individual buses or part of the same bus. The chipset110can also provide bus control and can handle transfers between the buses104,108, and114.

According to another aspect, the chipset110can be generally considered an application specific chipset that provides connectivity to various buses, and integrates other system functions. For example, the chipset110can be provided using an Intel® Hub Architecture (IHA) chipset that can also include two parts, a Graphics and AGP Memory Controller Hub (GMCH) and an I/O Controller Hub (ICH). For example, an Intel 820E, an 815E chipset, or any combination thereof, available from the Intel Corporation of Santa Clara, Calif., can provide at least a portion of the chipset110. The chipset110can also be packaged as an application specific integrated circuit (ASIC).

The information handling device100can also include a video graphics interface122that can be coupled to the chipset110using a third host bus124. In one form, the video graphics interface122can be an Accelerated Graphics Port (AGP) interface to display content within a video display unit126. Other graphics interfaces may also be used. The video graphics interface122can provide a video display output128to the video display unit126. The video display unit126can include one or more types of video displays such as a flat panel display (FPD) or other type of display device.

The information handling device100can also include an I/O interface130that can be connected via an I/O bus120to the chipset110. The I/O interface130and I/O bus120can include industry standard buses or proprietary buses and respective interfaces or controllers. For example, the I/O bus120can also include a Peripheral Component Interconnect (PCI) bus or a high speed PCI-Express bus. In one embodiment, a PCI bus can be operated at approximately 66 MHz and a PCI-Express bus can be operated at approximately 128 Mhz. PCI buses and PCI-Express buses can be provided to comply with industry standards for connecting and communicating between various PCI-enabled hardware devices. Other buses can also be provided in association with, or independent of, the I/O bus120including, but not limited to, industry standard buses or proprietary buses, such as Industry Standard Architecture (ISA), Small Computer Serial Interface (SCSI), Inter-Integrated Circuit (I2C), System Packet Interface (SPI), or Universal Serial buses (USBs).

In an alternate embodiment, the chipset110can be a chipset employing a Northbridge/Southbridge chipset configuration (not illustrated). For example, a Northbridge portion of the chipset110can communicate with the first physical processor102and can control interaction with the memory112, the I/O bus120that can be operable as a PCI bus, and activities for the video graphics interface122. The Northbridge portion can also communicate with the first physical processor102using first bus104and the second bus108coupled to the nthphysical processor106. The chipset110can also include a Southbridge portion (not illustrated) of the chipset110and can handle I/O functions of the chipset110. The Southbridge portion can manage the basic forms of I/O such as Universal Serial Bus (USB), serial I/O, audio outputs, Integrated Drive Electronics (IDE), and ISA I/O for the information handling device100.

The information handling device100can further include a disk controller132coupled to the I/O bus120, and connecting one or more internal disk drives such as a hard disk drive (HDD)134and an optical disk drive (ODD)136such as a Read/Write Compact Disk (R/W CD), a Read/Write Digital Video Disk (R/W DVD), a Read/Write mini-Digital Video Disk (R/W mini-DVD), or other type of optical disk drive.

FIG. 2illustrates a network200of a plurality of information handling devices and a flow chart201of its operation for determining the maximum transmission unit (MTU) of a communication path in accordance with at least one embodiment of the present disclosure. In the depicted example, the network200includes a plurality of local nodes, including nodes202and204, and a remote node206(also identified as nodes A, B, and C, respectively), and a subnetwork (subnet)208comprising a plurality of linked routers, including routers210,212,214, and216(also identified as routers A, B, C, and D, respectively). For ease of discussion, the nodes202,204, and206are illustrated and described as information handling devices at the edge of the network200(e.g., the ultimate sources and destinations of data transmitted via the network200). However, in certain embodiments, one or more of the nodes202,204, and206can be implemented as routers of other subnetworks. To illustrate, node202and node204each can include an edge router in a separate subnetwork connected to the subnetwork208via the router210, or the node206can include an edge router in a separate network connected to the subnetwork208via the router216. For the description below, the network200is describe as based on the IPv6 standard and that nodes202and204are identified as being on the same local link (e.g., as identified via their link-local network addresses). Further, although three nodes are illustrated for ease of discussion, the techniques described herein can be applied to a network having any number of nodes without departing from the scope of the present disclosure.

The nodes202,204, and206, and the routers210,212,214, and216each can be implemented as an information handling device as illustrated inFIG. 1. In such instances, the particular functions and processes attributed to the various nodes and routers as described below can be performed by one or more of the processors of the information handling device100ofFIG. 1(e.g. processors102and106ofFIG. 1). The one or more processors so configured can include hardware or firmware configured to perform some or all of the attributed functionality, some or all of the attributed functionality can be performed via software executed by the one or more processors, or a combination thereof. Each of the nodes202,204, and206includes a network interface to couple to a respective edge router of the subnet208. To illustrate, the nodes202and204couple to the router210as the edge router for the nodes202and204, and the node206is coupled to the router216as its edge router.

The routers210,212,214, and216(collectively, “routers 210-216”) include any of a variety of information handling devices configured to receive and transmit packetized data, including, but not limited to, routers, switches, bridges, etc. Each of the routers includes one or more network interfaces to couple to one or more other routers of the subnetwork208, and, if the router is an edge router, a network interface to couple to one or more local nodes. In the depicted example, the routers210-216are connected so as to form a communication path220between the router210and the router216(and thus between node202and node206and between node204and node206). The communication path220can be bidirectional (e.g., capable of communicating information from router210to router216and vice versa) or unidirectional (e.g., capable of communicating information only from router210to router216). AlthoughFIG. 2depicts a single communication path formed by a series of four routers for ease of describing the techniques of the present disclosure, it will be appreciated that a typical subnet can have more than four routers to form a path between edges of the subnet208, or that multiple possible communication paths between edge routers of a subnet may be present. The techniques of the present disclosure are equally applicable to such implementations, using the guidelines provided herein.

The communication path220includes a sequence of links between routers, including link222connecting router210and router212, link224connecting router212and router214, and link226connecting router214and216. These links can be implemented as wired communications links, wireless communication links, or a combination thereof. In certain instances, the configurations, capabilities, and physical characteristics of the routers210-216and the communications links forming the links therebetween may differ such that different links may be capable of handling different packet sizes, or transmission units. For example, the link222may have a link MTU of X (e.g., 4 kilobytes), whereas the link224may be have a link MTU of only Y<X (e.g., 2 kilobyte). As a packet transmitted between the router210and the router216cannot exceed the minimum link MTU of the links222,224, and226(unless packet fragmentation is permitted), the communication path220has a path MTU equal to the minimum link MTU of these links.

The information handling devices ofFIG. 2(the nodes202-206and the routers210-216) each can implement a separate destination cache (also referred to as a routing table) that directs the routing of packets within the network200. The destination cache can be stored in, for example, the memory112(FIG. 1), a data cache (not shown), a register file (not shown), and the like. Typically, the destination cache for a particular information handling device of the network200includes an entry for each known destination device or destination prefix, the next device in the path to the destination (referred to as the “next hop”), and the path MTU for the path to that destination. To illustrate, an entry of the destination cache of the node202with respect to the node206could be described in Table 1:

TABLE 1Destination Cache Entry for Node 202DestinationNext HopPath MTUNode 206Router 210X bytes
Similarly, an entry of the destination cache of the router210with respect to the node202and node206could be described in Table 2:

As described above, the IETF RFC 1981 specification describes a technique for determining the MTU of a communication path between a transmitting node and a receiving node by successively increasing the size of path MTU discovery messages transmitted between a transmitting node and a receiving node until the packet size of a path MTU discovery message exceeds the link MTU of a particular link in the communication path, thereby resulting in the transmission of an error message (e.g., a PacketTooBig message as specified by the Internet Control Message Protocol version 6 (ICMPv6)) back to the source node, which is then used by the source node to identify the path MTU. Once the path MTU was determined by the node, the node updated its destination cache to reflect the determined MTU. However, in conventional applications, the MTU for a given path determined by one node is not shared with any other nodes. As this information wasn't shared, the path MTU discovery process was repeated in its entirety by each node, even though certain nodes may share the same communication path (either as the entire communication path or as a link of a larger communication path). Thus, a considerable amount of effort is duplicated by each node, leading to a waste of network resources in transmitting the path MTU discovery messages and the resulting error messages.

Rather than repeating the same path MTU process for each node, in one embodiment the network200implements an improved technique whereby the path MTU discovery information can be shared between multiple nodes (e.g., those nodes on the same local link or associated with the same multicast address), thereby reducing or eliminating duplicate efforts by the individual nodes, and thereby freeing network resources for other processes. Flow chart201illustrates an example implementation of this path MTU discovery process as initiated by node202. However, this same path MTU discovery process may be initiated in the same manner by node204, or in the other direction by node206.

At block230, the node202initiates determination of the path MTU for the communication path220by attempting to transmit a sequence of path MTU discovery messages to node206via the subnet208(the size of each successive path MTU discovery message is larger than the previous) until the size of a path MTU discovery message exceeds the link MTU of a link in the communication path220. In response to which, the router at the forward edge of the link generates an MTU error message and transmits the MTU error message back to the node202. In the illustrated example, the link226linking router214and router216has the smallest MTU of the communication path220, and thus when the router214receives a path MTU discovery message via routers210and212that exceeds the MTU of the link226(event232), at block234the router214generates a MTU error message and transmits the MTU error message to the node202via the routers212and210to notify the node202that the size of the packet transmitted exceeds the capabilities of the link226.

In at least one embodiment, the MTU error message includes a field having data representative of the link MTU of the link226in the forward direction from the router214to the router216). For example, the MTU error message can comprise an IMCPv6 PacketTooBig message that includes the link MTU that was exceeded (e.g., by exceeding the link MTU of the link226in this example). To illustrate, the IETF RFC 1191 specification specifies that the router generating the PacketTooBig message include a value representative of the link MTU in the lower-order sixteen (16) bits of the header field of the PacketTooBig message, while setting the higher-order sixteen (16) bits to zero. The router212can generate the MTU error message as a PacketTooBig message in this manner. In other implementations, the MTU error message can include another standard message adapted to identify an MTU error and include data representative of the link MTU, or the MTU error message can include a custom-formatted message with this information.

In response to receiving the MTU error message in its transmission back to the node202, at block236the router210accesses the field of the MTU error message having the link MTU of the forward link and updates its destination cache to update the path MTU for the communication path220. To illustrate, if the MTU error message comprises an ICMPv6 PacketTooBig message in accordance with the IETF RFC 1191 specification, the router210can access the lower-order sixteen bits of the header field of the PacketTooBig message to obtain the data value representative of the link MTU. The non-edge router212also can update its destination cache in a similar manner upon receipt of the MTU error message.

In response to identifying that it is the edge router of the subnet208with respect to node202(e.g., by identifying that node202is the next hop) and further in response to receiving the MTU error message, at block238the router210generates an MTU change message that is multicast to any nodes on the same local link as the router210(nodes202and204in the illustrated example). The MTU error message can be multicast to the local nodes via, for example, a multicast address associated with the local nodes.

The MTU change message includes one or more fields that include data representative of the path MTU for the communication path220as determined by the router210at block326in response to receiving the MTU error message. To illustrate, the IETF RFC 2461 specification defines an ICMP Router Advertisement message that can be used by routers in an IPv6 network advertise their presence together with various link and Internet parameters either periodically, or in response to a Router Solicitation message. Conventionally, these Router Advertisements contain prefixes that are used for on-link determination and/or address configuration, a suggested hop limit value, etc. In one embodiment, the MTU change message can include an ICMP Router Advertisement message adapted to contain data representative of the determined path MTU for use by the receiving nodes. To illustrate, the ICMP Router Advertisement message semantics include an options field with a {type, length, value} triplet format, which may be adapted to provide the path MTU information, e.g., Type: 16 (Per Node MTU); Length: 128-bit prefix, 8-bit prefix length, 24-bit path MTU value; Length: 4 (as per RFC2461 specifications on the length notation of option fields).

In response to receiving the MTU change message, at block240the node202accesses the path MTU information from the appropriate field of the MTU change message and updates its destination cache to reflect the path MTU for the communication path220as indicated by the accessed path MTU information. Likewise, at block242the node204accesses the path MTU information from the MTU change message updates its destination cache to reflect the path MTU for the communication path220in response to receiving the MTU change message from the router210. Based on this path MTU update, at block244the node202then can begin communicating data with the node206by packetizing the data in accordance with the updated path MTU indicated in its destination cache and at block246the node204can begin communicating data with the node206by packetizing the data in accordance with the updated path MTU indicated in its destination cache.

As described above, the edge router linked to the node initiating the path MTU discovery process (i.e., the router210in the example above) updates all of the local nodes to which it is linked with path MTU information via the MTU change message, thereby allowing multiple nodes to make use of the path MTU process initiated by one node, rather than requiring each node to separately conduct its own path MTU process. By eliminating the need for other nodes to conduct the same path MTU process, the overall traffic transmitted on the subnet208is decreased, thereby permitting network resources to be utilized for other processes, such as the transmission of information.

As an example, assume there are two edge routers having M end nodes and N end nodes, respectively, and the conventional path MTU discovery process requires P iterations of the transmission of a path MTU discovery message. Further assume that each of the M end nodes establishes IPv6 connections to each of the N end nodes. Under these circumstances, the number of path MTU discovery messages that would be transmitted in accordance with the conventional path MTU discovery process would be equal to M*N*P. If M=100, N=2, and P=2, there would be 400 path MTU discovery messages transmitted in the conventional path MTU discovery process. In contrast, the best case scenario for the improved path MTU discovery process described above would be P path MTU messages. If P=2, this best case scenario represents a 20,000% improvement over the conventional path MTU discovery process under these conditions. The worst case scenario for the improved path MTU discovery process described above would be (P−1)+(M*N). If M=100, N=2, and P=2 as assumed above, the total number of path MTU messages transmitted in this worst case scenario is 201 path MTU messages, which still represents a 50% improvement over the conventional path MTU discovery process.

FIG. 3illustrates an additional aspect of the example path MTU process ofFIG. 2to accommodate for changes in the communication path between nodes in accordance with at least one embodiment of the present disclosure. In the depicted example, a network300(corresponding to the network200ofFIG. 2) includes a plurality of nodes, including the nodes202,204, and206and a subnetwork (subnet)308(corresponding to subnet208,FIG. 2) comprising a plurality of routers, including the routers210,212,214, and216(also identified as routers A, B, C, and D, respectively) and another router318(also identified as router E). As discussed above, the routers210-216can be connected so as to form the communication path220between the router210and the router216via the links222,224, and226discussed above. Further, another communication path320is available between the router210and the router216via the link222, a link322linking the router212to the router318, a link324linking the router318to the router214, and the link226.

The node202(or alternately the node204) can initiate the improved path MTU discovery process described above so that the node202and the node204are updated with the path MTU between the nodes202,204and the node206on the basis of the path MTU of the communication path220. However, in certain instances, one or more of the links of the communication path220may fail, temporarily or permanently. Accordingly, an alternate path, such as communication path320, if available, will be implemented in place of the failed communication path for communicating information across the subnet308. The flow chart301illustrates an example process for performing a path MTU discovery process in such instances. For the example of flow chart301, it is assumed that the link224between the router212and the router214fails for any of a variety of reasons, such as physical link failures (e.g., optical fiber is cut), network interface failures, or routing tasks failing on a particular interface, etc.

At block334, node202and node206communicate information via the communication path220of the subnet308based on the transmission of packets having a MTU not greater than the path MTU for the communication path220determined in accordance with the process ofFIG. 2. At some point during communications, the link224between the router220and the router214fails (event336), thereby preventing the transmission of packets via the entirety of the communication path220. In response to the failure of link224, the router212reconfigures its routing path to identify router318as its next hop in the path to node206and the router318configures its routing path to identify router214as its next hop in the path to node206, thereby establishing the communication path320as the communication path between nodes202,204and node206via the subnet308. Accordingly, at block338the node202begins to communicate information to the node206via the communication path320, including the router318.

In this example, the link322between the router212and the router318has an MTU that is less than the path MTU of the communication path220. Assuming the node202remains configured to use the path MTU of the communication path220as the size of the packets it is attempting to transmit to the node206, the first packet received at the router212from the node202that exceeds the MTU of the link322(event340) causes the router212to generate and transmit an MTU error message back to the node202at block342, whereby the MTU error message can include a field having data representing the link MTU of the link322.

In response to receiving the MTU error message, at block344the router210accesses the field of the MTU error message having the link MTU of the forward link and updates its destination cache to update the path MTU for the communication path320. The router212also can update its destination cache in a similar manner upon receipt of the MTU error message. Further, in response to identifying that it is the edge router of the subnet308with respect to node202(e.g., by identifying that node202is the next hop), at block346the router210generates an MTU change message that is multicast to any local nodes on the same link as the router210(nodes202and204in the illustrated example ofFIG. 3). As discussed above, the MTU change message can include one or more fields having data representative of the path MTU for the communication path320as determined by the router210in response to receiving the MTU error message.

In response to receiving the MTU change message, at block348the node202updates its destination cache to reflect the new path MTU for the communication path320as indicated by the MTU change message received from the router212. Likewise, at block350the node202updates its destination cache to reflect the new path MTU for the communication path320in response to receiving the MTU change message from the router210. Based on this path MTU update, at block352the node202then can begin communicating data with the node206by packetizing the data in accordance with the updated path MTU indicated in its destination cache and at blocks354the node204can begin communicating data with the node206by packetizing the data in accordance with the updated path MTU indicated in its destination cache.

As described above, the failure of one or more links in the communication path results in the use of an alternate communication path that may have a lower path MTU than the original communication path. Accordingly, if a packet having a size greater than the lower path MTU is transmitted along the alternate communication path, an MTU error message will be generated at the link having the lower link MTU, which can be used as the stimulus for the edge router linked to the node initiating the communication to update all of the local nodes with the newly determined path MTU, thereby eliminating the need for each local node to conduct a separate path MTU discovery process when the alternate communication path is brought into use.

FIG. 4illustrates an additional aspect of the example path MTU process ofFIGS. 2 and 3to accommodate for changes in the communication path between nodes of the network300in accordance with at least one embodiment of the present disclosure. As described above, one or more of the links of a communication path in the network300may temporarily fail and an alternate communication path, if available, can be implemented in place of the failed communication path for communicating information across the subnet308. However, at some point the failed link may become reenabled and it may be desirable at that point to reinstate the original communication path. Moreover, the capabilities of a particular link, and thus the MTU of the link, may fluctuate over time. Depending on the degree of change in the link MTU relative to the other links in the communication path, the change in the link MTU of a particular link may have the effect of increasing or decreasing the path MTU of the communication path. It can advantageous to update the destination caches of the nodes utilizing the subnet308so as to reflect the fluctuations in the path MTU of the subnet308, thereby allowing the nodes to utilize the largest packet size possible for the subnet308at any given time while avoiding the unnecessary generation and transmission of MTU error messages resulting from the transmission of packets having sizes in excess of the path MTU of the subnet308at that time. The flow chart401illustrates an example process for refreshing the path MTU discovery process for such instances. For the example of flow chart401, it is assumed that the link224between the router212and the router214becomes reenabled at some point after failing as described above with reference toFIG. 3.

At blocks432, node202and node206communicate information via the communication path320of the subnet308based on the transmission of packets having a MTU not greater than the path MTU for the communication path320determined in accordance with the process ofFIG. 3. At some point during communications, the link224between the router212and the router214is reenabled (event434), thereby allowing packets to be transmitted via the communication path220. In this example, it is assumed that the communication path220is preferred over communication path320. Thus, in response to the reenabling of link224, the router212reconfigures its routing path to identify router214as its next hop in the path to node206, thereby reestablishing the communication path220as the communication path between nodes202,204and node206via the subnet308. Accordingly, at block338the node202begins to communicate information to the node206via the communication path220. However, in accordance with typical routing mechanisms, the node206may not yet have been made aware that the communication path of the subnet208has changed. Typically, the destination cache of the node202is populated such that the node202is configured to identify the router210as the next hop in the path to the destination (node206) and thus the node202merely provides all packets to the router210for subsequent retransmission as the router210sees fit. Accordingly, the node202typically would initially continue to transmit packets having a size consistent with the path MTU of the communication path320even after the communication path220is reinstated in place of the communication path320. Thus, if the communication path220has a greater path MTU than the communication path320, the packets being transmitted from the node202are not taking full advantage of the efficiencies of the larger packet size available for transmission via the communication path220.

Accordingly, in one embodiment the subnet308is configured to periodically refresh the path MTU for the subnet308so as to identify any potential increases in the MTU available via the communication path currently in use at the subnet308. In one embodiment, the router210, as the edge router to nodes202and204, implements a timer set to periodically lapse (event436), thereby triggering the router210at block438to generate a MTU flush message that is multicast to any local nodes on the same link as the router210(nodes202and204in the illustrated example ofFIG. 4). In another embodiment, a different stimulus is used to occasionally trigger the generation of the MTU flush message. To illustrate, rather than using a timer, the router210instead can use a counter that counts a number of packets received at the router210and triggers once the count meets a threshold value. As another example, the router210can use the generation of a particular interrupt to trigger the generation of the MTU flush message.

The MTU flush message is intended to direct any receiving node to flush from the node's destination cache the path MTU associated with any destination (e.g., node206) reached via the subnet308. To illustrate, in one embodiment, the MTU flush message can include an ICMPv6 Router Advertisement message modified to include a path MTU value of 0 bytes, thereby signaling to the receiving nodes that the path MTU discovery process is to be reinitiated. Accordingly, at blocks440and442the nodes202and204each updates its destination cache to flush the path MTU associated with the subnet308. With the path MTU for the communication path from the nodes202,204to the node206being flushed with the destination caches of the nodes202and204, at block444one of the nodes202or204can initiate the path MTU discovery process described above with respect to flow chart201ofFIG. 2so as to discover the current path MTU of the communication path currently implemented at the subnet308.