Data Link Function 4 Identifying the Encapsulated Data

Finally, the fourth part of a data link identifies the contents of the data field in the frame. Figure 3-13 helps make the usefulness of this feature apparent.

Figure 3-13 Multiplexing Using Data Link Type and Protocol Fields

Novell PC1

NetWare Client

FTP Client

Data Link

802.3

802.2

Data

When PC1 receives data, does it give the data to the TCP/IP software or the NetWare client software? Of course, that depends on what is inside the data field. If the data came from the Novell server, then PC1 hands the data off to the NetWare client code. If the data comes from the Sun FTP server, PC1 hands it off to the TCP/IP code.

Ethernet and Token Ring 802.2 LLC provide a field in its header to identify the type of data in the data field.

PC1 receives frames that basically look like the two shown in Figure 3-14. Each data link header has a field with a code that means IP, or IPX, or some other designation defining the type of protocol header that follows. The first item to examine in the header is the 802.2 DSAP field. In the first frame in Figure 3-14, the destination service access point (DSAP) field has a value of E0, which means that the next header is a Novell IPX header. In the second frame, the DSAP field is AA, which implies that a SNAP header follows. Next, the type field in the Subnetwork Access Protocol (SNAP) header, which has a value of 0800, signifies that the next header is an IP header. RFC 1700, the "Assigned Numbers" RFC (http://www.isi.edu/in-notes/rfc1700.txt), lists the SAP and SNAP Type field values and the protocol types they imply.

Similarly, HDLC and Frame Relay need to identify the contents of the data field. Of course, it is atypical to have end-user devices attached to either of these types of data links. In this case, routers provide an example more typically found in most WAN environments, as shown in Figure 3-15.

Figure 3-14 802.2 SAP and SNAP Type Fields 14 1 1

802.3

DSAP

SSAP

CTL

IPX Data

802.3

802.5

SNAP

802.3

AA DSAP

AA SSAP

03 CTL

OUI

0800 Type

IP Data

802.3

Figure 3-15 Identifying Protocols over HDLC and Frame Relay

Barney

Barney

Barney -

Frame Relay

Frame Relay

Sun FTP

Server -

Fred (NetWare Server)

Sun FTP Server

Fred (NetWare Server)

Referring to the top part of Figure 3-15, if Barney is using FTP to transfer files to the Sun system and is also connected to the NetWare server (Fred) using IPX, then Barney will generate both TCP/IP and NetWare IPX traffic. As this traffic passes over the HDLC controlled link, R2 will need to know whether an IP or IPX packet follows the HDLC header. Mainly, this is so that the

router can find the Layer 3 destination address, assume its length (32 bits or 80 bits), perform table lookup in the correct routing table (ID or IPX), and make the correct routing decision.

HDLC does not provide a mechanism to identify the type of packet in the data field. IOS adds a proprietary 2-byte field immediately after the HDLC header that identifies the contents of the data. As shown in the bottom of Figure 3-15, the intervening Frame Relay switches do not care what is inside the data field. The receiving router, R2, does care for the same reasons that R2 cares when using HDLC—that is, the receiving router needs to know whether an IP or IPX packet follows the Frame Relay header. Frame Relay headers originally did not address this issue, either, because the headers were based on HDLC. However, the IETF created a specification called RFC 1490 that defined additional headers that followed the standard Frame Relay header. These headers include several fields that can be used to identify the data so that the receiving device knows what type is hidden inside.

The ITU and ANSI picked up the specifications of RFC 1490 and added it to their official Frame Relay standards: ITU T1.617 Annex F and ANSI Q.933 Annex E, respectively.

Figure 3-16 shows the fields that identify the type of protocol found in the data field.

Figure 3-16 HDLC and Frame Relay Protocol Type Fields

HDLC

Flag

Address

Control

Protocol Data FCS Type *

© © © ©

Flag

Address

Control

Pad NLPID J-2 J"3 SNAP Data FCS PID PID

Frame Relay * Cisco Proprietary

Optional Optional

As seen in Figure 3-16, a protocol type field comes after the HDLC control field. In the Frame Relay example, four different options exist for identifying the type of data inside the frame. RFC 2427, which obsoletes RFC 1490, provides a complete reference and is useful reading for those of you moving on to CCNP certification (www.isi.edu/in-notes/rfc2427.txt). ("Obsoletes" in the RFC world implies that a newer document has superceded it but does not necessarily mean that all or most of the original RFC has been changed.)

Table 3-8 summarizes the different choices for encoding protocol types for each of the four data link protocols. Notice that the length of some of these fields is only 1 byte, which historically has led to the addition of other headers. For example, the SNAP header contains a 2-byte type field because a 1-byte DSAP field is not big enough to number all the available options for what type of protocol is inside the data.

Table 3-8 Different Choices for Encoding Protocol Types for Each of the Four Example Data Link Protocols

Data Link Protocol

Field

Header in Which It Is Found

Size

802.3 Ethernet and 802.5 Token Ring

DSAP

802.2 header

1 byte

802.3 Ethernet and 802.5 Token Ring

SSAP

802.2 header

1 byte

802.3 Ethernet and 802.5 Token Ring

Protocol Type

SNAP header

2 bytes

Ethernet (DIX)

Ethertype

Ethernet header

2 bytes

HDLC

Cisco proprietary protocol id field

Extra Cisco header

2 bytes

Frame Relay RFC 2427

NLPID

RFC 1490

1 byte

Frame Relay RFC 2427

L2 or L3 Protocol ID

Q.933

2 bytes each

Frame Relay RFC 2427 SNAP Protocol Type SNAP Header 2 bytes

Frame Relay RFC 2427 SNAP Protocol Type SNAP Header 2 bytes

0 0

Post a comment