Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode
obsoletes
- rfc-877 — Standard for the transmission of IP datagrams over public data networks
Extracted elements (30)
Larger X.25 data packet sizes do not necessarily improve performance: store-and-forward X.25 switches on slow trunks incur larger per-hop delays for large packets, reducing pipelining and potentially harming end-to-end throughput. Segmenting into smaller complete packet sequences allows more pipelining through switches.
The IP datagram MTU was increased from 576 (RFC 877) to 1600 octets to reflect existing practice and align toward a standard 1500-octet default MTU usable on both LANs and WANs without router fragmentation.
The Null (multiplexed) encapsulation was introduced to allow multiprotocol routers that can only open a limited number of simultaneous virtual circuits to carry multiple network layer protocols over a single circuit, avoiding an unreasonable number of open VCs.
Virtual circuit call-collision algorithms are explicitly prohibited because multiple VCs per encapsulation are desired and allowed; implementing anti-collision logic would prevent legitimate multi-circuit use.
Some X.25 implementations incorrectly assign calls with CC CUD to the X.29 PAD facility when IP is not properly configured. Originators can detect this if they receive data packets with the Q bit set (especially first octets hex 02, 04, or 06); they should clear the call and apply a hold-down timer.
To interoperate with RFC 877 implementations, systems must be able to send IP with an MTU of 576 octets and receive IP datagrams up to 1600 octets. The default transmit MTU of 1500 and the CC CUD requirement preserve backward compatibility.
Each system MUST only accept calls for protocols it can process; every Internet system MUST accept the CC encapsulation for IP. A system MUST NOT accept a call and then immediately clear it, as accepted-then-cleared calls may be billed on some networks.
Each system MUST use an inactivity timer to clear idle virtual circuits. The timer SHOULD be configurable (with 'infinite' acceptable when explicitly set); a reasonable IP default is 90 seconds.
Every system MUST be able to receive and transmit PDUs up to at least 1600 octets. The default transmit MTU for IP SHOULD be 1500 and MUST be configurable in at least the range 576 to 1600, enabling interoperability with both RFC 877 and this specification.
For compatibility with existing practice and RFC 877, IP datagrams MUST by default be encapsulated on a virtual circuit opened with the CC CUD. Implementations MAY also support IP within Null, SNAP, and Null+SNAP encapsulations, each configurable per-peer.
IEEE 802.1d bridging across X.25 MUST use the Null (multiplexed) encapsulation because PDU ordering across different SNAP headers must be preserved.
Multiple virtual circuits for the same encapsulation between two systems are explicitly allowed. Receivers SHOULD accept such additional calls and MUST accept PDUs on them. Algorithms to prevent virtual circuit call collision (e.g., ISO/IEC 8473 section 8.4.3.5) MUST NOT be implemented.
PDU size (e.g., IP MTU) MUST be configurable on at least a per-interface basis; maximum transmitted PDU length SHOULD be configurable per-peer and MAY be configurable per-encapsulation.
PDUs MUST be sent as X.25 complete packet sequences: they begin on X.25 data packet boundaries, and the M bit (more data) is used to fragment PDUs larger than one X.25 data packet.
Receivers MUST NOT accept an incoming call only to subsequently close the circuit or ignore its PDUs.
Systems supporting NLPIDs other than hex CC SHOULD allow their use to be configured per-peer address. Use of hex CC for IP MUST always be allowed between peers and cannot be disabled by configuration.
When Null (multiplexed) encapsulation is used, a receiver MUST accept an incoming call if it supports the Null encapsulation for any network layer protocol, and MAY silently discard multiplexed PDUs for unsupported protocols.
X.25 implementations MUST minimally support call setup and clearing and complete packet sequences. For better performance, they SHOULD also support extended sequence numbering, flow control parameter negotiation, and reverse charging.
X.25 interrupt packets and the Q bit MUST NOT be used. The D bit SHOULD NOT be used because it interferes with M-bit PDU sequencing; the D-bit modification facility MUST NOT be subscribed.
ISO/IEC 8208 diagnostic code 249 signifies 'requested protocol not supported' when clearing an incoming call. Non-8208 systems typically use code 0. When supplied for this reason, the diagnostic MUST be either 249 or 0.
NLPID value hex 00 identifies Null (multiplexed) encapsulation, allowing multiple network layer protocols over a single virtual circuit. Each X.25 complete packet sequence on such a circuit begins with a one-octet NLPID identifying the protocol for that sequence only.
NLPID value hex 80 (128) identifies IEEE SNAP encapsulation. A five-octet SNAP header is included in the CUD field immediately following the hex 80 octet; SNAP headers are NOT included in subsequent X.25 data packets. Only one SNAP-identified protocol may be carried per circuit opened with this encoding.
NLPID value hex 81 (129) identifies ISO/IEC 8473 (CLNP); ES-IS and IS-IS datagrams MAY also be carried on the same virtual circuit as CLNP. NLPID hex 82 (130) is used specifically for ES-IS (ISO/IEC 9542). Support for CLNP and ES-IS is not required for conformance.
NLPID value hex CC (204) identifies IP (RFC 791) encapsulation. Every Internet system MUST support this encapsulation; conformance with this specification requires IP support.
The first octet of the Call User Data (CUD) field in the X.25 Call Request packet is a one-octet Network Layer Protocol Identifier (NLPID), per ISO/IEC TR 9577, used for protocol demultiplexing on the virtual circuit. Receivers MUST ignore extraneous octets beyond the NLPID.
Security issues are not discussed in this memo. No authentication, integrity, or confidentiality mechanisms are specified for X.25 encapsulation.
CLNP/ES-IS/IS-IS encapsulation: Call Request CUD contains hex 81 (CLNP) or hex 82 (ES-IS). Data packets carry CLNP, ES-IS, or IS-IS datagrams which are self-identifying in their first octet; no additional header is prepended.
IP encapsulation: Call Request CUD contains the single octet hex CC. X.25 data packets carry the IP datagram directly following the GFI/LCN/I header, with no additional encapsulation header.
Null (multiplexed) encapsulation: Call Request CUD contains hex 00. Each X.25 data packet begins with a 1-octet NLPID identifying the encapsulated protocol for that packet sequence; if NLPID is hex 80, a 5-octet SNAP header immediately follows before the PDU.
SNAP encapsulation: Call Request CUD contains hex 80 followed by a 5-octet SNAP header (OUI + PID). Subsequent X.25 data packets carry the PDU directly with NO SNAP header repeated.