Internet DRAFT - draft-ietf-smds-ipdatagram
draft-ietf-smds-ipdatagram
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 <tbd>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
