node type performs multiplexing for the PPP protocol.
It handles only packets that contain data, and forwards protocol negotiation
and control packets to a separate controlling entity (e.g., a
This approach combines the fast dispatch of
kernel implementations with the configuration flexibility of a
The PPP node type directly supports
multi-link PPP, Van Jacobson compression, PPP compression, PPP
encryption, and the IP, IPX, and AppleTalk protocols.
A single PPP node corresponds to one PPP multi-link bundle.
There is a separate hook for each PPP link in the bundle, plus
several hooks corresponding to the directly supported protocols.
For compression and encryption, separate attached nodes are required
to do the actual work.
The node type used will of course depend on the algorithm negotiated.
There is also a
hook which is used to handle any protocol not directly supported
by the node.
This includes all of the control protocols: LCP, IPCP,
Typically this node is connected to a user-land daemon via a
In general, the PPP node enables a specific link or functionality when
message has been received which enables it, and
(b) the corresponding hook(s) are connected.
This allows the controlling entity to use either method (a) or (b)
(or both) to control the node's behavior.
When a link is connected but disabled, traffic can still flow on
the link via the
hook (see below).
During normal operation, the individual PPP links are connected to hooks
links are supported.
These device-independent hooks transmit and receive full PPP
frames, which include the PPP protocol, address, control, and
information fields, but no checksum or other link-specific fields.
On outgoing frames, when protocol compression
has been enabled and the protocol number is suitable for compression,
the protocol field will be compressed (i.e., sent as one byte
instead of two).
Either compressed or uncompressed protocol fields
are accepted on incoming frames.
Similarly, if address and control
field compression has been enabled for the link, the address and
control fields will be omitted (except for LCP frames as required
by the standards).
Incoming frames have the address and control fields
stripped automatically if present.
Since all negotiation is handled outside the PPP node, the links
should not be connected and enabled until the corresponding link
has reached the network phase (i.e., LCP negotiation and authentication
have completed successfully) and the PPP node has been informed of
the link parameters via the
When a link is connected but disabled, all received frames are forwarded
directly out the
hook, and conversely, frames may be transmitted via the
hook as well.
This mode is appropriate for the link authentication phase.
As soon as the link is enabled, the PPP node will
begin processing frames received on the link.
COMPRESSION AND ENCRYPTION
Compression is supported via two hooks,
Compression and decompression can be enabled by toggling the
fields of the node configuration structure.
is set to
then all outgoing frames are sent to the
hook and all packets received on this hook are expected to be
compressed, so the COMPD tag is put on them unconditionally.
is set to
then packets received on the
hook are resent as is.
The compressor node should put the tag, if the packet was compressed.
is set to
then the node will sent to the
hook only those frames, that are marked with the COMPD tag.
is set to
then the node will sent all incoming packets to the
Compression and decompression can be completely disabled by setting the
fields to the
Encryption works exactly analogously via the
Data is always compressed before being encrypted,
and decrypted before being decompressed.
Only bundle-level compression and encryption is directly supported;
link-level compression and encryption can be handled transparently
by downstream nodes.
VAN JACOBSON COMPRESSION
When all of the
hooks are connected, and the corresponding configuration flag is
enabled, Van Jacobson compression and/or decompression will become active.
Normally these hooks connect to the corresponding hooks of a single
The PPP node is compatible with the
modes of the
When a frame is received on a link with an unsupported protocol,
or a protocol which is disabled or for which the corresponding hook
is unconnected, the PPP node forwards the frame out the
hook, prepended with a four byte prefix.
This first two bytes of
the prefix indicate the link number on which the frame was received
(in network order).
For such frames received over the bundle (i.e., encapsulated in the
multi-link protocol), the special link number
After the two byte link number is the two byte PPP protocol number
(also in network order).
The PPP protocol number is two bytes long even if the original frame
was protocol compressed.
Conversely, any data written to the
hook is assumed to be in this same format.
The four byte header is
stripped off, the PPP protocol number is prepended (possibly compressed),
and the frame is delivered over the desired link.
If the link number is
the frame will be delivered over the multi-link bundle; or, if multi-link
is disabled, over the (single) PPP link.
Typically when the controlling entity receives an unexpected packet on the
hook it responds either by dropping the frame (if it is not ready for
the protocol) or with an LCP protocol reject (if it does not recognize
or expect the protocol).
To enable multi-link PPP, the corresponding configuration flag must be set
and at least one link connected.
The PPP node will not allow more than
one link to be connected if multi-link is not enabled, nor will it allow
certain multi-link settings to be changed while multi-link operation is
active (e.g., short sequence number header format).
Since packets are sent as fragments across multiple individual links,
it is important that when a link goes down the PPP node is notified
immediately, either by disconnecting the corresponding hook or disabling
the link via the
Each link has configuration parameters for latency (specified in
milliseconds) and bandwidth (specified in tens of bytes per second).
The PPP node can be configured for
When configured for round-robin delivery, the latency and bandwidth
values are ignored and the PPP node simply sends each frame as a
single fragment, alternating frames across all the links in the
This scheme has the advantage that even if one link fails
silently, some packets will still get through.
It has the disadvantage
of sub-optimal overall bundle latency, which is important for
interactive response time, and sub-optimal overall bundle bandwidth
when links with different bandwidths exist in the same bundle.
When configured for optimal delivery, the PPP node distributes the
packet across the links in a way that minimizes the time it takes
for the completed packet to be received by the far end.
This involves taking into account each link's latency, bandwidth, and
current queue length.
Therefore these numbers should be configured as accurately as possible.
The algorithm does require
some computation, so may not be appropriate for very slow machines
and/or very fast links.
As a special case, if all links have identical latency and bandwidth,
then the above algorithm is disabled (because it is unnecessary)
and the PPP node simply fragments frames into equal sized portions
across all of the links.
This node type supports the following hooks:
Individual PPP link number
Connection to compression engine
Connection to decompression engine
Connection to encryption engine
Connection to decryption engine
IP packet data
AppleTalk packet data
IPX packet data
Bypass hook; frames have a four byte header consisting of
a link number and a PPP protocol number.
This node type supports the generic control messages, plus the following:
This command configures all aspects of the node.
This includes enabling
multi-link PPP, encryption, compression, Van Jacobson compression, and IP,
IPv6, AppleTalk, and IPX packet delivery.
It includes per-link configuration,
including enabling the link, setting latency and bandwidth parameters,
and enabling protocol field compression.
Note that no link or functionality
is active until the corresponding hook is also connected.
This command takes a
as an argument:
Returns the current configuration as a
This command takes a two byte link number as an argument and returns a
containing statistics for the corresponding link.
is a valid link number corresponding to the multi-link bundle.
Same as NGM_PPP_GET_LINK_STATS but returns
containing 64bit counters.
This command takes a two byte link number as an argument and
clears the statistics for that link.
but also atomically clears the statistics as well.
Same as NGM_PPP_GETCLR_LINK_STATS but returns
containing 64bit counters.
This node type also accepts the control messages accepted by the
When received, these messages are simply forwarded to
node, if any.
This is particularly useful when the individual
PPP links are able to generate
for a description).
This node shuts down upon receipt of a
control message, or when all hooks have been disconnected.