Switched Multimegabit Data Service (SMDS) Overview

back | next | index

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 Path

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:

Customer premises
Dedicated access line
Public SMDS network

The customer premises includes the CPE and CPE LANs, an attached ROUTER, and the SMDS Data Service Unit/Channel Service Unit (DSU/CSU) which terminates the access line.
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:

IEEE 806.2 DQDB MAN Access protocol
SMDS Interface Protocol (SIP)
Data Exchange Interface (DXI) protocol

The MAN Access protocol defines the basics of connecting LANs within a metropolitan area. The DQDB Access protocol is also contained within the IEEE 806.2 standard. This protocol defines how a customer accesses the network from the SNI to the SS.
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.

Relationship Between SMDS and the OSI Architecture

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:

LLC - Logical Link Control
MAC - Medium Access Control

The diagram on the next page compares the OSI model with the various protocols operating within an SMDS network. (IP is any Layer 3 protocol on the CPE, i.e., Internetworking Protocol.)

.-------------.  .-------.                             .-------.
| 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

Distributed Queue Dual Bus

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:

Dual-bus architecture, where each bus' operation is independent of the others
Cell relay transmission, using a reservation MAC process
Compatibility with LANs and FDDI
Ability to use many types of media, including:

Coaxial cable
Microwave system
Fiber optics

Fault tolerance (looped dual bus)
Rates from 1.544 to 155 Mbps
Operation independent of the number/address of stations
Simultaneous support of circuit- and packet-switched data

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.

DQDB Open Dual Bus Topology

       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

DQDB Looped Bus Topology

 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
       +=======|   |==========================|   |=======+
               `---'                          `---'

Fault Tolerance on a Looped Dual Bus Topology

               .---.                          .---.
       +=======|   |==========================|   |=======+
       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:

Header

Busy or empty
Slot type (when applicable)
Request type
Virtual Channel Identifier
Payload type
Priority
Head Check Sequence
Segment type and sequence number
Message Identifier (MID)

Trailer

Payload length and Cyclical Redundancy Check

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:

The Standard DQDB Slot

             [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 |
 `--------+---------+-----------------+-----+-------+---------'

SMDS Interface Protocol

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:

60-Bit addressing (DQDB will support other addressing schemes; SMDS does not)
Non-zero Header Extensions
Head of Bus (HOB) functions at customer's end-station equipment
Open bus topology, where the HOB for the A bus is the SS and the HOB for the B bus is the CPE

The protocol data units for SIP, although designated with a different nomenclature, contain similar elements that perform similar functions:

The Service Data Unit for SIP is the same MAC Service Data Unit generated by the CPE.
The SMDS Frame generated by the ROUTER [called the Layer 3 Protocol Data Unit (L3_PDU) in SIP] is comparable to the IMPDU for DQDB.
The SIP 53-octet cell, created by the DSU/CSU on the customer's premises, is known as the Layer 2 Protocol Data Unit (L2_PDU). These cells are comparable to the DMPDU for DQDB.

The SIP Layer 3 Protocol Data Unit

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 Layer 2 Protocol Data Unit

The SIP L2_PDU has the same basic format as the DMPDU of DQDB:

7-Octet HEADER
44-Octet SEGMENTATION UNIT
2-Octet TRAILER

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:

Access Control

Busy or empty
Request priority

Network Control Information

Virtual Circuit Identifier (VCI)
Payload type
Segment priority (PRI)
Header Check Sequence (HCS)

For SMDS the Network Control Information must be the hexadecimal sequence FF, FF, F0, 22.

    (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.

Physical Layer Convergence Protocol Frame Format

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

SIP Addressing Scheme

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". 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:

Individual addresses
Group addresses

Each individual address uniquely identifies a single Subscriber Network Interface (SNI). However, up to 16 individual addresses may be assigned to a single SNI, each equally valid.
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:

An individual address, not a group address
Legitimately assigned to the SNI from which the packet originates

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:

Performance management
Fault management
Accounting management
Configuration management
Security management

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.

back | next | index