Tag Archives: hdlc

Point-to-Point Protocol & HDLC

The ISO standard for the much older HDLC does not include a Type field, so the Cisco HDLC implementation adds a Cisco-proprietary 2-byte Type field to support multiple protocols over an HDLC link.

PPP framing (RFC 1662) defines the use of a simple HDLC header and trailer for most parts
of the PPP framing. PPP simply adds the Protocol field and
optional Padding field to the original HDLC framing. (The Padding field allows PPP to
ensure that the frame has an even number of bytes.)

PPP-HDLC

Feature HDLC PPP
Error detection? Yes Yes
Error recovery? No Yes
Standard Protocol Type field? No Yes
Default on IOS serial links? Yes No
Supports synchronous and asynchronous links? No Yes

PPP

  • RFC1661
  • includes an architected Protocol field
  • Link Control Protocol (LCP)
  • NCP for each L3 (IPCP, for example)

LCP features:

  • Link Quality Monitoring (LQM) (statistics about frames wo errors. if the percentage falls under configured value – frop the link). (ppp quality if command)
  • Looped link detection (send random magic number. if receive own number – drop the link)
  • Layer 2 load balancing (ML-PPP fragments the packet and sends the packet to each link. add header of 2 or 4 bytes for reassembly (sequence number and Flag bits designating the beginning and ending fragments)
  • Auth (pap, chap)

ML-PPP:

  • authenticated—Use the peer authenticated name as the bundle name. This option cannot support multiple clients using the same authentication username. (default option)
  • endpoint—Use the peer endpoint discriminator as the bundle name.
  • both—Use the peer authenticated name and endpoint discriminator as the bundle name.

Link Fragmentation and Interleaving (LFI): prevent small, delay-sensitive packets from having to wait on longer, delay-insensitive packets to be completely serialized out an interface. LFI tools fragment larger packets, and then send the delay-sensitive packet after just a portion of the original, longer packet.

PPP-interleave

  • ppp multilink interleave
  • ppp multilink fragment-delay x : size = x * bandwidth; Note that the unit for the delay parameter is  milliseconds, so the units for the interface bandwidth must also be converted. Eg.:
    bandwidth 256
    ppp multilink fragment-delay 10
    The fragment delay is set to 10 ms, so the fragments will be of size (256,000 * 0.01) = 2560 bits = 320 bytes.
  • ppp multilink multiclass the sequence number is maintained per class and so the interleaved small packets also would have the multilink header and so could be ordered correctly. Resolves out-of-order issues with LFI.

Compression: payload, TCP header and/or RTP header.
Payload: Cisco IOS software supplies three different payload compression options for PPP, namely Lempel-Ziv Stacker (LZS), Microsoft Point-to-Point Compression (MPPC), and Predictor. LZ uses more CPU and less memory in comparison to Predictor, and LZ typically results in a better compression ratio. Once compression is configured (matching compress command), PPP starts the Compression Control Protocol (CCP), which is another NCP, to perform the compression negotiations and manage the compression process.

Feature Stacker MPPC Predictor
Uses LZ algorithm Yes Yes No
Supported on HDLC Yes No No
Supported on PPP Yes Yes Yes
Supported on Frame Relay Yes No No
Supports ATM and ATM-to-Frame Relay Service Interworking (using MLP)? Yes Yes Yes

RTP header compression compresses the IP/UDP/RTP headers (40 bytes) into 2
or 4 bytes. With G.729 in use, RTP header compression reduces the required bandwidth by
more than 50 percent.
TCP header compression compresses the combined IP and TCP headers, a combined
40 bytes, into 3 or 5 bytes.
It does this by saving the state of TCP connections at both ends of a link, and only sending the differences in the header fields that change.
ip tcp headercompression [passive] and ip rtp header-compression [passive]: use IPCP to initiate compression (or wait if passive).
Alternative method using an MQC policy map to create classbased header compression.

PAP

  • Client sends username and password
  • Server sends authentication-ack (if credentials are OK) or authentication-nak (otherwise)
    Description 1 byte 1 byte 2 bytes 1 byte Variable 1 byte Variable
    Authentication-request Code = 1 ID Length Username length Username Password length Password
    Authentication-ack Code = 2 ID Length Message length Message
    Authentication-nak Code = 3 ID Length Message length Message

    PAP packet embedded in a PPP frame. The protocol field has a value of C023 (hex).

    Flag Address Control Protocol (C023 (hex)) Payload (table above) FCS Flag

CHAP

  • After the completion of the link establishment phase, the authenticator sends a “challenge” message to the peer.
  • The peer responds with a value calculated using a one-way hash function on the challenge and the secret combined.
  • The authenticator checks the response against its own calculation of the expected hash value. If the values matches, the authenticator acknowledges the authentication; otherwise it should terminate the connection.
  • At random intervals the authenticator sends a new challenge to the peer and repeats steps 1 through 3.
    Description 1 byte 1 byte 2 bytes 1 byte Variable variable
    Challenge Code = 1 ID Length Challenge Length Challenge value Name
    Response Code = 2 ID Length Response Length Response value Name
    Success Code = 3 ID Length Message
    Failure Code = 4 ID Length Message

The Challenge packet has a Value field which contains a variable stream of octets (a random value). The Challenge packet also has a Name field which contains the hostname of the router transmitting the packet.

The “hash” that is generated in an outgoing PPP CHAP Response is created as a combination of three variables, and without knowing all three values the Hash Response cannot be generated:

  • A router’s Hostname
  • The configured PPP CHAP password
  • The PPP CHAP Challenge value

This generates a one-way hash value and set in the Value field of the Response packet which is sent back to the authenticator. The Name field of the Response packet is set to the hostname of the peer router.

CHAP packet embedded in a PPP frame. The protocol field has a value of C223 (hex).

http://www.cisco.com/c/en/us/td/docs/ios/qos/configuration/guide/15_1/qos_15_1_book/header_compression.html
http://www.effnet.com/pdf/uk/Whitepaper_Header_Compression.pdf

Very nice explanation of interleaving:
https://networklessons.com/quality-of-service/ppp-multilink-lfi/

Most voice codecs require a maximum delay of 10 ms between the different VoIP packets. Let’s say the serial link offers 128 Kbit of bandwidth…how long would it take to send a voice packet that is about 60 bytes?

60 bytes * 8 = 480 bits / 128.000 = 0.00375.

So it takes roughly 3.7 ms to send the voice packet which is far below the required 10 ms. We can run into issues however when we also send data packets over this link. Let’s say we have a 1500 bytes data packet that we want to send over this link:

1500 bytes * 8 = 12.000 / 128.000 = 0.093.