The basic services provided by the network are referred to internally as "foreground" and "background".
Other services built upon them, including IP, are also described below.
Both the basic services are connection-oriented (also see here), so the mechanism is similar to making a telephone call or "tuning in" to a radio or TV broadcast. This allows the necessary resources to be reserved to provide a guaranteed service, and eliminates the overhead of providing addressing information in every packet. It also allows a clean separation between the choosing the route (a complex process done once per call, by software) and directing the packages along it (a simple process done for every package by hardware).
The foreground service is appropriate to live media such as audio, video, and telephony. Data flow is one-to-many: one unit is the source, and the network copies the packages as required to reach all the destinations. This is similar to the ATM point-to-multipoint configuration, but different from IP multicast.
A call is initiated from the destination. This is similar to tuning into a broadcast or "taking" a source from a cross-point router.
The call carries "packages" of data which are sent at defined intervals. The interval, and the maximum size of a package, are specified by the source.
The overhead per package is very low, so frequent short packages can be used, minimising the delays. A package can contain any number of bytes, so uncompressed audio can always be sent with one sample in each package, for any number of channels.
The system also minimises the time spent at switching points waiting to be forwarded on the next link. This simplifies switching equipment and reduces the delay even further.
By contrast, RTP, the current Internet standard for "streaming" media, needs up to about 100 bytes of overhead per packet. Routing is "store and forward", so each packet must be read into memory and then join the queue for the next link. Most broadcasts over the Internet send a separate copy of the data to each listener.
The foreground service is also better than an ATM CBR service, which requires the packages to contain 48 bytes each and has higher latency because it does more buffering of the packages and is less tightly synchronised.
All of the capacity not required for foreground calls, including capacity reserved but not used, is available for background traffic.
Background calls are bidirectional point-to-point, like a phone call. They carry datagrams (packets) which can be of any size and experience a similar "best effort" service, with store-and-forward routing, to other packet networks.
Connection-oriented protocols such as TCP can be used directly over this service, eliminating the additional headers that are otherwise required to carry addressing information in every packet.
Individual packets can also be routed through the system without setting up a call. There are two mechanisms that can be used.
Calls are connected using special messages between adjacent units in the network. This mechanism can also be used to carry "telegrams" to any destination, though it is not intended to support a large number of packets per second.
The other mechanism carries IP datagrams in a similar way to RFC2225 (IP over ATM), i.e. by setting up calls linking IP routers to each other and to endpoints. This mechanism will carry as much traffic as the link capacity and the IP routers will support. The overheads of encapsulating IP packets in background packages are much less than when using AAL5 over ATM, because the headers are a smaller percentage of the package size and there is no need to pad the message to a multiple of 48 bytes.
An address may serve to identify a service or endpoint, or to locate it within the topology of the network, or both. Where it does both, there should be a clear partition between the two parts. This is true of the NSAP addresses used in ATM (the prefix is a locator and the ESI is an identifier) but not of IPv4 addresses.
Nine Tiles Flexilink supports a wide range of addressing schemes, including NSAP and IPv4. It also supports hierarchical addressing whereby the first part of the address specifies a location, such as a gateway into a subnetwork, and the remainder is to be interpreted at that location. Where there is no locator, the address is interpreted as being on the local subnetwork.
Identifiers can include 48-bit MAC addresses and MIB objects such as sysName (defined in RFC1213).
Various checks are made when a connection is requested, and if any of them fails the call is refused, with a message giving the reason. Among the things that may be checked are the caller's rights to access the equipment or service, the destination's support for the format to be transmitted, and of course for foreground calls that the necessary bandwidth can be reserved. If appropriate, billing information can be collected.
The network can also be requested to avoid, as far as possible, routing a call through any equipment that carries a specified other call. An application that needs extra reliability can set up two different calls, by different routes, and transmit the data on both of them. Then any single failure can only interrupt one of the calls, and the destination will continue to receive at least one copy.
The addressing mechanism allows connection to units on other kinds of network, such as ATM and IP. It also allows connection between subnetworks of different kinds.
Calls between two ATM subnetworks pack the cells into 49-byte packages, the 49th byte carrying the Payload Type and CLP fields. The foreground service is used for CBR, and background for UBR.
IP is implemented using background calls which are identified as carrying IP datagrams. These calls use IP addresses, so no additional ARP is required. If the destination IP address is not on the local subnetwork, the call is made to the gateway IP address.
Ethernet packets can be carried in a similar way to IP datagrams.
Call connection protocols are compatible with SIP.
Initially, management protocols are based on IEC 62379, which is in turn based on SNMP. Other forms of management interface (e.g. via HTTP) will also be available.
------------- ooo OOO ooo -------------
Copyright ©2007 Nine Tiles Networks Ltd