Subject: RE: Cisco HDLC

From: Shahram Davari <[email-masked]>
Date: Thu, 29 Mar 2001 07:52:27 -0800

Hi Bora,

Thanks. But there are still some things that are not clear. For example:

1)is C-HDLC bit-stuffed or byte-stuffed? (somebody said it is bit-stuffed)
2)Does it have padding at the end?
3)Does it have CRC-16 or 32?
4)Does it use the same flag as HDLC?
5)Can C-HDLC be used in packet over sonet application?
6)If yes is it scrambled or not? If so what type of scrambling?

Yours,
-Shahram

> -----Original Message-----
> From: Bora Akyol [mailto:[email-masked]]
> Sent: Wednesday, March 28, 2001 11:33 PM
> To: James Carlson
> Cc: Archie Cobbs; Shahram Davari; 'Sylvanus Jonnalagadda';
> [email-masked]
> Subject: Re: Cisco HDLC
> 
> 
> 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
> 
> On Wednesday, March 28, 2001, at 02:22 PM, James Carlson wrote:
> 
> > Archie Cobbs writes:
> >> There's more to it than that.. if you can read FreeBSD 
> kernel source
> >> 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: James Carlson <[email-masked]>
Date: Thu, 29 Mar 2001 11:05:53 -0500 (EST)

> 1)is C-HDLC bit-stuffed or byte-stuffed? (somebody said it is bit-stuffed)

This isn't really a Cisco HDLC question; it's an HDLC question.

It would be bit-stuffed on synchronous links, and byte-stuffed on
asynchronous links.  Of course, I don't think it's ever used on async
links, but there's nothing wrong with doing that.

> 2)Does it have padding at the end?

No.

> 3)Does it have CRC-16 or 32?

Either.  As I recall, the default is CRC-16, but there's no reason you
couldn't support both.

Don't forget -- you have to configure both ends to use this protocol.
It's no big deal to configure optional features as well.

Plus, it's up to you to test for interoperability with the devices
that you care about.  You can't get that from any specification.  When
implementation and specification differ, most folks defer to
implementation, since it doesn't help the customer a bit if you merely
say "but we do it right, and that other box is wrong."

> 4)Does it use the same flag as HDLC?

Sure.  It uses HDLC.

> 6)If yes is it scrambled or not? If so what type of scrambling?

These are HDLC and deployment questions, not protocol issues.

If it were used in POS-type mode, I'd expect it to follow RFC 2615.
I haven't seen that done (all the POS devices I've used are either PPP
or Cisco SRP), but it sounds doable.

-- 
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