The PPP SNA Control Protocol (SNACP)
Extracted elements (16)
LLC(2) is included in the SNA over LLC 802.2 frame format to provide link-level error recovery, performed by the routers at each end of the PPP link. This preserves SNA's traditional reliance on LLC for reliable delivery at the link layer.
It is architecturally possible to transport HPR NLPs over LLC over PPP using PPP Protocol field type hex 004B (SNA over LLC 802.2) if the optional HPR link-level error recovery tower is included in the implementation. This is an alternative to using the dedicated 0x004D type.
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.
Exactly one HPR Network Layer Packet (NLP) is encapsulated in the PPP Information field, where the PPP Protocol field indicates type hex 004D (SNA).
Exactly one SNA XID or FID2 PIU over LLC 802.2 is encapsulated in the PPP Information field, where the PPP Protocol field indicates type hex 004B.
Exactly one SNACP packet is encapsulated in the PPP Information field, where the PPP Protocol field indicates type hex 804B (SNA over LLC 802.2) or hex 804D (SNA).
For SNACP, only Codes 1 through 7 (Configure-Request, Configure-Ack, Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack, and Code-Reject) are used. Other Codes should be treated as unrecognized and should result in Code-Rejects.
SNACP packets may not be exchanged until PPP has reached the Network-Layer Protocol phase. SNACP packets received before this phase is reached should be silently discarded.
The maximum length of a SNA packet transmitted over a PPP link is the same as the maximum length of the Information field of a PPP encapsulated packet.
When an implementation silently discards a packet, it SHOULD provide the capability of logging the error including the contents of the discarded packet, and SHOULD record the event in a statistics counter.
The SNA Control Protocol (SNACP) is responsible for configuring, enabling, and disabling SNA on both ends of a PPP point-to-point link. SNACP uses the same packet exchange mechanism as LCP. There are actually two SNA NCPs: one for SNA over LLC 802.2 and one for SNA without LLC 802.2, negotiated separately and independently.
There are no Configuration Options defined for SNA or for SNA over LLC 802.2 in SNACP. All other SNACP behavior is identical to LCP.
Security issues are not discussed in this memo. No authentication, integrity, or confidentiality mechanisms are defined for SNACP or for SNA traffic carried over PPP.
SNACP follows the same state machine as LCP. Before SNA packets can be communicated, PPP must reach the Network-Layer Protocol phase and the appropriate SNACP must reach the Opened state. Once Opened, SNA datagrams can be sent; the link remains configured until explicit LCP or SNACP packets close it or an external event occurs.
HPR Network Layer Packets (NLPs) are encapsulated in the PPP Information field with PPP Protocol field 0x004D. The frame contains: Protocol (0x004D), NHDR, THDR, and data fields, transmitted left to right.
SNA XID or FID2 PIUs over LLC 802.2 are encapsulated in the PPP Information field with PPP Protocol field 0x004B. The frame contains: Protocol (0x004B), DSAP Address, SSAP Address, Control Field, and LLC Information Field (carrying the XID or FID2 PIU).