rfc1209.txt
来自「RFC 的详细文档!」· 文本 代码 · 共 619 行 · 第 1/2 页
TXT
619 行
Network Working Group D. Piscitello
Request for Comments: 1209 J. Lawrence
Bell Communications Research
March 1991
The Transmission of IP Datagrams over the SMDS Service
Status of this Memo
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.
Abstract
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.
Acknowledgment
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.
Conventions
The following language conventions are used in the items of
specification in this document:
o MUST, SHALL, or MANDATORY -- the item is an absolute
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 followed
for all but exceptional circumstances.
o MAY or OPTIONAL -- the item is truly optional and may be
followed or ignored according to the needs of the implementor.
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 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:
o The SMDS Service provides a datagram packet transfer, where each
data unit is handled and switched separately without the prior
establishment of a network connection.
o The SMDS Service 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.
o 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.
o Both individually and group-addressed (multicast) packets can
be transferred.
o 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, or closed user group, over the SMDS Service. The
access control provided by the closed user group mechanism is
supplied by the SMDS provider according to the specifications
stated in [3].
o SMDS addresses are 60 bits plus a 4 bit Address Type. The
Address Type subfield occupies the 4 most significant bits of
the destination and source address fields of the SIP Level 3
Protocol Data Unit (PDU). It contains the value 1100 to
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-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.
Logical IP Subnetwork Configuration
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
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 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:
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 configured
that identifies all members of the LIS. Any packet transmitted
with this address is delivered by SMDS Service to all members
of the LIS.
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.
o SMDS Hardware Address (smds$ha). 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.
o SMDS LIS Group Address(smds$lis-ga). The SMDS Group address
that has been 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.
o SMDS Arp Request Address (smds$arp-req). The SMDS address
(individual or group) to which arp requests are to be sent. In
the initial LIS configuration this value is set to smds$lis-ga.
It is conceivable that in other configurations this value would
be set to some address other than that of smds$lis-ga (see
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 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.
o 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.
o SMDS Address Screening Tables (Source and Destination). The use
of SMDS screening tables is not necessary for the operation of
IP over SMDS Service. If the SMDS screening tables are to be
used, both source and destination tables for each SNI MUST be
configured to allow, at minimum, both the direct communication
between all hosts in the same LIS and the use of the SMDS LIS
Group Address.
Packet Format
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 over SMDS Working Group [Page 5]
RFC 1209 IP and ARP over the SMDS Service March 1991
+-------+
|IP/ARP | IP/ARP
+----+----+----+----+----+-------+
| Org Code |Ethertype| | SNAP
+----+----+----+----+----+----+----+----+-------+
|DSAP|SSAP|Ctrl| | LLC
+-----+----+-+-+----+----+----+----+----+----+----+----+-------+
|SIP..|HLPI|...| | SIP L3
+-----+----+-+-+----+----+----+----+----+----+----+----+-------+
Figure 2. Data Link Encapsulation
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 Type
One Unnumbered Information).
o The Org Code in the SNAP header is zero (000000 Internet
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?