Subject: Re: Cisco HDLC

From: Archie Cobbs <[email-masked]>
Date: Wed, 28 Mar 2001 14:00:16 -0800

> I have checked that. It seems that the only difference from the standard HDLC (RFC-1662) is the value encoded in
> Address, control field.

There's more to it than that.. if you can read FreeBSD kernel source
code there is an implementation at:

http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netgraph/ng_cisco.c?rev=1.14&content-type=text/x-cvsweb-markup

> Is it still using the byte or bit stuffing?

Yes, same frame encoding (bit stuffing, flags, CRC's, etc.)

-Archie

__________________________________________________________________________
Archie Cobbs     *     Packet Design     *     http://www.packetdesign.com

---

From: James Carlson <[email-masked]>
Date: Wed, 28 Mar 2001 17:22:20 -0500 (EST)

> code there is an implementation at:

I saved the following message from comp.dcom.sys.cisco several years
ago.  Hope this helps ...

-- 
James Carlson, Internet Engineering       <[email-masked]>
SUN Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677
Second Edition now available - http://people.ne.mediaone.net/carlson/ppp

From: [email-masked] (William "Chops" Westfield)
Subject: Re: Wanted: IP directly over HDLC
Date: 7 Nov 90 07:57:33 GMT

     We have an opportunity here to productize a capability of doing IP
    over serial lines.  The way I've prototyped this is to encapsulate IP
    datagrams directly into HDLC framing (ISO 3309), without any of the
    "upper-layer" (ISO 4335 or LAPB) retransmission or windowing stuff.

Indeed, this is what almost all of the major router vendors do.  PPP is
also like this except that there is a potential of doing millions of lines
of code to support all the random option negotiation.

    We were wondering if there are any implementations out there that are
    also able to do this.  Both Wellfleet and cisco boxes come to mind,
    but are there any other implementations that can do this in a
    non-proprietary manner?

As far as I know, wellfleet and cisco "hdlc" encapsulations are only
"proprietary" in that no one else does them - they aren't big secrets.
(Ill enclose a description of cisco's spec later in this message...)

    Note: I am aware of PPP and am not interested in implementing it as a
    solution at this time.

Why not?  I would think that this would be a good idea, especially if
you leave out the negotiation of the millions of options.  A "minimal
subset" (refuse all options) of PPP is not difficult, and even a format
equivilent to PPP with not option negotiation supported at all (eg only
the PPP wire format) probably has a better interoperability future than
anything else...

Bill Westfield
cisco Systems.

                        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.

---

From: Shahram Davari <[email-masked]>
Date: Wed, 28 Mar 2001 13:51:18 -0800

Hi,
 
I have checked that. It seems that the only difference from the standard HDLC (RFC-1662) is the value encoded in Address, control field. Is it still using the byte or bit stuffing?
 
What is the advantage of Cisco HDLC?
 
Yours,
-Shahram

-----Original Message-----
From: Sylvanus Jonnalagadda [mailto:[email-masked]]
Sent: Wednesday, March 28, 2001 4:56 PM
To: Shahram Davari; [email-masked]
Subject: RE: Cisco HDLC

Hi Sharam, 

I think it is explained in section 4.3.1 of RFC 1547. Check it out. 

-Sylvanus. 

-----Original Message----- 
From: Shahram Davari [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Wednesday, March 28, 2001 1:35 PM 
To: [email-masked] 
Subject: Cisco HDLC 

Hi All, 

Does any body know what is the protocol format of the Cisco HDLC? 

Yours, 
-Shahram

---

From: Bora Akyol <[email-masked]>
Date: Wed, 28 Mar 2001 20:32:34 -0800

Isn't it amazing that most people outside Cisco that have implemented 
C-HDLC have implemented it using this newsgroup message from years ago?

I would like to confirm that if you follow the message, the resulting 
implementation works.

Bora

---

From: James Carlson <[email-masked]>
Date: Thu, 29 Mar 2001 07:19:52 -0500 (EST)

> > From: [email-masked] (William "Chops" Westfield)
[...]
> > of code to support all the random option negotiation.

Since it apparently wasn't clear to everyone, I'd like to point out
explicitly that those are *not* my words nor are they my opinion.
They appeared in the original usenet posting.  For what it's worth,
the new version of Solaris PPP that I'm currently working on is about
59,642 lines of code, including all the user and kernel bits and debug
utilities.  Even if I did *all* of the options currently defined, I'd
have a hard time breaking the one million line mark.