Classifications

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

Definitions

• 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.
• MTU maximum transmission unit
• PMTU changing path MTU
• IPv4 Internet Protocol version 4
• IPv6 Internet Protocol version 6
• IPv6 Internet Protocol version 6
• 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.
• an IPv6 node that is, a source node
• 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.
• PMTU path MTU
• the source node fragments the packet in units each having the size of a next-hop link MTU and transmits the fragmented packet.
• 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.
• 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.
• 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
• 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.
• 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 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
• 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.
• an apparatus for changing a path maximum transmission unit (PMTU) between a source node and a destination node on a dynamic IP network 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.
• PMTU discovery packet generation unit which generates a PMTU discovery packet having an MTU information storage space in which a maximum transmission unit (MTU
• the PMTU discovery packet is generated if the current PMTU value is maintained for a predetermined time.
• the size of the PMTU discovery packet is equal to or less than the size of the current PMTU.
• 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.
• 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.
• FIG. 1 is a diagram showing a prior art method for changing a path maximum transmission unit (PMTU);
• PMTU path maximum transmission unit
• 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
• 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. 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.
• 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.
• 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.
• 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.
• 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.
• option headers are shown in table 1 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
• 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.
• 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
• 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.
• the source node 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.
• OIP packet a packet in which the OIP option described above is inserted
• the next-hop link MTU value of the source node is stored.
• each node 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.
• the router discards the OIP packet.
• the router compares the MTU value stored in the MTU field of the OIP packet with the next-hop link MTU.
• the router stores the smaller one of the compared values in the MTU field of the OIP packet.
• 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.
• the destination node 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.
• the source node 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.
• FIG. 7A is a diagram showing a preferred embodiment of a PMTU changing method according to the present invention.
• the source node 710 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.
• the source node 710 uses another timer (not shown) to transmit 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 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.
• 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.
• 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.
• the bit value can be set to 1 as in the OIP packet 780.
• 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.
• 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.
• 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 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
• 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.
• the value in the "Code” field is set to 0.
• the value in the "Code” field is set to 1.
• the value in the "Code” field is 0 or 1.
• the PMTU discovery method according to the present invention can be implemented.
• a new ICMP information message having a "Type" field number of 143 is generated and used.
• 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 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.
• 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.
• 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 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.
• the message since the message is about an ICMP-PMTUD Minimizing Packet ⁇ , the value in the "Code" field is 1.
• 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.
• 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).
• 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.

Landscapes

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

Applications Claiming Priority (5)

Publications (2)

Family

ID=28677697

Family Applications (1)

Country Status (4)

Families Citing this family (13)

Family Cites Families (1)

• 2003
  • 2003-02-26 EP EP03745469A patent/EP1491005A4/fr not_active Withdrawn
  • 2003-02-26 WO PCT/KR2003/000383 patent/WO2003084145A1/fr not_active Ceased
  • 2003-02-26 CN CN03807526.1A patent/CN1647454A/zh active Pending
  • 2003-02-26 AU AU2003215923A patent/AU2003215923A1/en not_active Abandoned

Non-Patent Citations (3)

Also Published As

Similar Documents

Legal Events