Internet-draft IP and ARP over SMDS June 1990 The Transmission of IP Datagrams over SMDS Status of this Memo This document specifies a method of encapsulating the Internet Protocol (IP)[1] datagrams and Address Resolution Protocol (ARP)[2] requests and replies over Switched Multi-megabit Data Service (SMDS)[3]. This draft document will be submitted to the RFC editor as a protocol specification. Distribution of this memo is unlimited. Please send comments to dave@sabre.bellcore.com or jcl@sabre.bellcore.com Abstract This memo describes an initial use of IP and ARP in an SMDS environment configured as a logical IP subnet, LIS (described below). The encapsulation method used is described, as well as various service-specific issues. This memo does not preclude subsequent treatment of SMDS in configurations other than LIS; specifically, public or inter-company, inter-enterprise configurations may be treated differently and will be described in future documents. Acknowledgment This memo draws heavily in both concept and text from RFC 1042[4], written by Jon Postel and Joyce Reynolds of ISI and RFC 1103[5], written by David Katz of Merit, Inc. The authors would also like to acknowledge the contributions of the IP Over SMDS working group of the Internet Engineering Task Force. Conventions The following language conventions are used in the items of specification in this document: + "Must," "Shall," or "Mandatory"--the item is an absolute requirement of the specification. + "Should" or "Recommended"--the item should generally be followed for all but exceptional circumstances. + "May" or "Optional"--the item is truly optional and may be followed or ignored according to the needs of the implementor. Piscitello, Lawrence June 1990 Internet-draft IP and ARP over SMDS June 1990 Introduction The goal of this specification is to allow compatible and interoperable implementations for transmitting IP datagrams and ARP requests and replies. The characteristics of SMDS and the SMDS Interface Protocol (SIP) are presented in [3], [6], and in [7]. Briefly, SMDS is a connectionless, public, packet-switched data service. The operation and features of SMDS are similar to those found in high-speed data networks such as LANs: + SMDS provides a datagram packet transfer, where each data unit is handled and switched separately without the prior establishment of a network connection. + SMDS exhibits high throughput and low delay, and provides the transparent transport and delivery of up to 9188 octets of user information in a single transmission. + No explicit flow control mechanisms are provided; instead, the rate of information transfer on the access paths is controlled both in the subscriber-to-network direction and in the network-to-subscriber direction through the use of an access class enforcement mechanism. + Both individually and group-addressed (Multicast) packets can be transferred. + In addition to these LAN-like features, a set of addressing-related service features (source address validation, source and destination address screening) are provided to enable a subscriber or set of subscribers to create a logical private network over SMDS. The SMDS Interface Protocol is based on the IEEE P802.6 Draft Standard, Distributed Queue Dual Bus (DQDB) MAN MAC protocol[8]. The service offered through SMDS 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: Piscitello, Lawrence June 1990 Internet-draft IP and ARP over SMDS June 1990 _____________________ IP/ARP _____________________ IEEE 802.2 LLC/SNAP _____________________ SIP LEVEL 3 (MAC) _____________________ SIP LEVEL 2 _____________________ SIP LEVEL 1 _____________________ Figure 1. Protocol stack for IP over SMDS This memo describes an initial use of IP and ARP in an SMDS environment configured as a logical IP subnet (described below). It does not preclude subsequent treatment of SMDS in configurations other than logical IP subnets; specifically, public or inter-company, inter-enterprise configurations may be treated differently and will be described in future documents. At this time, it is not necessary that the use of IP and ARP be consistent between SMDS, FDDI and IEEE 802 networks, but it is the intent of this memo not to preclude Data Link Layer interoperability at such time as the standards define it. Logical IP Subnet Configuration This section describes the scenario for an SMDS that is configured with multiple logical IP subnets (LIS). 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 it hosts within a closed logical IP network/subnet. Each LIS operates 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 a LIS is provided via an IP router.1 This configuration results in a number of disjoint LISs operating over the same SMDS. It is recognized that with this configuration, hosts of differing IP networks must communicate via an intermediate router even though a direct path over SMDS may be __________ 1. This router would simply be a station attached to SMDS that has been configured to be a member of both logical IP networks. Piscitello, Lawrence June 1990 Internet-draft IP and ARP over SMDS June 1990 possible. It is envisioned that the service will evolve to provide a more public interconnection, allowing machines directly connected to SMDS to communicate without an intermediate router. However, the issues raised by such a large public interconnection 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: + All members have the same IP network/subnetwork number. + All stations within a LIS are accessed directly over SMDS. + All stations outside of the LIS are accessed via a router. + For each LIS a single SMDS groups address has been configured that identifies all members of the logical IP subnet. This SMDS group address (smds$ip_ga) is treated in a similar manner over each SMDS LIS as hardware multicast addresses are treated over LAN technologies. The following list identifies SMDS specific subscription time configuration parameters. These values will vary across LISs. + SMDS Hardware Address (smds$ha). The 60 bit SMDS Individual address of the SMDS Network Interface (SNI) to which the host is attached, as determined at subscription time. Each host must be configured to accept datagrams destined for this address. + SMDS IP Group Address(smds$ip_ga). The 60 bit SMDS Group address that has been configured at subscription time to identify the SNIs of all members of the LIS which are directly connected to an SMDS. All members of the LIS must be configured to accept datagrams addressed to the smds$ip_ga. + SMDS Arp Request Address (smds$arp_req). The 60 bit SMDS address (individual or group) to which arp requests are to be sent. In the initial LIS configuration this value is set to smds$ip_ga. + SMDS Address Screening Tables (Source and Destination). The use of SMDS screening tables is not necessary for the operation of IP over SMDS. If the SMDS screening tables are to be used, both source and destination tables for each SNI must, at minimum, be configured to allow for the direct communication between all hosts in the same LIS. Piscitello, Lawrence June 1990 Internet-draft IP and ARP over SMDS June 1990 Packet Format IP datagrams and ARP requests and replies sent over SMDS 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]. IEEE 802.2 LLC Type 1 Unnumbered Information (UI) communication (which must be implemented by all conforming IEEE 802.2 stations) is used exclusively. 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 (Internet decimal 170)[10]. The 24-bit 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) (see Figure 2). ...--------+--------+--------+--------+ SMDS Level 3 Protocol Header | SMDS Level 3 ...--------+--------+--------+--------+ +--------+--------+--------+ |DSAP=K1 |SSAP=K1 |Control | IEEE 802.2 LLC +--------+--------+--------+ +--------+--------+---------+--------+--------+ |Protocol Id/ Org Code = K2 | EtherType | IEEE 802.1A SNAP +--------+--------+---------+--------+--------+ Figure 2. Data Link Encapsulation + The total length of the LLC Header and the SNAP header is 8 octets. + The value of K1 in the LLC header is Internet decimal 170. + The value of K2 in the SNAP header is 0 (zero). + The control value in the LLC header is 3 (Unnumbered Information). + The EtherType for IP is Internet decimal 2048. The EtherType for ARP is Internet decimal 2054. Address Resolution The mapping of 32-bit Internet addresses to 60-bit SMDS addresses shall be done via the dynamic discovery procedure of the Address Resolution Protocol (ARP)[2]. Internet addresses are assigned arbitrarily on Internet networks. SMDS addresses are assigned by a carrier network administrator. Each host's implementation must know its own Internet address and respond to Address Resolution requests appropriately. Hosts must also use ARP to translate Internet addresses to SMDS addresses when needed. Piscitello, Lawrence June 1990 Internet-draft IP and ARP over SMDS June 1990 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 for SMDS is 2 + The protocol type code for IP is Internet decimal 2048 [11]. + The hardware address length is 8. SMDS addresses are 60 bits plus an address type (group/individual) nibble. + The protocol address length (for IP) is 4. + The operation code is 1 for request and 2 for reply. For the sake of conformity, the hardware addresses in ARP packets (ar$sha, ar$tha) must be carried in "canonical" bit order, with the most significant bit (msb) of the Address Type sub-field3 of an SMDS address positioned as the low order bit of the first octet. As SMDS addresses are normally expressed with the msb of the Address Type field as the high order bit of the first octet, the addresses must be bit-reversed within each octet. Although outside the scope of this document, it is recommended that MAC addresses be represented in canonical order in all Network Layer protocols carried within the information field of an SIP L3_PDU. Traditionally, an ARP request is broadcast to all directly connected stations. For SMDS, 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$ip_ga, (the SMDS group address that identifies all members of the LIS)4. __________ 2. This number shall be unique (i.e., this number shall not be the 1 or 6 for Ethernet or IEEE 802.6 networks) and needs to be defined in Assigned Numbers. 3. The Address Type subfield occupies the 4 most significant bits of the destination and source address fields of the SIP L3_PDU. The Address Type contains the value 1100 when using an individual address and the value 1110 for a 60-bit group address. 4. It is conceivable that in a larger scale, public configuration, the smds$arp-req address might be set to that of some sort of ARP-server instead of broadcasting the Piscitello, Lawrence June 1990 Internet-draft IP and ARP over SMDS June 1990 IP Broadcast Address There is no facility for complete broadcast addressing over SMDS. As discussed in the "LIS Configuration" section, a 60-bit SMDS group address (smds$ip_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$ip_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 two 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$ip_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 SMDS. _________________________________________________________________ request to the entire network. Piscitello, Lawrence June 1990 Internet-draft IP and ARP over SMDS June 1990 Byte Order As described in Appendix B of the Internet Protocol specification[1], the IP datagram is transmitted over SMDS as a series of 8-bit bytes. This byte transmission order has been called "big-endian"[14]. MAC Sublayer Details Packet Size. SMDS 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. However, in order to allow future extensions to the SIP L3_PDU header, it is desirable to reserve additional space for (MAC) overhead. Therefore, the MTU for IP stations operating over SMDS networks shall be 8960 octets. This can provide for 8192 octets of data and 768 octets of header at the network layer and above5. Router implementations must be prepared to accept full-length packets and fragment them when necessary. Host implementations should be prepared to accept full-length packets; however, hosts must not send datagrams longer than 576 octets unless they have explicit knowledge that the destination is prepared to accept them. A host may communicate its size preference in TCP-based applications via the TCP Maximum Segment Size option[15]. Datagrams transferred over SMDS may be longer than the general Internet default maximum packet size of 576 octets. Hosts connected to SMDS should keep this in mind when sending datagrams to hosts that are not on the same SMDS LIS. It may be appropriate to send smaller datagrams to avoid unnecessary fragmentation at intermediate routers. Please see [15] for further information. There is no minimum packet size restriction defined for SMDS. __________ 5. These numbers where chosen somewhat arbitrarily. 8192 is, of course, 8 Kbytes. The header overhead is 3x256 octets. Piscitello, Lawrence June 1990 Internet-draft IP and ARP over SMDS June 1990 Other MAC Sublayer Issues SMDS requires that the 60-bit address format be used in both source and destination address fields of the SIP L3_PDU. 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 RFC 1042[4] and RFC 1103[5] describe the minimum functionality necessary for a conformant station. Implementors should also consult IEEE Std. 802.2 for details. Piscitello, Lawrence June 1990 Internet-draft IP and ARP over SMDS June 1990 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. "Metropolitan Area Network Generic Framework Systems Requirements in support of Switched Multi-megabit Data Service", Technical Advisory TA-TSY-000772, Bell Communications Research, Inc., Issue 3, October, 1989. 4. Postel, J., and Reynolds, J., "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", Merit/NSFNET. 6. F. R. Dix, M. Kelly, and R. W. 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 P802.6/D9, Proposed Standard Distributed Queue Dual Bus (DQDB) Metropolitan Area Network (MAN), August, 1989. 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.K., and J. Postel, "Assigned Numbers", RFC-1010, USC/Information Sciences Institute, May 1987. 12. Braden, R., and J. Postel, "Requirements for Internet Gateways", RFC-1009, USC/Information Sciences Institute, June 1987. Piscitello, Lawrence June 1990 Internet-draft IP and ARP over SMDS June 1990 13. Deering, S., "Host Extensions for IP Multicasting", RFC-1112, Stanford University, August, 1989. 14. Cohen, D., "On Holy Wars and a Plea for Peace", Computer, IEEE, October 1981. 15. Postel, J., "The TCP Maximum Segment Size Option and Related Topics", RFC-879, USC/Information Sciences Institute, November 1983. Piscitello, Lawrence June 1990