As per Relevance of the word configured, we have this rfc below:
Network Working Group D.
Request for Comments: 1209 J.
Bell Communications
March 1991
The Transmission of IP Datagrams over the SMDS
Status of this
This memo defines a protocol for the transmission of IP and
packets over a Switched Multi-megabit Data Service Network
as a logical IP subnetwork. This RFC specifies an IAB
track protocol for the Internet community, and requests
and suggestions for improvements. Please refer to the
edition of the "IAB Official Protocol Standards" for
standardization state and status of this protocol. Distribution
this memo is unlimited
This memo describes an initial use of IP and ARP in an SMDS
environment configured as a logical IP subnetwork, LIS (
below). The encapsulation method used is described, as well
various service-specific issues. This memo does not
subsequent treatment of the SMDS Service in configurations other
LIS; specifically, public or inter-company, inter-
configurations may be treated differently and will be described
future documents. This document considers only directly connected
end-stations or routers; issues raised by MAC level bridging
beyond the scope of this paper
This memo draws heavily in both concept and text from [4], written
Jon Postel and Joyce K. Reynolds of ISI and [5], written by
Katz of Merit, Inc. The authors would also like to acknowledge
contributions of the IP Over SMDS Service working group of
Internet Engineering Task Force
The following language conventions are used in the items
specification in this document
o MUST, SHALL, or MANDATORY -- the item is an
requirement of the specification
IP over SMDS Working Group [Page 1]
RFC 1209 IP and ARP over the SMDS Service March 1991
o SHOULD or RECOMMENDED -- the item should generally be
for all but exceptional circumstances
o MAY or OPTIONAL -- the item is truly optional and may
followed or ignored according to the needs of the implementor
The goal of this specification is to allow compatible
interoperable implementations for transmitting IP datagrams and
requests and replies
The characteristics of the SMDS Service and the SMDS
Protocol (SIP) are presented in [3], [6], and in [7]. Briefly,
SMDS Service is a connectionless, public, packet-switched
service. The operation and features of the SMDS Service are
to those found in high-speed data networks such as LANs
o The SMDS Service provides a datagram packet transfer, where
data unit is handled and switched separately without the
establishment of a network connection
o The SMDS Service exhibits high throughput and low delay,
provides the transparent transport and delivery of up to 9188
octets of user information in a single transmission
o No explicit flow control mechanisms are provided; instead,
rate of information transfer on the access paths is
both in the subscriber-to-network direction and in the network
to-subscriber direction through the use of an access
enforcement mechanism
o Both individually and group-addressed (multicast) packets
be transferred
o In addition to these LAN-like features, a set of addressing
related service features (source address validation, source
destination address screening) are provided to enable
subscriber or set of subscribers to create a logical
network, or closed user group, over the SMDS Service.
access control provided by the closed user group mechanism
supplied by the SMDS provider according to the
stated in [3].
o SMDS addresses are 60 bits plus a 4 bit Address Type.
Address Type subfield occupies the 4 most significant bits
the destination and source address fields of the SIP Level 3
Protocol Data Unit (PDU). It contains the value 1100
IP over SMDS Working Group [Page 2]
RFC 1209 IP and ARP over the SMDS Service March 1991
indicate an individual address and the value 1110 for a 60-
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.
remainder of the Data Link Service is provided by the IEEE 802.2
Logical Link Control (LLC) service [9]. The resulting stack
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
This memo describes an initial use of IP and ARP in an SMDS
environment configured as a logical IP subnetwork (described below).
It does not preclude subsequent treatment of SMDS Service
configurations other than logical IP subnetworks; specifically
public or inter-company, inter-enterprise configurations may
treated differently and will be described in future documents.
document does not address issues related to transparent data
layer interoperability
Logical IP Subnetwork
This section describes the scenario for an SMDS Service that
configured with multiple logical IP subnetworks, LIS (
below). The scenario considers only directly connected IP end
stations or routers; issues raised by MAC level bridging are
the scope of this paper
In the LIS scenario, each separate administrative entity
its hosts within a closed logical IP subnetwork. Each LIS
and communicates independently of other LISs over the same
providing SMDS. Hosts connected to SMDS communicate directly
other hosts within the same LIS. Communication to hosts outside
an individual LIS is provided via an IP router. This router
simply be a station attached to the SMDS Service that has
configured to be a member of both logical IP subnetworks.
configuration results in a number of disjoint LISs operating over
IP over SMDS Working Group [Page 3]
RFC 1209 IP and ARP over the SMDS Service March 1991
same network supporting the SMDS Service. It is recognized that
this configuration, hosts of differing IP networks would
via an intermediate router even though a direct path over the
Service may be possible
It is envisioned that the service will evolve to provide a
public interconnection, allowing machines directly connected to
SMDS Service to communicate without an intermediate router. However
the issues raised by such a large public interconnection, such
scalability of address resolution or propagation of routing updates
are beyond the scope of this paper. We anticipate that future
will address these issues
The following is a list of the requirements for a LIS configuration
o All members have the same IP network/subnet number
o All stations within a LIS are accessed directly over SMDS
o All stations outside of the LIS are accessed via a router
o For each LIS a single SMDS group address has been
that identifies all members of the LIS. Any packet
with this address is delivered by SMDS Service to all
of the LIS
The following list identifies a set of SMDS Service
parameters that MUST be implemented in each IP station which
connect to the SMDS Service. The parameter values will be
at SMDS subscription time and will be different for each LIS.
these parameters MUST be user configurable
o SMDS Hardware Address (smds$ha). The SMDS Individual
of the IP station as determined at subscription time.
host MUST be configured to accept datagrams destined for
address
o SMDS LIS Group Address(smds$lis-ga). The SMDS Group
that has been configured at subscription time to identify
SMDS Subscriber Network Interfaces (SNI) of all members of
LIS connected to the SMDS Service. All members of the LIS
be prepared to accept datagrams addressed to smds$lis-ga
o SMDS Arp Request Address (smds$arp-req). The SMDS
(individual or group) to which arp requests are to be sent.
the initial LIS configuration this value is set to smds$lis-ga
It is conceivable that in other configurations this value
be set to some address other than that of smds$lis-ga (
IP over SMDS Working Group [Page 4]
RFC 1209 IP and ARP over the SMDS Service March 1991
section on Address Resolution).
It is RECOMMENDED that routers providing LIS functionality over
SMDS service also support the ability to interconnect differing LISs
Routers that wish to provide interconnection of differing LISs
be able to support multiple sets of these parameters (one set
each connected LIS) and be able to associate each set of
with a specific IP network/subnet number. In addition, it
RECOMMENDED that a router be able to provide this multiple
support with a single physical SMDS interface that may have one
more individual SMDS addresses
The following list identifies LIS specific parameters that MUST
configured in the network supporting the SMDS Service. For each LIS
the IP network administrator MUST request the configuration of
parameters at subscription time. The administrator of each LIS
update these parameters as each new station is added to the LIS
o SMDS LIS Group Address(smds$lis-ga). An SMDS Group address
be configured at subscription time to identify the
Subscriber Network Interfaces (SNI) of all members of the
connected to the SMDS Service
o SMDS Address Screening Tables (Source and Destination). The
of SMDS screening tables is not necessary for the operation
IP over SMDS Service. If the SMDS screening tables are to
used, both source and destination tables for each SNI MUST
configured to allow, at minimum, both the direct
between all hosts in the same LIS and the use of the SMDS
Group Address
Packet
Service SHALL be encapsulated within the IEEE 802.2 LLC and
802.1A Sub-Network Access Protocol (SNAP) [10] Data Link
and the 3-level SIP. The SNAP MUST be used with
Organizationally Unique Identifier Code indicating that the
header contains the EtherType code as listed in Assigned
[11] (see Figure 2). Note that values specified in this
follow Internet conventions: multi-byte fields are described
big-endian order and bits within bytes are described as
significant first [11].
IP over SMDS Working Group [Page 5]
RFC 1209 IP and ARP over the SMDS Service March 1991
+-------+
|IP/ARP | IP/
+----+----+----+----+----+-------+
| Org Code |Ethertype| |
+----+----+----+----+----+----+----+----+-------+
|DSAP|SSAP|Ctrl| |
+-----+----+-+-+----+----+----+----+----+----+----+----+-------+
|SIP..|HLPI|...| | SIP L
+-----+----+-+-+----+----+----+----+----+----+----+----+-------+
Figure 2. Data Link
o The value of HLPI in the SIP L3 Header is 1.
o The total length of the LLC Header and the SNAP header is 8
octets
o The value of DSAP and SSAP in the LLC header is 170 (decimal),
AA (Internet hexadecimal).
o The Ctrl (Control) value in the LLC header is 3 (Indicates
One Unnumbered Information).
o The Org Code in the SNAP header is zero (000000
hexadecimal).
o The EtherType for IP is 2048 (decimal), 0800 (
hexadecimal). The EtherType for ARP is 2054 (decimal), 0806
(Internet hexadecimal).
IEEE 802.2 LLC Type One Unnumbered Information (UI)
(which must be implemented by all conforming IEEE 802.2 stations)
used exclusively. The Higher Layer Protocol Id (HLPI) field in
SIP L3_PDU header MUST be set to the IEEE 802.6 assigned Protocol
value for LLC (decimal 1) [8]. All frames MUST be transmitted
standard IEEE 802.2 LLC Type 1 Unnumbered Information format,
the DSAP and the SSAP fields of the IEEE 802.2 header set to
assigned global SAP value for SNAP (decimal 170) [10]. The 24-
Org Code (Organizationally Unique Identifier Code) in the SNAP
be set to a value of zero, and the remaining 16 bits are set to
EtherType value from Assigned Numbers [11] (2048 for IP, 2054
ARP).
The data link encapsulation for IP packets is shown in Figure 3
for ARP in Figure 4. All values shown are in Internet
format
IP over SMDS Working Group [Page 6]
RFC 1209 IP and ARP over the SMDS Service March 1991
+--------------+---------------------------------------+-------+
| 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
+--------------+---------------------------------------+-------+
| 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
Address
The dynamic mapping of 32-bit Internet addresses to SMDS
SHALL be done via the dynamic discovery procedure of the
Resolution Protocol (ARP) [2].
Internet addresses are assigned independent of SMDS addresses.
host implementation MUST know its own Internet address and
address and respond to Address Resolution requests appropriately
Hosts MUST also use ARP to map Internet addresses to SMDS
when needed
The ARP protocol has several fields that parameterize its use in
specific context [2]. These fields are
ar$hrd 16 - bits The Hardware Type
ar$pro 16 - bits The Protocol Type
ar$hln 8 - bits Octets in each hardware
ar$pln 8 - bits Octets in each protocol
ar$op 16 - bits Operation
o The hardware type code assigned to SMDS addresses is 14
(decimal), 0E (Internet hexadecimal) [11].
o The protocol type code for IP is 2048 (decimal), 0800
(Internet hexadecimal) [11].
IP over SMDS Working Group [Page 7]
RFC 1209 IP and ARP over the SMDS Service March 1991
o The hardware address length for SMDS is 8.
o The protocol address length for IP is 4.
o The operation code is 1 for request and 2 for reply
The SMDS hardware addresses in ARP packets (ar$sha, ar$tha) MUST
carried in SMDS native address format, with the most significant
of the Address Type sub-field as the high order bit of the
octet. Although outside the scope of this document, it
RECOMMENDED that SMDS addresses be represented in this format in
higher layer Internet protocols (e.g., SNMP).
Traditionally, ARP requests are broadcast to all directly
stations. For the SMDS Service, the ARP request packet
transmitted to the smds$arp-req hardware address. In the
configuration, the smds$arp-req address is set to smds$lis-ga, (
SMDS group address that identifies all members of the LIS). It
conceivable that in a larger scale, public configuration,
smds$arp-req address would be configured to the address of some ARP
server(s) instead of the group address that identifies the
LIS
IP Broadcast
There is no facility for complete hardware broadcast addressing
the SMDS Service. As discussed in the "LIS Configuration" section
an SMDS group address (smds$lis-ga) SHALL be configured to
all stations in the same LIS. The broadcast Internet address (
address on that network with a host part of all binary ones) MUST
mapped to smds$lis-ga (see also [12]).
IP Multicast
A method of supporting IP multicasting is specified in [13].
would be desirable to fully utilize the SMDS group
capabilities to support IP multicasting. However, the method in [13]
requires a Network Service Interface which provides multicast-
ability to provide dynamic access to the local network
interface operations
o JoinLocalGroup (group-address
o LeaveLocalGroup (group-address
The SMDS group address ability does not currently support
subscription and removal from group address lists. Therefore, it
RECOMMENDED that in the LIS configuration, if IP multicasting is
IP over SMDS Working Group [Page 8]
RFC 1209 IP and ARP over the SMDS Service March 1991
be supported, the method of IP multicasting described for
broadcast media, such as the Experimental Ethernet, be used.
this method, all Multicast IP addresses are mapped to the same
address which the broadcast Internet address is mapped for a
LIS. Thus all Multicast IP addresses are mapped to smds$lis-ga
Filtering of multicast packets MUST be performed in the
host
Trailer
Some versions of Unix 4.x BSD use a different encapsulation method
order to get better network performance with the VAX virtual
architecture. Trailers SHALL not be used over the SMDS Service
Byte
As described in Appendix B of the Internet Protocol
[1], the IP datagram is transmitted over the SMDS Service as a
of 8-bit bytes. The byte order of the IP datagram shall be
directly onto the native SMDS byte order
MAC Sublayer
Packet
The SMDS Service defines a maximum service data unit size of 9188
information octets. This leaves 9180 octets for user data after
LLC/SNAP header is taken into account. Therefore, the MTU for
stations operating over the network supporting the SMDS Service
be 9180 octets
There is no minimum packet size restriction defined for the
Service
Other MAC Sublayer
The SMDS Service requires that the publicly administered 60-
address plus 4-bit type field format SHALL be used in both source
destination address fields of the SIP L3_PDU [3].
IEEE 802.2
While not necessary for supporting IP and ARP, all
MUST support IEEE 802.2 standard Class I service in order to
compliant with IEEE 802.2. Some of the functions are not
directly to the support of the SNAP SAP (e.g., responding to XID
TEST commands directed to the null or global SAP addresses), but
part of a general LLC implementation. Both [4] and [5] describe
IP over SMDS Working Group [Page 9]
RFC 1209 IP and ARP over the SMDS Service March 1991
minimum functionality necessary for a conformant station
Implementors should also consult IEEE Std. 802.2 [14] for details
1. Postel, J., "Internet Protocol", RFC 791, USC/
Sciences Institute, September 1981.
2. Plummer, D., "An Ethernet Address Resolution Protocol - or -
Converting Network Protocol Addresses to 48.bit Ethernet
for Transmission on Ethernet Hardware", RFC 826, MIT,
1982.
3. "Generic Systems Requirements in support of Switched Multi
megabit Data Service", Technical Advisory TA-TSY-000772,
Technical Advisory, Issue 3, October 1989.
4. Postel, J., and J. Reynolds, "A Standard for the Transmission
IP Datagrams over IEEE 802 Networks", RFC 1042, USC/
Sciences Institute, February 1988.
5. Katz, D., "A Proposed Standard for the Transmission of
Datagrams over FDDI Networks", RFC 1188, Merit/NSFNET,
1990.
6. Dix, F., Kelly, M., and R. Klessig, "Access to a Public
Multi-Megabit Data Service Offering", ACM SIGCOMM CCR, July 1990.
7. Hemrick, C. and L. Lang, "Introduction to Switched Multi-
Data Service (SMDS), an Early Broadband Service",
pending in the Proceedings of the XIII International
Symposium (ISS 90), May 27, 1990 - June 1, 1990.
8. Institute of Electrical & Electronic Engineers, Inc.
Standard 802.6, "Distributed Queue Dual Bus (DQDB) Subnetwork
a Metropolitan Area Network (MAN) Standard", December 1990.
9. IEEE, "IEEE Standards for Local Area Networks: Logical
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.
IP over SMDS Working Group [Page 10]
RFC 1209 IP and ARP over the SMDS Service March 1991
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
8802/2", IEEE, New York, New York, 1985.
Security
Security issues are not discussed in this memo
Authors'
Dave
Bell Communications
331 Newman Springs
Red Bank, NJ 07701
Phone: (908) 758-2286
EMail: dave@sabre.bellcore.
Joseph
Bell Communications
331 Newman Springs
Red Bank, NJ 07701
Phone: (908) 758-4146
EMail: jcl@sabre.bellcore.
IP over SMDS Working Group [Page 11]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
