|
Viewed
Inside MCSE
|
TCP/IP Core ProtocolsThe TCP/IP protocol component that is installed in your network operating system is a series of interconnected protocols called the core protocols of TCP/IP. All other applications and other protocols in the TCP/IP protocol suite rely on the basic services provided by the following protocols: IP, ARP, ICMP, IGMP, TCP, and UDP. IPIP is a connectionless, unreliable datagram protocol primarily responsible for addressing and routing packets between hosts. Connectionless means that a session is not established before exchanging data. Unreliable means that delivery is not guaranteed. IP will always make a best effort attempt to deliver a packet. An IP packet might be lost, delivered out of sequence, duplicated, or delayed. IP does not attempt to recover from these types of errors. The acknowledgment of packets delivered and the recovery of lost packets is the responsibility of a higher-layer protocol, such as TCP. IP is defined in RFC 791. An IP packet consists of an IP header and an IP payload. Table 3 describes the key fields in the IP header. Table 3 Key fields in the IP header
Fragmentation and ReassemblyIf a router receives an IP packet that is too large for the network onto which the packet is being forwarded, IP will fragment the original packet into smaller packets that will fit on the downstream network. When the packets arrive at their final destination, IP at the destination host reassembles the fragments into the original payload. This process is referred to as fragmentation and reassembly. Fragmentation can occur in environments that have a mix of networking technologies, such as Ethernet and Token Ring. The fragmentation and reassembly works as follows: 1. When an IP packet is sent by the source, it places a unique value in the Identification field. 2. The IP packet is received at the router. The IP router notes that the maximum transmission unit (MTU) of the network onto which the packet is to be forwarded is smaller than the size of the IP packet. 3. IP fragments the original IP payload into fragments that will fit on the next network. Each fragment is sent with its own IP header which contains:
4. When the fragments are received by IP at the remote host, they are identified by the Identification field as belonging together. The Fragment Offset is then used to reassemble the fragments into the original IP payload. ARPWhen IP packets are sent on shared access, broadcast-based networking technologies such as Ethernet or Token Ring, the Media Access Control (MAC) address corresponding to a forwarding IP address must be resolved. ARP uses MAC-level broadcasts to resolve a known forwarding IP address to its MAC address. ARP is defined in RFC 826. For more information on ARP, see the "Physical Address Resolution" section later in this paper. ICMPInternet Control Message Protocol (ICMP) provides troubleshooting facilities and error reporting for packets that are undeliverable. For example, if IP is unable to deliver a packet to the destination host, ICMP will send a Destination Unreachable message to the source host. Table 4 shows the most common ICMP messages. Table 4 Common ICMP messages
To send ICMP Echo Request messages and view statistics on the responses on a Windows NT-based computer, use the ping utility at a Windows NT command prompt. There are a series of defined Destination Unreachable ICMP messages. Table 5 describes the most common ICMP Destination Unreachable messages. Table 5 Common ICMP Destination Unreachable messages
ICMP does not make IP a reliable protocol. ICMP attempts to report errors and provide feedback on specific conditions. ICMP messages are carried as unacknowledged IP datagrams and are themselves unreliable. ICMP is defined in RFC 792. IGMPInternet Group Management Protocol (IGMP) is a protocol that manages host membership in IP multicast groups. An IP multicast group, also known as a host group, is a set of hosts that listen for IP traffic destined for a specific multicast IP address. Multicast IP traffic is sent to a single MAC address but processed by multiple IP hosts. A given host listens on a specific IP multicast address and receives all packets to that IP address. Some additional aspects of IP multicasting:
For a host to receive IP multicasts, an application must inform IP that it will be receiving multicasts at a specified destination IP multicast address. If the network technology supports hardware-based multicasting, then the network interface is told to pass up packets for a specific multicast address. In the case of Ethernet, the network interface card is programmed to respond to a multicast MAC address corresponding to the desired IP multicast address. A host supports IP multicast at one of the following levels:
The protocol to register host group information is IGMP. IGMP is required on all hosts that support level 2 IP multicasting. IGMP packets are sent using an IP header. IGMP messages take two forms:
For IP multicasting to span routers across an internetwork, multicast routing protocols are used by routers to communicate host group information so that each router supporting multicast forwarding is aware of which networks contain members of which host groups. TCPTCP is a reliable, connection-oriented delivery service. The data is transmitted in segments. Connection-oriented means that a connection must be established before hosts can exchange data. Reliability is achieved by assigning a sequence number to each segment transmitted. An acknowledgment is used to verify that the data was received by the other host. For each segment sent, the receiving host must return an acknowledgment (ACK) within a specified period for bytes received. If an ACK is not received, the data is retransmitted. TCP is defined in RFC 793. TCP uses byte-stream communications, wherein data within the TCP segment is treated as a sequence of bytes with no record or field boundaries. Table 6 describes the key fields in the TCP header. Table 6 Key fields in the TCP header
TCP PortsA TCP port provides a specific location for delivery of TCP segments. Port numbers below 1024 are well-known ports and are assigned by the Internet Assigned Numbers Authority (IANA). Table 7 lists a few well-known TCP ports. Table 7 Well-known TCP ports
For a complete list of assigned TCP ports, see RFC 1700 from the above menu RFC [2] Ref. The TCP Three-Way HandshakeA TCP connection is initialized through a three-way handshake. The purpose of the three-way handshake is to synchronize the sequence number and acknowledgment numbers of both sides of the connection, exchange TCP Window sizes, and exchange other TCP options such as the maximum segment size. The following steps outline the process:
TCP uses a similar handshake process to end a connection. This guarantees that both hosts have finished transmitting and that all data was received. UDPUDP provides a connectionless datagram service that offers unreliable, best-effort delivery of data transmitted in messages. This means that the arrival of datagrams is not guaranteed; nor is the correct sequencing of delivered packets. UDP does not recover from lost data through retransmission. UDP is defined in RFC 768. UDP is used by applications that do not require an acknowledgment of receipt of data and that typically transmit small amounts of data at one time. The NetBIOS name service, NetBIOS datagram service, and the Simple Network Management Protocol (SNMP) are examples of services and applications that use UDP. Table 8 describes the key fields in the UDP header. Table 8 Key fields in the UDP header
UDP PortsTo use UDP, an application must supply the IP address and UDP port number of the destination application. A port provides a location for sending messages. A port functions as a multiplexed message queue, meaning that it can receive multiple messages at a time. Each port is identified by a unique number. It's important to note that UDP ports are distinct and separate from TCP ports even though some of them use the same number. Table 9 lists well-known UDP ports. Table 9 Well-known UDP ports
For a complete list of assigned UDP ports, see RFC 1700 from the above menu RFC [2] Ref. |
| The MCP Logo is displayed on this web site in accordance with Microsoft Certified Professional Program and Logo Agreement. © Paramvir Likhari 1997 - 1999 |