in accordance with the principles of the invention all data exchanged between adjacent routers in the content based network of fig1 is carried via http over tcp . a single tcp connection between routers can be achieved , if the http layer is used to de - multiplex the control and data flows , as shown in fig2 . two routers 10 and 11 are connected by an http over tcp connection 12 , which is terminated by the http function 16 in each router . within the single http over tcp connection 12 , there are three flows 13 , 14 and 15 . flow 13 connects the xlsp protocol 17 in each router 10 and 11 . flow 14 connects the xsmp protocol 18 in each router 10 and 11 . flow 15 connects the data plane forwarding engine ( dp - fe ) 19 in each router 10 and 11 . http identifies “ paths ” or locations for the exchanged data via field called the uniform resource identifier ( uri ). the definition of the http uri , specified in the reference above , allows the passing of arguments between the communicating devices . arguments are identified by the leading character “?”. the general form of the http universal resource locator ( url ), which is a form of a universal resource identifier ( uri ) is : within the “ query ” portion , the “? name ” argument is used to identify and de - multiplex data flows to the appropriate sub - systems within the content router , for example , the three subsystems 17 , 18 and 19 shown in fig2 . for example , there are three currently recognized values for & lt ; subsystem_name & gt ;, which are identified in fig2 . as an example , when sending an xlsp message to the adjacent content router with ip address 192 . 168 . 10 . 1 , the uri would be : the default subsystem is the dp - fe , and if an http message is received without the name =& lt ; subsystem_name & gt ; parameter specified , then the dp - fe subsystem 19 is selected by default . another method to use a single http session to multiplex / demultiplex multiple protocol flows is to use the “ absolute path ” portion of the uri to specify the subsystem . for example : where subsystem name is one of those specified in fig2 . for example , for the xlsp subsystem 17 , the uri would be : additionally , other http header fields could be utilized instead of the http uri in order to specify the subsystem name for the purposes of multiplexing / demultiplexing multiple protocol flows over a single http connection . http consists of numerous header fields to carry various control information , such as the http content length . one of these existing fields could be used to define the subsystem , or a new header field could be defined . for example , the defined http “ pragma ” general - header field could be used to specify the subsystem . for example , in order to specify the xlsp subsystem : alternatively , if a new field “ subsystem ” was defined and used as part of the http header , the subsystem could be specified as : the technique of multiplexing control and data flows over a single tcp connection presents a potential problem in the prioritization of control traffic over data traffic ( or more generally higher priority application traffic over lower priority application traffic ). in the presence of heavy volumes of customer dataplane traffic ( handled by the dp - fe subsystem 19 of fig2 ), links can become congested , which can lead to significant delays or lost messages . it is critical that the implicit routing protocol ( irp ) protocol messages are isolated from these effects , as they can lead to routing instabilities , routing cycles and lost subscriptions ; all of which lead to a disruption in customer data . note that the irp function is composed of the xlsp subsystem and the xsmp subsystem . the irp is described in co - filed application ser . no . 60 / 530 , 615 . design techniques are applied to the outbound traffic direction to mitigate the effect of congestion on irp protocol traffic . congestion on a tcp connection is reflected by a backup of outgoing messages ready to be sent on that connection . these messages are stored internally in the content router in a software queuing data structure ( which can also be implemented as a hardware queue if the http over tcp function is implemented using hardware acceleration ). by separating the control and dataplane traffic into separate queues , and imposing a queue servicing and scheduling discipline across the queues , it is possible to minimize the delays experienced by the control traffic . the scheduling discipline chosen is a work conserving - weighted round robin , as depicted in fig3 . work conserving involves scheduling disciplines which always make use of available link bandwidth . weighted round robin is a scheduling discipline which cycles through a set of queues , and grants access to the physical medium based on weights assigned to the queues . in this scheme , the two queues can be assigned weights m : n , such that under congestion scenarios , the bandwidth received by the control queue is m /( n + m ) of the total available bandwidth . typical values for m : n are 5 : 1 . since the ratio of data plane traffic to control messaging is typically largely biased in favor of the data plane ( i . e . in typical network operations there are many more data plane messages than control plane messages ), it is rare that control messaging will ever consume the full bandwidth available to it . in these cases the work conserving aspect of the scheduler kicks in : if one of the queues has no data to send in its timeslot , the other queue is serviced . the queuing is shown in fig3 . a single tcp socket ( tcp connection ) 20 carries the three application flows of xlsp 23 , xsmp 24 and dp - fe 25 as described above , using http 22 . the xlsp subsystem 23 produces a message flow 26 . the xsmp subsystem 24 produces a message flow 27 . the dp - fe subsystem 25 produces a message flow 28 . these messages are formatted as http by the http block 22 . the xlsp 23 and xsmp 24 messages are placed into queue 30 , and the dp - fe 25 messages are placed into queue 29 . the work conserving - weighted round robin ( wc - wrr ) block 31 is responsible for managing the removal of messages from queues 30 and 29 for sending to the tcp connection manager block 21 , which manages the tcp connection 20 . queue 30 carries the control plane traffic , and queue 29 carries the dataplane traffic . in fig3 , a single queue 30 is used for both xlsp 23 and xsmp 24 , which together comprise the irp . however , each of these two subsystems could be given their own queue if the traffic between xlsp and xsmp needed different priority treatment . in addition , additional subsystems could be added to the system in addition to the three shown , and this could result in the addition of additional queues , or the new subsystems could share existing queues 29 and 30 . it will be appreciated by persons skilled in the art that many variants of the invention are possible .