table lookup in the correct routing table (ID or IPX), and make the correct routing decision.
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.
Relay standards: ITU T1.617 Annex F and ANSI Q.933 Annex E, respectively.
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.)
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.