Switched Multimegabit Data Service (SMDS) is a telecommunications service that provides connectionless, high- performance, packet-switched data transport. It is neither a PROTOCOL nor a TECHNOLOGY. Rather, it supports standard protocols and communications interfaces using current (and future) technology.
SMDS allows users to transparently extend their data communications capabilities over a wider geographical area. Since it is a SERVICE offered by the telephone companies, SMDS permits this expansion using existing Customer Premises Equipment (CPE) and protocols, with minimal investment in dedicated leased lines as the number of line terminations increases.
SMDS has been defined by the IEEE 802.6 Metropolitan Area Network (MAN) standard, as implemented by Bellcore. It can use a variety of technologies, including Broadband ISDN (B-ISDN) and Distributed Queue Dual Bus (DQDB). Current North American implementations utilize DQDB with DS1 (1.5 Mbps) or DS3 (45 Mbps) lines. Other implementations utilize E1 lines at speeds in excess of 1.9 Mbps or E3 lines. Future SMDS networks will couple B-ISDN with SONET OC3 at 155 Mbps.
The development of this service has paralleled the emerging Asynchronous Transfer Mode (ATM) standards. Like ATM, SMDS uses CELL RELAY TRANSPORT. Both services use 53-octet cells for transport and can accommodate packet lengths of 9188 octets (However, the maximum length for SMDS is 9188 octets and the maximum length for ATM is 65535 octets.) Because of this, SMDS is considered to be an intermediate between the packet-switched services offered today and the ATM service of the future.
The SMDS service allows you to create a connectionless network between CPE [single unit, chained units, and/or Local Area Networks (LANs)] at various sites nationwide. The physical SMDS service path consists of three parts:
The dedicated access line is either a DS1 line operating at 1.5 Mbps, DS3 line operating at 45 Mbps, or appropriate E1 or E3 line. The public SMDS network consists of the local and interexchange carriers, their switching stations, and network connections.
LOCAL EXCHANGE CARRIER
.----------------------. |
| | V
| .-----. .--------. | .---------------.
| | CPE |---| ROUTER | | | .----. |
| `--/--' `---|----' |+-- SNI | +---| SS | |
| || DXI--->| || | | `-|--' |
| .--\--. .----|----. |V | .--|-. | |
| | CPE | | DSU/CSU |=|===================|=| SS | | |
| `-----' `---------' | DEDICATED ACCESS | `----' | |
`----------------------' LINE `----------|----'
CUSTOMER PREMISES |
.----------|----.
| .-|--. |
| | SS | |
INTEREXCHANGE CARRIER --> | `-|--' |
SNI = Subscriber Network Interface SS = Switching System
Three protocols tie these three physical elements together:
The SIP protocol is also defined in IEEE 806.2. This protocol is a specific implementation of the MAN Access protocol designed for SMDS. It functions at the physical and data link layers.
The DXI protocol is a bit-oriented protocol (BOP) implementation designed by the SMDS Interest Group (SIG) as a standard communications protocol at the physical and link layers between the router and DSU/CSU. It is supported by all major SMDS equipment vendors.
The MAN Access protocol and SIP have a layered architecture, that while not EXACTLY like the 7-layer architecture described by the Open Systems Interconnect model, does parallel the layers.
These protocols operate in the chained layers of the OSI model, Layers 1, 2, and 3: the physical layer, data link layer, and packet layer, respectively. Most of the SMDS functionality is at the link level, Layer 2 of the OSI model. This layer can be broken functionally into two sublayers:
.-------------. .-------. .-------.
| APPLICATION | | | <--- CPE using standard | |
+-------------+ | | LAN protocol stack | |
| PRESENTATION| | | | |
+-------------+ | | | |
| SESSION | | | CPE designed for the | |
+-------------+ | | SMDS protocol ------> | |
| TRANSPORT | | | | |
+-------------+ +-------+ +--------------+ +-------+
| NETWORK | | IP | | IP | | IP |
+-------------+ +-------+ +--------------+ +-------+
| DATA | | LLC | | LLC | | LLC |
| | +-------+ +-------+------+ .-----. +-------+
| | | MAC |<>| MAC | | | | | |
+-------------+ +-------+ +-------+ SIP |<>| SIP |<>| SIP |
| PHYSICAL | | PHY |<>| PHY | | | | | |
`-------------' `-------' `-------'------' `-----' `-------'
OSI MODEL CPE ROUTER NETWORK CPE
The current SMDS implementation makes use of DQDB features to transport the 53-octet cells throughout the network. DQDB provides the SMDS network with many advantages:
DQDB provides the interface between the MAC and the actual transmission facilities. Only the physical layer is aware of the transmission system in use. A different Physical Layer Convergence Protocol (PLCP) is implemented for each type of transmission system to ensure a consistent set of services between the DQDB Layer and the Physical Layer.
The two most-common implementations of DQDB are Open Dual Bus and Looped Dual Bus. Open Dual Bus is a less-expensive topology than Looped Dual Bus. However, the Looped Dual Bus topology provides fault tolerance: a cable break in this topology results in an Open Dual Bus topology, providing a seamless fault recovery with uninterrupted service for the customer.
The two DQDB buses are not interconnected in either topology. Each node on the each bus knows its position in the queue for that particular bus, with the first node acting as Head of Bus. The Head of Bus node can only write to that bus; the End of Bus node can only read from that bus. All other nodes may both read from and write to either bus.
HEAD OF BUS A END OF BUS A
| |
.---.v .---. .---. v.---.
| ||=======| |==============| |======>| |
| N | | N | | N | | N |
| O | | O | | O | | O |
| D | | D | | D | | D |
| E | | E | | E | | E |
| |<=======| |==============| |======|| |
`---'^ `---' `---' ^`---'
| |
END OF BUS B HEAD OF BUS B
END OF BUS A | | HEAD OF BUS A
v.---.v .---.
+======>| ||=========================| |=======+
H | N | | N | H
H | O | | O | H
H | D || END OF BUS B | D | H
H | E |v | E | H
H +==|| |<=========================| |===+ H
H H ^`---' `---' H H
H H | HEAD OF BUS B H H
H H .---. .---. H H
H +===| |==========================| |===+ H
H | N | | N | H
H | O | | O | H
H | D | | D | H
H | E | | E | H
+=======| |==========================| |=======+
`---' `---'
.---. .---.
+=======| |==========================| |=======+
H | N | | N | H
H | O | | O | H
H | D | | D | H
H | E | | E | H
H +===| |==========================| |===+ H
H H `---' `---' H H
H H | END OF BUS B HEAD OF BUS B | H H
H H v.---. .---.v H H
H +==>| |===/ /=======| ||==+ H
H | N | / / | N | H
H | O | / broken cable / | O | H
H | D | / / | D | H
H | E | / / | E | H
+======|| |===/ /=======| |<======+
^`---' `---'^
HEAD OF BUS A | / END OF BUS A
Using the dual buses, a switching station creates transmission slots (each 53 octets) and maintains a count of available slots. Each SMDS cell created contains 44 octets of data and 9 octets of DQDB and SIP management overhead. This overhead includes:
The nodes on the SMDS network access this overhead material for each data cell that received on either bus. If the cell is empty (and the node is not first in the queue to transmit), the cell is either passed through the node unchanged or used to send a waiting cell to a node beyond it on the bus.
If the cell is busy, the node checks further to ascertain whether the contents of that cell are addressed to it. Cells not addressed to the node are passed through untouched. If the cell is addressed to the node, the cell contents are dumped to the node and the cell overhead information is changed to indicate that the cell is empty.
All incoming cells are empty when the node is the Head of Bus. Cells received by the End of Bus, if not intended for that node, are discarded WHETHER FULL OR NOT.
Each node sends a Request to Transmit when it has a data cell ready for transmission. The node then waits until it is at the head of the queue and then transmits its data.
The node then decrements a counter once for every empty cell that passes on the bus, until it has become first in the queue. It then appropriates the next empty cell arriving on the bus and dumps its data. In this manner, all nodes on the bus have equal priority and equal access time to the bus.
It is possible, however, to send both delay-sensitive and delay- insensitive material on the same bus. The SMDS cell overhead allows three levels of request urgency and queue assignments may be allocated according to the type of request submitted.
Since each node has access to both buses, it is possible to send data to nodes in either direction. This assures that each node has access to every other node on the SMDS system regardless of the sending nodes position on the bus.
These cells are then packaged into an appropriate Physical Layer Convergence Protocol (PLCP) frame and sent out over the line.
The DQDB slot is created by the network switch and passed to the node functioning as Head of Bus. This slot consists of 1 octet of network overhead (access control) and a 52-octet payload segment.
This is diagrammed as follows:
[Number of octets] (Number of Bits)
[1] [52]
.---------------+--------------------------------------------.
| ACCESS CONTROL| SEGMENT |
`---------------+--------------------------------------------'
| \ ______
| \ _____
| \ ______
| \ _______
| \
| (1) (1) (1) (2) (1) (1) (1) |
.------+---------+-----+------+-------+-------+-------.
| BUSY | SL_TYPE | PSR | RESV | REQ_2 | REQ_1 | REQ_0 |
`------+---------+-----+------+-------+-------+-------'
SL_TYPE = slot type PSR = Previous slot instructions
RESV = reserved REQ = Request
The SEGMENT of this slot, when full, contains a DQDB MAC SERVICE PROTOCOL DATA UNIT consisting of a 2-octet DMPDU Header, a 44- octet Segmentation Unit, and a 2-octet DMPDU Trailer.
.----------+---------+------------.
| SEG TYPE | SEQ NO. | MESSAGE ID |
`----------+---------+------------'
| (2) (4) (10) |
| ___________________ /
| / [2]
.--------+------------------------------------------+--------.
| HEADER | SEGMENTATION UNIT TRAILER |
`--------+------------------------------------------+--------'
[2] [44] ____________ / |
/ (6) (10)
.------------+-----------.
| PAY LENGTH | PAY CRC |
`------------+-----------'
The SEGMENTATION UNIT is a 44-octet piece of the Initial MAC PDU. This IMPDU is generated by the router, which adds management overhead to the MAC Service Data Unit generated by the CPE. An IMPDU may range in size from 28 octets to a maximum of 9248 octets. The DSU/CSU is responsible for splitting the IMPDU into 44-octet segments.
.--------+---------+-----------------+-----+-------+---------. | HEADER | HDR EXT | MAC SDU | PAD | CRC32 | TRAILER | `--------+---------+-----------------+-----+-------+---------'
The SMDS Interface Protocol (SIP) is an implementation of DQDB that is based on connectionless service to the MAC and the queued arbitrated portion of DQDB. It utilizes four optional features of DQDB in addition:
The protocol data units for SIP, although designated with a different nomenclature, contain similar elements that perform similar functions:
The SIP L3_PDU is generated by the router by incorporating management control information before and after the SDU generated by the CPE.
.--------+-------------------+-----+--------+---------.
| HEADER | INFORMATION (SDU) | PAD | CRC32* | TRAILER |
`--------+-------------------+-----+--------+---------'
[36] [0-9188] [0-3] [0 or 4] [4]
* Note that the Cyclical Redundancy Check (CRC32) is optional
with the L3_PDU. If it is present, it is 4 octets in length.
However, present or not, the CRC32 bits for the L3_PDU are
ignored by the SMDS network.
The L3_PDU header contains information used in verifying the PDU integrity as well as addressing information. The header format is as follows:
[Number of octets] (Number of bits)
.-----+------+-------+---+---+-----+---+----+----+----+---+---.
| RSVD| BETag| BASize| DA| SA| HLPI| PL| QOS| CIB| HEL| BR| HE|
| | | | | | * | | * | | | * | |
`-----+------+-------+---+---+-----+---+----+----+----+---+---'
[1] [1] [2] [8] [8] (6) (2) (4) (1) (2) [2] [12]
RSVD = reserved QOS = Quality of Service
BETag = beginning-end tag CIB = CRC32 Indication Bit
BASize = buffer allocation size HEL = Header Extension Length
DA = Destination Address BR = Bridging
SA = Source Address HE = Header Extension
HLPI = Higher-Layer Protocol ID * indicates bits ignored by
PL = PAD length SMDS network
The BASize octets indicate the length of the L3_PDU. The CIB indicates the presence or absence of the 32-bit CRC in the PDU.
The Header Extension is also present in the SIP L3_PDU and is always 12 octets in length. This extension is a mechanism to include optional SMDS-specific information in the data unit. It must contain the SIP version in use and may contain 0-3 Interexchange Carriers of choice.
The Destination and Source Addresses are each 8 octets in length. For each address, the 64 bits include a 4-bit Address Type and a 60-bit Address based on the E.163 or E.164 address plan. In current implementations, you may include by INDIVIDUAL and GROUP addresses of up to 15 digits.
The INTERVIEW SMDS Application programs currently support only the North American addressing, a "1" followed by 10 digits and the sequence: "F", "F", "F", "F".
The 4-octet L3_PDU Trailer has the following format:
.------+-------+--------.
| RSVD | BETag | LENGTH |
`------+-------+--------'
RSVD = reserved
BETag = beginning-end tag
The BETag in the header is used to indicate the beginning of the L3_PDU; in the trailer, the BETag indicates the end of the specific L3_PDU.
The LENGTH is compared with the BASize octets in the header when the L3_PDU transmission is complete. This functions as the node's first quality check, quickly determining if the entire L3_PDU has been received, i.e., whether to assemble the L3_PDU or to discard the cells' contents.
The SIP L2_PDU has the same basic format as the DMPDU of DQDB:
The Header contains the Access Control information (1 octet), the Network Control information (4 octets), the Segment Type, the Sequence Number, and the Message Identifier.
The Trailer contains the Payload Length (6 bits) and the Payload Cyclical Redundancy Check (10 bits).
[Number of Octets] (Number of Bits)
[1] [4] (2) (4) (10)
.------------+-------------+----------+---------+-----.
| ACCESS CON | NETWORK CON | SEG TYPE | SEQ NO. | MID |
`------------+-------------+----------+---------+-----'
| ___________________ /
| __________________ /
| /
.--------+-------------------------------+---------.
| HEADER | SEGMENTATION UNIT | TRAILER |
`--------+-------------------------------+---------'
[7] [44] | [2] \ _______
| \
| (6) (10) \
.-----------+--------.
| PAY LNGTH | PAY CRC|
`-----------+--------'
The ACCESS CONTROL and NETWORK CONTROL INFORMATION portions of the Header contain information analogous to the Access Control portion of the DQDB slot and the DQDB Payload Header, respectively. This includes:
(Number of bits) **** These 4 bits are ignored
by the SMDS network. They
(1) (4) (1) (1) (1) are the SL_TYPE, PSR,
.------+------+-------+-------+-------. and RESV bits of the
| BUSY | **** | REQ_2 | REQ_1 | REQ_0 | DQDB slot Access
`------+------+-------+-------+-------' Header byte.
| _________ /
| _________ /
| /
.------------+-------------+----------+---------+-----.
| ACCESS CON | NETWORK CON | SEG TYPE | SEQ NO. | MID |
`------------+-------------+----------+---------+-----'
| \_________
| \
| (20) (2) (2) (8) |
.-----+----------+-----+-----.
| VCI | PAY TYPE | PRI | HCS |
`-----+----------+-----+-----'
The segment type is used by SMDS to indicate whether the Segmentation Unit (SU) in a given cell is the beginning of the message (BOM), a continuation of a message (COM), the end of the message (EOM), or a single segment (an entire frame within one cell).
The BOM always contains ALL of the header information from the L3_PDU and performs a "Call Setup" function. This cell also contains the Message Identifier (MID) used to alert a node that subsequent cells are part of a message intended for it.
All COM cells are essentially the same: a portion of the SU encapsulated in the L2_PDU. Each COM carries the same MID contained in the BOM and a Sequence Number that increments from 0 to 15, in a rotating fashion, to indicate position within the message
The EOM contains the last portion of the SU, PAD, CRC32, and Trailer of the L3_PDU. This information is used to verify that the full message has been received by the node. If any of the message's cells are missing or corrupt, all cells with that MID are discarded by the node.
The L2_PDUs are formatted into a PLCP frame for transmission over the DS1 or E1 lines. (The INTERVIEW currently does not support SMDS on DS3 or E3 lines.)
The PLCP frame format consists of 10 "rows" each 57 octets in length. For DS1, the last row also contains a 6-octet trailer.
NOTE: For the PLCP frame, the MOST-SIGNIFICANT BIT is transmitted over the line first. This is contrary to most other protocols monitored by the INTERVIEW (including the raw data display during bit-image data playback via sync with Display Idle: ON) and is not the way data is normally stored in the unit. The received process reverses the bit order of the data as it is received, so that the first bit of each octet is stored as the most-significant bit in memory.
The DS1 frame has a duration of 3 milliseconds. It is transmitted at a rate of 1.536 Mbps. The E1 frame is similar in size.
The format of the PLCP frame for DS1 is shown on the next two pages. The first 2 octets of each row function as sync bytes.
[1] [1] [1] [1] [53 octets] .----+----+----+----+-------------------------------. | A1 | A2 | P9 | Z4 | L2_PDU | +----+----+----+----+-------------------------------+ | A1 | A2 | P8 | Z3 | L2_PDU | +----+----+----+----+-------------------------------+ | A1 | A2 | P7 | Z2 | L2_PDU | +----+----+----+----+-------------------------------+ | A1 | A2 | P6 | Z1 | L2_PDU | +----+----+----+----+-------------------------------+ | A1 | A2 | P5 | F1 | L2_PDU | +----+----+----+----+-------------------------------+ | A1 | A2 | P4 | B1 | L2_PDU | +----+----+----+----+-------------------------------+ | A1 | A2 | P3 | G1 | L2_PDU | +----+----+----+----+-------------------------------+ | A1 | A2 | P2 | M2 | L2_PDU | +----+----+----+----+-------------------------------+ | A1 | A2 | P1 | M1 | L2_PDU | +----+----+----+----+-------------------------------+---------. | A1 | A2 | P0 | C1 | L2_PDU | TRAILER | `----+----+----+----+-------------------------------+---------' Key: A1 = 11110110 (fixed) A2 = 00101000 (fixed) Px = Path Overhead Identifier Zx = Growth octets F1 = PLCP Path User Channel B1 = Bit-Interleaved Parity 8 G1 = PLCP Path Status (BIP-8) C1 = Cycle/Stuff Counter Mx = SIP Layer 1 Control Info
The SIP Destination and Source Addresses for the United States are 10-digit numbers preceded by a "1" and followed by four Binary-Coded Decimal (BCD) "F"s. International addresses include the appropriate country code, telephone number, and node designation, not exceeding 15 BCD digits (not supported by the INTERVIEW SMDS Application programs at this time). Two types of addresses are used:
Each group address is used to identify a group of up to 128 individual addresses. The Switching System is able to support up to 1024 group addresses.
A given individual address is able to participate in a maximum of 32 group addresses. Each SNI is able to be a part of up to 48 group addresses.
In addition to indicating the source node and the destination node, the SIP address functions as part of the security system of the SMDS network. As the BOM of each SMDS packet is received, the Source Address is verified to ensure that the sender is not inserting another subscriber's address. The SS will verify that the Source Address is:
Both Source and Destination Addresses are also used in the ADDRESS SCREENS that may be maintained by the SS. Address screens may be used to create Closed User Groups (CUGs) within the SMDS network. This allows for the creation of virtual private networks within the context of the public-access SMDS network. Up to 128 address screens may be maintained by the SS for any SNI on the network.
An INDIVIDUAL ADDRESS SCREEN consists of a set of "allowed" or "disallowed" addresses used to screen the destination packets sent by a specific node and the source addresses of received packets for that node. This type of screen may be used to prevent unauthorized traffic from reaching a "sensitive" node and also to prevent unauthorized use of CPE.
A GROUP ADDRESS SCREEN is used to screen the destination addresses of packets sent by the CPE at a node. This type of screen is usually used for a CUG. SMDS NETWORK MANAGEMENT
The current implementation of SMDS in North America has Customer Network Management (CNM) capabilities. This implementation allows the CUSTOMER to maintain control over the network functions, including:
The CNM implementation currently in place for SMDS is the Simple Network Management Protocol (SNMP). This is a LAN network management supported by many vendors and used on many non-TCP/IP networks.