Network Working Group D. Piscitello Request for Comments: 1209 J. Lawrence Bell Communications Research March 1991
This memo defines a protocol for the transmission of IP and ARP
packets over a Switched Multi-megabit Data Service Network configured
as a logical IP subnetwork. This RFC specifies an IAB standards
track protocol for the Internet community, and requests discussion
and suggestions for improvements. Please refer to the current
edition of the "IAB Official Protocol Standards" for the
standardization state and status of this protocol. Distribution of
this memo is unlimited.
This memo describes an initial use of IP and ARP in an SMDS service environment configured as a logical IP subnetwork, LIS (described below). The encapsulation method used is described, as well as various service-specific issues. This memo does not preclude subsequent treatment of the SMDS Service in configurations other than LIS; specifically, public or inter-company, inter-enterprise configurations may be treated differently and will be described in future documents. This document considers only directly connected IP end-stations or routers; issues raised by MAC level bridging are beyond the scope of this paper.
This memo draws heavily in both concept and text from [4], written by Jon Postel and Joyce K. Reynolds of ISI and [5], written by David Katz of Merit, Inc. The authors would also like to acknowledge the contributions of the IP Over SMDS Service working group of the Internet Engineering Task Force.
The following language conventions are used in the items of specification in this document:
The goal of this specification is to allow compatible and interoperable implementations for transmitting IP datagrams and ARP requests and replies.
The characteristics of the SMDS Service and the SMDS Interface Protocol (SIP) are presented in [3], [6], and in [7]. Briefly, the SMDS Service is a connectionless, public, packet-switched data service. The operation and features of the SMDS Service are similar to those found in high-speed data networks such as LANs:
indicate an individual address and the value 1110 for a 60-bit group address.
The SMDS Interface Protocol is based on the IEEE Standard 802.6, Distributed Queue Dual Bus (DQDB) Connectionless MAC protocol [8]. The SMDS service layer corresponds to the IEEE 802 MAC sublayer. The remainder of the Data Link Service is provided by the IEEE 802.2 Logical Link Control (LLC) service [9]. The resulting stack of services is illustrated in Figure 1:
+--------------------+ | IP/ARP | +--------------------+ |IEEE 802.2 LLC/SNAP | +--------------------+ | SIP LEVEL 3 (MAC) | +--------------------+ | SIP LEVELS 1 & 2 | +--------------------+
Figure 1. Protocol stack for IP over SMDS Service
This memo describes an initial use of IP and ARP in an SMDS Service environment configured as a logical IP subnetwork (described below). It does not preclude subsequent treatment of SMDS Service in configurations other than logical IP subnetworks; specifically, public or inter-company, inter-enterprise configurations may be treated differently and will be described in future documents. This document does not address issues related to transparent data link layer interoperability.
This section describes the scenario for an SMDS Service that is configured with multiple logical IP subnetworks, LIS (described below). The scenario considers only directly connected IP end- stations or routers; issues raised by MAC level bridging are beyond the scope of this paper.
In the LIS scenario, each separate administrative entity configures its hosts within a closed logical IP subnetwork. Each LIS operates and communicates independently of other LISs over the same network providing SMDS. Hosts connected to SMDS communicate directly to other hosts within the same LIS. Communication to hosts outside of an individual LIS is provided via an IP router. This router would simply be a station attached to the SMDS Service that has been configured to be a member of both logical IP subnetworks. This configuration results in a number of disjoint LISs operating over the
same network supporting the SMDS Service. It is recognized that with this configuration, hosts of differing IP networks would communicate via an intermediate router even though a direct path over the SMDS Service may be possible.
It is envisioned that the service will evolve to provide a more public interconnection, allowing machines directly connected to the SMDS Service to communicate without an intermediate router. However, the issues raised by such a large public interconnection, such as scalability of address resolution or propagation of routing updates, are beyond the scope of this paper. We anticipate that future RFCs will address these issues.
The following is a list of the requirements for a LIS configuration:
The following list identifies a set of SMDS Service specific parameters that MUST be implemented in each IP station which would connect to the SMDS Service. The parameter values will be determined at SMDS subscription time and will be different for each LIS. Thus these parameters MUST be user configurable.
section on Address Resolution).
It is RECOMMENDED that routers providing LIS functionality over the SMDS service also support the ability to interconnect differing LISs. Routers that wish to provide interconnection of differing LISs MUST be able to support multiple sets of these parameters (one set for each connected LIS) and be able to associate each set of parameters with a specific IP network/subnet number. In addition, it is RECOMMENDED that a router be able to provide this multiple LIS support with a single physical SMDS interface that may have one or more individual SMDS addresses.
The following list identifies LIS specific parameters that MUST be configured in the network supporting the SMDS Service. For each LIS, the IP network administrator MUST request the configuration of these parameters at subscription time. The administrator of each LIS MUST update these parameters as each new station is added to the LIS.
Service SHALL be encapsulated within the IEEE 802.2 LLC and IEEE
802.1A Sub-Network Access Protocol (SNAP) [10] Data Link layers
and the 3-level SIP. The SNAP MUST be used with an
Organizationally Unique Identifier Code indicating that the SNAP
header contains the EtherType code as listed in Assigned Numbers
[11] (see Figure 2). Note that values specified in this document
follow Internet conventions: multi-byte fields are described in
big-endian order and bits within bytes are described as most
significant first [11].
+-------+ |IP/ARP | IP/ARP +----+----+----+----+----+-------+ | Org Code |Ethertype| | SNAP +----+----+----+----+----+----+----+----+-------+ |DSAP|SSAP|Ctrl| | LLC
Figure 2. Data Link Encapsulation
IEEE 802.2 LLC Type One Unnumbered Information (UI) communication (which must be implemented by all conforming IEEE 802.2 stations) is used exclusively. 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 (decimal 1) [8]. All frames MUST be transmitted in standard IEEE 802.2 LLC Type 1 Unnumbered Information format, with the DSAP and the SSAP fields of the IEEE 802.2 header set to the assigned global SAP value for SNAP (decimal 170) [10]. The 24-bit Org Code (Organizationally Unique Identifier Code) in the SNAP MUST be set to a value of zero, and the remaining 16 bits are set to the EtherType value from Assigned Numbers [11] (2048 for IP, 2054 for ARP).
The data link encapsulation for IP packets is shown in Figure 3 and for ARP in Figure 4. All values shown are in Internet hexadecimal format.
+--------------+---------------------------------------+-------+ | SIP | LLC / SNAP | IP | | | | | |SIP..|HLPI|...|DSAP|SSAP|Ctrl| Org Code |Ethertype| | +-----+----+-+-+----+----+----+----+----+----+----+----+-------+ |SIP..| 01 |...| AA | AA | 03 | 000000 | 0800 | IP... | +-----+----+-+-+----+----+----+----+----+----+----+----+-------+
Figure 3. IP Data Link Encapsulation and Values
+--------------+---------------------------------------+-------+ | SIP | LLC / SNAP | ARP | | | | | |SIP..|HLPI|...|DSAP|SSAP|Ctrl| Org Code |Ethertype| | +-----+----+-+-+----+----+----+----+----+----+----+----+-------+ |SIP..| 01 |...| AA | AA | 03 | 000000 | 0806 | ARP...| +-----+----+-+-+----+----+----+----+----+----+----+----+-------+
Figure 4. ARP Data Link Encapsulation and Values
The dynamic mapping of 32-bit Internet addresses to SMDS addresses SHALL be done via the dynamic discovery procedure of the Address Resolution Protocol (ARP) [2].
Internet addresses are assigned independent of SMDS addresses. Each host implementation MUST know its own Internet address and SMDS address and respond to Address Resolution requests appropriately. Hosts MUST also use ARP to map Internet addresses to SMDS addresses when needed.
The ARP protocol has several fields that parameterize its use in any specific context [2]. These fields are:
ar$hrd 16 - bits The Hardware Type Code ar$pro 16 - bits The Protocol Type Code ar$hln 8 - bits Octets in each hardware address ar$pln 8 - bits Octets in each protocol address ar$op 16 - bits Operation Code
The 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. Although outside the scope of this document, it is RECOMMENDED that SMDS addresses be represented in this format in all higher layer Internet protocols (e.g., SNMP).
Traditionally, ARP requests are broadcast to all directly connected stations. For the SMDS Service, the ARP request packet is transmitted to the smds$arp-req hardware address. In the LIS configuration, the smds$arp-req address is set to smds$lis-ga, (the SMDS group address that identifies all members of the LIS). It is conceivable that in a larger scale, public configuration, the smds$arp-req address would be configured to the address of some ARP- server(s) instead of the group address that identifies the entire LIS.
There is no facility for complete hardware broadcast addressing over the SMDS Service. As discussed in the "LIS Configuration" section, an SMDS group address (smds$lis-ga) SHALL be configured to include all stations in the same LIS. The broadcast Internet address (the address on that network with a host part of all binary ones) MUST be mapped to smds$lis-ga (see also [12]).
A method of supporting IP multicasting is specified in [13]. It would be desirable to fully utilize the SMDS group address capabilities to support IP multicasting. However, the method in [13] requires a Network Service Interface which provides multicast-like ability to provide dynamic access to the local network service interface operations:
The SMDS group address ability does not currently support dynamic subscription and removal from group address lists. Therefore, it is RECOMMENDED that in the LIS configuration, if IP multicasting is to
be supported, the method of IP multicasting described for pure broadcast media, such as the Experimental Ethernet, be used. For this method, all Multicast IP addresses are mapped to the same SMDS address which the broadcast Internet address is mapped for a given LIS. Thus all Multicast IP addresses are mapped to smds$lis-ga. Filtering of multicast packets MUST be performed in the destination host.
Some versions of Unix 4.x BSD use a different encapsulation method in order to get better network performance with the VAX virtual memory architecture. Trailers SHALL not be used over the SMDS Service.
As described in Appendix B of the Internet Protocol specification [1], the IP datagram is transmitted over the SMDS Service as a series of 8-bit bytes. The byte order of the IP datagram shall be mapped directly onto the native SMDS byte order.
The SMDS Service defines a maximum service data unit size of 9188 information octets. This leaves 9180 octets for user data after the LLC/SNAP header is taken into account. Therefore, the MTU for IP stations operating over the network supporting the SMDS Service SHALL be 9180 octets.
There is no minimum packet size restriction defined for the SMDS Service.
The SMDS Service requires that 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 [3].
While not necessary for supporting IP and ARP, all implementations MUST support IEEE 802.2 standard Class I service in order to be compliant with IEEE 802.2. Some of the functions are not related directly to the support of the SNAP SAP (e.g., responding to XID and TEST commands directed to the null or global SAP addresses), but are part of a general LLC implementation. Both [4] and [5] describe the
minimum functionality necessary for a conformant station. Implementors should also consult IEEE Std. 802.2 [14] for details.
Security issues are not discussed in this memo.
Dave Piscitello
Bell Communications Research
331 Newman Springs Road
Red Bank, NJ 07701
Phone: (908) 758-2286
EMail: dave@sabre.bellcore.com
Joseph Lawrence
Bell Communications Research
331 Newman Springs Road
Red Bank, NJ 07701
Phone: (908) 758-4146
EMail: jcl@sabre.bellcore.com