| Main index | Section 4 | Options |
#include <sys/types.h>
#include <netgraph/ng_ppp.h>
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 bypass hook which is used to handle any protocol not directly supported by the node. This includes all of the control protocols: LCP, IPCP, CCP, etc. Typically this node is connected to a user-land daemon via a ng_socket(4) type node.
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 NGM_PPP_LINK_CONFIG message.
When a link is connected but disabled, all received frames are forwarded directly out the bypass hook, and conversely, frames may be transmitted via the bypass 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.
Encryption works exactly analogously via the encrypt and decrypt nodes. 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.
Conversely, any data written to the bypass 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 NG_PPP_BUNDLE_LINKNUM 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 bypass 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).
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 NGM_PPP_SET_CONFIG control message.
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 round-robin or optimized packet delivery.
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 bundle. 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.
| link<N> | |
| Individual PPP link number <N> | |
| compress | |
| Connection to compression engine | |
| decompress | |
| Connection to decompression engine | |
| encrypt | |
| Connection to encryption engine | |
| decrypt | |
| Connection to decryption engine | |
| vjc_ip | |
| Connection to ng_vjc(4) ip hook | |
| vjc_vjcomp | |
| Connection to ng_vjc(4) vjcomp hook | |
| vjc_vjuncomp | |
| Connection to ng_vjc(4) vjuncomp hook | |
| vjc_vjip | |
| Connection to ng_vjc(4) vjip hook | |
| inet | |
| IP packet data | |
| ipv6 | |
| IPv6 packet data | |
| atalk | |
| AppleTalk packet data | |
| ipx | |
| IPX packet data | |
| bypass | |
| Bypass hook; frames have a four byte header consisting of a link number and a PPP protocol number. | |
| NGM_PPP_SET_CONFIG ( setconfig) | |
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
struct ng_ppp_node_conf
as an argument:
/* Per-link config structure */
struct ng_ppp_link_conf {
u_char enableLink; /* enable this link */
u_char enableProtoComp;/* enable protocol field compression */
u_char enableACFComp; /* enable addr/ctrl field compression */
uint16_t mru; /* peer MRU */
uint32_t latency; /* link latency (in milliseconds) */
uint32_t bandwidth; /* link bandwidth (in bytes/sec/10) */
};
| |
| NGM_PPP_GET_CONFIG ( getconfig) | |
| Returns the current configuration as a struct ng_ppp_node_conf. | |
| NGM_PPP_GET_LINK_STATS ( getstats) | |
| This command takes a two byte link number as an argument and returns a struct ng_ppp_link_stat containing statistics for the corresponding link. Here NG_PPP_BUNDLE_LINKNUM is a valid link number corresponding to the multi-link bundle. | |
| NGM_PPP_GET_LINK_STATS64 ( getstats64) | |
| Same as NGM_PPP_GET_LINK_STATS but returns struct ng_ppp_link_stat64 containing 64bit counters. | |
| NGM_PPP_CLR_LINK_STATS ( clrstats) | |
| This command takes a two byte link number as an argument and clears the statistics for that link. | |
| NGM_PPP_GETCLR_LINK_STATS ( getclrstats) | |
| Same as NGM_PPP_GET_LINK_STATS, but also atomically clears the statistics as well. | |
| NGM_PPP_GETCLR_LINK_STATS64 ( getclrstats64) | |
| Same as NGM_PPP_GETCLR_LINK_STATS but returns struct ng_ppp_link_stat64 containing 64bit counters. | |
This node type also accepts the control messages accepted by the ng_vjc(4) node type. When received, these messages are simply forwarded to the adjacent ng_vjc(4) node, if any. This is particularly useful when the individual PPP links are able to generate NGM_VJC_RECV_ERROR messages (see ng_vjc(4) for a description).
, RFC 1661, The Point-to-Point Protocol (PPP),
, , , , , RFC 1990, The PPP Multilink Protocol (MP),
| NG_PPP (4) | November 13, 2012 |
| Main index | Section 4 | Options |
Please direct any comments about this manual page service to Ben Bullock. Privacy policy.
| “ | I have a natural revulsion to any operating system that shows so little planning as to have to named all of its commands after digestive noises (awk, grep, fsck, nroff). | ” |