The structure of an Internet Protocol Packet header is as follows:
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(Note. Each tick mark represents one bit position. for a full description of all of the header fields, please read the ) This packet format is implemented as the composite type "@IP_Protocol.IP_Packet" in the MootoothWorkspace2 workspace.
In the implementation of IP created for this project, the IP service mechanisms described in the Introduction section are provided in the following manner:
The type of service is described by the 8-bit 'Type of Service' section in the header, and is arranged as follows:
Bits 0-2: Precedence.
Bit 3: 0 = Normal Delay, 1 = Low Delay.
Bits 4: 0 = Normal Throughput, 1 = High Throughput.
Bits 5: 0 = Normal Reliability, 1 = High Reliability.
Bit 6-7: Reserved for Future Use.
Since it would have taken a lot of work to simulate network conditions which would have allowed differing service qualities in VCC, all packets were transmitted with this part set to '00000000'
A packet's time to live is determined by the value in the similarly named header field, which is filled in by the sender. It is not an absolute time, but rather a value which is decremented every time the packet reaches an intermediate machine on its journey. In our VCC based implementation, this is achieved by making the IP block decrement this value in the header of every packet it receives, so the packet could be passed through multiple IP block en route to its destination. If the packet passes through so many blocks that its Time To Live expires, then it is discarded and not transmitted any further.
The 'Options' section of the IP header is used to specify various properties which may be given to a packet, but aren't used in ordinary communications. For a full list of the options, please read the RFC. Since no network conditions requiring these options could be simulated easily in VCC, all packets are sent with this field set entirely to 0 (the default value).
A checksum is used in the header, to verify that the packet has not been damaged while in transit. In our implementation, the checksum value is simply set to be the length of the packet, since it was felt that the time required to implement a proper checksum algorithm could be better spent on other tasks.
In order to send data via IP, TCP activates the 'IP_Send_Port' of the 'IP_TCP_HANDLER' block, passing a TCP_Packet as an argument. This is then 'wrapped-up' in an IP_Packet. The TCP packet data is put into the 'byte_array' field of the IP_Packet composite type in VCC. The IP headers are then filled in as appropriate. This IP_Packet is then sent to the 'IP_PPP_HANDLER' block to be bundled up and sent to the PPP layer.
The 'IP_PPP_HANDLER' block takes this IP_Packet and puts it into the data field of a PPP_Packet , along with a 2-byte PPP header which signifies the protocol which is being used to send this packet. The PPP_Packet is then output to PPP by activating the 'Send_PPP' port.
In order for data to be received by IP and then passed to the layer above it, PPP activates the 'Receive_IP' port on the 'IP_PPP_HANDLER', passing a 'PPP_Packet' as an argument. The 2-byte 'protocol' header on the PPP_Packet is examined to ensure that this packet is indeed intended to be received by IP. The IP_Packet which is contained in the data field of the PPP_Packet is then passed to the 'IP_TCP_HANDLER' block.
The IP_Packet is then examined. The destination address of the packet is examined, and if it matches the address of this IP block (which is a parameter of each instance of the block), and it still has some Time To Live, the byte_array (which is actually a full TCP packet) section of the IP_Packet is removed and placed into a TCP_Packet structure and sent to TCP via the 'IP_Receive_Port'
The 'ClearSignal' port is activated by the multiplier block, in conjunction with the PPP block's Clear-to-Send-Signal, and informs the IP block that it is free to send more data. This signal is also passed up to TCP, in order to let TCP know that IP is ready to receive more data.
The implementation of IP as created in VCC is fairly complete with respect to the specification, and meets all of the requirements for a minimal version of IP. The only potentially major feature which has not been implemented is IP's ability to fragment data for transfer over small packet networks. Since this would be almost directly duplicating work done while implementing TCP, it was felt that this feature could be reasonably left out, to allow more time to work in other areas.
General Service Mechanisms
Type of Service
Time To Live
Options
Header Checksum
Sending Data
Receiving Data
Clear to Send
Summary