The following explains the modifications made to the IPv4 header, which resulted in the IPv6 header shown in Figure 2.

• The header has been made fixed-length (40 bytes). Considering that two 128-bit address fields have been accommodated, the header size is a remarkable optimization (compare it with the 20 to 60-byte IPv4 header). This was made possible by getting rid of the many of the redundant fields in v4 header.
• All fields relating to fragmentation have been discarded. This functionality has been moved to optional headers. A discussion follows.
• The checksum field has been dropped. Calculating the checksum greatly reduced network performance. Error checks are already prevalent at the link and the transport layers; hence checksums at the network layer were considered redundant.
• The option of extension headers has been introduced. These headers can be supplied to provide extra information. In this way, the new IP gives network software designers a very straightforward technique for introducing new header options in the future.
• The flags and header length fields have been discarded. The functionality of the IPv4 type-of-service field has been transferred to the two new IPv6 fields: flow control and priority.
  

The following discussion describes the IP packet fields illustrated in Figure 30-2:

• Version---Indicates the version of IP currently used.
• IP Header Length (IHL)---Indicates the datagram header length in 32-bit words.
• Type-of-Service---Specifies how an upper-layer protocol would like a current datagram to be handled, and assigns datagrams various levels of importance.
• Total Length---Specifies the length, in bytes, of the entire IP packet, including the data and header.
• Identification---Contains an integer that identifies the current datagram. This field is used to help piece together datagram fragments.
• Flags---Consists of a 3-bit field of which the two low-order (least-significant) bits control fragmentation. The low-order bit specifies whether the packet can be fragmented. The middle bit specifies whether the packet is the last fragment in a series of fragmented packets. The third or high-order bit is not used.
• Fragment Offset---Indicates the position of the fragment's data relative to the beginning of the data in the original datagram, which allows the destination IP process to properly reconstruct the original datagram.
• Time-to-Live---Maintains a counter that gradually decrements down to zero, at which point the datagram is discarded. This keeps packets from looping endlessly.
• Protocol---Indicates which upper-layer protocol receives incoming packets after IP processing is complete.
• Header Checksum---Helps ensure IP header integrity.
• Source Address---Specifies the sending node.
• Destination Address---Specifies the receiving node.
• Options---Allows IP to support various options, such as security.
• Data---Contains upper-layer information.
  

3. TCP Packet Format

http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/ip.htm#24904

Figure 30-10: Twelve fields comprise a TCP packet.

TCP Packet Field Descriptions

The following descriptions summarize the TCP packet fields illustrated in Figure 30-10:

• Source Port and Destination Port---Identifies points at which upper-layer source and destination processes receive TCP services.
• Sequence Number---Usually specifies the number assigned to the first byte of data in the current message. In the connection-establishment phase, this field also can be used to identify an initial sequence number to be used in an upcoming transmission.
• Acknowledgment Number---Contains the sequence number of the next byte of data the sender of the packet expects to receive.
• Data Offset---Indicates the number of 32-bit words in the TCP header.
• Reserved---Remains reserved for future use.
• Flags---Carries a variety of control information, including the SYN and ACK bits used for connection establishment, and the FIN bit used for connection termination.
• Window---Specifies the size of the sender's receive window (that is, the buffer space available for incoming data).
• Checksum---Indicates whether the header was damaged in transit.
• Urgent Pointer---Points to the first urgent data byte in the packet.
• Options---Specifies various TCP options.
• Data---Contains upper-layer information

• 4. UDP Packet Format

Figure 30-11: A UDP packet consists of four fields.

The UDP packet format contains four fields, as shown in Figure 30-11. These include source and destination ports, length, and checksum fields. Source and destination ports contain the 16-bit UDP protocol port numbers used to demultiplex datagrams for receiving application-layer processes. A length field specifies the length of the UDP header and data. Checksum provides an (optional) integrity check on the UDP header and data.

UDP is useful in situations where the reliability mechanisms of TCP are not necessary, such as in cases where a higher-layer protocol might provide error and flow control.

UDP is the transport protocol for several well-known application-layer protocols, including Network File System (NFS), Simple Network Management Protocol (SNMP), Domain Name System (DNS), and Trivial File Transfer Protocol (TFTP).

Figure 20-5: An ATM cell, UNI cell, and ATM NNI cell header each contain 48 bytes of payload.

http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/atm.htm

ATM Cell-Header Format

An ATM cell header can be one of two formats: UNI or the NNI. The UNI header is used for communication between ATM endpoints and ATM switches in private ATM networks. The NNI header is used for communication between ATM switches. Unlike the UNI, the NNI header does not include the Generic Flow Control (GFC) field. Additionally, the NNI header has a Virtual Path Identifier (VPI) field that occupies the first 12 bits, allowing for larger trunks between public ATM switches.

In addition to GFC and VPI header fields, several others are used in ATM cell-header fields. The following descriptions summarize the ATM cell-header fields illustrated in Figure 20-5:

• Generic Flow Control (GFC)---Provides local functions, such as identifying multiple stations that share a single ATM interface. This field is typically not used and is set to its default value.
• Virtual Path Identifier (VPI)---In conjunction with the VCI, identifies the next destination of a cell as it passes through a series of ATM switches on the way to its destination.
• Virtual Channel Identifier (VCI)---In conjunction with the VPI, identifies the next destination of a cell as it passes through a series of ATM switches on the way to its destination.
• Payload Type (PT)---Indicates in the first bit whether the cell contains user data or control data. If the cell contains user data, the second bit indicates congestion, and the third bit indicates whether the cell is the last in a series of cells that represent a single AAL5 frame.
• Congestion Loss Priority (CLP)---Indicates whether the cell should be discarded if it encounters extreme congestion as it moves through the network. If the CLP bit equals 1, the cell should be discarded in preference to cells with the CLP bit equal to zero.
• Header Error Control (HEC)---Calculates checksum only on the header itself.
  

• 5. FDDI Packet and Token Format
• token-based

• PA - Preamble: 4 or more symbols of Idle.
• SD - Starting Delimiter: The symbols 'J' and 'K'.
• FC - Frame Control: 2 symbols describing what the INFO field will be.
• DA - Destination Address: 12 symbols indicating who the recipient of the frame will be.
• SA - Source Address: 12 symbols indicating who sourced the frame.
• INFO - Information Field: 0 to 4478 bytes of information.
• FCS - Frame Check Sequence: 8 symbols of Cyclic Redundancy Check.
• ED - Ending Delimiter: a 'T' symbol.
• FS - End of Frame Sequence: 3 indicator symbols.

• FDDI Token Format

• PA - Preamble: 4 or more symbols of Idle.
• SD - Starting Delimiter: The symbols 'J' and 'K'.
• FC - Frame Control: 2 symbols describing what type the token is.
• ED - Ending Delimiter: two 'T' symbols.
  

The token is a control signal comprised of a unique symbol sequence that circulates on the medium following each information transmission. Any station, upon detection of a token, may capture the token by removing it from the ring. The station may then transmit one or more frames of information. At the completion of its information transmission, the station issues a new Token, which provides other stations the opportunity to gain access to the ring.