protocol for a distributed switching interactive catvnetwork bound... · protocol for a distributed...

Philips J. Res. 41, 559-575, 1986 RI145

PROTOCOL FOR A DISTRIBUTED SWITCHINGINTERACTIVE CATV NETWORK

by T. N. SAADAWI*)8), N. JAIN**) and M. SCHWARTZ***)8)*) Electrical Engineering Dept., City University of New York, New York, NY 10031

**) Philips Laboratories, North American Philips Corp., Briarcliff Manor, NY 10510, currently, at Trintex Corporation, White Plains, NY 10601

***) Electrical Engineering Dept. and Center for Telecommunications Research, Columbia Uni-versity, New York, NY 10027

AbstractIn this report, we present a fast switching network protocol for a distri-buted switching two-way interactive CATV system. The backbone networkprotocol takes advantage of the tree topology of the CATV network toreduce the processing time and memory requirements at the intermediatenodes. Backbone virtual circuit switching is assumed. The concept of fixedhierarchical logical channel number is suggested since it will provide forfast switching at the network layer within the intermediate nodes alongwith a node address or identifier. Discussion of the directory databaseproblem and the different methods for locating a specific user are pre-sented. A modified version of High-level Data Link Control is suggestedfor the local access protocol, incorporating the functions of call set-up andclearing at the link level.PACS numbers: 47.10.

1. IntroduetionThe rapid growth of the information industry has fueled the demand for

data networks in the past few years. While several alternatives are availablefor transporting data over long distances, the end user access in most casesmust be through the local telephone system. This usually means high connec-tion costs and limitation to low data rates (typically 1200 baud in recentyears). The 'steady increase of Community Antenna Television (CATV, alsoknown as cable television) penetration has resulted in 600/0of households inthe United States being passed by this new transmission medium. While mostcable systems have been dedicated to distribution of entertainment television,

a) Consultants to Philips Laboratories, Briarcliff Manor.

Philip. Journalof Research Vol. 41 No.6 1986 559

560 Phlllps Journalof Research Vol.41 No. 6 1986

T.N. Saadawi, N. Jain and M. Schwartz

there exists a huge potential for wideband communications that has remainedlargely untapped to this date. In ref. 1 we have looked at the possibilities fortwo-way interactive services over CATV systems and focused on the varioustechnical issues that must be considered.It is worth mentioning some architectural details of CATV systems to

motivate the discussion that follows. The central node of a CATV plant iscalled the head-end. Here, the signals from different sources such as satelliteand terrestial broadcasts, as well as local origination programming, aremodulated onto RF carriers and combined together for distribution over thecable system. Super-trunks (high quality microwave, fiber-optie, or cablelinks) connect the head-end to strategically placed local distribution centersknown as hubs. Several trunks may originate from a hub, each trunk furtherdividing into sub-trunks and feeder lines in the form of a tree to providecoverage over a large contiguous area. Individual trunks may run to distancesas long as 20 to 30 km with a large geographical area of up to 500 km2 oftenbeing covered by a single cable system. Present day CATV systems provide atleast 60 TV channels over a 440MHz bandwidth on a single cable and oftentwice that number on a dual cable system (some of the newer systems are beinginstalled with 550MHz bandwidth). A portion of the frequency spectrum (5 to50 MHz) is dedicated to 'upstream' traffic that is inbound towards the head-end. Some systems actually include the filters and the amplifiers to provide thisreturn channel while others build in the capability to add these at a later date.

In ref. 1 we have looked at some practical considerations for data transmis-sion over CATV systems. The cable system requires that all messages fromusers be sent on the upstream channel and received on the downstream chan-nel. This usually means that the message travels all the way to the head-endwhere it is frequency converted and re-transmitted on the down-stream fre-quency. The large distances cause substantial round trip delays which makecentralized control schemes very inefficient in this environment. It also leadsto degradation in performance of random access schemes such as CSMA/CDdue to increased collisions when high data rates are used. Another problemrelates to the so called noise 'funnelling' in the reverse direction. This is due tothe noise. of all the amplifiers combining together for inbound transmission,thereby raising the noise floor considerably. A distributed switching schemehas been proposed as a solution to these problems.In ref. 2 we have presented and analysed the advantage of distributed switch-

ing for two-way interactive CATV. In such a system, fig. I, packet switches areinstalled at different locations on the main trunk (possibly at the bridgeramplifiers). The switches have the capabilities of routing, flow control, errordetection, etc. The distributed switching offers some advantages over the clas-

~----- _--- ----

Protocol for a distributed switching interactive CATV network

SWITCH

-. UPSTREAM

_ DOWNSTREAM SWITCH

SUB-BRANCH

MAIN TRUNK

BRANCH

Fig. 1. Two-way interactive distributed CATV system.

sical approach, namely centralized switching in which all the traffic must travelto the CATV head-end and be retransmitted on the down-stream frequency.With distributed switching, the amount of traffic flow on the main trunk willbe much less than that of the centralized approach and hence less channelbandwidth will be required for the distributed approach. Also, the problem oflocally accessing the channel becomes less critical since the user accesses thenearest node. In the analysis of distributed switching, two configurations havebeen considered. In the first, switches are located only on the trunk and in thesecond, switches are located on the branches as well. In both cases, expressionshave been developed for the traffic flow along the trunk, average throughputof the switches, and message delay as a function of the total traffic being car-ried. The scheme with switches only on the trunk is shown to be the preferredmethod for the representative examples of traffic considered.

In this paper, we go beyond the results developed in refs 1 and 2 to discussthe implementation of a distributed switching network on a CATV system.A fast switching protocol is proposed for such a network. The protocol usesvirtual circuits (VCs) along the main trunk backbone network. It is based onthe X.25 architecture "), with modifications introduced to obtain improvedperformance in the CATV environment. A polling procedure based on amodified version of High-level Data Link Control (HDLC) is used to provideaccess to the backbone network. Sec. 2 discusses the need for a fast packetswitching protocol for two-way distributed CATV networks. Sec. 3 presentsthe network protocol architecture, while sec. 4 addresses the directory database problem associated with locating destination users in this protocol. Sec.5discusses the network access protocol.

Phlllps Journalof Research Vol. 41 No. 6 1986 561

Ol = (1 - ~) i Ob.

Eq. (1) can be easily explained as follows (see also ref. 2). We can considernodes 1, 2, ... , i as a single large node that generates iOb simultaneous yes.As a result of the uniform distribution, ilM of these ves will be destined tothe branches attached to nodes 1, 2, ... , i, while the remaining (1 - i/M)of these ves will represent the upstream ves destined to nodes i+ 1, i + 2,... , M. For a 50000 user single-trunk, five-branch system (M = 5 and 10000users per branch) and assuming 200/0 simultaneous active users in the system(Le. a total of 5000 simultaneous active yes), Ob == 1000 simultaneous activeves per branch. Using eq. (1), we can easily establish table I, which represents

(1)


2. The need for a fast switching network protocol

The need for a fast switching protocol is motivated mainly by the fact that inthe eATV environment, the number of data users is expected to be large(typical values might be 50000 to 100000 users per system). With the eATVtree topology and cascaded switches ori the main trunk, a large number of vesmust be supported by every switch. This is demonstrated by the followingexample which determines the average number of ves passing by every switch.Let M be the number of switches on the main trunk (also the number of

branches) and assume each branch supports an equal number of users. Let Obbe the average number of simultaneous ves over every branch. We.assumethat users communicate with each other with a uniform distribution (i.e., theprobability of a ve established from a given branch to any other branch isl/M). Hence, the average number of upstream ves passing by switch i on themain trunk, Ot, is given by (see fig. 1)

TABLE I

Nodal throughput (in simultaneous yes)

average number average number nodalnode of upstream of downstream branch throughput in

number vcs vcs vcs simultaneous ve

1 800 none 1000 18002 1200 800 1000 30003 1200 1200 1000 34004 800 1200 1000 30005 none 800 1000 1800

M = 5, Bb= 1000 VC, one branch per node.

562 Philip. Journalof Research Vol.41 No. 6 1986


the average number of simultaneous upstream and downstream Yes, BI and tifor node i, 1< i<M, respectively.From the table, node 3 has the highest nodal throughput (3400 VC), which

is extremely high. Taking the Tymnet routing procedure 4) as an example, wewould have to create permuter tables with 1200'entries for upstream and an-other 1200 entries for downstream and 1000 entries for the branch traffic. Eachentry in the table represents the logical channel number (or logical recordnumber in the Tymnet terminology) and the corresponding memory addresswhere the ,data packet can be stor~d or retrieved from. For an incomingpacket, the switch reads the packet's logical channel number and then scansthe permuter table (in our case with 1200 entries for upstream packets) to findthe corresponding memory address to store the packet. After the packet isprocessed for sequence numbering, correctness, etc., it is stored in the outputport memory location. At the output side, the Cf'U scans the permuter table(again possibly with 1200 entries) and retrieves the packet from the memorylocation found in the table.Tymnet is a terrestrial network with 4.8 kbps and 9.6 kbps trunks. For

4.8 kbps trunks, the average number of ves is 48, while for 9.6 kbps trunks itis 192. These numbers are easily achievable with present day switches and pro-tocols. However, with 1200 Yes, huge memory requirements, large lookuptable scan time and significant processing time would be inevitable. In addi-tion, the broadband CATV environment justifies the use of wideband (Mbps)transmission rates. As a result, we feel strongly motivated to design a fastpacket switching protocol that utilizes the eATV inherent tree topology andthe cascaded nature of the switching 'nodes.

_UPSTREAM_ DOWNSTREAM

}TRANSITTRAFFIC

"" LOCALTRAFFIC

BRANCH

Fig. 2. Types of traffic passing by a node.

Phlllps Journalof Research Vol. 41 No. 6 1986 563


The main objective of our protocol is to reduce the processing time for thetransit traffic, i.e. the traffic already in the network and passing through thenode from upstream to downstream or vice versa. This is distinguished fromlocal traffic, originating on or destined for a branch at the node in question(see fig. 2).As noted above, the protocol developed is based on X.25, with modifica-

tions introduced to improve its performance in the CATV environment.

3. Fast switching packet protocol

In the two-way CATV environment, it is envisioned that every user, whetherhome or business, will have a home data terminal unit (HDTU) that has thecapability to send and receive data over the CATV system. In the design ofthese HDTUs, simplicity and low cost are essential goals.

Ideally, one would envision using an X.25-like protocol (up to and in-cluding the packet level, level 3), to establish end-to-end VCs between com-municating users (HDTUs). Call set-up and clearing, as well as data transfer,would then be taken care of by the users. The cost of the user terminal, theHDTU, as well as its complexity, would rise considerably. Instead we havechosen to use a VC-based X.25-like protocol along the backbone networkonly. Call set-up, including directory lookup to determine the location of thecalled party (HDTU), VC routing during the data transfer phase, and calltear-down, are then handled by the packet switches along the backbone net-work.Before describing details of the protocol, we define some terms that will be

used in the following material. All users in the network are associated with a(parent) network 'node' which is the location of a packet switch. The usersaccess their parent node by the prevalent local access technique (see sec. 5)over the branch channels. The 'entry node' is the node to which the sourceuser (initiating a call) sends a call request message to establish a VC. The 'exitnode' is the node associated with the destination user (called party). Any nodelocated in the path between the entry and exit nodes will be referred to as an'intermediate node'.A packet switch at a node polls all users connected to it. Data transfer be-

tween the user and the packet switch is accomplished using a data link pro-tocol derived from HDLC. Details are presented in sec. 5 following. A userdesiring to establish a call to another user in the network so indicates in a usercall request message to the packet switch to which it is connected. That switchthen locates the address of the destination user, either by searching its ownlocal database, or by interrogating a directory database located elsewhere inthe network. On establishing the destination address, the initiating switch at

564 Phillps Journalof Research Vol.41 No. 6 1986

the entry node proceeds to set up a VC to the switch at the appropriate exitnode. To do this the initiating switch assigns a logical channel number (LCN)to the VC and incorporates this in a network call request packet addressed tothe exit node. The LCN assignment is unique to each entry node. Its useobviates the need for source and destination user addresses to be carried ineach packet (which is the case with packets traversing a network in thedatagram rather than the VC mode) and represents a considerable saving inpacket overhead. In our protocol, a total of 16 bits is used for the LCN ofwhich the first 4 bits identify the entry node.

We assume for simplicity that the user profile data base is located at thecenter switch. Such a data base contains information about all the users, theirlocation in the network (which branch a user is attached to), the user accessrights, user billing information, etc. All other switches have informationabout their local users only. In the section following we compare the een-tralized directory scheme with a distributed one. The protocol is simplifiedsomewhat in the latter case.

We explain the protocol by assuming that user Ai wants to communicatewith user B; (the subscripts i and n refer to physical address and name respec-tively), as shown in fig. 3. User A i sends a user call request message to its switch(switch A). The user call request message contains the source address (AI) andthe destination name (Bn). Switch A scans its own local users' table. If the des-tination user B; is found, switch A maps it to address BI and sends a user callrequest to the local user BI. If B; can't be found, switch A sends a searchpacket to the central database. The search packet (fig. 3) contains the directoryaddress D shown as X in fig. 4, the source address (Ai), destination name (Bn)and a LCN (A,locaIA) assigned by the entry switchA. This LCN, as indicated,consists of two parts. It has a subfield A uniquely identifying the entry switchand a sub-field locals representing the logical channel identification for theuser. Upon receiving the search packet, the data base scans the users' tableand locates user BI and the switch to which it is attached (switch B). The database then sends an exist packet to switch A. The exist packet (fig. 3) containsthe source and destination addresses (AI and BI) and the LCN (A,locaIA), aswell as the entry and exit switch identifiers (A and B). If the data base can'tfind user Bi (reasons might include the fact that Bi is denied from using thesystem, or that it never existed on the system), the data base sends a not foundpacket to switch A. Once switch A receives the exist packet, it sends a networkcall request packet to switch B. As shown in fig. 3, this packet contains the exitnode address, LCN (A,locaIA), and the source and destination addresses.

The various packet types defined here are required for this protocol becauseof the assumption above of a central database with user addresses and infor-

Philip. Journalof Research Vol. 41 No. 6 1986 565


--~yIIIIII

Us IëFlcALLFlë '

I AIBI QUëST

CCEP"fUSER CII.LL 11. I

11.\6\ I

II

AI,BI : PHYSICAL USER ADDRESS

Bn : NAME OF USER BI

(A.LOCALA): FIXED HIERARCHICAL LCN

Fig. 3. Typical message exchange sequence.

mation. Another possibility would obviously be one of duplicating the users'database at each switch. In this case these packets would not be needed. Thiswould typically require duplicating information concerning as many as100000 users at each switch. Not only is the memory cost high in this case, butkeeping all databases up-to-date becomes time consuming and costly, whilethe added processing power required to search a large database at each nodecan be costly as well. In the next section we compare the centralized directoryconcept with a distributed one in which each switch maintains a directory oflocal (branch) users only ..Note that we have distinguished the user call request message from the net-

work call request packet, since their formats are different. The former is des-cribed in sec. 5 following.The intermediate nodes, upon receiving the network call request packet,

read the exit (destination) switch identifier first, realize that it is destined foranother switch and queue the packet to the output trunk.

566 Philip. Journalof Research Vol.41 No. 6 1986

Protocol for a distributed switching interactive CAT.V network

x I GFI

A I______ 1

LOCALA

TYPE

LENGTH OF~ILENGTH OFSOURCE ADDR DEST. NAME

SOURCE ADDR (AI)

DEST. NAME (Bn)

SEARCH PACKETAND NOT FOUND PACKET

x I GFI

A I1------_1LOCALA

TYPE

LENGTH OF d LENGTH OFSOURCEADDR DEST. ADOR

SOURCE ADDR (A I)

DEST.ADDR (BI)

FACILITY

NETWORK CALL REQUESTAND NETWORK CALLACCEPT PACKETS

x GFI

A I_____ ...1

LOCALA

TYPE

LENGTH OF LENGTH OFSOURCE ADOR DEST. ADDR

SOURCE ADDR (AI)':""_--IDEST. ADDR (BI)

---IEXIT SWITCH ADDR (B)

EXIST PACKE""'T-__J

X GFI

A I______ ...J

LOCALA

peR) M pes) I 0

DATA

DATA PACKET

X = DEST. SWITCH I.O.

(A, LOCALA)= LOGICAL CHANNEL NUMBER

Fig. 4. Packet format for the network protocol.

The destination switch (B) on receiving the network call request packetissues a user call request message over the local branch. User BI responds witha user call accept (or user call reject) message. The exit switch then sends a net-work call accept (or network call reject) packet to the entry switch A, whichissues a user call accept (or user call reject) message to user AI. Data transferthen occurs.Notice the following:

1) An intermediate node does not inspect the receiving or sending sequencenumbers of transit packets, thus saving processing time.

2) The intermediate node does no mapping for the LeNs since the protocolworks with a fixed hierarchical logical channel numbering scheme(A,locaIA), thus saving memory space (no look-up tables are required) andalso saving processing time.Packet formats for all the packets mentioned above appear in fig. 4. Note

that these are based on the X.25 interface protocol packet format, with modi-

Philip. Journalof Research Vol.41 No. 6 1986 567


fications made to accommodate the network characteristics, rather than inter-face properties of the protocol, as well as the CATV environment for which ithas been designed. The first 4-bit field in all packets is the destination switchaddress, labelled X in fig. 4. This enables the packets to be more rapidly routedto the appropriate outgoing trunk. If there is no traffic queued for that trunk,the packet may be immediately read out on that trunk. This is similar to cut-through switching described in ref. 5. Note also that routing is very simple inthe CATV environment - the receiving node is either an exit or intermediatenode. This is very easily determined by reading the destination fieldX. If thenode is.an intermediate one, the outgoing trunk must be the one other than theone on which it is received (fig. 2). Packets can thus be processed relativelyquickly, resulting in a fast packet protocol.The LCN (A,locaIA), as shown in fig. 4 is 16 bits long. The entry node A is

identified by a unique 4-bit field, as was the destination address X. 16 switchescan be accommodated. The user-id (locala) is 12bits long allowing 4096 activeusers per node to be accommodated.The other functions of the network layer, not specifically discussed here, are

assumed to be implementable in a manner similar to X.25.

4. The directory data baseIn the previous section, we assumed that the directory for all the users in the

system is located in one switch, say the central switch. Here, we compare thatmethod with one not requiring a central directory. Instead each switch incor-porates a directory of local (branch) users only. These represent two extremecases. Cases in between would include duplicated central directories or areadirectories.

4.1. Centralized directoryThis is the case assumed in our previous example. Each switch maintains a

directory of all local users. The central directory contains all network users.Notice the following:a) Three new control packets are required:

search packet: sent from the entry switch to the directory and containssource address, destination address and LCN;exist packet: sent from the directory to the entry switch and carries theaddress of the exit switch;not found: sent from the directory to the entry switch in case the destina-tion user is not on the system.

b) There may be considèrable search time, since the directory might have toscan all the names in order to locate the exit switch address.

568 Philip. Journol of Research Vol.41 No. 6 1986


c) The call set-up time is increased compared to a distributed directory, sinceit includes the time required to interrogate the directory (the time from themoment the entry switch sends out the search packet until it receives theexist packet).

4.2. Distributed directoryIn this method, each switch again maintains a directory of the local users

attached to its branches. There is no central directory. When a switch receivesa user call request, it scans its local user table searching for the destinationuser. If the destination user does not exist in the local table, the switch sends anetwork call request packet to the down-stream and up-stream switches (i.e.,left and right) at the same time. Both left and right switches search their localtables looking for the destination user. If they do not find the destination user,they propagate the network call request to subsequent switches. The procedurecontinues until one switch (say located to the left of the entry switch) finds thedestination user. This switch eventually becomes the exit switch.The exit switch now sends a usercall request on the local branch to the desti-

nation user who responds with a user call accept. The exit switch then sendsa network call accept packet to the entry node. Note that the entry node hasoriginally sent two network call request packets to the left and right. In ourexample, we assumed the exit switch is located to the left, so that none of theright switches includes the destination user. In this case, the last switch to theright will issue a not found packet back to the entry switch. The entry switchdiscards the not found packet, when it receives the network call accept packetfrom the exit switch. In some cases, both the farthest switches to the right andleft of the entry switch might send a not found packet, since the user mighthave been barred from the system, there might be an error in the destinationuser name, etc. The entry switch will then have to send a user call reject mes-sage to the source user. This control packet normally appears in the discon-nect phase, not discussed here.Notice the following:

a) Only one new control packet is needed; this is the not found packet.b) The network call request and network call accept (or reject) packets im-

plicitly perform the function of search and exist packets, respectively, inthe centralized directory case. This reduces the call set-up time, since adirectory search mode, as required by the centralized scheme, is not ex-plicitly needed. The directory search time is reduced as well. Except for thedirectory mode, the same protocol is used in both cases.The following problem may arise: The entry switchA sends to the right and

left, a network call request packet with a chosen LCN (A,locaIA). Let us

Philip, Journalof Research Vol. 41 No. 6 1986 569

570 Phlllps Journalof Research Vol.41 No.6 1986


assume that the exit switch is located to the right, and the VC is being estab-lished. The entry switch should also receive a not found packet from thefarthest left switch. Say, this packet takes a long time until it show's up at theentry switch (reasons such as delay in processing at the farthest left switch,network congestion, etc.). During that time, the VC with LCN (A,locaIA) hasgone through the data transfer phase and then the disconnect phase. Now, ifthe entry switch attempts to set up a new VC with the same LCN (A,locaIA)and at that time the not found packet for the old VC shows up at the entryswitch, it will be assumed that it relates to the present VC and cause con-fusion.A possible solution is as follows: Since the logical channel scheme is a fixed

hierarchical scheme and the LCN is assigned by the entry switch, the entryswitch selects the LCN in a sequential cyclic order. With a l2-bit LCN field, itwill take 4096 VCs before the same number recycles again. Now, by adding atime stamp to the network call request packet and the corresponding not foundpacket, and by attaching a life time to the not found packet, such a problemwould be handled.

5. Network access protocol

It has been indicated earlier that the decentralized packet switching architec-ture for a CATV network simplifies the local access problem considerably.This is because access is now only to the nearest node and a smaller group is incontention for the resources. This group may be quite large (5000 to 10000),however, and a suitable access protocol must be determined. Random accesstechniques, in particular CSMA/CD, are very popular for bursty interactivecommunications in local area networks. To effect such a system here, all usermessages would have to travel upstream to the parent node and be retrans-mitted downstream after frequency" conversion which would entail significantround-trip cabled distances (typically up to 10 km). This places a severe restric-tion on the data rates that may be employed. We are also concerned with theingress noise for which CATV networks are notorious. Such noise enters thesystem for various reasons (e.g. poor terminations) and adds up to significantlevels due to funnelling in the upstream direction. For these reasons, wefavour a controlled technique for local access to the network. This reducessensitivity to cabled distances and permits use of bridger switching to controlnoise inflow.The specific technique chosen here is an adaptive polling strategy; the polling

cycle adapts to the level of user activity, both individually and as a function ofoverall subscriber activity as well. The objective is to provide an appropriateresponse time at the user terminal for each class of service supported by the


system. Typically, the users would be divided into two classes, active and in-active. All users are initially considered as being inactive. When a user res-ponds to a poll message, it is upgraded to the active category. The systemmaintains different tables for each class, with the active class being polledmore frequently. A response time of 1 to 2 seconds at an interactive terminalwould be desirable. This is achieved by going through several polling cycles inthe active table for each pass through the inactive table. As the active listgrows, more frequent poll cycles are required to maintain response. Clearly,this is at the expense of the inactive users whose response gradually degrades.The size of the active table cannot be allowed to grow indefinitely without in-curring a penalty eventually in response time. Therefore, the active table iscontinually monitored and users with low activity level are returned to theinactive state. The various parameters would adapt gradually to the overallsystem traffic and a precipitous drop in throughput exhibited by random sys-tems will not be seen.

In our network, the nodes also play the role of central controller for localaccess. All user stations are slaves and may only transmit when explicitly per-mitted to do so by a poll message. A modified version of HDLC is employedfor data link control. For the multipoint polling configuration, the normalresponse mode (NRM) of HDLC is used. Details of the HDLC procedure maybe found in refs 6 to 8.The unit of data exchange in HDLC is a frame. The basic frame structure is

shown in fig. 5. Three frame types are defined and are distinguished by thecontents of the control field. These are the supervisory, information, and un-numbered frames. The subset of frames selected for efficient data exchange inNRM is shown in table Il. The table also identifies the designated usage of eachframe.

~r!~ING ADDRESS CONTROL INFORMATION FCS ~t~~ING

01111110 16 bits 8 bits Variable 16bits 01111110

Fig. 5. HDLC frame structure

To access the backbone network, the user stations should be able to per-form the basic functions of call setup, data transfer, and call disconnect orclearing. As mentioned earlier, we maintain the simplicity of the user terminalby incorporating these functions in a modified HDLC structure rather thanadding a full network layer with its concomitant overheads and redundant ex-change of messages. In HDLC and all its commonly known variations such asLAPB, ADCCP, etc., only 17out of the possible 32 unnumbered frames havebeen defined for known use. We suggest using five of the remaining frames to

PhllIps Journalof Research Vol. 41 No.6 1986 571


TABLE 11

HDLC frames used in NRM

frame type description primary secondary

SNRM U set normal response mode X

DISC U disconnect X

FRMR U frame reject X X

UA U unnumbered acknowledgement X X

DM U disconnected mode X

RR S receive ready X X

RNR S receive not ready X X

SREJ S selective reject X X

I I information X X

TABLE III

Extensions to HDLC for network access

control field info. field

frame description 12345678 size contents

UCR user call request 1 1 0 1 010 variable dest. nameUCA user call accept 1 1 0 1 o 1 1 3 bytes dest. addressUCC user call reject 1 1 0 1 001 3 bytes dest. addressUDR user disc. request 1 1 0 1 100 4 bytes dest. addr, RcodeUDA user disc. ack. 1 1 0 1 1 0 1 4 bytes dest. addr, Rcode

implement the network access functions. These are described in table Ill. Notethat these are precisely the User-Switch messages referred to previously andshown in fig. 3.

The link layer functions of link set-up, disconnect, and data transfer areperformed in the usual manner. Error recovery is effected by the use of Poll!Final checkpointing and the SREJ frame. A good discussion of these opera-tions in the NRM mode can be found in ref. 9. As mentioned above, the addi-tional U (unnumbered) frames are used to access the backbone network. Allthese frames carry additional information, qualifying their action in the I fieldas shown in table Ill. In the case of the user call request frame, this (variablesized alphanumeric) field contains the name of the destination user. The callaccept and reject frames carry a 3 byte.physical user address identifying thedestination user (when these frames are transmitted by the exit switch, the

572 Phlllps Journni of Research Vol.41 No.6 1986


address field identifies the source user). In the disconnect request and discon-nect acknowledgement frames, the I field would carry this address and mayalso contain a 1 byte 'disconnect reason code' shown as Rcode in table Ill.When the link layer receives one of these special U frames, it always respondswith an unnumbered acknowledgement (UA) frame, and passes the contentsof the control and information fields to higher-level software for furtheraction. To maintain reliable operation, the U frames will be retransmitted if aUA is not received and the retransmission timer expires. This procedure isrepeated until the retry count (a system parameter) is exceeded, at which.timeerror recovery must be initiated by higher layers. In some instances, duplicateframes will be received as a result of retransmission. Since the link layer hasno way of distinguishing duplicate U frames, these will have to be resolved byhigher-layer software, as shown in the appendix.

Consider the data transfer phase. As shown in fig. 3, the user AI simplysends an HDLC I frame to its switch (A). Here it is associated with a LCN(A,locaIA) and sent out as a data packet over, the network. The exit switch Bthen associates this LCN with the destination user BI and transmits an I frameover its local channel.The user at either end of the VC may initiate disconnection by transmitting

a UDR frame. Since there may already be data packets in the system, the cir-cuit is not actually cleared until the other end confirms the disconnection by aUDA frame. Upon receiving the UDA, the parent switch sends a network dis-connect acknowledgement to the node which initiated the request, and alsoremoves the VC entry from its own LCN table. The far node then sends aUDA to its local user and removes the VC entry from its LCN table as well.The circuit is now clear.Finally, it must be noted that once a user is in an established VC with another

user, he can communicate with no other user except by disconnecting andestablishing a new call. Certain applications, e.g. conference calls, may requiremultipoint communication. While this may be accomplished by repeatedlysetting up and tearing down calls to the individual users, it is not the mostefficient way. Although this subject has not been addressed in this paper, astudy which determines the need for multipoint or multicast VCs and modifiesthe lower layers accordingly for efficient implementation, would be desirable.

6. ConclusionDistributed switching for two way CATV seems to offer performance im-

provement over centralized switching. In this report we have presented a fastpacket switching protocol for a distributed packet switching two-way CATVsystem. The protocol is based on the idea of a fixed hierarchicallogical chan-

Phillps Journalof Research Vol. 41 No. 6 1986 573


nel numbering scheme and a destination switch identifier. A discussion of thetrade-off between centralized and distributed directory data base has beenpresented. An adaptive polling strategy based on a modified version of HDLChas been suggested for local access on the branch channel.

Appendix

Handling duplicate Uframes

As mentioned in the text, an access link transmission error will cause re-transmission of unnumbered frames. In certain instances (as when a frame iscorrectly received but its acknowledgement is destroyed), this will lead toduplicate U frames being received at the link level. The frames which relate tonormal link functions (SNRM, DISC, UA, DM) do not cause any problemas they can be acted upon directly. The additional frames (shown earlier intable Ill) used for network access are passed to the next higher layer of soft-ware. These frames carry no additional information (such as an embeddedsequence number) that identifies them as being duplicate. Since this networkassumes low error-rate channels, we try to minimize the software overhead todetect these duplicate frames. Instead, the processor proceeds to execute thenormal network functions associated with the duplicate frame. If the functionhas already been performed or it is inconsistent with the state of the VC, thenthe frame is simply discarded. All the different frame types can be handled inthis way as illustrated below:

User call request

When this duplicate frame arrives at the entry switch, there will exist in theLCN table an entry which associates the calling user's subaddress with a LCN.Since the user may be in only one VC at a time, a new call request is invalidand will be discarded. Similarly, when the called user receives such a duplicateframe from the exit switch, it is already in an established VC and discards thisrequest to set up another call. Note that this cannot be a call from a differentparty" as it should have been pre-empted by the exit switch which already hasan entry in the LCN table for the target user.

User call accept

When this frame was received by the exit switch for the first time, it con-firmed the entry (made earlier) in its LCN table associating the appropriatelocal user with a LCN. On receiving the duplicate, it will attempt to repeat thisaction, only to find it redundant, and discard the frame. If the frame is dupli-cated at the calling user's end, it is already in an established VC and will auto-matically discard all frames relating to setting up a VC.

574 Philips Journalof Research Vol.41 No. 6 1986


User call rejectOn receiving this frame for the first time, the exit switch removes the ten-

tative entry made earlier in its LCN table and sends a call reject packet throughthe network. When the duplicate frame is received, there is no correspondingentry in the LCN table and the frame is simply discarded. If this frame isrepeated at the calling user's end, it has no outstanding requests for a VC any-more and discards the now meaningless frame.

User disconnect requestWhen a user receives this frame, it would normally acknowledge with a

UDA frame and update its own VC status accordingly. If the frame is'a dupli-cate, the user would find that it is being asked to disconnect a circuit that doesnot exist any longer. The frame is therefore disregarded. When this frame isduplicated at the' entry switch, there are two possibilities. In the first case, adisconnect acknowledgement has already been received from the other endand the corresponding LCN table entry removed. The switch is unable torelate this UDR to a VC and discards it. In the second case, the duplicateframe arrives prior to receiving a disconnect acknowledgement. It will thenpropagate all the way to the exit switch, where it might be discarded as above,or continue to the end user and be handled as described earlier.

User disconnect acknowledgement

When this frame propagates through the network for the first time, theentry and exit switches remove the corresponding entries from their LCNtable, in effect clearing the circuit. The duplicate frame cannot therefore berelated to a LCN at the entry switch and will be discarded. If duplicated at thereceiving user's end, an attempt is made to clear a VC which has already beencleared and no further action is taken.

REFERENCES1) N. J ain, T. N. Saadawi and M. Schwartz, Technical considerations of two-way interactive

CATV, Conference Record of NCTA 'Cable 85', Las Vegas, 1985.2) T. N. Saadawi and M. Schwartz, IEEE Jour. on Se!. Areas Comm. SAC-3, 323 (1985).S) A. Rybczynski, IEEE Trans. Comm. COM-28, 500 (1980).4) M. Schwar tz and T. Stern, IEEE Trans. Comm. COM-28, 539 (1980).6) P. Kermani and L. Kleinrock, IEEE Trans. Comp, C-29, 1052 (1980).6) ISO 3309-1979(E), Data communications - High-level data link control procedures - Frame

structure.7) ISO 4335-1979(E), HOLC - Elements of procedures.8) ISO 6159-1980(E), HOLC - Unbalanced classes of procedures. See also ECMA-60 ..9) O. E. Carlson, IEEE Trans. on Comm. COM-28, 455 (1980).

Phlllps Journol of Research Vol. 41 No. 6 1986 575

protocol for a distributed switching interactive catvnetwork bound... · protocol for a distributed...

Documents