WO2003084145A1 - Method for changing pmtu on dynamic ip network and apparatus using the method - Google Patents

Method for changing pmtu on dynamic ip network and apparatus using the method Download PDF

Info

Publication number
WO2003084145A1
WO2003084145A1 PCT/KR2003/000383 KR0300383W WO03084145A1 WO 2003084145 A1 WO2003084145 A1 WO 2003084145A1 KR 0300383 W KR0300383 W KR 0300383W WO 03084145 A1 WO03084145 A1 WO 03084145A1
Authority
WO
WIPO (PCT)
Prior art keywords
packet
mtu
node
pmtu
information
Prior art date
Application number
PCT/KR2003/000383
Other languages
French (fr)
Inventor
Hak-Goo Lee
Young-Keun Kim
Sun-Woo Kim
Jae-Hwang Lee
Original Assignee
Samsung Electronics Co., Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from KR10-2002-0034132A external-priority patent/KR100453056B1/en
Application filed by Samsung Electronics Co., Ltd. filed Critical Samsung Electronics Co., Ltd.
Priority to AU2003215923A priority Critical patent/AU2003215923A1/en
Priority to EP03745469A priority patent/EP1491005A4/en
Publication of WO2003084145A1 publication Critical patent/WO2003084145A1/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/26Route discovery packet
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/161Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/167Adaptation for transition between two IP versions, e.g. between IPv4 and IPv6

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

A method for discovery and change of a PMTU between a source node and a destination node on a dynamic IP network comprises generating a PMTU discovery packet having a MTU information storage space in which an MTU value on a routing path between the source node and the destination node is stored; transmitting the generated PMTU discovery packet to the destination node; and if a response packet to the PMTU discovery packet from the destination node is received, changing the PMTU according to MTU information contained in the response packet, wherein the MTU value stored in the MTU information storage space is compared with a link MTU value on a path which the PMTU discovery packet traverses, and the smaller one of the stored MTU value and the link MTU value on the path which the packet traverses is stored in the MTU information storage space.

Description

METHOD FOR CHANGING PMTU ON DYNAMIC IP NETWORK AND APPARATUS USING THE METHOD
Technical Field The present invention relates to a method and apparatus for more efficiently operating a network, and more particularly, to a method and apparatus for performing discovery of a maximum transmission unit (MTU) on a path more appropriately to a dynamic network environment, and changing path MTU (PMTU) according to the discovered MTU with higher efficiency.
Background Art
As the number of the Internet users has been rapidly increasing recently, the 32-bit address system in the networks based on the conventional Internet Protocol version 4 (IPv4) has shown the limits of Internet protocol (IP) addresses and functional restrictions. To solve these problems, Internet Protocol version 6 (IPv6) by which a variety of services can be provided through diverse expanded functions with a 128- bit address system has been proposed. In the IPv4, when the size of a packet is greater than a link MTU, a router located on a routing path performs fragmentation of a packet. However, in IPv6 unlike in IPv4, if a packet is once transmitted by a source node, a node in the middle of a path does not perform fragmentation of the packet. Instead, the source node searches for a minimum MTU on a path, fragments packets according to the discovered MTU, and transmits the fragmented packets.
Accordingly, when an IPv6 node, that is, a source node, is desired to transmit data to a destination node in a remote location, a link MTU of a path through which a packet is transmitted is first discovered. That is, a path MTU (hereinafter referred to as "PMTU") that is a minimum link MTU in a routing path between the source node and the destination node should be determined. According to the prior art PMTU discovery method, when a source node first transmits a packet, the source node fragments the packet in units each having the size of a next-hop link MTU and transmits the fragmented packet. When the size of a packet transmitted from the source node is greater than a link MTU between hops in the routing path, this packet is discarded, and an Internet Control Message Protocol (ICMP)-Packet Too Big message containing next-hop link MTU information is generated and transmitted to the source node. Using the MTU information of the ICMP-Packet Too Big message, the source node fragments the packet again and transmits it again. This routine is repeated until the packet arrives at the destination node without being discarded after being transmitted by the source node.
FIG. 1 is a diagram showing a process for changing a PMTU by applying a prior art method for PMTU discovery when a routing path between a source node 110 and a destination node 170 changes from a path connecting a first node 120, a second 130, a third node 140, and the destination node 170, to a path connecting the first node 120, a fourth node 150, a fifth node 160, and the destination node 170 in a dynamic network environment.
In the prior art method, while a packet is being transmitted, a PMTU may change if there is a change of a routing path according to the dynamic network environment. Therefore, when a PMTU is maintained for a predetermined time, the prior art PMTU discovery method described above is used to discover the PMTU of the current routing path, and according to the discovered result, the PMTU is increased. However, in this case, an ICMP error message of IPv6, that is, an error message such as an ICMP-Packet Too Big message, is unnecessarily generated such that network resources are wasted. Referring to FIG. 1 , a method for discovering and changing a
PMTU of a current routing path according the prior art PMTU discovery method in order to change a PMTU, and an apparatus thereof will now be explained.
First, when a routing path between the source node 110 and the destination node 170 changes from a path connecting the first node 120, the second node 130, the third node 140, and the destination node 170, to a path connecting the first node 120, the fourth node 150, the fifth node 160, and the destination node 170 in a dynamic IP network environment, the PMTU values increase from MTU=2 to MTU=3, but the current source node 110 continuously fragments packets according to MTU=2, and transmits the packets. Using a timer (not shown), if a predetermined time passes, the source node 100 generates a packet φ (MTU=6) based on the MTU value 6 and transmits the packet to the next node, the first node 120.
Since the size of the received packet φ (MTU=6) is greater than the next-hop link MTU value 5, the first node 120 discards the received packet φ (MTU=6), and generates an ICMP error message containing next-hop link MTU information, which is MTU=5. That is, the first node 120 generates an ICMP Packet Too Big message φ (MTU=5), and transmits the message to the source node 110.
The source node 110 fragments the packet again according to the next-hop link MTU value, that is, MTU=5, of the first node 120 contained in the received ICMP error message φ (MTU=5) transmitted by the first node 120, and transmits the re-fragmented packet (3) (MTU=5) to the destination node 170.
Since the size of the received packet φ (MTU=5) is greater than the next-hop link MTU value, that is, MTU=4, the fourth node 150 discards the received packet ® (MTU=5), generates an ICMP error message © (MTU=4) containing the next-hop link MTU information, and transmits the message to the source node 110. Like the previous step, the source node 110 fragments the packet to satisfy the new link MTU=4, and transmits the fragmented packet © (MTU=4) to the destination node 170. As in nodes 1 and 4, since the size of the received packet © (MTU=4) is greater than the next-hop link MTU value, that is, MTU=3, the fifth node 160 discards the received packet © (MTU=4), generates an ICMP error message © (MTU=3) containing the next-hop link MTU information, and transmits the message to the source node 110. Like the previous step, the source node 110 fragments the packet to satisfy the new link MTU, and transmits the fragmented packet © (MTU=3) to the destination node 170.
Thus, in the prior art method for increasing a PMTU, in order to discover a PMTU of a current routing path and change the PMTU, much time is spent and network resources are unnecessarily wasted.
Disclosure of the Invention
To solve the above problems, the present invention provides a method and apparatus for more efficiently discovering a PMTU of a current routing path in a dynamic network environment and changing a PMTU according to the discovered PMTU.
According to an aspect of the present invention, there is provided a method for changing a path maximum transmission unit (PMTU) between a source node and a destination node on a dynamic Internet protocol (IP) network, the method comprising: (a) generating a PMTU discovery packet having a maximum transmission unit (MTU) information storage space in which an MTU value on a routing path between the source node and the destination node is stored; (b) transmitting the generated PMTU discovery packet to the destination node; and (c) if a response packet to the PMTU discovery packet from the destination node is received, changing the PMTU according to MTU information contained in the response packet, wherein the MTU value stored in the MTU information storage space is compared with a link MTU value on a path which the PMTU discovery packet traverses, and the smaller one of the stored MTU value and the link MTU value on the path which the packet traverses is stored in the MTU information storage space. It is preferable that the PMTU discovery packet which is generated in step (a) is generated if a current PMTU value is maintained for a predetermined time.
It is preferable that in step (a) a next-hop link MTU value of the source node is stored in the MTU information storage space.
It is preferable that step (c) comprises step (d ) in which if the
PMTU discovery packet arrives at the destination node, a packet containing the MTU value stored in the MTU information storage space of the PMTU discovery packet is generated, and the packet is transmitted to the source node.
According to another aspect of the present invention, there is provided an apparatus for changing a path maximum transmission unit (PMTU) between a source node and a destination node on a dynamic IP network, the apparatus comprising: a PMTU discovery packet generation unit which generates a PMTU discovery packet having an MTU information storage space in which a maximum transmission unit (MTU) value on a routing path between the source node and the destination node is stored; a transmission unit which transmits the generated PMTU discovery packet to the destination node; and a PMTU changing unit which, if a response packet to the PMTU discovery packet from the destination node is received, changes the PMTU according to MTU information contained in the response packet, wherein the MTU value stored in the MTU information storage space is compared with a link MTU in a path which the PMTU discovery packet traverses, and the smaller one of the stored MTU value and the link MTU value in the traverse path is stored in the MTU information storage space.
It is preferable that the PMTU discovery packet is generated if the current PMTU value is maintained for a predetermined time.
It is preferable that the size of the PMTU discovery packet is equal to or less than the size of the current PMTU.
It is preferable that a next-hop link MTU value of the source node is stored in the MTU information storage space. It is preferable that the PMTU discovery packet is a packet which complies with Internet Protocol version 6 and has a hop-by-hop option header that is an extension header.
It is preferable that an option type field of the hop-by-hop option header of the PMTU discovery packet stores information indicating that if a node in the middle of a routing path does not recognize the option type field of the PMTU discovery packet, the PMTU discovery packet should be discarded.
It is preferable that the information indicating that the PMTU discovery packet should be discarded is located in the highest 2 bits stored in the option type field.
It is preferable that the option type field stores information indicating whether or not it is possible to change MTU information stored in the MTU information storage space. It is preferable that the information indicating whether or not it is possible to change MTU information is located in the third highest bit stored in the option type field.
It is preferable that the field in which the MTU information is stored is an option data field in the option field of the hop-by-hop header of IPv6.
Brief Description of the Drawings
The above objects and advantages of the present invention will become more apparent by describing in detail preferred embodiments thereof with reference to the attached drawings in which:
FIG. 1 is a diagram showing a prior art method for changing a path maximum transmission unit (PMTU);
FIG. 2 is a diagram of a basic header of Internet Protocol version 6 (IPv6) used in the present invention; FIG. 3 is a diagram of a basic structure of an Internet Control
Message Protocol version 6 (ICMPv6) extension header used in the present invention; FIG. 4A is a diagram showing a basic structure of a hop-by-hop option header used in the present invention;
FIG. 4B is a diagram of the structure of an Options" field in the hop-by-hop option header shown in FIG. 4A; FIG. 5A is a diagram of the structure of an "Options" field in a hop-by-hop option header constructed according to a preferred embodiment of the present invention;
FIG. 5B is a diagram of the structure of an "Options" field in a hop-by-hop option header constructed according to another preferred embodiment of the present invention;
FIG. 6 is a diagram of the structure of a packet containing an OIP option according to the present invention;
FIG. 7A is a diagram showing a PMTU changing method according to a preferred embodiment of the present invention; FIG. 7B is a diagram showing a PMTU changing method according to another preferred embodiment of the present invention;
FIG 8 is a diagram showing a storage space shape of a node according to the present invention;
FIG. 9A is a diagram showing a basic structure of an ICMPv6 message used in the present invention;
FIG. 9B is a diagram showing a basic structure of an ICMP- Packet Too Big message used in the present invention;
FIG. 10A is a diagram showing a modified ICMP-Packet Too Big message used in a PMTU discovery method according to the present invention; and
FIG. 10B is a diagram showing a newly defined ICMP-PMTUD Minimizing Packet used in a PMTU discovery method according to the present invention.
Best mode for carrying out the Invention
First, terminologies used in this specification are defined as follows: a »'*s«
node: a device that implements IPv6. router: a node that forwards IPv6 packets not explicitly addressed to itself. host: any node that is not a router. upper layer: a protocol layer immediately above IPv6. For example, transport protocols such as TCP and UDP, control protocols such as ICMP path maximum transmission unit discovery (PMTU) Minimizing Packet: a newly defined ICMP information message. link: a communication facility or medium over which nodes can communicate at the link layer. packet: an IPv6 header plus a payload. link MTU: the maximum transmission unit. path: the set of links traversed by a packet between a source node and a destination node path MTU (PMTU): the minimum link MTU of all the links in a path between a source node and a destination node.
Referring to the attached drawings, preferred embodiments of the present invention will now be explained.
FIG. 2 is a diagram of a basic header of IPv6 used in the present invention. All packets of IPv6 begin with a basic header formed with 40 bytes. "Version" of FIG. 2 indicates the version of IP, and "Payload Length" indicates the length of an IP packet in units of bytes. "Next Header" indicates which extension header follows the basic header of IPv6, and "Hop Limit" is used to restrict in units of hops a distance for transmitting an IP packet. "Source Address" and "Destination Address" indicate the address of a host transmitting a packet and the address of a destination to which the packet is to be transmitted, respectively. The length of the each address is 128 bits.
FIG. 3 is a diagram of an extension header in IPv6 used in the present invention. The extension header in IPv6 is retrieved in the order in which the "Next Header" field of a basic header is first retrieved, and then a next extension header of a value indicated by the "Next Header" field is retrieved. In the structure of the extension header, the first byte indicates the value of a next extension header and the next byte indicates the length of the present extension header. Table 1 lists various values of a next header and corresponding extension headers.
Table 1
Figure imgf000010_0001
The order in which option headers are shown in table 1 is determined by considering that when apparatuses of nodes located in the middle of a routing path through which a packet is transmitted retrieve the header part of the packet being transmitted, the apparatuses retrieve from the beginning part only to the needed part of the packet. The routers supporting IPv6 refer to the hop-by-hop option header and routing information.
FIG. 4A is a diagram showing a basic structure of a hop-by-hop option header. The "Next Header" field is used to distinguish the type of a header immediately following the hop-by-hop option header. A "Hdr Ext Len" field indicates the length of the hop-by-hop option header. An "Options" field is a variable-length field and stores option information related to the hop-by-hop option header.
FIG. 4B is a diagram of the structure of the Options" field in the hop-by-hop option header shown in FIG. 4A. An Option Type" field stores option type information, an "Opt Data Len" field stores the length of an option data field of this option, and an "Option data" field is a variable-length field and stores option type-specific data.
The highest 2 bits of the "Option Type" field indicates the type of measures which a node in the middle of the routing path takes on the present packet when the node cannot recognize the option type stored in the "Option Type" field. For example, if the highest 2 bits of the Option Type" field are 01 and the node in the middle of the routing path cannot recognize the option type stored in the "Option Type" field, this node discards the present packet.
The third highest bit of the Option Type" field indicates whether or not information stored in the "Option Data" field of the hop-by-hop header changes in the middle of the routing path. For example, if the third highest bit of the Option Type" field is 0, it indicates that the option data information of the "Option Data" field cannot change and if the bit is 1 , it indicates that the option data information of the Option Data" field can change.
FIG. 5A is a diagram of the structure of the Options" field in a hop-by-hop option header constructed according to a preferred embodiment of the present invention when a packet is transmitted from a source node to a destination node.
Information "0_1 1 0 0 1 1 1" is stored in the "Option Type" field of FIG. 5A. The highest 2 bits "0 1" indicate that when a node in the middle of the routing path cannot recognize the option type stored in the "Option Type" field, for example, the option "103" that indicates the optimization of increasing the PMTU option (hereinafter referred to as an "OIP option"), the packet in which the OIP option is inserted should be discarded. This is to prevent unnecessary wastage of network resources when an apparatus of a node in the middle of the routing path does not support the OIP option method according to the present invention, and at the same time to enable a PMTU increase using the prior art PMTU discovery method. Also, the third highest bit "1 " of the Option Type" field indicates that option data information of the Option Data" field can change. In addition, the value "0 1 1 0 0 1 1 1" i.e. 103, stored in the Option Type" field indicates that an OIP option of a case where a routing path from the source node to the destination node is inserted into the present packet. FIG. 5B is a diagram of the structure of the Options" field in a hop-by-hop option header constructed according to another preferred embodiment of the present invention when a packet is transmitted from a destination node to a source node. Information "0_1 0 0 0 1 1 1 " is stored in the "Option Type" field of
FIG. 5B. The highest 2 bits "0 1" indicates that when a node in the middle of the routing path cannot recognize the option type stored in the "Option Type" field, for example, the option "71" indicating the OIP option, the packet in which the OIP option is inserted should be discarded. This is to prevent unnecessary wastage of network resources when an apparatus of a node in the middle of the routing path does not support the OIP option method according to the present invention, and at the same time to enable a PMTU increase using the prior art PMTU discovery method. Also, the third highest bit "0" of the "Option Type" field indicates that option data information of the Option Data" field cannot change. In addition, the value "0 1 0 0 0 1 1 1 " i.e., 71 stored in the "Option Type" field indicates that an OIP option of a case where a routing path is from the destination node to the source node is inserted into the present packet.
Also, the value "0 0 0 0 0 1 0 0" stored in the "Opt Data Len" field indicates that the length of the option data field of this option is 4 octets in total. A minimum link MTU of the routing path is stored in this 4-octet- long option data field. FIG. 6 is a diagram of the structure of a packet containing an OIP option according to the present invention.
Thus, according to the optimized PMTU increasing method according to the present invention, when time is up according to a timer setting and the source node desires to increase the PMTU, the source node generates a packet in which the OIP option described above is inserted (hereinafter, referred to as an "OIP packet") with the size of the existing PMTU, and transmits the packet to the destination node.
Here, in the "Opt Data Len" field (hereinafter, referred to as an "MTU field") of the OIP option, the next-hop link MTU value of the source node is stored.
While this OIP packet traverses each node on the routing path between the source node and the destination node, the apparatus of each node, for example, a router, performs the following operation.
1. When the node cannot recognize the option type stored in the "Option Type" field of the OIP packet, the router discards the OIP packet.
2. When the node recognizes the option type stored in the Option Type" field of the OIP packet, the router compares the MTU value stored in the MTU field of the OIP packet with the next-hop link MTU.
3. The router stores the smaller one of the compared values in the MTU field of the OIP packet.
After this operation is performed at every node until the destination node, the minimum link MTU value between the source node and the destination node, that is, the PMTU value, is stored in the MTU field of the OIP packet.
If the destination node receives the OIP packet storing the PMTU value, the destination node immediately transmits the value to the source node. The source fragments the packet according to the received PMTU value and transmits the packet.
Accordingly, it is possible to prevent generation of unnecessary error messages and wastage of network resources that occur in the prior art PMTU increasing method by which a PMTU unconditionally increases as time passes.
Also, when the source node does not receive a response packet to the OIP packet from the destination node even after a predetermined time passes after transmission of the OIP packet, the source node fragments the packet according to the PMTU value which increases based on the prior art PMTU increasing method, and transmits the packet.
Accordingly, even when a node in a routing path between the source node and the destination node cannot recognize the OIP packet and discards the OIP packet, it is possible to increase the PMTU according to the prior art PMTU increasing method such that the compatibility with the prior art PMTU increasing method is maintained.
FIG. 7A is a diagram showing a preferred embodiment of a PMTU changing method according to the present invention.
First, a PMTU changing method and apparatus according to the present invention which is applied to a case when a routing path between a source node 710 and a destination node 770 in a dynamic IP network environment changes from a path connecting a first node 720, a second node 730, a third node 740, and the destination node 770, to a path connecting the first node 720, a fourth node 750, a fifth node 760, and the destination node 770, that is, when the PMTU value increases from MTU=2 to MTU=3, will now be explained.
When the present PMTU value is maintained for a predetermined time, the source node 710 with using a timer (not shown) generates an OIP packet 780 according to the present invention and transmits the OIP packet to the destination node 770.
In an embodiment according to the present invention, if an ICMP- Packet Too Big message is not received for a predetermined time, the source node generates an OIP packet 780 having the size of the existing PMTU, that is, MTU=2, and transmits the packet. However, it is also possible to selectively generate an OIP packet having a size less than the present PMTU, or to generate an OIP packet if other predetermined conditions are satisfied and to transmit the packet. Using another timer (not shown), the source node 710 transmits the OIP packet and at the same time measures the time so that a PMTU can be changed according to the prior art PMTU changing method if a response packet to the transmitted OIP packet is not received for a predetermined time because the OIP packet is lost in the routing path.
The option type number "103" is stored in the option type field of the OIP packet, and the next-hop link MTU value of the source node 710, that is, MTU=6, is stored in the MTU field. Here, the size of the OIP packet is the existing PMTU value, that is, MTU=2. This is to prevent the OIP packet from being discarded in the routing path due to the size of the packet.
The first node 720 receives the OIP packet 780 transmitted by the source node 710, and recognizes the option type. Since the third highest bit value of the option type is 1 , the first node 720 compares the MTU value stored in the MTU field of the OIP packet 780 with the next- hop link MTU=5, stores the smaller of the two values, that is, MTU=5, in the MTU field, and then transmits the OIP packet 780 to the destination node 770.
The fourth node 750 receives the OIP packet 780 transmitted by the first node 720, and recognizes the option type. Since the third highest bit value of the option type is 1 , the fourth node 750 compares the MTU value stored in the MTU field of the OIP packet 780 with the next-hop link MTU=4, stores the smaller of the two values, that is, MTU=4, in the MTU field, and then transmits the OIP packet 780 to the destination node 770.
The fifth node 760 receives the OIP packet 780 transmitted by the fourth node 750, and recognizes the option type. Since the third highest bit value of the option type is 1 , the fifth node 760 compares the MTU value stored in the MTU field of the OIP packet 780 with the next- hop link MTU=3, stores the smaller of the two values, that is, MTU=3, in the MTU field, and then transmits the OIP packet 780 to the destination node 770. The destination node 770 generates an OIP packet 790 based on information stored in the received OIP packet 780, and transmits the OIP packet 790 to the source node 710. Option type number "71", that is, "0 1 0 0 0 1 1 1" is stored in the option type field of the OIP packet 790 and the information stored in the MTU field of the OIP packet 780 received by the destination node 770, that is, MTU=3 is stored in the MTU field. The fifth node 760 receives the OIP packet 790 transmitted by the destination node 770, and recognizes the option type. Since the third highest bit value of the option type is 0, the fifth node 760 transmits the OIP packet 790 to the source node 710 without changing the MTU information stored in the MTU field. The fourth node 750 receives the OIP packet 790 transmitted by the fifth node 760, and recognizes the option type. Since the third highest bit value of the option type is 0, the fourth node 750 transmits the OIP packet 790 to the source node 710 without changing the MTU information stored in the MTU field. The first node 720 receives the OIP packet 790 transmitted by the fourth node 750, and recognizes the option type. Since the third highest bit value of the option type is 0, the first node 720 transmits the OIP packet 790 to the source node 710 without changing the MTU information stored in the MTU field. When the source node 710 receives the OIP packet 790 storing the PMTU value, the source node 710 fragments the packet according to the PMTU value stored in the MTU field of the OIP packet 790 and transmits the packet.
Though the third highest bit value of the option type of the OIP packet 790 generated in the destination node 770 is set to 0 in the embodiment of the present invention, the bit value can be set to 1 as in the OIP packet 780.
According to the PMTU increasing method of the present invention, it is possible to prevent generation of unnecessary error messages and waste of network resources that occur in the prior art PMTU increasing method by which a PMTU unconditionally increases as time passes. Also, when the fourth node 750 in the routing path cannot recognize the option type of the OIP packet 780 and therefore discards the OIP packet 780 in the embodiment of FIG. 7A, if the source node 710 does not receive a response OIP packet 790 to the OIP packet 780 from the destination node 770 after a predetermined time passes after transmission of the OIP packet 780, the source node 710 fragments the packet according to a PMTU value increased based on the prior art PMTU increasing method, and transmits the packet.
Accordingly, even when a node in a routing path between the source node 710 and the destination node 770 cannot recognize the OIP packet 780 and discards the OIP packet 780, it is possible to increase the
PMTU according to the prior art PMTU increasing method such that the compatibility with the prior art PMTU increasing method is maintained.
FIG. 7B is a diagram showing an improved PMTU changing method which is applied to a case when a node in the middle of a routing path between the source node 710 and the destination node 770 cannot recognize the OIP packet 780 and discards the OIP packet 780.
In the embodiments of FIGS. 7A and 7B, when a node in a routing path between the source node 710 and the destination node 770 cannot recognize the OIP packet 780 and discards the OIP packet 780, it is possible to increase the PMTU by using the prior art PMTU discovery method described in FIG. 1. However, if the prior art PMTU discovery method is used, relatively more time is required in discovery of the PMTU of the present routing path and network resources are unnecessarily wasted.
Accordingly, in an embodiment according to the present invention,
ICMPv6 messages shown in FIGS. 9A and 9B are modified or newly defined, and the modified ICMP-Packet Too Big message of FIG. 10A and the ICMP-PMTUD Minimizing Packet in which is a newly defined ICMP information message shown in FIG. 10B, are used.
ICMPv6 messages shown in FIGS. 9A and 9B, the modified ICMP-Packet Too Big message of FIG. 10A and the ICMP-PMTUD Minimizing Packet, which is a newly defined ICMP information message shown in FIG. 10B, will now be explained first, and then referring to FIG. 7B, a PMTU discovery method according to a preferred embodiment of the present invention will be explained. FIG. 9A is a diagram showing a basic structure of an ICMPv6 message used in the present invention.
In the "Type" field of the ICMPv6 message, numbers 0 to 127 are used in transmitting a message on an error, and numbers 128 to 255 are used in transmitting a message on information. In an ICMP-Packet Too Big message used in discovering a PMTU, the value in the "Type" field is 2.
FIG. 9B is a diagram showing a basic structure of an ICMP- Packet Too Big message when the value in the "Type" field of an ICMPvβ message is 2. The value in the "Type" field of the ICMPvδ message is set to 2, and the value in a "Code" field is usually set to 0 by a sender, and is neglected in a receiver. An "MTU" field indicates a next-hop link MTU value.
The destination address of an ICMP-Packet Too Big message is copied from the source address of the IP header of the received original packet.
FIG. 10A is a diagram showing a basic structure of a modified ICMP-Packet Too Big message used in a PMTU discovery method according to the present invention. Except the fact that the value of the "Code" field is 0 or 1 , the modified ICMP-Packet Too Big message shown in FIG. 10A has the same structure as that of the ICMP-Packet Too Big message of FIG. 9B.
When an ICMP-Packet Too Big message is generated for a data packet transmitted from the source node, the value in the "Code" field is set to 0. When an ICMP-Packet Too Big message is generated for a PMTUD Minimizing Packet having a "Type" field number of 143, which will be explained later, the value in the "Code" field is set to 1. In the embodiment for explaining the PMTU discovery method according to the present invention, the value in the "Code" field is 0 or 1. However, even when the ICMP-Packet Too Big message of FIG. 9B, in which the value in the "Code" field is set to 0, is selectively used, the PMTU discovery method according to the present invention can be implemented.
FIG. 10B is a diagram showing a newly defined ICMP information message used in the PMTU discovery method according to the present invention, that is, an ICMP-PMTUD Minimizing Packet. At present, numbers 128 to 255 can be used in an ICMP information message and definitions have been determined to number 142.
In an embodiment for explaining a protocol according to the present invention, a new ICMP information message having a "Type" field number of 143 is generated and used. However, it is also possible to use the PMTU discovery method according to the present invention, by using another "Type" field number that is not 143 and is not defined at present.
The number 143 indicating the PMTUD Minimizing Packet which is newly defined according to the present invention is stored in the "Type" field of the ICMP information message shown in FIG. 10B, and the value stored in the "Code" field is set to 0.
The next-hop link MTU value is stored in the "MTU" field. The source address of the previous packet being discarded is stored as a source address value, and the destination address of the previous packet being discarded is stored as a destination address value.
The newly defined ICMP information message, that is, the PMTUD Minimizing Packet is transmitted to the destination node unlike the ICMP- Packet Too Big message. To make the size of the message meet the next-hop link MTU, the message is filled with dummy data. When an OIP packet according to the present invention is lost in a routing path and the source node 710 cannot receive a response OIP packet for a predetermined time after transmission of the OIP packet 780, a PMTU discovery method using the modified ICMP-Packet Too Big message of FIG. 10A and the ICMP-PMTUD Minimizing Packet that is a newly defined ICMP information message shown in FIG. 10B is performed. Referring to FIG. 7B, the PMTU discovery method will now be explained. The predetermined time can be appropriately adjusted by considering the system and network environment.
The source node 710 which operates as a host shown in FIG. 7B comprises a function unit which can distinguish between 0 and 1 of the "Code" field of the modified ICMP-Packet Too Big message, and immediately after this message is received, newly defines a PMTU, and retransmits a packet satisfying the size of the new PMTU.
Each of the first node 720, the fourth node 750, and the fifth node 760 comprises a function unit which can distinguish between 0 and 1 of the "Code" field of the modified ICMP-Packet Too Big message as in the source node, and generates the modified ICMP-Packet Too Big message of FIG. 10A and the ICMP-PMTUD Minimizing Packet, which is the newly defined ICMP information message of FIG. 10B. Also, each of these nodes comprises a storage space, as shown in FIG. 6, for example, a cache (not shown), for storing the source address, destination address, and previous PMTU information stored in the discarded ICMP-PMTUD Minimizing Packet, for a predetermined time, when the ICMP-PMTUD Minimizing Packet is discarded.
The source node 710 transmits packet φ, which is fragmented according to the next-hop link MTU value, that is, MTU=6, to the destination node 770.
Since the size of the received packet φ is greater than the next- hop link MTU value of 5, the first node 720 generates an ICMP-Packet Too Big message containing the next-hop link MTU information, that is, MTU=5, and transmits the message to the source node 710. Here, since this message is an ICMP error message for the data packet which is originally desired to be transmitted by the source node 710, the value in the "Code" field is 0. The first node 720 also generates an ICMP- PMTUD Minimizing Packet φ which is generated to satisfy the next-hop link MTU=5 and shown in FIG. 10B, and transmits the packet to the destination node 770.
Since the size of the ICMP-PMTUD Minimizing Packet φ which is transmitted by the first node 720 is greater than the next-hop link MTU value of 4, the fourth node 750 generates an ICMP-Packet Too Big message ® containing the next-hop link MTU information, that is, MTU=4, and transmits the message to the source node 710. Here, since the message is about an ICMP-PMTUD Minimizing Packet, the value in the "Code" field is 1. Also, the fourth node 750 stores information stored in the "MTU", "Source Address," and "Destination Address" fields of the previous ICMP-PMTUD Minimizing Packet, that is, the ICMP-PMTUD Minimizing Packet φ which is transmitted by the first node 720, into a storage space, for example, a cache having the structure shown in FIG. 8. In addition, the fourth node 750 generates an ICMP-PMTUD Minimizing Packet © which is generated to satisfy the next-hop link MTU=4, and transmits the packet to the destination node 770.
Since the size of the ICMP-PMTUD Minimizing Packet © which is transmitted by the fourth node 750 is greater than the next-hop link MTU value 3, the fifth node 760 generates an ICMP-Packet Too Big message © containing the next-hop link MTU information, that is, MTU=3, and transmits the message to the source node 710. Here, since the message is about an ICMP-PMTUD Minimizing Packet ©, the value in the "Code" field is 1. Also, the fifth node 760 stores information stored in the "MTU", "Source Address," and "Destination Address" fields of the previous ICMP-PMTUD Minimizing Packet, that is, the ICMP- PMTUD Minimizing Packet © which is transmitted by the fourth node 750, into a cache, and generates an ICMP-PMTUD Minimizing Packet © which is generated to satisfy the next-hop link MTU=3, and transmits the packet to the destination node 770. Meanwhile, after receiving the ICMP-Packet Too Big message φ having a "Code" field value of 0 and which is transmitted by the first node 720, the source node 710 fragments the packet according to the link MTU value contained in the message, that is, MTU=5, and transmits the fragmented packet.
If the source node 710 receives the ICMP-Packet Too Big message ® having a "Code" field value of 1 and which is transmitted by the fifth node 760 before the source node 710 transmits the packet fragmented according to the link MTU value, that is, MTU=5, contained in the ICMP-Packet Too Big message φ having a "Code" field value of 0 and which is transmitted by the first node 720, the source node 710 discards the packet fragmented according to the ICMP-Packet Too Big message φ, and again fragments the packet according to the MTU value, that is, the size of MTU=4, contained in the ICMP-Packet Too Big message ® having a "Code" field value of 1 , and transmits the fragmented packet.
If the source node 710 transmits the packet fragmented according to the MTU information, that is, MTU=5, contained in the ICMP-Packet Too Big message having a "Code" field value of 0, before the source node 710 receives the ICMP-Packet Too Big message having a "Code" field value of 1 , the packet fragmented according to MTU=5 can arrive at the fourth node 750. However, since the next-hop link MTU is 4, the fourth node 750 discards the packet.
The fourth node 750 already stored information stored in "MTU", "Source Address," and "Destination Address" fields of the ICMP-PMTUD Minimizing Packet © which was transmitted by the first node 720, in the cache. Since these values stored in the cache are the same as the information in the packet, the fourth node 750 does not generate a separate ICMP error message. By doing so, it is possible to prevent unnecessary use of network resources. Industrial Applicability
In the embodiments according to the present invention, it is assumed that all nodes on the routing path between the source node and destination node support the modified ICMP-Packet Too Big message of FIG. 10A and the ICMP PMTUD Minimizing Packet that is the newly defined ICMP information message of FIG. 10B, according to the present invention. However, even though some of these nodes do not support the messages according to the present invention, PMTU discovery between the source node and destination node by using the prior art PMTU discovery method is also possible.
Optimum embodiments have been explained above and are shown. However, the present invention is not limited to the preferred embodiment described above, and it is apparent that variations and modifications by those skilled in the art can be effected within the spirit and scope of the present invention defined in the appended claims.
The present invention may be embodied in a code, which can be read by a computer, on a computer readable recording medium. The computer readable recording medium includes all kinds of recording apparatuses on which computer readable data are stored. The computer readable recording media includes storage media such as magnetic storage media (e.g., ROM's, floppy disks, hard disks, etc.), optically readable media (e.g., CD-ROMs, DVDs, etc.) and carrier waves (e.g., transmissions over the Internet). Also, the computer readable recording media can be scattered on computer systems connected through a network and can store and execute a computer readable code in a distributed mode.
As described above, when the PMTU increasing method according to the present invention is used, a PMTU can be determined in a shorter time, and it is possible to minimize the use of network resources, compared to prior art PMTU methods. Also, even though some of nodes in a routing path do not support the packet type according to the present invention, PMTU discovery between the source node and destination node can be performed by using the prior art PMTU discovery method.
While the invention has been particularly shown and described with reference to preferred embodiments thereof, it will be understood by those of ordinary skill in the art that various changes in form and details may be made therein without departing from the spirit and scope of the present invention as defined by the appended claims.

Claims

What is claimed is
1. A method for changing a path maximum transmission unit
(PMTU) between a source node and a destination node on a dynamic Internet protocol (IP) network, the method comprising: (a) generating a PMTU discovery packet having a maximum transmission unit (MTU) information storage space in which an MTU value on a routing path between the source node and the destination node is stored;
(b) transmitting the generated PMTU discovery packet to the destination node; and
(c) if a response packet to the PMTU discovery packet from the destination node is received, changing the PMTU according to MTU information contained in the response packet, wherein the MTU value stored in the MTU information storage space is compared with a link MTU value on a path which the PMTU discovery packet traverses, and the smaller one of the stored MTU value and the link MTU value on the path which the packet traverses is stored in the MTU information storage space.
2. The method of claim 1 , wherein the PMTU discovery packet which is generated in step (a) is generated if a current PMTU value is maintained for a predetermined time.
3. The method of claim 1 , wherein the size of the PMTU discovery packet is equal to or less than the size of the current PMTU.
4. The method of claim 1 , wherein in step (a) a next-hop link MTU value of the source node is stored in the MTU information storage space.
5. The method of claim 1 , wherein step (c) comprises step (d) which if the PMTU discovery packet arrives at the destination node, a packet containing the MTU value stored in the MTU information storage space of the PMTU discovery packet is generated, and the packet is transmitted to the source node.
6. The method of claim 1 , wherein the PMTU discovery packet is a packet which complies with Internet Protocol version 6 and has a hop-by- hop option header that is an extension header.
7. The method of claim 6, wherein option type field of the hop-by- hop option header of the PMTU discovery packet stores information indicating that if a node in the middle of a routing path does not recognize the option type of the PMTU discovery packet, the PMTU discovery packet should be discarded.
8. The method of claim 7, wherein the information indicating that the PMTU discovery packet should be discarded is the highest 2 bits stored in the option type field.
9. The method of claim 6, wherein the option type field stores information indicating whether or not it is possible to change MTU information stored in the MTU information storage space.
10. The method of claim 9, wherein the information indicating whether or not it is possible to change MTU information is the third highest bit stored in the option type field.
11. The method of claim 1 , wherein the field in which the MTU information is stored is option data field in the option field of the hop-by- hop header of IPv6.
12. The method of claim 1 , further comprising:
(d) if a response packet is not received for a predetermined time after transmitting the PMTU discovery packet to the destination node, transmitting a packet fragmented according to a predetermined PMTU value, to the destination node.
13. The method of claim 12, wherein the predetermined size is a next-hop link MTU of the source node.
14. The method of claim 12, further comprising:
(e) if an error message is received after transmitting the packet fragmented according to the predetermined PMTU value, fragmenting the packet again according to link MTU information contained in the received error message and transmitting the packet.
15. The method of claim 14, wherein the error message is an Internet Control Message Protocol (ICMP) error message which uses one of numbers 0 to 127 in a "Type" field of an ICMP message of Internet Protocol version 6 (IPv6).
16. The method of claim 15, wherein the error message is an ICMP- Packet Too Big message of IPv6.
17. The method of claim 12, further comprising:
(f) if the size of the packet transmitted in step (d) is greater than a next-hop link MTU of a node in the middle of a routing path, the node generating an error message, transmitting the generated error message to the source node, generating a test message of the size of the next-hop link MTU of the node, and transmitting the generated test packet to the destination node.
18. The method of claim 17, wherein the test message is an ICMP information message which uses one of numbers 128 to 255 in a "Type" field of an ICMP message of IPv6.
19. The method of claim 17, wherein the test message generated in step (f) contains source address and destination address information of the packet received by the node, and next-hop link MTU information of the node.
20. The method of claim 17, further comprising:
(g) if the packet received by the node is a test message generated by a previous node in the routing path, storing MTU information, source address information, and destination address information contained in the received packet.
21. The method of claim 20, further comprising:
(h) comparing the MTU information, source address information, and destination address information of a packet received after transmitting the error message generated in step (f) to the source node, with the MTU information, source address information, and destination address information stored in step (g), and if the information in each of the comparison is the same, discovering the packet received after transmitting the error message generated in step (g) without generating the error message and the test message.
22. An apparatus for changing a path maximum transmission unit (PMTU) between a source node and a destination node on a dynamic IP network, the apparatus comprising: a PMTU discovery packet generation unit which generates a
PMTU discovery packet having an MTU information storage space in which a maximum transmission unit (MTU) value on a routing path between the source node and the destination node is stored; a transmission unit which transmits the generated PMTU discovery packet to the destination node; and a PMTU changing unit, which if a response packet to the PMTU discovery packet from the destination node is received, changes the PMTU according to MTU information contained in the response packet, wherein the MTU value stored in the MTU information storage space is compared with a link MTU in a path which the PMTU discovery packet traverses, and the smaller one of the stored MTU value and the link MTU value in the traverse path is stored in the MTU information storage space.
23. The apparatus of claim 22, wherein the PMTU discovery packet is generated if the current PMTU value is maintained for a predetermined time.
24. The apparatus of claim 22, wherein the size of the PMTU discovery packet is equal to or less than the size of the current PMTU.
25. The apparatus of claim 22, wherein a next-hop link MTU value of the source node is stored in the MTU information storage space.
26. The apparatus of claim 22, wherein if the PMTU discovery packet arrives at the destination node, a packet containing the MTU value stored in the MTU information storage space of the PMTU discovery packet is generated and transmitted to the source node.
27. The apparatus of claim 22, wherein the PMTU discovery packet is a packet which complies with Internet Protocol version 6 and has a hop-by-hop option header that is an extension header.
28. The apparatus of claim 27, wherein option type field of the hop- by-hop option header of the PMTU discovery packet stores information indicating that if a node in the middle of a routing path does not recognize the option type of the PMTU discovery packet, the PMTU discovery packet should be discarded.
29. The apparatus of claim 28, wherein the information indicating that the PMTU discovery packet should be discarded is the highest 2 bits stored in the option type field.
30. The apparatus of claim 27, wherein the option type field stores information indicating whether or not it is possible to change MTU information stored in the MTU information storage space.
31. The apparatus of claim 30, wherein the information indicating whether or not it is possible to change MTU information is the third highest bit stored in the option type field.
32. The apparatus of claim 22, wherein the field in which the MTU information is stored is an option data field in the option field of the hop- by-hop header of IPv6.
33. The apparatus of claim 22, wherein if a response packet is not received for a predetermined time after transmitting the PMTU discovery packet to the destination node, a packet fragmented according to a predetermined PMTU value is transmitted to the destination node.
34. The apparatus of claim 33, wherein the predetermined size is a next-hop link MTU of the source node.
35. The apparatus of claim 33, wherein if an error message is received after transmitting the packet fragmented according to the predetermined PMTU value, the packet is fragmented again according to link MTU information contained in the received error message and is transmitted.
36. The apparatus of claim 35, wherein the error message is an Internet Control Message Protocol (ICMP) error message which uses one of numbers 0 to 127 in a "Type" field of an ICMP message of Internet Protocol version 6 (IPv6).
37. The apparatus of claim 35, wherein the error message is an ICMP-Packet Too Big message of IPv6.
38. The apparatus of claim 33, wherein if the size of the transmitted packet is greater than a next-hop link MTU of a node in the middle of a routing path, the node generates an error message, transmits the generated error message to the source node, generates a test message of the size of the next-hop link MTU of the node, and transmits the generated test packet to the destination node.
39. The apparatus of claim 38, wherein the test message is an ICMP information message which uses one of numbers 128 to 255 in a "Type" field of an ICMP message of IPv6.
40. The apparatus of claim 38, wherein the generated test message contains source address and destination address information of the packet received by the node and next-hop link MTU information of the node.
41. The apparatus of claim 38, wherein if the packet received by the node is a test message generated by a previous node in the routing path, MTU information, source address information, and destination address information contained in the received packet are stored.
42. The apparatus of claim 42, wherein the MTU information, source address information, and destination address information of a packet, which is received after transmitting the generated error message to the source node, are compared with the stored MTU information, source address information, and destination address information, and if the information in each of the comparison is the same, discovering the packet received after transmitting the error message generated without generating the error message and the test message.
PCT/KR2003/000383 2002-03-29 2003-02-26 Method for changing pmtu on dynamic ip network and apparatus using the method WO2003084145A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
AU2003215923A AU2003215923A1 (en) 2002-03-29 2003-02-26 Method for changing pmtu on dynamic ip network and apparatus using the method
EP03745469A EP1491005A4 (en) 2002-03-29 2003-02-26 Method for changing pmtu on dynamic ip network and apparatus using the method

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US36832902P 2002-03-29 2002-03-29
US60/368,329 2002-03-29
KR10-2002-0034132 2002-06-18
KR10-2002-0034132A KR100453056B1 (en) 2002-03-29 2002-06-18 Method for changing PMTU on dynamic IP network and apparatus thereof

Publications (1)

Publication Number Publication Date
WO2003084145A1 true WO2003084145A1 (en) 2003-10-09

Family

ID=28677697

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2003/000383 WO2003084145A1 (en) 2002-03-29 2003-02-26 Method for changing pmtu on dynamic ip network and apparatus using the method

Country Status (4)

Country Link
EP (1) EP1491005A4 (en)
CN (1) CN1647454A (en)
AU (1) AU2003215923A1 (en)
WO (1) WO2003084145A1 (en)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2406245A (en) * 2003-09-17 2005-03-23 Siemens Ag Packet transmission utlising maximum segment size (MSS)/maximum transmission unit (MTU) information
CN100375433C (en) * 2003-11-13 2008-03-12 中兴通讯股份有限公司 Method for dynamically discovering IPsec tunnel PMTU
US7697524B2 (en) 2005-04-05 2010-04-13 Cisco Technology, Inc. Method and system for determining path maximum transfer unit for IP multicast
US8364824B2 (en) 2005-09-08 2013-01-29 International Business Machines Corporation Reducing the learning curve of a transmission control protocol connection
US20160218962A1 (en) * 2015-01-26 2016-07-28 Mediatek Inc. Maximum Transmission Unit Size Reporting and Discovery by a User Equipment

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100459576C (en) * 2005-08-05 2009-02-04 华为技术有限公司 Method for detecting maximal transmission unit of path
CN1992638A (en) * 2005-12-26 2007-07-04 华为技术有限公司 Method and system for obtaining path maximum transmission unit in network
CN101022419B (en) * 2007-03-27 2011-04-06 杭州华三通信技术有限公司 Path maximum transmission unit item establishing method and message transmitting method and device
CN101207571B (en) * 2007-12-12 2011-04-20 华为技术有限公司 Apparatus and method for forwarding packets
JP5200755B2 (en) * 2008-08-20 2013-06-05 日本電気株式会社 Wireless base station, wireless communication system, path connection method and program
CN103117949B (en) * 2013-01-24 2016-08-10 杭州华三通信技术有限公司 A kind of message transmitting method based on lsp tunnel and equipment
CN106302246A (en) * 2015-06-03 2017-01-04 中兴通讯股份有限公司 A kind of method and apparatus adjusting IPv6 tunnel MTU
CN113162866B (en) * 2020-01-22 2023-08-01 中国移动通信有限公司研究院 Message transmission method, communication equipment and medium

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6341129B1 (en) * 1998-04-03 2002-01-22 Alteon Networks, Inc. TCP resegmentation

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6341129B1 (en) * 1998-04-03 2002-01-22 Alteon Networks, Inc. TCP resegmentation

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
BILIC H. ET AL.: "Deferred segmentation for wired-speed transmission of large TCP frames over standard GbE networks", HOT INTERCONNECTS 9, 22 August 2001 (2001-08-22) - 24 August 2001 (2001-08-24), pages 81 - 85, XP008070332 *
FARRELL P.A., HONG ONG: "Communication performance over a gigabit ethernet network", IEEE INTERNATIONAL PERFORMANCE, COMPUTING AND COMMUNICATIONS, 20 February 2000 (2000-02-20) - 22 February 2000 (2000-02-22), pages 181 - 189, XP010500024 *
See also references of EP1491005A4 *
YASU Y. ET AL.: "Quality of service on gigabit ethernet for event builder", IEEE 2000 NUCLEAR SCIENCE SYMPOSIUM CONFERENCE RECORD, vol. 3, 15 October 2000 (2000-10-15) - 20 October 2000 (2000-10-20), LYON, FRANCE, pages 26/40 - 26/44, XP010379197 *

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2406245A (en) * 2003-09-17 2005-03-23 Siemens Ag Packet transmission utlising maximum segment size (MSS)/maximum transmission unit (MTU) information
GB2406245B (en) * 2003-09-17 2006-01-04 Siemens Ag A method of transmitting packet data on a network
CN100375433C (en) * 2003-11-13 2008-03-12 中兴通讯股份有限公司 Method for dynamically discovering IPsec tunnel PMTU
US7697524B2 (en) 2005-04-05 2010-04-13 Cisco Technology, Inc. Method and system for determining path maximum transfer unit for IP multicast
US8364824B2 (en) 2005-09-08 2013-01-29 International Business Machines Corporation Reducing the learning curve of a transmission control protocol connection
US20160218962A1 (en) * 2015-01-26 2016-07-28 Mediatek Inc. Maximum Transmission Unit Size Reporting and Discovery by a User Equipment
US9787596B2 (en) * 2015-01-26 2017-10-10 Mediatek Inc. Maximum transmission unit size reporting and discovery by a user equipment
US10142250B2 (en) 2015-01-26 2018-11-27 Hfi Innovation Inc. Maximum transmission unit size reporting using AT commands
US10142251B2 (en) 2015-01-26 2018-11-27 Hfi Innovation Inc. Control of maximum transmission unit size discovery using AT commands
US10686713B2 (en) 2015-01-26 2020-06-16 Hfi Innovation Inc. Maximum transmission unit size reporting using AT commands
US10708190B2 (en) 2015-01-26 2020-07-07 Hfi Innovation Inc. Control of maximum transmission unit size discovery using AT commands

Also Published As

Publication number Publication date
AU2003215923A1 (en) 2003-10-13
EP1491005A4 (en) 2006-09-13
CN1647454A (en) 2005-07-27
EP1491005A1 (en) 2004-12-29

Similar Documents

Publication Publication Date Title
US20030185208A1 (en) Method and apparatus for changing path maximum transmission unit on dynamic IP network
US7451227B2 (en) Method for path MTU discovery on IP network and apparatus thereof
McCann et al. Path MTU Discovery for IP version 6
US9893984B2 (en) Path maximum transmission unit discovery
JP5123367B2 (en) Filtering and routing of fragmented datagrams in data networks
US7450499B2 (en) Method and apparatus for interconnecting IPv4 and IPv6 networks
JP5648737B2 (en) Communication apparatus and communication method
Johnson et al. RFC 4728: The dynamic source routing protocol (DSR) for mobile ad hoc networks for IPv4
JPH11112574A (en) Method and system for generating data packet in different kinds of network
KR100513282B1 (en) Apparatus and method for transmitting data using path MTU in ad-hoc network
KR100462864B1 (en) Routing table Management Method using Interface ID in the IPv6
WO2003084145A1 (en) Method for changing pmtu on dynamic ip network and apparatus using the method
US7317692B2 (en) Network path discovery
US7304959B1 (en) Utility based filtering mechanism for PMTU probing
Sun et al. The Internet underwater: An IP-compatible protocol stack for commercial undersea modems
US10205651B2 (en) Apparatus and method of selecting next hops for a session
WO2004075487A1 (en) Communication or computing node and method of routing data
EP1491004A1 (en) Method for path mtu discovery on ip network and apparatus thereof
Papadopoulos et al. RFC 4944: per-hop fragmentation and reassembly issues
McCann et al. RFC1981: Path MTU Discovery for IP version 6
JP2013110689A (en) Network system, relay device, communication method, relay method and relay program
JP7008714B2 (en) Communication device
McCann et al. RFC 8201: Path MTU Discovery for IP version 6
Herrero et al. Network and Transport Layers
JP2004511136A (en) Internet protocol headers for communication networks

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SC SD SE SG SK SL TJ TM TN TR TT TZ UA UG UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PT SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
WWE Wipo information: entry into national phase

Ref document number: 2003745469

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 20038075261

Country of ref document: CN

WWP Wipo information: published in national office

Ref document number: 2003745469

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP