SMDS has had mixed popularity. It started to take off several years back, and then ATM got hot all of a sudden. SMDS faded from the limelight at that point, although at the time WAN ATM was unavailable or extremely costly. SMDS is a perfectly good carrier technology. I keep running into people doing SMDS -- partly because the Service Providers may have surplus capacity, already sunk the costs of delivering SMDS services, and may be offering it at bargain prices. You have to decide if the amount saved is worth the cost of the HSSI interfaces, if you don't already have them. There's perhaps the "it's not nifty new technology" factor as well. But if it saves you money, you may not care! And if you stick with this article to the end, you'll see that since SMDS supports IP multicast, configuring it for IP is downright easy.
Oh, by the way, any errors in this are mine -- I edited Alec's words and configuration samples, and added some of my own words.
Bellcore developed the specifications for SMDS due to the demand for wide-area networking with LAN-like characteristics. (Pete comment: And some of us think it was a way to experiment with pre-ATM ATM-like data transport, anticipating an ISDN-like 15 year rollout of ATM).
SMDS supports fiber or copper based media and operates over Digital Signal level 1 (DS-1) and Digital Signal level 3 (DS-3) facilities. The service provides large packet sizes (up to 9188 octets). This enables the encapsulation of IEEE 802.3, IEEE 802.4, IEEE 802.5, and FDDI frames. The service offers different access classes, address screening, and group addressing. The latter two allow organizations to create Virtual Private Networks/closed user groups. The technology is suitable for applications that are high-speed and require burst-traffic versus continuous data flowing at a high rate.
One connection method is via SMDSU. This is seen generally when the access class is DS-3. The other connection method, DXI, is normally seen when the access class is DS-1 or less. In this case, a standard DSU is used and the carrier switch will convert the format from DXI to SNI.
Subscriber Network Interface (SNI) provides the seamless/transparent connection
between the customer network and the carrier network. It is basically the
demarcation point between the customer premise equipment and the carrier
equipment (see the above figure).
SMDS Interface Protocol (SIP) runs over SNI. The SIP is based on the MAC
sub-layer. The SIP does not provide flow control or recovery mechanisms. SIP
operates over the physical connection between the CPE equipment and the carrier
equipment. SIP utilizes a subset of the IEEE 802.6 standard for Metropolitan
Area Networks, Distributed Queue Dual Bus (DQDB), as the method of communication
between CPE and carrier equipment (DQDB describes a method of accessing a
medium composed of two uni-directional buses) Each CPE is connected to both
buses and can read from and write to each bus. Where multiple CPE’s are involved,
data from each CPE is slotted into the overall bandwidth.
SMDS can be provided by a number of interface protocols: SIP-based, SIP over DXI-based (see above), ATM, and Frame Relay. For purposes of this article, we will mainly discuss SIP Based Access (over SNI).
Let's look at how SMDS works. It is TDM-based, with rigid time slots. Time is allocated on the network using fixed length time slots. The slot size is 53 octets: 5 octets for the header (routing and control information) and 48 octets for the information. Of the 48 octets 44 is used for user information. Within the header are a busy bit and a request bit used to control each stations access to the bandwidth.
The SIP is logically divided into three levels of operation.
The SIP level 3 operation is as follows: Information in the form of service data units are passed form the LLC layer to the MAC layer for processing. The MAC layer adds a header and a trailer to transform the service data units into SMDS protocol data units (PDUs). PDUs are then segmented to form a sequence of 53 octet cells before they are passed on to the physical layer for transmission onto the medium.
That’s right cells! at 53 octets in size (sound familiar?)This segmentation operation just described is SIP level 2.
SIP level 1 operates at the physical layer. The physical layer is divided into the Physical Layer Convergence Protocol (PLCP) and the transmission system sublayers. The Physical Layer Convergence Procedure (PLCP) is responsible for matching the data to the format used in the transmission system. The transmission system sublayer defines the characteristics and method of attachment to the media (DS-1, DS-3).
Note: When configuring an interface (on a Cisco router), only the first 11 digits are required. Therefore, it would be correct syntax to leave out all the FFFF's in the above addresses.
SMDS does provide some security. Source addresses from data units, sent from an SNI are validated to ensure that the source address is associated with the same SNI in which it was received. If the source address of the data unit does not match the address of the source SNI, the data unit will be discarded. In addition to the validation feature, customers can restrict access based upon source/destination addresses. This is called address screening. Address screening can be performed on destination or source addresses (including unicast and multicast addresses). Screening and source address validation ensure the integrity of the VPN or closed user group.
Cisco’s IOS expects an address in the E.164 format. Although this format is composed of 15 digits, IOS will accept the first 11.
We have consulted with our service provider to create a VPN/closed user group amongst the sites. That means that we have our individual addresses (unicast) for our sites as well as our group addresses (multicast). We are now ready to configure our routers. We will perform the following operations in interface configuration mode.
Checklist for interface configuration:
interface Hssi5/0In this instance, we set the encapsulation on the major interface. Note that we recorded the circuit ID in the description. It is a good idea to have this information available without having to look it up in notebooks or documents on a workstations. This is especially helpful when you have a lot of circuits.
description SMDS DS-3 36QFDD555111
no ip address
encapsulation smds
no ip route-cache optimum
bandwidth 34000
crc 32
!
interface Hssi5/0.1 point-to-point
description smds
ip address 172.16.31.1 255.255.255.0
ip ospf network broadcast
smds address c120.2202.6800
smds multicast ARP e170.3202.4329 172.16.31.0 255.255.255.0
smds multicast IP e170.3202.4329 172.16.31.0 255.255.255.0
smds enable-arp
The other two routers for this retail operation would have similar configurations. The IP addresses and SMDS addresses on the interfaces would of course be different. And that's it!
For routing, we might configure OSPF on our network, telling it the interface is a broadcast medium. EIGRP would be another obvious possibility.
(Note: for protocols other than IP, you have to statically map all peers, since there is no SMDS counterpart to ARP for matching layer 2 addresses to layer 3 addresses in the other network protocols).
Using the show commands we can get useful information for troubleshooting SMDS.
show interfaceUse the show smds addresses privileged EXEC command to display the individual addresses and the interface with which they are associated.
router#show int serial4/3.1
Serial4/3.1 is up, line protocol is up
Hardware is 4T/MC68360
Description: Circuit ID xxxxxxx Location XYZ
Internet address is 172.16.150.1/24
MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255
SMDS hardware address is E170.3204.1234.FFFF
Encapsulation SMDS
ARP type: SMDS, ARP Timeout 00:00:00
router#show smds addressesUse the show smds map privileged EXEC command to display all SMDS addresses that are mapped to higher-level protocol addresses. The following is sample output from this command:
SMDS address - Serial4/3.1 E170.3204.1234.FFFF
router#show smds mapOther commands that can be used are:
Serial4/3.1: ARP 172.16.150.1 255.255.255.0 maps to E170.3204.1234 multicast
Serial4/3.1: IP 172.16.150.1 255.255.255.0 maps to E170.3204.1234 multicast
show smds traffic
show arp
RFC 1209 “The Transmission of IP Datagrams over the SMDS Service"
RFC 1694 “Definitions of Managed Objects for SMDS Interfaces using SMIv2”
I'd like to do a series on IP multicast when time permits. And QoS needs revisiting, there's lots of new things to go over there, including some new thoughts from Cisco on how to best do QoS for Voice. A couple of people have suggested VPN's, although they come in several flavors, depending on what you're trying to do -- another series. And I've been thinking that Security Best Practices might be interesting (or maybe we'll just make that "Some Tips and a Checklist", since I don't claim to be a Security guru and know how to do it best).
So we certainly won't lack for topics. If I've missed your favorite, or if you want to try to get me to write about yours sooner, do send email!
Dr. Peter J. Welcher (CCIE #1773, CCSI #94014) is a Senior Consultant with Chesapeake NetCraftsmen. NetCraftsmen is a high-end consulting firm and Cisco Premier Partner dedicated to quality consulting and knowledge transfer. NetCraftsmen has nine CCIE's, with expertise including large network high-availability routing/switching and design, VoIP, QoS, MPLS, network management, security, IP multicast, and other areas. See http://www.netcraftsmen.net for more information about NetCraftsmen. Pete's links start at http://www.netcraftsmen.net/welcher . New articles will be posted under the Articles link. Questions, suggestions for articles, etc. can be sent to pjw@netcraftsmen.net .