Browse Prior Art Database

Enhancing data integrity at the IP(Internet Protocol) level of data communication

IP.com Disclosure Number: IPCOM000023285D
Original Publication Date: 2004-Mar-29
Included in the Prior Art Database: 2004-Mar-29
Document File: 2 page(s) / 31K

Publishing Venue

IBM

Abstract

Each client tcp/udp connection requires a unique identifier for each IP datagram that it sends to remote system. Currently all client connections on a system use a system wide global counter to provide this identifier. This counter rolls over when it's maximum value is reached. An IP datagram must be broken into multiple packets when the original datagram is too large to be transmitted by an interface while enroute from a source system to a destination system. The ip_id field of the IP datagram is a supposed unique number that is used to identify and reassemble the fragments of a datagram at the destination system. Because high speed interfaces can use most of the possible ip_id numbers(0 thru 65535) of a single system counter each second, a given connection could use the same ip_id number in consequtive IP datagrams. Reassembly of fragments with the same ip_id from different IP datagrams will cause data integrity problems that will be extremely difficult to identify/diagnose. This problem needs to be addressed to avoid possible litigation from customers whose data will be compromised in this scenario.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 2

Enhancing data integrity at the IP (Internet Protocol) level of data communication

This invention proovides the mechanisms to avoid using a single ip_id counter, for all system interfaces, that repeats too quickly. Individual ip_id counters will be maintained for each destination host/protocol(tcp or udp) combination. Hosts which reside on remote networks are reached by referencing a routing table entry called a cloned route.The current cloned route table entry will be enhanced by adding:

1) "active_flag" to indicate that network option "route_expire" has not expired due to lack of traffic to/from the remote host
2) "tcp_ip_id" to contain ip_id for tcp traffic
3) "udp_ip_id" to contain ip_id for udp traffic
4) "ip_ttl" to contain a time to live counter. This counter is decremented if this table entry changes to inactive status per "active_flag". This route table entry is held so that "tcp_ip_id" and "udp_ip_id" can be used in a replacement cloned route that is created before "ip_ttl" expires.

A cloned route will be deleted if it remains inactive for "ip_ttl" time. An inactive cloned route will also be deleted after it's replacement is created(before expiration of ip_ttl) using tcp_ip_id and udp_ip_id counters from the inactive route entry. If a cloned route is manually deleted , the cloned route table entry will be marked inactive and handled in the same manner as an entry which has been marked inactive due to lack of tcp/udp traffic. Each remote destination host address/protocol combination will therefore have access to 65536 ip_ids.

The arp table structure will be used to hold ip_...