Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

About Cisco HDLC

I know that Cisco HDLC frame contains a field indicating the payload type, what is the other differences between standard and Cisco HDLC (error detection, correction, flow control, windowing)?

2 REPLIES
Silver

Re: About Cisco HDLC

Other than the protocol (or payload) field SLARP (Serial Line ARP) is the only other major difference. Below is the white paper published some time ago on the Cisco HDLC spec:

cisco Serial Line Encapsulation

-------------------------------

cisco's default encapsulation on synchronous serial lines uses HDLC framing,

with packet contents defined as follows:

The first ("address") octet is set to 0x0F for unicast packets and 0x8F

for broadcast packets. Broadcast just means that the higher-level protocol

thought this was a broadcast packet; cisco doesn't support multidrop

HDLC at this time.

The second ("control") octet is always 0.

The next two octets are a 16-bit protocol code, sent most-significant-first.

These codes are usually Ethernet type codes. cisco has added some codes to

support packet types that don't appear on Ethernets. The current list of codes

is as follows:

TYPE_PUP 0x0200 PUP

TYPE_XNS 0x0600 XNS

TYPE_IP10MB 0x0800 IP

TYPE_CHAOS 0x0804 Chaos

TYPE_IEEE_SPANNING 0x4242 DSAP/SSAP for IEEE bridge spanning prot.

TYPE_DECNET 0x6003 DECnet phase IV

TYPE_BRIDGE 0x6558 Bridged Ethernet/802.3 packet

TYPE_APOLLO 0x8019 Apollo domain

TYPE_REVERSE_ARP 0x8035 cisco SLARP (not real reverse ARP!)

TYPE_DEC_SPANNING 0x8038 DEC bridge spanning tree protocol

TYPE_ETHERTALK 0x809b Apple EtherTalk

TYPE_AARP 0x80f3 Appletalk ARP

TYPE_NOVELL1 0x8137 Novell IPX

TYPE_CLNS 0xFEFE ISO CLNP/ISO ES-IS DSAP/SSAP

This list is shared between serial and Ethernet encapsulations. Not all

these codes will necessarily appear on serial lines. This list will probably

be extended as cisco adds support for more protocols.

Bytes after this are higher-level protocol data. These normally look the

same as they'd look on Ethernet. Bridging packets include Ethernet/802.3

MAC headers; no other packets do.

Packets with type 8035 (reverse ARP) don't contain reverse ARP data as

they would on an Ethernet. Instead, they carry a protocol cisco refers to

as SLARP. SLARP has two functions: dynamic IP address determination and

serial line keepalive.

The serial line model supported by SLARP assumes that each serial line is

a separate IP subnet, and that one end of the line is host number 1, while

the other end is host number 2. The SLARP address resolution protocol allows

system A to request that system B tell system A system B's IP address,

along with the IP netmask to be used on the network. It does this by sending

a SLARP address resolution request packet, to which system B responds with a

SLARP address resolution reply packet. System A then attempts to determine its

own IP address based on the address of system B. If the host portion of system

B's address is 1, system A will use 2 for the host portion of its own IP

address. Conversely, if system B's IP host number is 2, system A will use IP

host number 1. If system B replies with any IP host number other than 1 or 2,

system A assumes that system B is unable to provide it with an address via

SLARP.

For the SLARP keepalive protocol, each system sends the other a keepalive

packet at a user-configurable interval. The default interval is 10 seconds.

Both systems must use the same interval to ensure reliable operation.

Each system assigns sequence numbers to the keepalive packets it sends,

starting with zero, independent of the other system. These sequence numbers

are included in the keepalive packets sent to the other system. Also included

in each keepalive packet is the sequence number of the last keepalive packet

_received_ from the other system, as assigned by the other system. This number

is called the returned sequence number. Each system keeps track of the last

returned sequence number it has received. Immediately before sending a keepalive

packet, it compares the sequence number of the packet it is about to send with

the returned sequence number in the last keepalive packet it has received.

If the two differ by 3 or more, it considers the line to have failed, and

will route no further higher-level data across it until an acceptable keepalive

response is received.

There is interaction between the SLARP address resolution protocol and the

SLARP keepalive protocol. When one end of a serial line receives a SLARP

address resolution request packet, it assumes that the other end has restarted

its serial interface and reset its keepalive sequence numbers. In addition

to responding to the address resolution request, it will act as if the

other end had sent it a keepalive packet with a sequence number of zero,

and a returned sequence number the same as the returned sequence number

of the last real keepalive packet it received from the other end.

The following is a C definition for the SLARP packet. The "long" and "ulong"

types are 32-bit numbers, high octet sent first. The "ushort" type is a 16-bit

number, high octet sent first.

struct slarp {

long code; /* SLARP packet type code */

union sl { /* followed by one of: */

struct { /* Address resolution functions */

ulong address; /* Address of system sending this pkt */

ulong mask; /* IP subnet mask for this line */

ushort unused; /* Unused: contents undefined */

} add; /* -- or -- */

struct { /* Keepalive probing functions */

ulong mysequence; /* Outgoing sequence number */

ulong yoursequence; /* Returned sequence number */

ushort reliability; /* Reserved: set to FFFF */

} chk;

} t;

};

Note that the data storage for t.add is overlayed on the data storage for

t.chk. The whole SLARP packet consists of a 32-bit type code, followed by

two 32-bit quantities and one 16-bit quantity. The overall length of the

SLARP packet is 14 octets. The "code" field is used to identify the packet's

SLARP type. Legal values for the "code" field are as follows:

SLARP_REQUEST 0 Address resolution request

SLARP_REPLY 1 Address resolution reply

SLARP_LINECHECK 2 Line keepalive

For address resolution request packets, the "address" and "mask" fields are

set to zero, and the contents of the "unused" field field are undefined. For

address resolution reply packets, the "address" field contains the IP address

of the _replying_ system, and the "mask" field contains the IP subnet mask

to be used. The contents of the "unused" field are undefined.

For keepalive packets, the "mysequence" field contains the sequence number

of the packet and the "yoursequence" field contains the returned sequence

number, which is the sequence number of the last keepalive packet the sending

system has gotten from the receiving system. The "reliability" field is

reserved for future use, and _must_ be set to FFFF hexadecimal.

Re: About Cisco HDLC

OK, thanks for the valuable info but just one more thing; what about error detection and backward error correction?

891
Views
4
Helpful
2
Replies
CreatePlease login to create content