The Transmission of IP Datagrams over the SMDS Service
also
- std-52
Extracted elements (27)
Each LIS operates independently over the same SMDS network, requiring hosts in different LISs to communicate via an intermediate router even when a direct SMDS path exists. This simplifies address resolution and routing propagation at the cost of suboptimal paths.
SMDS group addresses do not support dynamic subscription (JoinLocalGroup/LeaveLocalGroup), so the RFC 1112 IP multicasting method cannot be used directly. Instead, all multicast IP addresses are mapped to smds$lis-ga (the same address used for broadcast), and filtering is done at the destination host.
The LIS model intentionally routes inter-LIS traffic through a router even when a direct SMDS path exists between the endpoints. This avoids scalability issues with address resolution and routing update propagation that would arise in large public SMDS interconnection scenarios.
It is RECOMMENDED that SMDS addresses be represented in native SMDS format (most significant bit of Address Type sub-field as high-order bit of first octet) in all higher layer Internet protocols such as SNMP, for consistency with ARP packet encoding.
SMDS does not support the JoinLocalGroup/LeaveLocalGroup dynamic subscription interface required by RFC 1112 IP multicasting, making standard IP multicast procedures incompatible with SMDS. The broadcast-media fallback method from RFC 1112 is used instead.
All frames MUST be transmitted in standard IEEE 802.2 LLC Type 1 Unnumbered Information format with DSAP and SSAP set to decimal 170 (0xAA). The 24-bit Org Code in the SNAP MUST be set to zero.
All implementations MUST support IEEE 802.2 standard Class I service to be compliant with IEEE 802.2, including functions not directly related to SNAP SAP support such as responding to XID and TEST commands directed to the null or global SAP addresses.
All members of a LIS MUST be prepared to accept datagrams addressed to the SMDS LIS Group Address (smds$lis-ga), which identifies all SNIs of LIS members.
An SMDS Group Address (smds$lis-ga) MUST be configured at subscription time to identify all LIS member SNIs. If SMDS address screening tables are used, both source and destination tables for each SNI MUST allow direct communication between all LIS hosts and use of smds$lis-ga.
Because SMDS does not support dynamic group membership, all multicast IP addresses in a LIS are mapped to smds$lis-ga, and filtering of multicast packets MUST be performed in the destination host.
Because SMDS provides no complete hardware broadcast facility, the broadcast Internet address (host part all binary ones) MUST be mapped to smds$lis-ga.
Dynamic mapping of 32-bit Internet addresses to SMDS addresses SHALL be performed via ARP. Each host MUST know its own Internet address and SMDS address and MUST use ARP to map Internet addresses to SMDS addresses when needed.
Each host MUST be configured to accept datagrams destined for its SMDS Individual address (smds$ha) as assigned at subscription time.
IP and ARP packets over SMDS SHALL be encapsulated within IEEE 802.2 LLC and IEEE 802.1A SNAP. The SNAP MUST be used with an OUI of zero, indicating the SNAP header contains an EtherType code from Assigned Numbers.
Routers providing LIS interconnection MUST support multiple sets of LIS parameters (one per connected LIS) and associate each set with a specific IP network/subnet number. A single physical SMDS interface with one or more individual addresses is RECOMMENDED.
SMDS hardware addresses in ARP packets (ar$sha, ar$tha) MUST be carried in SMDS native address format with the most significant bit of the Address Type sub-field as the high order bit of the first octet.
SMDS service-specific parameters (smds$ha, smds$lis-ga, smds$arp-req) MUST be implemented in each IP station and MUST be user configurable, as values are determined at SMDS subscription time and differ per LIS.
The Higher Layer Protocol Id (HLPI) field in the SIP L3_PDU header MUST be set to the IEEE 802.6 assigned Protocol Id value for LLC, which is decimal 1.
The MTU for IP stations operating over SMDS SHALL be 9180 octets. This is derived from the SMDS maximum SDU of 9188 octets minus the 8-octet LLC/SNAP header. There is no minimum packet size restriction.
The publicly administered 60-bit address plus 4-bit type field format SHALL be used in both source and destination address fields of the SIP L3_PDU.
Trailer encapsulation (used by some Unix 4.x BSD implementations for VAX performance optimization) SHALL NOT be used over the SMDS Service.
ARP requests are sent to smds$arp-req rather than a true broadcast. In the LIS configuration, smds$arp-req is set to smds$lis-ga (the group address of all LIS members). In larger public configurations, it could be set to an ARP server address.
The Logical IP Subnetwork (LIS) configuration requires: all members share the same IP network/subnet number; all stations in the LIS are accessed directly over SMDS; all stations outside the LIS are accessed via a router; and a single SMDS group address (smds$lis-ga) identifies all LIS members.
Security issues are not discussed in this memo. The SMDS closed user group mechanism (source address validation and source/destination address screening) is noted as a service feature that can create a logical private network, but security implications for IP operation are not analyzed.
ARP packets for SMDS use hardware type code 14 (0x0E), protocol type 2048 (0x0800) for IP, hardware address length 8 (SMDS address size in octets), protocol address length 4, and operation code 1 (request) or 2 (reply).
SMDS addresses use the publicly administered 60-bit address plus a 4-bit Address Type field. The Address Type subfield occupies the 4 most significant bits of the destination and source address fields in the SIP L3 PDU: 0b1100 for individual address, 0b1110 for group address.
The LLC/SNAP header is 8 octets total. DSAP and SSAP are each set to 0xAA (decimal 170, the global SAP for SNAP). The Ctrl field is 0x03 (Type 1 Unnumbered Information). The 24-bit Org Code is 0x000000. The 16-bit EtherType is 0x0800 for IP or 0x0806 for ARP.