PPP
RFC1548 http://www.cis.ohio-state.edu/htbin/rfc/rfc1548.html
RFC1661 http://www.cis.ohio-state.edu/htbin/rfc/rfc1661.html
RFC1662 http://www.cis.ohio-state.edu/htbin/rfc/rfc1662.html
PPP (Point-to-Point Protocol) is designed
for simple links which transport packets between two peers.
These links provide full-duplex simultaneous bi-directional
operation and are assumed to deliver packets in order. PPP provides
a common solution for the easy connection of a wide variety
of hosts, bridges and routers.
The structure of the PPP header is shown
in the following illustration:
Address |
Control |
Protocol |
Information |
FCS |
1 byte |
1 byte |
2 bytes |
variable |
2 bytes |
PPP header structure |
Address
HDLC broadcast address. PPP does
not assign individual station addresses. The value of this field
is always set to FF Hex.
Control
HDLC command for Unnumbered Information (UI) with the Poll/Final
bit set to zero. The value of this field is always set to 03
Hex. Frames containing any other value in this field are discarded.
Protocol
Identifies the encapsulated protocol within the Information
field of the frame.
Information
Higher-level protocol data.
FCS
Value of the frame checksum calculation. PPP verifies
the contents of the FCS field upon receipt of the packet.
Interested in more
details about testing this protocol?

PPP-BPDU
RFC1638 http://www.cis.ohio-state.edu/htbin/rfc/rfc1638.html
There exist two basic types of bridges: those
that interconnect LANs directly, called Local Bridges, and those
that interconnect LANs via an intermediate WAN medium such as
a leased line, called Remote Bridges. The PPP-BPDU (Bridge Protocol
Data Unit) is used to connect Remote Bridges.
The format of the PPP-BPDU packet is shown
in the following illustration:
|
4 |
8 |
16 |
32 bits |
F |
I |
Z |
0 |
Pads |
MAC type |
LAN ID high word (optional) |
LAN ID low word (optional) |
Pad byte |
Frame control |
Destination MAC address |
Destination MAC address |
Source MAC address |
Source MAC address |
LLC data |
PPP-BPDU
packet structure |
F
F flag, set if the LAN FCS field
is present.
I
I flag, set if the LAN ID field is present.
Z
Z flag, set if IEEE 802.3 pad must be zero filled to minimum
size.
0
0 flag reserved, must be zero.
Pads
Any PPP frame may have padding inserted in the Optional Data
Link Layer Padding field. This number tells the receiving system
how many pad octets to strip off.
MAC type
Values of the MAC Type field.
1 |
Bridge-Identification |
2 |
Line-Identification |
3 |
MAC-Support |
4 |
Tinygram-Compression |
5 |
LAN-Identification |
6 |
MAC-Address |
7 |
Spanning-Tree-Protocol |
LAN ID
Optional 32-bit field that identifies
the Community of LANs which may be interested in receiving this
frame. If the LAN ID flag is not set, then this field is not
present and the PDU is four octets shorter.
Frame control
On 802.4, 802.5 and FDDI LANs,
there are a few octets preceding the Destination MAC Address,
one of which is protected by the FCS. The MAC Type of the frame
determines the contents of the Frame Control field. A pad octet
is present to provide a 32-bit packet alignment.
Destination MAC address
As defined by the IEEE. The MAC
Type field defines the bit ordering.
Source MAC address
As defined by the IEEE. The MAC
Type field defines the bit ordering.
LLC data
This is the remainder of the
MAC frame which is (or would be were it present) protected by
the LAN FCS.
Interested in more details about testing
this protocol?
BAP
RFC2125 http://www.cis.ohio-state.edu/htbin/rfc/rfc2125.html
The Bandwidth Allocation Protocol (BAP) can
be used to manage the number of links in a multi-link bundle.
BAP defines datagrams to coordinate adding and removing individual
links in a multi-link bundle, as well as specifying which peer
is responsible for various decisions regarding managing bandwidth
during a multi-link connection.
The format of the BAP packet is shown in
the following illustration:
Type |
Length |
Data |
1 byte |
1 byte |
variable |
BAP
packet structure |
Type
One-octet field which indicates
the type of the BAP Datagram Option. This field is binary coded
Hexadecimal.
Interested in more details about testing
this protocol?
CHAP
RFC1334 http://www.cis.ohio-state.edu/htbin/rfc/rfc1334.html
Challenge Handshake Authentication Protocol
(CHAP) is used to periodically verify the identity of the peer
using a 3-way handshake. This is done upon initial link establishment
and may be repeated any time after the link has been established.
Exactly one CHAP packet is encapsulated in
the Information field of a PPP data link layer frame where the
protocol field indicates type hex c223. The structure of the
CHAP packet is shown in the following illustration.
Code |
Identifier |
Length |
Data . . . |
1 byte |
1 byte |
2 bytes |
variable |
CHAP
packet structure |
Code
Identifies the type of CHAP packet.
CHAP codes are assigned as follows:
1 |
Challenge |
2 |
Response
|
3 |
Success |
4 |
Failure |
Identifier
Aids in matching challenges,
responses and replies.
Length
Length of the CHAP packet including the Code, Identifier, Length
and Data fields.
Data
Zero or more octets, the format of which is determined by the
Code field. The format of the Challenge and Response data fields
is shown in the following illustration:
Value Size |
Value |
Name |
1 byte |
|
1 byte |
CHAP
Challenge and Response data structure |
Value size
Indicates the length of the Value field.
Value
Challenge value is a variable stream of octets which must be
changed each time a challenge is sent.
Response value is the one-way hash calculated over a stream
of octets consisting of the Identifier, followed by the “secret”
and the Challenge value.
Name
Identification of the system transmitting the packet.
For Success and Failure, the data field contains
a variable message field which is implementation dependent.
Interested in more details about testing
this protocol?
IPHC
RFC 2509
IP Header Compression (IPHC) may be used for compression of
both IPv4 and IPv6 datagrams or packets encapsulated with multiple
IP headers. IPHC is also capable of compressing both TCP and
UDP transport protocol headers. The IP/UDP/RTP header compression
defined in CRTP fits within the framework defined by IPHC so
that it may also be applied to both IPv4 and IPv6 packets.
In order to establish compression of IP datagrams
sent over a PPP link, each end of the link must agree on a set
of configuration parameters for the compression. The process
of negotiating link parameters for network layer protocols is
handled in PPP by a family of network control protocols (NCPs).
Since there are separate NCPs for IPv4 and IPv6, this document
defines configuration options to be used in both NCPs to negotiate
parameters for the compression scheme.
Configuration option format
Both the network control protocol for IPv4,
IPCP (RFC1332) and the IPv6 NCP, IPV6CP (RFC2023) may be used
to negotiate IP Header Compression parameters for their respective
protocols. The format of the configuration option is the same
for both IPCP and IPV6CP.
Type |
Length |
IP compression protocol |
TCP_SPACE |
NON_TCP_SPACE |
TCP_SPACE |
F_MAX_TIME |
MAX_HEADER |
Suboptions |
1 byte |
1 byte |
2 byte |
IPHC
configuration option format |
The following parameters are available:
Type
The value of the Type field is 2.
Length
Indicates the length of the suboption in its entirety,
including the lengths of the type and length fields. The value
of this field is 14.
IP compression protocol
The value of this field is 0061 (hex).
TCP_SPACE
The TCP_SPACE field indicates the maximum value of a
context identifier in the space of context identifiers allocated
for TCP. The suggested value of this field is: 15. TCP_SPACE
must be at least 0 and at most 255 (The value 0 implies having
one context).
F_MAX_PERIOD
Maximum interval between full headers. No more then F_MAX_PERIOD
compressed non-TCP headers may be sent between full header headers.
Suggested value: 256
F_MAX_TIME
Maximum time interval between full headers. Suggested
value: 5 seconds. A value of zero implies infinity.
MAX_HEADER
The largest header size in octets that may be compressed.
Suggested value: 168 octets.
The value of MAX_HEADER should be large enough so that at least
the outer network layer header can be compressed. To increase
compression efficiency MAX_HEADER should be set to a value large
enough to cover common combinations of network and transport
layer headers.
Suboptions
The Suboptions field consists of zero or more suboptions.
Each suboption consists of a type field, a length field and
zero or more parameter octets, as defined by the suboption type.
The value of the length field indicates the length of the suboption
in its entirety, including the lengths of the type and length
fields.
Interested in more details about testing
this protocol?
LCP
RFC1570 http://www.cis.ohio-state.edu/htbin/rfc/rfc1570.html
RFC1661 http://www.cis.ohio-state.edu/htbin/rfc/rfc1661.html
In order to be sufficiently versatile to
be portable to a wide variety of environments, PPP provides
the Link Control Protocol (LCP) for establishing, configuring
and testing the data link connection. LCP is used to automatically
agree upon the encapsulation format options, handle varying
limits on sizes of packets, detect a looped-back link and other
common misconfiguration errors, and terminate the link. Other
optional facilities provided are authentication of the identity
of its peer on the link, and determination when a link is functioning
properly and when it is failing.
The format of the LCP packet is shown in
the following illustration:
Code |
Identifier |
Length |
Data |
1 byte |
1 byte |
2 bytes |
variable |
LCP packet structure |
Code
Decimal value which indicates the
type of LCP packet:
1 |
Configure-Request. |
2 |
Configure-Ack. |
3 |
Configure-Nak. |
4 |
Configure-Reject. |
5 |
Terminate-Request. |
6 |
Terminate-Ack. |
7 |
Code-Reject. |
8 |
Protocol-Reject. |
9 |
Echo-Request. |
10 |
Echo-Reply. |
11 |
Discard-Request. |
12 |
Link-Quality Report. |
Identifier
Decimal value which aids in matching
requests and replies.
Length
Length of the LCP packet, including the Code, Identifier, Length
and Data fields.
Data
Variable length field which may contain one or more configuration
options. The format of the LCP configuration options is as follows:
Type |
Length |
Data |
LCP
configuration options |
Type
One-byte indication of the type
of the configuration option.
Length
Length of the configuration option
including the Type, Length and Data fields.
Data
Value of the Data field.
 |
LCP decode |
Interested in more details about testing
this protocol?
LQR
RFC1333
http://www.cis.ohio-state.edu/htbin/rfc/rfc1333.html
The Link Quality Report (LQR) protocol specifies
the mechanism for link quality monitoring within PPP. Packets
are sometimes dropped or corrupted due to line noise, equipment
failure, buffer overruns, etc. and it is often desirable to
determine when and how often the link drops data. Routers may
temporarily allow another route to take precedence, or an implementation
may have the option of disconnecting and switching to an alternate
link. For these reasons, such a quality monitoring mechanism
is necessary.
One LQR packet is encapsulated in the information
field of PPP data link layer frames where the protocol field
indicates type hex c025. The structure of the LQR packet is
shown in the following illustration:
4 bytes |
Magic number |
Last out LQRs |
Last out packets |
Last out octets |
Peer in LQRs |
Peer in packets |
Peer in discards |
Peer in errors |
Peer in octets |
Peer out LQRs |
Peer out packets |
Peer out octets |
Save in LQRs |
Save in packets |
Save in discards |
Save in errors |
Save in octets |
LQR
packet structure |
Magic number
Aids in detecting links which are in the looped-back condition.
Last out LQRs
Copied from the most recently received Peer Out LQRs on transmission.
Last out packets
Copied from the most recently received Peer Out Packets on transmission.
Last out octets
Copied from the most recently received Peer Out Octets on transmission.
Peer in LQRs
Copied from the most recently received Save In LQRs on transmission.
Whenever the Peer In LQRs field is zero, the Last Out fields
are indeterminate and the Peer In fields contain the initial
values for the peer.
Peer in packets
Copied from the most recently received Save In Packets on transmission.
Peer in discards
Copied from the most recently received Save In Discards on transmission.
Peer in errors
Copied from the most recently received Save In Errors on transmission.
Peer in octets
Copied from the most recently received Save In Octets on transmission.
Peer out LQRs
Copied from the Out LQRs on transmission. This number must include
this LQR.
Peer out packets
Copied from the current MIB ifOutUniPackets and ifOutNUniPackets
on transmission. This number must include this LQR.
Peer out octets
Copied from the current MIB ifOutOctets on transmission. This
number must include this LQR.
The following fields are not actually transmitted
over the inbound link. Rather, they are logically appended to
the packet by the Rx process.
Save in LQRs
Copied from In LQRs on reception. This number must include this
LQR.
Save in packets
Copied from the current MIB ifInUniPackets and ifInNUniPackets
on reception. This number must include this LQR.
Save in discards
Copied from the current MIB ifInDiscards on reception. This
number must include this LQR.
Save in errors
Copied from the current MIB ifInErrors on reception. This number
must include this LQR.
Save in octets
Copied from the current InGoodOctets on reception. This number
must include this LQR.
Interested in more
details about testing this protocol?

MPPC
RFC 2118 http://www.cis.ohio-state.edu/htbin/rfc/rfc2118.html
The Point-to-Point Protocol provides a standard
method for transporting multi-protocol datagrams over point-to-point
links. The PPP Compression Control Protocol provides a method
to negotiate and utilize compression protocols over PPP encapsulated
links. The Microsoft Point to Point Compression protocol (also
referred to as MPPC) compresses PPP encapsulated packets. The
Microsoft Point to Point Compression scheme is a means of representing
arbitrary Point-to-Point Protocol (PPP) packets in a compressed
form. The MPPC algorithm is designed to optimize processor utilization
and bandwidth utilization in order to support large number of
simultaneous connections. The MPPC algorithm is also optimized
to work efficiently in typical PPP scenarios (1500 byte MTU,
etc.). The CCP configuration Option negotiates the use of MPPC
on the link. Before any MPPC packets may be transmitted, PPP
must reach the Network-Layer protocol phase and the CCP Control
Protocol must reach the opened state. One MPPC datagram is encapsulated
in the PPP information field. Only packets with PPP protocol
numbers in the range 0021 to 00FA are compressed.
The format of the MPPC packet is shown in
the following illustration:
1 byte |
|
1 byte |
PPP Protocol |
A B C D |
Coherency Count |
Compressed
Data… |
……
…..
|