The PPP OSI Network Layer Control Protocol (OSINLCP)
Extracted elements (25)
It is recommended that alignment be achieved through PPP header compression combinations whenever possible rather than leading zero padding. For example, an alignment of 3 could be achieved by combining uncompressed Address/Control fields (2 octets) with a compressed Protocol field (1 octet).
OSI protocols have peculiar alignment problems because they are often encapsulated in data link protocols with odd-length headers, while PPP defaults to even-length headers. A router switching an OSI packet may encounter inconvenient memory boundaries, addressable by leading zero padding.
OSINLCP does not define a separate configuration option for OSI Network Layer address exchange; instead, the ES-IS protocol (ISO 9542) is used. ES-IS already provides a mechanism for determining the neighbor's Network Layer address(es) and whether the neighbor is an End System or Intermediate System.
The Align-NPDU option is negotiated separately in each direction because empirical evidence suggests the greatest time deficit for re-alignment exists at the receiver, not the sender.
For ES-IS over very unreliable PPP links, it may be necessary to set the Holding Timer to slightly more than three times the Configuration Timer (rather than the ISO 9542 recommendation of twice) to ensure loss of configuration information is an unusual event.
For IS-IS over unreliable PPP links, the Holding Time must be greater than k times the ISISHello timer, where k is chosen such that loss of k consecutive IS-IS Hellos is rare. If link quality is poor, the Holding Time must be increased or the ISISHello timer decreased to avoid unnecessary link flapping.
IDRP contains built-in reliability mechanisms because it expects to run over datagram links but requires reliable exchange of routing information; no additional PPP-level changes are required.
The OSI Connection-Oriented Network Protocol (ISO 8208, effectively X.25 Packet Layer) is intended to run over a reliable data link such as IEEE 802.2 type II or LAPB, and therefore the unreliable data link service provided by PPP is not appropriate for use with ISO 8208.
A receiver that does not need alignment MUST NOT request the Align-NPDU option. A sender that desires a particular alignment prior to sending SHOULD Configure-Nak with an appropriate Alignment value.
An implementation should be prepared to wait for Authentication and Link Quality Determination to finish before timing out waiting for a Configure-Ack or other response. It is suggested that an implementation give up only after user intervention or a configurable amount of time.
Before any NPDUs may be communicated, PPP must reach the Network-Layer Protocol phase and the OSINLCP must reach the Opened state. Exactly one OSI NPDU is encapsulated in the Information field of a PPP frame where the Protocol field indicates hex 0023.
If a sender accepts the peer's Align-NPDU option, it MUST transmit packets with the agreed alignment. By default, alignment is at the sender's discretion.
OSINLCP packets may not be exchanged until PPP has reached the Network-Layer Protocol phase. OSINLCP packets received before this phase is reached should be silently discarded.
Regardless of whether leading zero padding is used, an implementation MUST be able to receive a PPP packet with any arbitrary alignment of the NPDU.
The Align-NPDU alignment request is advisory; failure to agree on an alignment MUST NOT prevent the OSINLCP from reaching the Opened state. All receivers MUST be capable of accepting packets with any alignment.
The Inactive Network Layer Protocol (NLPID value zero, defined in ISO 8473) MUST NOT be used over PPP, ensuring that any OSI network layer protocol in use has a non-zero NLPID value.
The maximum length of an OSI NPDU transmitted over a PPP link equals the maximum length of the Information field of a PPP data link layer frame. Larger NPDUs must be segmented as necessary.
When sending, an implementation MAY insert one to three octets of zero between the PPP header and the OSI NPDU for alignment purposes. On reception, any such leading zero octets MUST be removed.
Exactly one OSINLCP packet is encapsulated in the Information field of a PPP Data Link Layer frame where the Protocol field indicates type hex 8023 (OSI Network Layer Control Protocol). Only Codes 1 through 7 are used; other Codes should result in Code-Rejects.
OSI Network Layer protocols are discriminated by the Network Layer Protocol Identifier (NLPID), which is the first octet of each NPDU as defined in ISO/TR 9577. This allows multiple OSI protocols to share a common data link without a discriminator below the network layer.
OSINLCP has one Configuration Option: Align-NPDU (type 1), which allows a receiver to negotiate a particular alignment of the OSI NPDU. Alignment is accomplished through a combination of PPP header compression and leading zero padding.
The Alignment field values are: 1–4 require an offset of that specific length modulo 4; 255 requests an odd-length offset (1 or 3); 254 requests an even-length offset (2 or 4). If the sender cannot dynamically vary padding, it MUST NAK with one of the two specific values.
The OSI Network Layer Control Protocol (OSINLCP) is the PPP NCP responsible for configuring, enabling, and disabling OSI protocol modules on both ends of a point-to-point link. It uses the same packet exchange mechanism as LCP and is identified by Protocol field hex 8023.
Security issues are not discussed in this memo. RFC 1377 defers all security considerations.
The Align-NPDU Configuration Option is 3 octets: Type (1 octet, value 1), Length (1 octet, value 3), and Alignment (1 octet). The Alignment field specifies the desired offset of the OSI NPDU relative to the start of the PPP packet header.