RFC 1209

The Transmission of IP Datagrams over the SMDS Service

📅 published March 1991, from ietf

The Transmission of IP Datagrams over the SMDS Service 🎀

  • RFC number: 1209 🌸
  • Series: Network Working Group 🧚
  • Authors: D. Piscitello and J. Lawrence, both at Bell Communications Research 💅
  • Date: March 1991 ⭐
  • Category: IAB standards track protocol 👑
  • Obsoletes: the header doesn't list any 🙈
  • Updates: the header doesn't list any 🙈

Status of This Memo ✨

Okay so this memo defines a protocol for sending IP and ARP packets over a Switched Multi-megabit Data Service Network that's set up as a logical IP subnetwork. This RFC specifies an IAB standards track protocol for the Internet community, and it asks for 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 💖.

Abstract 🦋

So this is the big picture! This memo describes an initial use of IP and ARP in an SMDS service environment set up as a logical IP subnetwork, LIS (more on that below) 🌈. It walks through the encapsulation method and a bunch of service-specific issues. It doesn't rule out handling the SMDS Service differently in other setups. Public or inter-company, inter-enterprise configurations may be treated differently, and those will get their own documents later 👀. This document only looks at directly connected IP end-stations or routers, because issues raised by MAC level bridging are out of scope for this paper 🙅‍♀️.

Acknowledgment 🙌

This memo borrows heavily, both in concept and in text, from [4], written by Jon Postel and Joyce K. Reynolds of ISI, and from [5], written by David Katz of Merit, Inc. 💜 The authors also want to shout out the IP Over SMDS Service working group of the Internet Engineering Task Force 📣.

Conventions 💅

Read this part carefully, bestie, because it tells you how to read the rest of the doc 🫶. The following language conventions are used in the items of specification in this document:

  • MUST, SHALL, or MANDATORY — this one is an absolute requirement of the specification. No debate 💀.
  • SHOULD or RECOMMENDED — you should generally follow this for all but exceptional circumstances 🍓.
  • MAY or OPTIONAL — this one is truly optional. You can follow it or ignore it depending on what your implementation needs 🌸.

Introduction 🧚

The goal here is simple and iconic: allow compatible, interoperable implementations for transmitting IP datagrams and ARP requests and replies ✨.

The SMDS Service and the SMDS Interface Protocol (SIP) are described in [3], [6], and [7]. Briefly, the SMDS Service is a connectionless, public, packet-switched data service 🦋. It acts a lot like the high-speed data networks you already know, like LANs, and here's how:

  • The SMDS Service gives you datagram packet transfer. Every data unit gets handled and switched separately, with no network connection set up beforehand 💖.
  • The SMDS Service has high throughput and low delay. It transparently transports and delivers up to 9188 octets of user information in a single transmission 🔥.
  • There's no explicit flow control. Instead, the rate of information transfer on the access paths gets controlled in both the subscriber-to-network direction and the network-to-subscriber direction, using an access class enforcement mechanism 🌈.
  • Both individually addressed and group-addressed (multicast) packets can be transferred 🫶.
  • On top of those LAN-like features, there's a set of addressing-related service features (source address validation, and source and destination address screening). These let a subscriber, or a group of subscribers, make a logical private network, also called a closed user group, over the SMDS Service 👑. The access control that the closed user group mechanism provides is supplied by the SMDS provider, following the specifications in [3] 💅.
  • SMDS addresses are 60 bits plus a 4 bit Address Type. The Address Type subfield takes up the 4 most significant bits of the destination and source address fields of the SIP Level 3 Protocol Data Unit (PDU). It holds the value 1100 for 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, and the rest of the Data Link Service comes from the IEEE 802.2 Logical Link Control (LLC) service [9] 💖. Here's how the whole stack looks, 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 is an initial use of IP and ARP in an SMDS Service environment set up as a logical IP subnetwork (more on that below) 🌸. It doesn't rule out handling SMDS Service in other configurations besides logical IP subnetworks. Public or inter-company, inter-enterprise configurations may be treated differently and will be described in future documents 🦋. This document doesn't address issues related to transparent data link layer interoperability 🙈.

Logical IP Subnetwork Configuration 🌈

This section describes the scenario for an SMDS Service that's configured with multiple logical IP subnetworks, LIS (described below) 💅. The scenario only considers directly connected IP end-stations or routers. MAC level bridging issues are beyond the scope of this paper 🙅‍♀️.

In the LIS scenario, each separate administrative entity sets up its hosts inside a closed logical IP subnetwork 🫶. Each LIS works and communicates independently of the other LISs over the same network that provides SMDS. Hosts connected to SMDS talk directly to other hosts in the same LIS. Communication to hosts outside an individual LIS goes through an IP router. That router is simply a station attached to the SMDS Service that's been configured as a member of both logical IP subnetworks 👑. The result is a bunch of disjoint LISs running over the same network that supports SMDS. Yes, hosts on different IP networks will go through an intermediate router, even when a direct path over the SMDS Service might be possible 🙈.

The service is expected to evolve into a more public interconnection, where machines directly connected to the SMDS Service can talk to each other without an intermediate router ✨. But the issues that a large public interconnection would raise (like scalability of address resolution or propagation of routing updates) are beyond the scope of this paper. We expect future RFCs to tackle those 🔮.

The following is a list of the requirements for a LIS configuration:

  • All members have the same IP network/subnet number 🎀.
  • All stations within a LIS are accessed directly over SMDS 🦋.
  • All stations outside the LIS are accessed via a router 💖.
  • For each LIS, a single SMDS group address is configured to identify all members of the LIS. Any packet sent to this address gets delivered by SMDS Service to every member of the LIS 🌸.

The following list identifies a set of SMDS Service specific parameters that MUST be implemented in each IP station that would connect to the SMDS Service 🔥. The parameter values get decided at SMDS subscription time and will be different for each LIS, so these parameters MUST be user configurable 💅.

  • SMDS Hardware Address (smds$ha). This is the SMDS Individual address of the IP station, as determined at subscription time. Each host MUST be configured to accept datagrams destined for this address 🧚.
  • SMDS LIS Group Address (smds$lis-ga). This is the SMDS Group address configured at subscription time to identify the SMDS Subscriber Network Interfaces (SNI) of all members of the LIS connected to the SMDS Service. All members of the LIS MUST be prepared to accept datagrams addressed to smds$lis-ga 🫶.
  • SMDS Arp Request Address (smds$arp-req). This is the SMDS address (individual or group) that ARP requests get sent to. In the initial LIS configuration, this value is set to smds$lis-ga. It's conceivable that in other configurations this value would be set to some address other than smds$lis-ga (see 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 they MUST be able to associate each set of parameters with a specific IP network/subnet number. On top of that, 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 🦋.

  • SMDS LIS Group Address (smds$lis-ga). An SMDS Group address MUST be configured at subscription time to identify the SMDS Subscriber Network Interfaces (SNI) of all members of the LIS connected to the SMDS Service 🎀.
  • SMDS Address Screening Tables (Source and Destination). Using SMDS screening tables isn't necessary for IP over SMDS Service to work 🙈. If you do decide to use them, both the source and destination tables for each SNI MUST be configured to allow, at minimum, direct communication between all hosts in the same LIS and use of the SMDS LIS Group Address 🔥.

Packet Format ✨

Okay bestie, this is where we get into the actual packet layout 🎀 The 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 that says the SNAP header carries the EtherType code from Assigned Numbers [11] (see Figure 2). Also, values in this document follow Internet conventions, so multi-byte fields are big-endian and bits within bytes are most significant first [11] 💅

                                                       +-------+
                                                       |IP/ARP | IP/ARP
                              +----+----+----+----+----+-------+
                              |   Org Code   |Ethertype|       | SNAP
               +----+----+----+----+----+----+----+----+-------+
               |DSAP|SSAP|Ctrl|                                | LLC
+-----+----+-+-+----+----+----+----+----+----+----+----+-------+
|SIP..|HLPI|...|                                               | SIP L3
+-----+----+-+-+----+----+----+----+----+----+----+----+-------+

Figure 2. Data Link Encapsulation

  • The value of HLPI in the SIP L3 Header is 1.
  • The total length of the LLC Header and the SNAP header is 8 octets.
  • The value of DSAP and SSAP in the LLC header is 170 (decimal), AA (Internet hexadecimal).
  • The Ctrl (Control) value in the LLC header is 3 (Indicates Type One Unnumbered Information).
  • The Org Code in the SNAP header is zero (000000 Internet hexadecimal).
  • The EtherType for IP is 2048 (decimal), 0800 (Internet hexadecimal). The EtherType for ARP is 2054 (decimal), 0806 (Internet hexadecimal).

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

Address Resolution 🗺️

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 hardware type code assigned to SMDS addresses is 14 (decimal), 0E (Internet hexadecimal) [11].
  • The protocol type code for IP is 2048 (decimal), 0800 (Internet hexadecimal) [11].
  • The hardware address length for SMDS is 8.
  • The protocol address length for IP is 4.
  • The operation code is 1 for request and 2 for reply.

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.

IP Broadcast Address 📡

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]).

IP Multicast Support 🎶

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:

  • JoinLocalGroup (group-address)
  • LeaveLocalGroup (group-address)

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. 🔍

Trailer Formats 🚫

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.

Byte Order 🔢

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.

MAC Sublayer Details 🧩

Packet Size 📏

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.

Other MAC Sublayer Issues 🌸

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].

IEEE 802.2 Details 🧠

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.

REFERENCES 📚

  1. Postel, J., "Internet Protocol", RFC 791, USC/Information Sciences Institute, September 1981.
  2. Plummer, D., "An Ethernet Address Resolution Protocol - or - Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", RFC 826, MIT, November 1982.
  3. "Generic Systems Requirements in support of Switched Multi-megabit Data Service", Technical Advisory TA-TSY-000772, Bellcore Technical Advisory, Issue 3, October 1989.
  4. Postel, J., and J. Reynolds, "A Standard for the Transmission of IP Datagrams over IEEE 802 Networks", RFC 1042, USC/Information Sciences Institute, February 1988.
  5. Katz, D., "A Proposed Standard for the Transmission of IP Datagrams over FDDI Networks", RFC 1188, Merit/NSFNET, October 1990.
  6. Dix, F., Kelly, M., and R. Klessig, "Access to a Public Switched Multi-Megabit Data Service Offering", ACM SIGCOMM CCR, July 1990.
  7. Hemrick, C. and L. Lang, "Introduction to Switched Multi-megabit Data Service (SMDS), an Early Broadband Service", publication pending in the Proceedings of the XIII International Switching Symposium (ISS 90), May 27, 1990 - June 1, 1990.
  8. Institute of Electrical & Electronic Engineers, Inc. IEEE Standard 802.6, "Distributed Queue Dual Bus (DQDB) Subnetwork of a Metropolitan Area Network (MAN) Standard", December 1990.
  9. IEEE, "IEEE Standards for Local Area Networks: Logical Link Control", IEEE, New York, New York, 1985.
  10. IEEE, "Draft Standard P802.1A--Overview and Architecture", 1989.
  11. Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1060, USC/Information Sciences Institute, March 1990.
  12. Braden, R., and J. Postel, "Requirements for Internet Gateways", RFC 1009, USC/Information Sciences Institute, June 1987.
  13. Deering, S., "Host Extensions for IP Multicasting", RFC 1112, Stanford University, August 1989.
  14. IEEE,"ANSI/IEEE Std 802.2-1985, ISO Draft International Standard 8802/2", IEEE, New York, New York, 1985.

Security Considerations 🔐

Security issues are not discussed in this memo. Read the room, bestie. 😭

Authors' Addresses 🦋

  • 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
📦 where this page comes from