BT funded research using SuperJanet Document Reference: LUTBT002
TITLE: Providing ATM connectivity over SuperJanet
AUTHOR Iain Phillips, David Parish and Geoff Tagg(OBU)
ORGANISATION: LUT
ABSTRACT:
This document describes several ways to interwork ATM and SMDS, allowing SuperJanet sites not on the ATM network to perform wide area ATM experiments.
DATE OF ISSUE: Oct 1994
NUMBER OF PAGES: 5 (including cover sheet)
ISSUE STATUS: 1: Draft
CONFIDENTIALITY: Members of BT URI Consortium + BT
DISTRIBUTION: Members of BT URI Consortium + BT
COPYRIGHT: Loughborough University of Technology
The copyright of this document is reserved on behalf of the collaborating bodies by the originating organisation. The contents may not be copied or disclosed outside the above without permission.
AUTHOR'S SIGNATURE:
ACKNOWLEDGEMENT: The BT URI is a collaborative venture funded by BT. Project partners are Loughborough University of Technology, Oxford Brookes University, Lancaster University, Imperial College London, University College London and Cambridge University.
There is a need to connect SuperJanet sites which are not on the PDH (SDH) ATM network together in order for interworking of different aspects of the SuperJanet URI. In addition, other sites on SuperJanet, such as UKC, could benefit from such a facility. Other than extending the ATM network, the only wide area connectivity between such sites is the SMDS service. This documents describes several ways to provide ATM connectivity over the SuperJanet SMDS. Note that none of these solutions is ideal as SMDS by its very design is only a data service and cannot be expected to provide the real time access necessary for some aspects of ATM.
SMDS is a packet switched network. The information we have gleaned about it from various networking magazines and private correspondence follows. Note that this and other technical information in this document comes from adverts, features, marketing and technical documents. Sometimes these contradict with each other.
1. Sites connect to SMDS using a router and a DSU. The DSU is owned by BT, the router by the subscriber, in our case UKERNA.
2. The DSU talks SMDS DXI to the router over either HSSI, X21 or V35. SMDS DXI is simply SIP L3 PDU (SMDS Interface Protocol, Level 3, PDU) over HDLC. A packet consists of an address and up to 9188 bytes of data.
3. The DSU segments these into 53 byte cells (SIP L2 PDUs) which are transmitted to the network.
4. The network routes these L2 PDUs to the destination, possibly reassembling them into L3 PDUs at some stages. In either case the addressing information must be extracted from the first L2 PDU. In the BT SMDS the L3 PDUs are reassembled.
5. The DSU at the remote site reassembles the L2 PDUs into an L3 PDU.
SMDS is therefore really an L3 PDU switching service.
It would appear that there are several conceptial approaches to the generie problem of providing some degree of ATM (or ATM like) connectivity over the SMDS element of the SuperJanet Network. Each approach has its own particular characteristics, indeed some of the approaches could best be received as merely an end-to-end protected conversion at the lower layers. This infers that the ATM connectivity appears to exist only to the end users; in reality the main elements of the network view the data not as a cell stream, but as a protocol data unit flow at a higher layer (e.g. an IP stream).
It should be further noted that due to the operational nature of SuperJanet, certain solutions which appear attractive to the Research Community are not possible in practice due to the disruption caused to the user community.
Possible approaches include:
1. Just connect using IP, with an IP packet in each L3 PDU. Run IP over ATM locally and connect either using an ATM card in a router or the ethernet port on a FORE switch.
PROS: Is definately available and at known cost.
Does not interface with other users. (other than due to any increase in traffic).
CONS: "ATM" performance will be poor. Will provide an IP service only ie. not cell level end-to-end connection.
2. Encapsulate an ATM cell in an IP packet. Requires some software/hardware to do this, should be simple and quick.
PROS: Provides cell level connection
Does not interface with other users. (other than due to any increase in traffic).
CONS: "ATM" performance will be poor, both in the delay and QoS predictability.
3. Encapsulate cells in L3 PDUs directly, perhaps using a box from one of the UCL RACE projects such as COMBINE; otherwise a combination of commercial and specially developed equipment may be used.
PROS: Improves 1 and 2 with a higher quality (ie. higher data rate, lower latency) connection into SMDS. Provides cell level connectivity.
CONS: Equipment provision and cost is more questionable, although some options are available. May involve some development work. May still effectively be a "higher" layer connection, perhaps L3_SIP.
4. As above + encapsulate AAL3/4 or AAL5 packets in an L3 PDU using an appropiate Interworking box.
PROS: Provides cell level connectivity and slightly more efficient packet level connectivity.
CONS: Requires a new access point on the SMDS in order not to interfere with the existing service.
A number of potential implementations for each approach have been studied in more details. Some of these are site dependent as follows:
The main router is currently a Cisco AGS+. The research laboratory ATM network will be centred around a FORE ATM switch. Unfortunately, no ATM card is to be produced for he AGS+. The options are therefore:
(a) Change the Router
(b) Use a dedicated Ethernet connection between the Router and the FORE switch
At LUT, a DL3200 type DSU is in use. We believe, this provides only one high speed (HSSI) DTE interface and this is connected to the router; it is also impossible to add more DTE ports to this device.
The DSU would therefore have to be changed. There are at least two possibilities here.
(a) Replace the DL 3200 by a Digital Link DL3202 SMDS Cell Multiplexer with 2 DTE ports. This will then provide a separate HSSI port over which SMDS DXI data may be passed. This connection could then be provided by either dedicated equipment (see below), or by a dedicated router (This would be expensive).
(b) The possibility of using a Digital Link W/ATM Gateway. This devise may be able to support multiple DTE corrections, including ATM networks. It will multiplex these onto a single E3 link into a high speed network such as ATM, or possibly SMDS. This will need further investigation.
This approach may in practice be used in cooperation with 2 above. It may be necessary to produce a unit which will connect an ATM cell stream to SMDS DX1 via an HSSI interface.
An alternative approach is to launch SMDS L2 PDUS (i.e. SMDS cells) directly onto an E3 line. Note that the service at this level is still really L3-PDUs, however the Interworking Unit would present the ATM network with ATM cell level correction. A further problem is now the need to consider whether a separate E3 SMDS feed is required, or a multiplexer feeding on to the line, as described above, will suffice. This is because of the need to support the current user community.
Clearly, connection over CSMA/CD (ethernet) is not really an option for multimedia data, owing to the packet jitter arising from the use of this MAC-level protocol, even when using a dedicated link to the router. Also this only provides an IP service.
Connection over HSSI appears to be an option. Using this interface, it would be theoretically possible to carry IP datagrams at speeds of up to 50Mbit/s into the router, whence they would be carried in the usual way to the DSU. This would make possible the following physical configuration:
The ATM-HSSI router would perform the function of relaying IP datagrams between the local ATM subnet and the SuperJANET router. This would be necessary on sites (such as OBU) which currently have a non-ATM-ready router, such as a 3Com NetBuilder II or Cisco AGS+. There are some potential problems with this approach:
(i) How to provide the ATM-HSSI router function: should this be within a workstation or be a separate unit? If within a workstation, there is the question of the HSSI card; these are available for SUN workstations, which is the nor being adopted for this project. However, interoperability with router HSSI cards is a bit of an unknown quantity at this stage. If this function is supplied as a stand-alone router, there is the question of cost. There is also the question of whether the HSSI interface between the two routers should run the DXI protocol.
(ii) Whether the SuperJANET router is capable of taking two HSSI cards. Conversations with various personnel indicate that the 3COM cannot. However, the Cisco routers can, but it does appear to be somewhat unknown territory.
PROS: it would appear to be feasible; it would also be independent of SuperJANET router type.
CONS: there are still some unknowns which access to the right personnel might solve; it would be messy if the DXI protocol were not run over both HSSI links. It would be simpler to run the ATM LAN all the way into the SuperJANET router, but then this would have to be an ATM-ready model, such as the Cisco 7000. Still only provides an IP service.
The configuration would be much the same, logically, as the above. Physically, the HSSI link into the SuperJANET router would be replaced by an FDDI link which would alter the ATM LAN router to an ATM-FDDI router relaying IP datagrams. The protocol would be ordinary asynchronous FDDI, mainly because of the general lack of products supporting synchronous access. (Note that FDDI II would be even more appropriate theoretically, but there are no known products.)
PROS: it would work; FDDI has extremely well developed management, which is potentially useful; it would be convenient where FDDI is already in place.
CONS: where FDDI does not already exist on-site, it would be expensive to install it just to meet this option. Also only provides and IP service.
These IP only options all assume that the main purpose is to provide IP interworking between non SuperJanet ATM sites. All configurations have a segmentation/re-assembly function on one side of the SuperJANET router, and a further SMDS segmentation/re-assembly function on the other at the DSU. The implications of this for packet jitter (and therefore the jitter related to a group of cells) are significant, which could form the basis for some inter-site investigations.
This was suggested by Jon Crowcroft in an email message to mmn-tech. We belive that this would not work as full addressing information is carried at the L3 PDU level only. This depends on the exact operation of BT's SMDS service, and will required their full cooperation.
Any modification to the networking equipment after the site router will require both considerable expense and negotiation. The best proposal therefore appears to be to attempt, at an early stage, to secure true ATM connectivity to all URI sites. This is the only sensible option for people to do true cell level wide area experimentation.
Failing this, an upgrade of the site, DSU equipment and provision of a dedicated router or Interworking Unit for the research groups should be considered.