Data forwarding can be collectively defined as either local or remote for which the forwarding process relies on the application of the protocol stack in order to achieve end-to-end transmission. End systems may be part of the same network, or located in different networks, however the general forwarding principle to enable transmission between hosts follows a clear set of protocols that have been introduced as part of the unit. How these protocols work together shall be reinforced, as well as building the relationship between the upper layer TCP/IP protocols and the lower link layer based Ethernet protocol standards.
An end system that intends to forward data to a given destination must initially determine whether or not it is possible to reach the intended destination. In order to achieve this, the end system must go through a process of path discovery. An end system should be understood to be capable of supporting operation at all layers since its primary function is as a host to applications. In relation to this, it must also be capable of supporting lower layer operations such as routing and link layer forwarding (switching) in order to be capable of upper/application layer data forwarding. The end system therefore contains a table that represents network layer reachability to the network for which the upper layer data is destined.
End systems will commonly be aware of the network to which they reside, but may be without a forwarding path in cases where remote network discovery has not been achieved. In the example given, host A is in possession of a path to the destined network through the ‘any network’ address that was briefly introduced as part of the IP Addressing section. The forwarding table identifies that traffic should be forwarded to the gateway as a next-hop via the interface associated with the logical address of 10.1.1.1.
Following discovery of a feasible route towards the intended destination network, a physical next-hop must also be discovered to facilitate frame forwarding. The TCP/IP protocol suite is responsible for determining this before packet encapsulation can proceed. The initial step involves determining whether a physical path exists to the next-hop identified as part of the path discovery process.
This requires that the ARP cache table be consulted to identify whether an association between the intended next-hop and the physical path is known. From the example it can be seen that an entry to the next-hop gateway address is present in the ARP cache table. Where an entry cannot be found, the Address Resolution Protocol (ARP) must be initiated to perform the discovery and resolve the physical path.
When both the logical and physical path forwarding discovery is complete, it is possible for encapsulation of data to be performed for successful transmission over IP/Ethernet based networks. Upper layer processes in terms of encryption and compression may be performed following which transport layer encapsulation will occur, identifying the source and destination ports via which upper layer data should be forwarded.In the case of TCP, sequence and acknowledgement fields will be populated, code bits set as necessary with the ACK bit commonly applied. The window field will be populated with the current supported window size, to which the host will notify of the maximum data buffer that can be supported before data is acknowledged.
Values representing the TCP fields are included as part of the checksum, which is calculated using a ones compliment calculation process, to ensure TCP segment integrity is maintained once the TCP header is received and processed at the ultimate destination. In the case of basic TCP code operations, upper layer data may not always be carried in the segment, as in the case of connection synchronization, and acknowledgements to received data.
Following transport layer encapsulation, it is generally required that instructions be provided, detailing how transmission over one or more networks is to be achieved. This involves listing the IP source as well as the ultimate destination for which the packet is intended. IP packets are generally limited to a size of 1500 bytes by Ethernet, inclusive of the network and transport layer headers as well as any upper layer data. Initial packet size will be determined by Ethernet as the maximum transmission unit, or MTU to which packets will conform, therefore fragmentation will not occur at the source.
In the case that the MTU changes along the forwarding path, only then will fragmentation will be performed. The Time to Live field will be populated with a set value depending on the system, in ARG3 series routers, this is set with an initial value of 255. The protocol field is populated based on the protocol encapsulated prior to IP. In this case the protocol in question is TCP for which the IP header will populate the protocol field with a value of 0x06 as instruction for next header processing. Source and destination IP addressing will reflect the originating source and the ultimate destination.
Link layer encapsulation relies on IEEE 802.3 Ethernet standards for physical transmission of upper layer data over Ethernet networks. Encapsulation at the lower layers is performed by initially determining the frame type that is used. Where the upper layer protocol is represented by a type value greater than 1536 (0x0600) as is the case with IP (0x0800), the Ethernet II frame type is adopted. The type field of the Ethernet II frame header is populated with the type value of 0x0800 to reflect that the next protocol to be processed following frame processing will be IP. The destination MAC address determines the next physical hop, which in this case represents the network gateway.
As part of the link layer operation, it is imperative to ensure that the transmission medium is clear of signals in shared collision domain. The host will first listen for any traffic on the network as part of CSMA/CD and should the line remain clear, will prepare to transmit the data. It is necessary for the receiving physical interface to be made aware of the incoming frame, so as to avoid loss of initial bit values that would render initial frames as incomplete. Frames are therefore preceded by a 64 bit value indicating to the link layer destination of the frame’s imminent arrival.
The initial 56 bits represent an alternating 1, 0 pattern is called the preamble, and is followed immediately by an octet understood as the Start of Frame Delimiter (SFD). The final two bits of the SFD deviate from an alternating pattern to a 1,1 bit combination that notifies that the bits that follow represent the first bit values of the destination MAC address and therefore the start of the frame header.
As a frame is received by the link layer destination, it must go through a number of checks to determine its integrity as well as validity. If the frame was transmitted over a shared Ethernet network, other end stations may also receive an instance of the frame transmitted, however since the frame destination MAC address is different from the MAC address of the end station, the frame will be discarded.
Frames received at the intended destination will perform error checking by calculating the ones compliment value based on the current frame fields and compare this against the value in the Frame Check Sequence (FCS) field. If the values do not match, the frame will be discarded. Receiving intermediate and end systems that receive valid frames will need to determine whether the frame is intended for their physical interface by comparing the destination MAC address with the MAC address of the interface (or device in some cases).
If there is a match, the frame is processed and the type field is used to determine the next header to be processed. Once the next header is determined, the frame header and trailer are discarded.
The packet is received by the network layer, and in particular IP, at which point the IP header is processed. A checksum value exists at each layer of the protocol stack to maintain the integrity at all layers for all protocols. The destination IP is used to determine whether the packet has reached its ultimate destination. The gateway however determines that this is not the case since the destination IP and the IP belonging to the gateway do not match.
The gateway must therefore determine the course of action to take with regards to routing the packet to an alternate interface, and forward the packet towards the network for which it is intended. The gateway must firstly however ensure that the TTL value has not reached 0, and that the size of the packet does not exceed the maximum transmission unit value for the gateway. In the event that the packet is larger than the MTU value of the gateway, fragmentation will generally commence.
Once a packet’s destination has been located in the forwarding table of the gateway, the packet will be encapsulated in a new frame header consisting of new source and destination MAC addresses for the link layer segment, over which the resulting frame is to be forwarded, before being once again transmitted to the next physical hop. Where the next physical hop is not known, ARP will again be used to resolve the MAC address.
Frames received at the ultimate destination will initially determine whether the frame has arrived at the intended location. The example shows two servers on a shared Ethernet network over which both receive a copy of the frame.The frame is ultimately discarded by server B since the destination MAC value and the interface MAC address of server B do not match. Server A however successfully receives the frame and learns that the MAC fields are the same, the integrity of the frame based on the FCS can also be understood to be correct. The frame will use the type field to identify 0x0800 as the next header, following which the frame header and trailer are discarded and the packet is received by IP.
Upon reaching the ultimate destination, the IP packet header must facilitate a number of processes. The first includes validating the integrity of the packet header through the checksum field, again applying a ones compliment value comparison based on a sum of the IP header fields. Where correct, the IP header will be used to determine whether the destination IP matches the IP address of the current end station, which in this case is true.
If any fragmentation occurred during transmission between the source and the destination, the packet must be reassembled at this point. The identification field will collect the fragments belonging to a single data source together, the offset will determine the order and the flags field will specify when the reassembly should commence, since all fragments must be received firstly and a fragment with a flag of 0 will be recognized as the last fragment to be received.
A timer will then proceed during which time the reassembly must be completed, should reassembly fail in this time period, all fragments will be discarded. The protocol field will be used to identify the next header for processing and the packet header will be discarded. It should be noted that the next header may not always be a transport layer header, a clear example of where this can be understood is in the case of ICMP, which is understood to also be a network layer protocol with a protocol field value of 0x01.
In the case where a packet header is discarded, the resulting segment or datagram is passed to the transport layer for application-to-application based processing. The header information is received in this case by TCP (0x06).
In the example it can be understood that a TCP connection has already been established and the segment represents an acknowledgement for the transmission of HTTP traffic from the HTTP server to the acknowledging host. The host is represented by the port 1027 as a means to distinguish between multiple HTTP connections that may exist between the same source host and destination server. In receiving this acknowledgement, the HTTP server will continue to forward to the host within the boundaries of the window size of the host.
SUMMARY
Prior to the encapsulation and forwarding of data, a source must have knowledge of the IP destination or an equivalent forwarding address such as a default address to which data can be forwarded. Additionally it is necessary that the forwarding address be associated with a physical next-hop to which the data can be forwarded within the local network.
Any frame that is received by a gateway or end system (host) to which it is not intended, is subsequently dropped, following inspection of the destination MAC address in the frame header.
The delivery of data relies on the destination port number in the TCP and UDP headers to identify the application to which the data is intended. Following analysis of this value by the TCP or UDP protocol, the data is forwarded.
The source port of the TCP header for the HTTP traffic distinguishes between the different application sessions that are active. Return HTTP traffic from the HTTP server is able to identify each individual web browser session based on this source port number. For example, the source port of two separate requests for HTTP traffic originating from IP source 10.1.1.1 may originate from source ports 1028 and 1035, however the destination port in both cases remains as port 80, the HTTP server.