HDLC-Like Framing - PPP

This is a discussion on HDLC-Like Framing - PPP ; Hi, I am writing some software which decodes the various packets in an incoming serial data stream. I have encountered a problem in deciding what the framing method is, HDLC or PPP. An HDLC frame starts with the flag 7E ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: HDLC-Like Framing

  1. HDLC-Like Framing

    Hi,

    I am writing some software which decodes the various packets in an
    incoming serial data stream. I have encountered a problem in deciding
    what the framing method is, HDLC or PPP.

    An HDLC frame starts with the flag 7E followed by the Address and
    Control fields (FF 03) and then the encapsulated PPP packet, followed
    by the FCS and end flag (7E again). The PPP packet starts with the
    protocol contained within it, i.e. C021 for an LCP packet followed by
    that packet's data.

    However, in the example I am looking at the LCP negotiations have
    allowed "Address and Control Field Compression" after which the
    Address and Control fields (FF 03) no longer appear. This means that
    what I am left with is a PPP packet and FCS framed with the start and
    end flags 7E.

    LCP is a LINK control protocol, not a FRAME control protocol and
    therefore should only modify the way PPP operates. If this is the case
    the Address and Control fields must be a part of the PPP packet which
    is using the "HDLC-Like" framing.

    My questions are:
    Am I seeing an HDLC frame containing a PPP packet, or am I seeing a
    PPP packet which is using "HDLC-Like" framing?

    If the second is true, why does the PPP specification only consist of
    the 16-bit protocol type (i.e. CO21) followed by the encapsulated
    packet and not the additional 7E flags and FCS?

    Many thanks
    O.C.

  2. Re: HDLC-Like Framing

    In article ,
    Old Codger wrote:
    >Hi,
    >
    >I am writing some software which decodes the various packets in an
    >incoming serial data stream. I have encountered a problem in deciding
    >what the framing method is, HDLC or PPP.
    >
    >An HDLC frame starts with the flag 7E followed by the Address and
    >Control fields (FF 03) and then the encapsulated PPP packet, followed
    >by the FCS and end flag (7E again). The PPP packet starts with the
    >protocol contained within it, i.e. C021 for an LCP packet followed by
    >that packet's data.


    Technically, a PPP (over async) packet starts with the same 7E flag, OPTIONALLY
    followed by the address and control fields (FF 03), followed by the protocol
    field (C0 21 for example), packet data, a 16-bit CRC, and a closing 7E flag.

    >However, in the example I am looking at the LCP negotiations have
    >allowed "Address and Control Field Compression" after which the
    >Address and Control fields (FF 03) no longer appear. This means that
    >what I am left with is a PPP packet and FCS framed with the start and
    >end flags 7E.


    Sure. While LCP is being negotiated, the address and control fields are
    REQUIRED. LCP may negotiate to compress out (omit) the address and control
    fields, after which all (non-LCP) packets are not required to include the
    address and control fields any more.

    >LCP is a LINK control protocol, not a FRAME control protocol and
    >therefore should only modify the way PPP operates. If this is the case
    >the Address and Control fields must be a part of the PPP packet which
    >is using the "HDLC-Like" framing.
    >
    >My questions are:
    >Am I seeing an HDLC frame containing a PPP packet, or am I seeing a
    >PPP packet which is using "HDLC-Like" framing?


    Yes. ) I guess technically, once LCP negotiates to omit the address
    and control fields, the frames aren't really HDLC any more, are they?
    I'm not an HDLC expert, so I can't say for sure, but the few pages I just
    looked at would bear out what you're saying.

    >If the second is true, why does the PPP specification only consist of
    >the 16-bit protocol type (i.e. CO21) followed by the encapsulated
    >packet and not the additional 7E flags and FCS?


    I'm not exactly sure what you're asking, but the PPP frames do have the
    same 16 bit CRC and closing flag as you're expecting with HDLC frames.
    Although PPP allows you to negotiate away the CRC or change it to a 32 bit
    CRC, I've never seen anything but 16 bit CRC on PPP frames. Where would
    you think an "additional 7E flags and FCS" go?

    >Many thanks
    >O.C.


    If you have any packets that don't make total sense to you, dump the hex
    in a posting for this newsgroup and we'll let you know what it represents.
    It's usually best to dump the raw byte stream (before unescaping bytes) to
    give us the best information.

    Patrick
    ========= For LAN/WAN Protocol Analysis, check out PacketView Pro! =========
    Patrick Klos Email: patrick@klos.com
    Klos Technologies, Inc. Web: http://www.klos.com/
    ==================== What goes around, comes around... =====================

  3. Re: HDLC-Like Framing

    patrick@klos.com writes:
    > In article ,
    > Old Codger wrote:
    > >Hi,
    > >
    > >I am writing some software which decodes the various packets in an
    > >incoming serial data stream. I have encountered a problem in deciding
    > >what the framing method is, HDLC or PPP.
    > >
    > >An HDLC frame starts with the flag 7E followed by the Address and
    > >Control fields (FF 03) and then the encapsulated PPP packet, followed
    > >by the FCS and end flag (7E again). The PPP packet starts with the
    > >protocol contained within it, i.e. C021 for an LCP packet followed by
    > >that packet's data.

    >
    > Technically, a PPP (over async) packet starts with the same 7E flag, OPTIONALLY
    > followed by the address and control fields (FF 03), followed by the protocol
    > field (C0 21 for example), packet data, a 16-bit CRC, and a closing 7E flag.


    That's close but (in my opinion) not quite it ...

    The 7E marker is required *between* frames. There's no requirement
    that each frame be delimited by distinct start and end markers. In
    other words, AHDLC allows "shared flag mode" -- the 7E that marks the
    end of one packet also marks the start of the next one. Thus,
    representing it as "7E FF 0E ... FCS 7E" is misleading.

    Also, the Address and Control Fields aren't optional. They can be
    negotiated away, but that requires *knowing* agreement between the
    peers. Unless the negotiation happens, they're required.

    > Sure. While LCP is being negotiated, the address and control fields are
    > REQUIRED. LCP may negotiate to compress out (omit) the address and control
    > fields, after which all (non-LCP) packets are not required to include the
    > address and control fields any more.


    Right. The point is that the endpoints are knowingly relaxing their
    conformance with HDLC requirements. Both peers must agree to this, or
    it isn't done at all. Any implementation that (for whatever reason)
    feels that it must strictly conform with HDLC can simply LCP
    Configure-Reject the appropriate options, and the peer *must not* omit
    those fields.

    > >LCP is a LINK control protocol, not a FRAME control protocol and
    > >therefore should only modify the way PPP operates. If this is the case
    > >the Address and Control fields must be a part of the PPP packet which
    > >is using the "HDLC-Like" framing.


    Looking at it as a matter of layering is likely to drive the
    implementor slightly batty. ;-}

    The layering model is helpful for understanding how software fits
    together. It's sometimes helpful for figuring out what things are
    "good design" and what things aren't. It's not a crutch, and it's not
    a restriction, though.

    In this case, the peers either know that the underlying framing layer
    can handle frames without the HDLC address and control fields, and
    that they can tell that layer (through some implementation-specific
    mechanism) to switch modes -- and they can then agree to compress away
    those fields -- or they do not know that the framing layer can do this
    and thus cannot agree to compress away the fields.

    (Consider the relationship between DHCP and IP, for example: DHCP
    itself is an application protocol, but it modifies network layer
    properties. There are _many_ such examples in networking. Real
    systems just don't conform perfectly with the ISO model.)

    > >My questions are:
    > >Am I seeing an HDLC frame containing a PPP packet, or am I seeing a
    > >PPP packet which is using "HDLC-Like" framing?

    >
    > Yes. ) I guess technically, once LCP negotiates to omit the address
    > and control fields, the frames aren't really HDLC any more, are they?
    > I'm not an HDLC expert, so I can't say for sure, but the few pages I just
    > looked at would bear out what you're saying.


    More to the point: it doesn't matter. Peers that have mutual
    agreement to change coding standards can do anything they like.

    > >If the second is true, why does the PPP specification only consist of
    > >the 16-bit protocol type (i.e. CO21) followed by the encapsulated
    > >packet and not the additional 7E flags and FCS?

    >
    > I'm not exactly sure what you're asking, but the PPP frames do have the
    > same 16 bit CRC and closing flag as you're expecting with HDLC frames.


    He's asking a layering question, and it's really not all that
    relevant. He's asking why PPP itself doesn't just redefine or subsume
    all of HDLC. The answer is that it wouldn't be helpful.

    > Although PPP allows you to negotiate away the CRC or change it to a 32 bit
    > CRC, I've never seen anything but 16 bit CRC on PPP frames.


    For what it's worth, the Solaris implementation of pppd allows the CRC
    to be negotiated to CRC-32 or away entirely.

    --
    James Carlson, IP Systems Group
    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

  4. Re: HDLC-Like Framing

    Thanks James and Patrick for your comments. I have dropped the idea of
    displaying an HDLC packet and have decided to call it a PPP packet
    which is using "HDLC-Like Framing".
    O.C.

+ Reply to Thread