CircuitPath > Technology

Synchronous Adaptive Infrastructure Network (SAIN) Background Most network planners have "wish lists" of requirements to support a transition from today's interoperability-challenged operational structures to structures that increasingly rely on a network based communications infrastructure to support critical information systems. Those wish lists usually include an underlying networking infrastructure that: assures universal interoperability among constituent elements assures 99.999% availability, even under adverse conditions does not obsolete what exists is based on Commercial Off-The-Shelf (COTS) components is non-obsolescent to future needs is secure is voice/video/data convergent overcomes today's limitations: o lack of scalability o high delay and large delay variation o low bandwidth utilization efficiency o high complexity o highly variable, or non-existent Quality of Service (QoS) performance o high operating, administration and maintenance (OAM) cost Although progress has been made, today's networking approach fall well short of meeting these goals. This page introduces a technology that meets the challenge. SAIN BACKGROUND Digital networks depend on time multiplexing - the ability to efficiently share transmission links among a large number of users. A data stream may be divided into time segments that use either explicit or implicit addressing. Addressing for packet and cell switching is explicit; time division addressing it is implicit. As shown in Figure 1, this means that time division addressing is based upon the physical position of information in the flow while packet and cell addressing utilizes additional bits from the transmission for addressing. Time division addressing is ideal for Constant Bit Rate (CBR), or circuit flows, and packet/cell switching is ideal for non-constant rate bursty flows. The latter is true as long as the efficiency in handling the variability overcomes the packet/cell overhead for the addressing and other control information and network resources are sufficiently underutilized to mitigate congestion and contention issues. Experience has shown that when aggregated traffic is homogeneous and the number of flows is large, bandwidth utilization efficiency can be as high as 80%. But, for small numbers of flows and traffic that has widely different characteristics, bandwidth utilization is likely to be far less.
Figure 1 - Types of Time Multiplexing
One example of time division implicit addressing is the digital Public Switched Telephone Network (PSTN). The PSTN transmission scheme is based on 8-bit voice samples transmitted in frames of 24 samples that are repeated once every 125 µsecs. This narrowly defined model for time division multiplexing does not fit the needs of a switched data network. Asynchronous multiplexing, with explicit addressing and variable length packets, emerged in the '70s to overcome the deficiencies, becoming the de facto way of allowing similar and dissimilar host computers to intercommunicate. This approach, a stark contrast to the fixed structure of the PSTN, formed the basis of the DoD ARPANET, and later, became the Internet. This asynchronous packet-based networking method of choice is today a family of thousands of protocol standards we know as the Internet, most of which are based on a Layer 2 protocol called the Internet Protocol (IP).
	At the time IP was being developed by the Department of Defense, there was general agreement on the desirability of packet switching, but there was no agreement on a single format. Mutually incompatible networks began to emerge with the commercial sector developing competing proprietary protocols. To remedy the situation, standards organizations focused on defining a single high-level architectural model for data networking protocols. The result was the International Standards Organization (ISO) seven-layer packet protocol model. Almost all network researchers today believe that this structure must now be followed for not only all data networks, but also for networks that combine flow-based voice and video plus bursty data. A major effort to combine both flow-based and bursty traffic has been Asynchronous Transfer Mode (ATM) and related protocols. ATM-based switching has been deployed by a number of the world's carriers and their vendors. However, the protocol became so complex within the standard process at the time and deployment beyond a portion of the carrier market has proved to be non-competitive. Quite independently, a large effort has been underway globally since the 1970s to build IP-only networks making IP both the network access protocol of choice and also using IP as the universal core network (router-based) switching protocol. These efforts have produced many exciting technical innovations, but they too are very complex and are still evolving. In the end, IP is still a "best effort" networking protocol. And while "best effort" can be optimized to "very good" under the proper circumstances, the issues of scaling IP to very large and/or robust networks are not yet fully understood nor addressed. As an access protocol, IP is excellent. As for networking, IP is unlikely to meet the demands for high performance converged voice, video and data networking. It is time to look for a simpler approach.
The SAIN Approach Over the past ten years, CircuitPath has been developing a different way to solve networking problems. Our simple approach makes use of implicit addressing, but overcomes the limitations of the PSTN and similar networks. It supports both the seven-layer protocol paradigm and the older circuit switched model with higher performance than can be obtained with a packet switching only approach. Our concept is that simplicity scales. Synchronous Adaptive Infrastructure Networks (SAIN) technology separates network connectivity and bandwidth management capabilities from higher layer protocols, bringing a new level of simplicity and performance to packet switching.
SAIN's underlying protocol structure is shown in Figure 2, a Bandwidth-On-Demand Sublayer 1.5 that consists of two parts - a modem-like interface as seen by each network connection and a control plane software interface that supports both setting up connections and dynamically managing their assigned bandwidth thereafter. This functionality is critical to the needs for dynamic bandwidth management after connectione stablishment to respond to variations in the communications environment. As discussed in the next section, the protocol is based on implicit addressing within		Figure 2 -SAIN Protocol Model
Time Division Multiplexed frames of small fixed-length (per link) time slots called cellets . An integer number of cellets per frame is allocated to a single connection. Changing the value of the integer dynamically changes the connection's bandwidth. The modem-like interface with per connection dynamically controlled clocking rates is the source of SAIN's simplicity. It eliminates the need for packet buffers inside a network. As a result, discarding packets to overcome congestion never occurs inside a SAIN. Layer 2 and higher packet protocol buffering and congestion control issues are only required at source and destination nodes. The paradigm is very similar to a pure circuit model that is particularly appropriate to today's predominantly flow-based applications. This approach greatly simplifies network design, heterogeneous network interoperability and operational support. Higher layer network protocol specialists are required only to focus on those protocols supported at ingress and egress node pairs. As a result, packet headers including their address and control bytes never occur explicitly within a SAIN, a fact that greatly increases network security. Unlike early packet networks that focused on passing messages and files among host computers, today's networks must deal mostly with real-time information flows such as interactive web traffic, voice traffic and conferencing. Admission and flow control are today's critical requirements. These along with all statistical multiplexing issues need only occur at network edges - a very different model compared to the historical model that requires complex network paradigms and expensive intelligence sharing with the users. The desire of network providers and users alike is for simple, straightforward networks that support high capacity flows with assured service quality where intelligence need exist only in a network's access nodes. SAIN multiplexing and switching technology makes such networks possible.
Figure 3 - SCHEMATIC DIAGRAM OF THE SAIN BANDWIDTH-ON-DEMAND LAYER 1.5			Figure 3 shows a schematic diagram of the SAIN interface. The two upward arrows at the bottom of the figure show a node clock synchronized with the physical layer send/receive clock. The clock determines precisely when a cellet is sent to and received from the underlayer multiplex structure by the PHY layer. The down and up arrows show the direction of synchronized cellet flow. The arrows at the left top of Figure 3 represent the flow of TDM structure's clock and data signals to and from higher network protocol layers. The clocking signals synchronize "Put" and "Get" times of cellets between the underlayer and within a TDM frame to and from the adjoining PHY and network protocol layers. The Control Plane is implemented by including a subset of existing networking standards supported by a standardized Application Protocol Interface (API) and signaling channel structure. Because the bandwidth management operation is very simple, only a few bytes need be exchanged (in a TDM format without packet headers) for most functions. Control Plane signaling could be handled in a similar way, although in most network applications of SAIN technology, it will likely be a mix of TDM-based signaling and standardized packet messaging.
In defining and implementing the SAIN architecture, the overriding principle is to include only subsets of field-proven standards for all aspects of SAIN, including network control, transmission, traffic and operational management. The intent is not to reinvent networking, but to apply selectively the best work that has been developed over the past forty years within a simplifying model. The goal is to realize the performance and operational objectives previously stated. We feel CircuitPath's ten-year investment in the simplification described here is a sound basis for achieving this goal.