Abstract:
An implicit routing protocol for content-based networks having a plurality of XML routers includes an XML Link State Protocol and an XML Subscription Management Protocol that routes customer data based on XML content. The XML Link State Protocol and the XML Subscription Management Protocol includes several messages that must be exchanged between XML routers in the network. These messages are encoded using XML.

Description:
CROSS REFERENCE TO RELATED APPLICATION 
   This application claims the benefit under 35 USC 119(e) of prior U.S. provisional application Ser. No. 60/530,675 filed Dec. 19, 2003, the contents of which are herein incorporated by reference. 

   FIELD OF THE INVENTION 
   This invention relates to content-based networks, and in particular a method coding of routing protocol messages in such networks using a markup language, such as XML. 
   BACKGROUND OF THE INVENTION 
   A routing scheme for content-based networks is described in the paper by A. Carzaniga, M. J. Rutherford, A. L. Wolf, A routing scheme for content-based networking, Department of Computer Science, University of Colorado, June 2003, the contents of which are herein incorporated by reference. 
   In traditional control plane protocols, such as routing protocols or signaling protocols, messages are typically encoded in a raw binary format. That is, a message is defined as a sequence of fields with pre-defined and fixed sizes. Locating a given field in the message is simply a matter of reading data from a fixed offset. The semantics of a field are known in advance to be either numeric (hexadecimal) data, string or an enumerated value. 
   An example of a prior-art routing protocol utilizing pre-defined fields with fixed sizes is OSPF Version 2, as defined by RFC 2328, “OSPF Version 2”, April 1998, The Internet Society. An example of a routing message from OSPF is shown in  FIG. 1 . In this encoding format, the example routing message  1  is made up of a number of pre-defined, fixed size fields. For example, the packet type 2 is determined by the second field, where a value of 1 indicates a hello packet. The size of a given field cannot grow without changing the version number 3, which affects backwards compatibility. Moreover, new fields cannot be added, since the hello message has a variable sized list of neighbors 4 (i.e. repeated neighbor fields) at the end of the message. The Packet length 5 is used to determine how many neighbor entries are present. 
   More recently defined protocols often make use of a more flexible encoding, known as Type-Length-Value (TLV). In these schemes, each message consists of a series of data elements, and each element contains a “type”(which identifies both the field and semantics of the data), a “size” specified in bytes (which allows more flexible parsing of a message, when the tag value is not known by the receiver), and a “value”(the actual data assigned being propagated by this element).  FIG. 2  shows an example TLV encoding in the prior art. The type field  11  is 1 octet, and indicates the type of information being encoded. Other names for field  11  is tag or code. The length field  12  indicates the number of octets which appears in the value field  13 . The length field  12  is one octet, and the value field  13  contains the number of octets indicated by the length field  12 . An example of a routing protocol using TLV encoding is IS-IS, as defined by RFC 1142, “OSI IS-IS Intra-domain Routing Protocol”, February 1990, the Internet Society. 
   An example IS-IS routing message utilizing TLVs is shown in  FIG. 3 , as per RFC 1195, “Use of OSI IS-IS for Routing in TCP/IP and Dual Environments”, December 1990, the Internet Society.  FIG. 3  shows an example routing message  15 , which is a “Level 1 Partial Sequence Numbers PDU”. In this message, the header portion  16  utilizes fixed field definitions similar to the OSPF example of  FIG. 1 . Field  17  indicates the number of octets in the header portion  16 . Field  18  indicates the number of octets in the entire PDU, and the lengh of the variable length fields  19  is determined by field  18  less field  17 . The variable length fields  19  is a sequence of TLV-encoded entries, with each entry using the format shown in  FIG. 2 . This method has similar limitations in the header portion, since fixed fields are utilized. However, the message is extensible through the use of variable length fields  19 , using TLV encodings. If the entire message had been encoded with TLVs, including the header portion, then the message would have even further flexibility as described above. 
   A fundamental requirement of all networking protocols is that they must be extensible. That is, all protocols evolve, and new fields are added to messages or the size of existing fields is changed. Protocols with fixed message formats typically include a “version” field, which is modified to indicate a change in the protocol specification. There is, of course, a problem with backwards compatibility, as software implemented for a previous version of the protocol can not interpret the new message format. 
   Protocols utilizing TLV encoding are somewhat better suited to dealing with this; as the message parsing code can be designed to ignore “types” that it doesn&#39;t understand (i.e. new message fields), and cope with “lengths” that it does not expect (although in many cases this coping is limited, for example, if a software module is designed to expect a 16 bit integer for some value, and instead receives a 32 bit value, it would be forced to truncate, likely introducing a protocol error). 
   A common interoperability problem introduced by fixed or TLV formatted messages is caused by the different “endian-ness” of various system architectures. Protocols are typically defined as being in “big-endian” format, meaning the most significant bits and bytes are sent first on the network. However, a sloppy implementation of a protocol on a “little-endian” system may lead to the opposite behavior. Often in this case, encoding problems are not detected until two systems of different endian-ness are tested. 
   Another side effect of both the fixed or TLV formatted messages, is the increased difficulty of debugging network problems. Network sniffers are a common debugging tool, but much of the value of the network sniffer is it is built in protocol parser; that is, its ability to convert from binary messages to human readable form. 
   SUMMARY OF THE INVENTION 
   In a broad aspect the invention provides a method of controlling communication networks including a plurality of network elements, comprising encoding control plane protocol messages using a markup language; and transferring said encoded messages between said network elements. 
   In one embodiment the invention employs an Implicit Routing Protocol (IRP), which consists of the XML Link State Protocol (XLSP) and the XML Subscription Management Protocol (XSMP), which routes customer data based on Extensible Markup Language (XML) content. The IRP consists of several messages that must be exchanged between XML routers in the network. The encoding of those messages is accomplished using XML, which ensures that the protocols are forward extensible. The use of XML also ensures that future versions of the protocol can be made backwards compatible with previously deployed systems. 
   The definition of XML encoded routing/networking protocol messages allow ease of forward extensibility. Future backwards compatibility of the protocol can be provided by allowing versioning information, and easily implemented parsing rules to be defined. 
   XML encoding eliminates “endian-ness” concerns from the realm of the protocol implementation (both message formatting and parsing). 
   The invention also provides an implicit routing protocol for content-based networks including a plurality of XML routers, comprising an XML Link State Protocol and an XML Subscription Management Protocol that routes customer data based on XML content, said XML Subscription Management Protocol comprising IRP (Implicit Routing Protocol) messages that must be exchanged between XML routers in the network, and said messages being encoded using XML. 
   The invention also provides a content router for use in a content routed network, said router being configured to exchange control messages containing control information with other content routers in the network, and said router further being configured to encode said control information using a markup language. 

   
     BRIEF DESCRIPTION OF THE DRAWING 
     The invention will now be described in more detail, by way of example only, with reference to the accompanying drawings, in which: 
       FIG. 1  shows an Example Prior Art Routing Message; 
       FIG. 2  shows an Example Prior Art TLV Encoding; 
       FIG. 3  shows an Example Prior Art Routing Message Using TLV; 
       FIG. 4  shows a Neighbor Acquisition Request Message; 
       FIG. 5  shows a Neighbor Acquisition Response Message; 
       FIG. 6  shows a Link State Packet Request Message; 
       FIG. 7  shows a Link State Packet Response Message; 
       FIG. 8  shows a Link State Database Description Request Message; 
       FIG. 9  shows a Link State Database Description Response Message; 
       FIG. 10  shows a Hello Packet Request Message; 
       FIG. 11  shows a Hello Packet Response Message; 
       FIG. 12  shows a Register XSMP Node Request Message; 
       FIG. 13  shows a Register XSMP Node Response Message; 
       FIG. 14  shows an XML Subscription Database Description Request Message; 
       FIG. 15  shows an XML Subscription Database Description Response Message; 
       FIG. 16  shows an XML Subscription Request Message; 
       FIG. 17  shows an XML Subscription Response Message; 
       FIG. 18  shows a Subscription Update Request Message (Router to Router); 
       FIG. 19  shows a Subscription Update Request Message (Subscriber to Router); 
       FIG. 20  shows a Subscription Update Response Message; 
       FIG. 21  shows an Add Subscriber Request Message; 
       FIG. 22  shows an Add Subscriber Response Message; 
       FIG. 23  shows a Remove Subscriber Request Message; 
       FIG. 24  shows a Remove Subscriber Response Message; and 
       FIG. 25  is a diagram of a typical content routed network. 
   

   DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
   The content routed network shown in  FIG. 25  comprises content routers  100  interconnected by links  120 . The network is connected to publishers  140  responsible for generating content, which is transferred to the subscribers  160  over the network. Control messages are exchanged between the network elements. 
   In accordance with embodiments of the invention the control messages are encoded using XML. A detailed explanation of XML can be found in “Extensible Markup Language (XML) 1.0 (Third Edition)”, W3C Recommendation 4 Feb. 2004, W3C (World Wide Web consortium) and “Extensible Markup Language (XML) 1.1”, W3C Recommendation 15 Apr. 2004, W3C, the contents of which are herein incorporated by reference. A description of IRP, including XLSP and XSMP, can be found in co-filed application Ser. No. 60/530,615, the contents of which are herein incorporated by reference. 
   The following general points describe how control messages between network elements are formatted in accordance with embodiments of the invention:
         1. The first XML tag in each IRP message reflects the type of the message.   2. The first XML tag in each IRP message includes an attribute indicating the version of the protocol. Versions are specified in the format {“version=x.y}”, where both x and y are numeric characters. See below for rules on versioning.   3. The remaining elements nested within an IRP message represent the fields of a given protocol message. Each element may optionally be tagged with attributes which define the parsing and backwards compatibility rules for that field:
           a. {mandatory =TRUE |FALSE}   
           4. Optionally, some fields may be omitted from a message. This is accomplished simply by not including the XML element corresponding to that field. The rule for which fields may be omitted is specific to a given protocol and message. Handling by the receiver of omitted fields is described below.       

   The complete list of XLSP messages and associated XML tag name is shown in Table 1 below: 
   
     
       
             
           
             
             
           
         
             
               TABLE 1 
             
           
           
             
                 
             
             
               XLSP Messages 
             
           
        
         
             
               XLSP Message 
               Outermost XML Tag Name 
             
             
                 
             
             
               Neighbor Acquisition Request 
               NaRequest 
             
             
               Neighbor Acquisition Response 
               NaReponse 
             
             
               Link State Packet Request 
               Lsp 
             
             
               Link State Packet Response 
               LspResponse 
             
             
               Link State Database Description Request 
               Lsdd 
             
             
               Link State Database Description Response 
               LsddResponse 
             
             
               Hello Packet Request 
               HelloPacket 
             
             
               Hello Packet Response 
               HelloPacketResponse 
             
             
                 
             
           
        
       
     
   
     FIG. 4  shows a sample Neighbor Acquisition Request Message  30 . The outermost tag  31  in the XML message is the tag “NaRequest”, which indicates the type of message as per Table 1 above. On the “NaRequest” element  31 , the attribute “version”  32  indicates that this message has a version number of “1.0”. Embedded elements, such as “senderId”  33 , provide the contents of the NaRequest message  30 . In the example element “senderId”  33 , the value is indicated by the attribute “val”  34 , with contents of “ROUTER_ENDPOINT:HTTP:192.168.1.1:8080”. The senderId  33  also has an attribute “mandatory”  35  with a value of “TRUE”, indicating that the “senderId”  33  is mandatory information. The components of the NaRequest message are shown in Table 2 below. 
   
     
       
             
           
             
             
             
             
           
         
             
               TABLE 2 
             
           
           
             
                 
             
             
               NaRequest Message Components 
             
           
        
         
             
               Tag 
               Attribute 
               Description 
               Mandatory? 
             
             
                 
             
             
               NaRequest 
                 
               Message&#39;s abbreviated name 
               Yes 
             
             
               requestId 
               val 
               Sequential request identifier 
               No 
             
             
               senderId 
               val 
               The sending router&#39;s unique id 
               Yes 
             
             
               priority 
               val 
               The router&#39;s priority (1 high −&gt; 
               No 
             
             
                 
                 
               4 low) 
             
             
               level 
               val 
               The tier level to which the router 
               No 
             
             
                 
                 
               belongs 
             
             
               deadTime 
               val 
               The router&#39;s dead time 
               No 
             
             
                 
             
           
        
       
     
   
     FIG. 5  shows a sample Neighbor Acquisition Response Message  38 . The outermost tag  37  is “NaResponse”, which indicates that this message is a Neighbor Acquisition Response. The “isAccepted” element  36  indicates whether the sender of the response message accepted the Neighbor Acquisition Request message. In this example, “isAccepted”  36  indicates that the request was accepted, since the value is 1 (a value of 0 indicates rejection). The components of the NaResponse message are shown in Table 3 below. 
   
     
       
             
           
             
             
             
             
           
         
             
               TABLE 3 
             
           
           
             
                 
             
             
               NaResponse Message Components 
             
           
        
         
             
                 
               Attri- 
                 
               Manda- 
             
             
               Tag 
               bute 
               Description 
               tory? 
             
             
                 
             
             
               NaResponse 
                 
               Message&#39;s abbreviated name 
               Yes 
             
             
               requestId 
               val 
               The corresponding request&#39;s requestId 
               No 
             
             
               isAccepted 
               val 
               Boolean value indicating if the 
               Yes 
             
             
                 
                 
               relationship has been accepted 
             
             
               senderId 
               val 
               The responding router&#39;s unique id 
               Yes 
             
             
               priority 
               val 
               The responding router&#39;s priority 
               No 
             
             
                 
                 
               (1 high −&gt; 4 low) 
             
             
               Level 
               val 
               The tier level to which the responding 
               No 
             
             
                 
                 
               router belongs 
             
             
               deadTime 
               val 
               The responding router&#39;s dead time 
               No 
             
             
                 
             
           
        
       
     
   
     FIG. 6  shows a sample Link State Packet Request Message  39 . The components of the Link State Packet Request Message  39  are shown in Table 4 below. 
   
     
       
             
           
             
             
             
             
           
         
             
               TABLE 4 
             
           
           
             
                 
             
             
               Link State Packet Request Message Components 
             
           
        
         
             
                 
               Attri- 
                 
               Manda- 
             
             
               Tag 
               bute(s) 
               Description 
               tory? 
             
             
                 
             
             
               Lsp 
                 
               Message&#39;s abbreviated name 
               Yes 
             
             
               RequestId 
               val 
               Sequential request identifier 
               No 
             
             
               senderId 
               val 
               The sending router&#39;s unique 
               Yes 
             
             
                 
                 
               id 
             
             
               sourceId 
               val 
               The router&#39;s unique id for 
               Yes 
             
             
                 
                 
               which the packet originated 
             
             
               sequenceNumber 
               val 
               The sequence number assigned 
               Yes 
             
             
                 
                 
               to the LSP by the source, 
             
             
                 
                 
               which is used to determine 
             
             
                 
                 
               whether a received LSP is 
             
             
                 
                 
               newer than an instance 
             
             
                 
                 
               previously received. 
             
             
               linkCosts 
                 
               Tag indicating a list of 
               No 
             
             
                 
                 
               zero or more link costs 
             
             
               linkCost 
               routerId, 
               The neighbouring router&#39;s 
               No 
             
             
                 
               cost 
               unique id along with the 
             
             
                 
                 
               link&#39;s cost 
             
             
                 
             
           
        
       
     
   
     FIG. 7  shows a sample Link State Packet Response Message  40 , which is sent in response to a received Link State Packet Request Message. The components of the Link State Packet Response Message  40  are shown in Table 5 below. 
   
     
       
             
           
             
             
             
             
           
         
             
               TABLE 5 
             
           
           
             
                 
             
             
               Link State Packet Response Message Components 
             
           
        
         
             
                 
               Attri- 
                 
                 
             
             
               Tag 
               bute 
               Description 
               Mandatory? 
             
             
                 
             
             
               LspResponse 
                 
               Message&#39;s abbreviated name 
               Yes 
             
             
               requestId 
               val 
               The corresponding request&#39;s 
               No 
             
             
                 
                 
               requestId 
             
             
               senderId 
               val 
               The responding router&#39;s unique 
               Yes 
             
             
                 
                 
               id 
             
             
               sourceId 
               val 
               The source router id as 
               Yes 
             
             
                 
                 
               specified in the request 
             
             
               sequenceNumber 
               val 
               The corresponding request&#39;s 
               Yes 
             
             
                 
                 
               sequence number 
             
             
                 
             
           
        
       
     
   
     FIG. 8  shows a sample Link State Database Description Request Message  41 . Notice that this message contains many nested and repeated elements. XML encoding of routing messages allows any level of element nesting, repeated elements, etc. to be handled in a flexible and expandable manner. For example, the top-level tag “Lsdd”  47  contains a number of nested elements, such as “LinkStatePackets”  42 . “LinkStatePackets”  42  itself contains a plurality of nested “Lsp” elements  43 . The structure allows for any number of nested “Lsp” elements  43  to be present, which is required by the XLSP routing protocol. Within each “Lsp” element  43 , there are further nested elements, such as “LinkCosts”  45 . “LinkCosts”  45  itself has a plurality of nested “linkCost” elements  46 . The nesting described above allows a given Link State Database Description Message  41  to contain a plurality of “Lsp” information  43 , and each “Lsp” information  43  can contain a plurality of “linkCost” information  46 . This allows the Link State Database Description Mesasge  41  to carry “Lsp” information about a number of XLSP nodes, and for each XLSP node, all the link information for that node can be carried. Using XML as an encoding scheme allows for complex data relationships to be easily modeled and exchanged between routers, as opposed to the prior art routing message encoding schemes of using fixed structures or TLV encodings. The components of the Link State Database Description Request Message  41  are shown in Table 5 below. 
   
     
       
             
           
             
             
             
             
           
         
             
               TABLE 6 
             
           
           
             
                 
             
             
               Link State Database Description Request Message Components 
             
           
        
         
             
                 
               Attri- 
                 
                 
             
             
               Tag 
               bute(s) 
               Description 
               Mandatory? 
             
             
                 
             
             
               Lsdd 
                 
               Message&#39;s abbreviated name 
               Yes 
             
             
               requestId 
               val 
               Sequential request identifier 
               No 
             
             
               senderId 
               val 
               The sending router&#39;s unique id 
               Yes 
             
             
               LinkStatePackets 
                 
               Tag indicating a list of zero or 
               No 
             
             
                 
                 
               more link state packets 
             
             
               Lsp 
                 
               Start tag for a link state 
               No 
             
             
                 
                 
               packet (refer to Link State 
             
             
                 
                 
               Packet Request in Table 4 
             
             
                 
                 
               above.) 
             
             
                 
             
           
        
       
     
   
     FIG. 9  shows a sample Link State Database Description Response Message  50 , which is sent in response to a received Link State Database Description Request Message. The components of the Link State Database Description Response Message  50  are shown Table 7 below. 
   
     
       
             
           
             
             
             
             
           
         
             
               TABLE 7 
             
           
           
             
                 
             
             
               Link State Database Description Response Message Components 
             
           
        
         
             
               Tag 
               Attribute 
               Description 
               Mandatory? 
             
             
                 
             
             
               LsddResponse 
                 
               Message&#39;s abbreviated name 
               Yes 
             
             
               requestId 
               val 
               The corresponding request&#39;s 
               No 
             
             
                 
                 
               requestId 
             
             
               senderId 
               val 
               The responding router&#39;s 
               Yes 
             
             
                 
                 
               unique id 
             
             
                 
             
           
        
       
     
   
     FIG. 10  shows a sample Hello Packet Request Message  51 . The components of the Hello Packet Request Message  51  are shown in Table 8 below. 
   
     
       
             
           
             
             
             
             
           
         
             
               TABLE 8 
             
           
           
             
                 
             
             
               Hello Packet Request Message Components 
             
           
        
         
             
               Tag 
               Attribute(s) 
               Description 
               Mandatory? 
             
             
                 
             
             
               HelloPacket 
                 
               Message&#39;s abbreviated name 
               Yes 
             
             
               requestId 
               val 
               Sequential request identifier 
               No 
             
             
               senderId 
               val 
               The sending router&#39;s unique id 
               Yes 
             
             
                 
             
           
        
       
     
   
     FIG. 11  shows a sample Hello Packet Response Message  52 , which is sent in response to a Hello Packet Request Message. The components of the Hello Packet Response Message  52  are shown in Table 9 below. 
   
     
       
             
           
             
             
             
             
           
         
             
               TABLE 9 
             
           
           
             
                 
             
             
               Hello Packet Response Message Components 
             
           
        
         
             
                 
               Attri- 
                 
                 
             
             
               Tag 
               bute 
               Description 
               Mandatory? 
             
             
                 
             
             
               HelloPacketResponse 
                 
               Message&#39;s abbreviated 
               Yes 
             
             
                 
                 
               name 
             
             
               requestId 
               val 
               The corresponding 
               No 
             
             
                 
                 
               request&#39;s requestId 
             
             
               senderId 
               val 
               The responding router&#39;s 
               Yes 
             
             
                 
                 
               unique id 
             
             
                 
             
           
        
       
     
   
   The complete list of XSMP messages and associated XML tag name is shown in Table 10 below: 
   
     
       
             
           
             
             
           
         
             
               TABLE 10 
             
           
           
             
                 
             
             
               XSMP Messages 
             
           
        
         
             
               XSMP Message 
               Outermost XML Tag Name 
             
             
                 
             
             
               Register XSMP Node Request 
               RegisterXsmpNode 
             
             
               Register XSMP Node Response 
               RegisterXsmpNodeResponse 
             
             
               XML Subscription Database Description 
               Xsdd 
             
             
               Request 
             
             
               XML Subscription Database Description 
               XsddResponse 
             
             
               Response 
             
             
               XML Subscription Request 
               Xsr 
             
             
               XML Subscription Response 
               XsrResponse 
             
             
               Subscription Update Request 
               SubscriptionUpdate 
             
             
               Subscription Update Response 
               SubscriptionUpdateResponse 
             
             
               Add Subscriber Request 
               AddSubscriber 
             
             
               Add Subscriber Response 
               AddSubscriberResponse 
             
             
               Remove Subscriber Request 
               RemoveSubscriber 
             
             
               Remove Subscriber Response 
               RemoveSubscriberResponse 
             
             
                 
             
           
        
       
     
   
     FIG. 12  shows a sample Register XSMP Node Request Message  53 . Note the use of nested “XsmpNodeInfo” elements  54 , which themselves contain nested elements. The components of the Register XSMP Node Request Message  53  are shown in Table 11 below. 
   
     
       
             
           
             
             
             
             
           
         
             
               TABLE 11 
             
           
           
             
                 
             
             
               Register XSMP Node Request Message Components 
             
           
        
         
             
                 
               Attri- 
                 
               Manda- 
             
             
               Tag 
               bute(s) 
               Description 
               tory? 
             
             
                 
             
             
               RegisterXsmpNode 
                 
               Message&#39;s abbreviated name 
               Yes 
             
             
               senderId 
               val 
               The sending endpoint&#39;s unique 
               No 
             
             
                 
                 
               id 
             
             
               XsmpNodeList 
                 
               Indicate the beginning of a 
               No 
             
             
                 
                 
               list of xsmp nodes 
             
             
               XsmpNodeInfo 
                 
               Start tag for information 
               No 
             
             
                 
                 
               about an xsmp node 
             
             
               nodeId 
               val 
               The Xsmp node&#39;s unique id 
               No 
             
             
                 
             
           
        
       
     
   
     FIG. 13  shows a sample Register XSMP Node Response Message  55 , which is sent in response to a received Register XSMP Node Request Message. The components of the Register XSMP Node Response Message  55  are shown in Table 12 below. 
   
     
       
             
           
             
             
             
             
           
         
             
               TABLE 12 
             
           
           
             
                 
             
             
               Register XSMP Node Response Message Components 
             
           
        
         
             
                 
               Attri- 
                 
               Manda- 
             
             
               Tag 
               bute(s) 
               Description 
               tory? 
             
             
                 
             
             
               RegisterXsmpNodeResponse 
                 
               Message&#39;s abbreviated 
               Yes 
             
             
                 
                 
               name 
             
             
               senderId 
               val 
               The responding 
               Yes 
             
             
                 
                 
               router&#39;s id 
             
             
               isOk 
               val 
               Boolean value indi- 
               Yes 
             
             
                 
                 
               cating whether the 
             
             
                 
                 
               registration was 
             
             
                 
                 
               successful or not 
             
             
                 
             
           
        
       
     
   
     FIG. 14  shows a sample XML Subscription Database Description Request Message  56 . Note the use of nested “XsdbRowDescription” elements  57 , which themselves contain nested elements. The components of the XML Subscription Database Description Request Message  56  are shown in Table 13 below. 
   
     
       
             
           
             
             
             
             
           
         
             
               TABLE 13 
             
           
           
             
                 
             
             
               XML Subscription Database Description 
             
             
               Request Message Components 
             
           
        
         
             
                 
               Attri- 
                 
               Manda- 
             
             
               Tag 
               bute(s) 
               Description 
               tory? 
             
             
                 
             
             
               Xsdd 
                 
               Message&#39;s abbreviated name 
               Yes 
             
             
               senderId 
               val 
               The sending router&#39;s id 
               Yes 
             
             
               XsddRows 
                 
               Tag indicates beginning of 
               Yes 
             
             
                 
                 
               the list of row descriptions 
             
             
               XsdbRowDescription 
                 
               Tag indicates beginning of a 
               Yes 
             
             
                 
                 
               row description 
             
             
               nodeId 
               val 
               The router id whose XML 
               Yes 
             
             
                 
                 
               Subscription Database 
             
             
                 
                 
               (XSDB) row is being 
             
             
                 
                 
               described 
             
             
               firstSeqNum 
               val 
               The sequence number of 
               Yes 
             
             
                 
                 
               the first message in XSDB 
             
             
               lastSeqNum 
               val 
               The sequence number of 
               Yes 
             
             
                 
                 
               the last message in XSDB 
             
             
                 
             
           
        
       
     
   
     FIG. 15  shows a sample XML Subscription Database Description Response Message  58 , which is sent in response to a received XML Subscription Database Description Request Message. The components of the XML Subscription Database Description Response Message  58  are shown in Table 14 below. 
   
     
       
             
           
             
             
             
             
           
         
             
               TABLE 14 
             
           
           
             
                 
             
             
               XML Subscription Database Description 
             
             
               Response Message Components 
             
           
        
         
             
                 
               Attri- 
                 
               Manda- 
             
             
               Tag 
               bute(s) 
               Description 
               tory? 
             
             
                 
             
             
               XsddResponse 
                 
               Message&#39;s abbreviated name 
               Yes 
             
             
               senderId 
               val 
               The responding router&#39;s id 
               Yes 
             
             
               isOk 
               val 
               Boolean value indicating whether 
               Yes 
             
             
                 
                 
               the database description was 
             
             
                 
                 
               processed successfully or not 
             
             
                 
             
           
        
       
     
   
     FIG. 16  shows a sample XML Subscription Request Message  59 . Note the use of nested “XsmpUpdateRequest” elements  60 , which themselves contain nested elements. The components of the XML Subscription Request Message  59  are shown in Table 15 below. 
   
     
       
             
           
             
             
             
             
           
         
             
               TABLE 15 
             
           
           
             
                 
             
             
               XML Subscription Request Message 
             
           
        
         
             
                 
               Attri- 
                 
               Manda- 
             
             
               Tag 
               bute(s) 
               Description 
               tory? 
             
             
                 
             
             
               Xsr 
                 
               Message&#39;s abbreviated name 
               Yes 
             
             
               senderId 
               val 
               The sending router&#39;s id 
               Yes 
             
             
               reqNodeInfo 
               val 
               Boolean flag indicating 
               Yes 
             
             
                 
                 
               interest in node information 
             
             
               reqXsdd 
               val 
               Boolean flag indicating 
               Yes 
             
             
                 
                 
               interest in a nodes XSDD 
             
             
               requests 
                 
               Tag indicates beginning of 
               Yes 
             
             
                 
                 
               the list of requests 
             
             
               XsmpUpdateRequest 
                 
               Tag indicates beginning of a 
               Yes 
             
             
                 
                 
               request 
             
             
               nodeId 
               val 
               The router id whose XSDB 
               Yes 
             
             
                 
                 
               row is being requested 
             
             
               firstSeqNum 
               val 
               The sequence number of the 
               Yes 
             
             
                 
                 
               first message being requested 
             
             
               lastSeqNum 
               val 
               The sequence number of the 
               Yes 
             
             
                 
                 
               last message being requested 
             
             
                 
             
           
        
       
     
   
     FIG. 17  shows a sample XML Subscription Response Message  61 , which is sent in response to a received XML Subscription Request Message. The components of the XML Subscription Response Message  61  are shown in Table 16 below. 
   
     
       
             
           
             
             
             
             
           
         
             
               TABLE 16 
             
           
           
             
                 
             
             
               XML Subscription Response Message 
             
           
        
         
             
                 
               Attri- 
                 
                 
             
             
               Tag 
               bute(s) 
               Description 
               Mandatory? 
             
             
                 
             
             
               XsrResponse 
                 
               Message&#39;s abbreviated name 
               Yes 
             
             
               senderId 
               val 
               The responding router&#39;s id 
               Yes 
             
             
               isOk 
               val 
               Boolean value indicating whether 
               Yes 
             
             
                 
                 
               the request was fulfilled 
             
             
                 
                 
               successfully or not 
             
             
                 
             
           
        
       
     
   
     FIG. 18  shows a sample Subscription Update Request Message  62 . Note that within the “PacketList” element  63 , there can exist a plurality of “NameSpacePacket” elements  64  and a plurality of “SubscriptionPacket” elements  65 . Within a “NamespacePacket” element  64 , the “prefix” element  66  indicates a unique namespace prefix name, and the “namepace” element  67  indicates the namespace name that is assigned to the prefix. In this example, the prefix “pref1” defined in element  66  is mapped to the namespace “www.pref1.com” in element  67 . Refer to “Namespaces in XML”, W3C Recommendation 14 Jan. 1999, World Wide Web Consortium (W3C) and “Namespaces in XML 1.1”, W3C Recommendation 4 Feb. 2004, World Wide Web Consortium (W3C). This allows prefixes to be assigned to namespaces for use in XPath expressions as part of subscriptions. In the “SubscriptionPacket”  65 , the “subscription” element  68  contains an “xpe” attribute that defines the subscription string “/pref1:x/y/z”. Note that “xpe” refers to “XPath Expression”. Refer to “XML Path Language (XPath) Version 1.0”, W3C Recommendation 16 Nov. 1999, World Wide Web Consortium (W3C). This subscription uses the previously defined prefix “pref1”. This scheme allows the sending router to send a shared set of prefix definitions which can be used across a large set of subscriptions. The components of the Subscription Update Request Message  62  are shown in Table 17 below. This version of the message is used from one XML router to another XML router. 
   
     
       
             
           
             
             
             
             
           
         
             
               TABLE 17 
             
           
           
             
                 
             
             
               Subscription Update Request Message (Router to Router) 
             
           
        
         
             
                 
               Attri 
                 
               Manda- 
             
             
               Tag 
               bute(s) 
               Description 
               tory? 
             
             
                 
             
             
               SubscriptionUpdate 
                 
               Message&#39;s abbreviated name 
               Yes 
             
             
               senderId 
               val 
               The sending router&#39;s id 
               No 
             
             
               subscriberId 
               val 
               The id of the router for which 
               Yes 
             
             
                 
                 
               the update applies 
             
             
               xsdbFirstSeqNum 
               val 
               The sequence number of the 
               Yes 
             
             
                 
                 
               first packet in the XSDB (XML 
             
             
                 
                 
               Subscription Database) 
             
             
               xsdbLastSeqNum 
               val 
               The sequence number of the last 
               Yes 
             
             
                 
                 
               packet in the XSDB 
             
             
               PacketList 
                 
               Tag indicates beginning of the 
               Yes 
             
             
                 
                 
               list of update packets 
             
             
               NamespacePacket 
                 
               Tag indicates beginning of a 
               No 
             
             
                 
                 
               namespace packet 
             
             
               addFlag 
               val 
               Boolean indicating whether to 
               No 
             
             
                 
                 
               add (1) or remove (0) the 
             
             
                 
                 
               namespace (default is 1). 
             
             
               prefix 
               val 
               The prefix to be associated 
               Yes 
             
             
                 
                 
               with the following namespace 
             
             
               namespace 
               val 
               The namespace associated with 
               Yes 
             
             
                 
                 
               the prefix 
             
             
               seqNum 
               val 
               The update packet&#39;s sequence 
               Yes 
             
             
                 
                 
               number 
             
             
               prevSeqNum 
               val 
               The sequence number of the 
               Yes 
             
             
                 
                 
               preceding update packet 
             
             
               SubscriptionPacket 
                 
               Tag indicates beginning of a 
               No 
             
             
                 
                 
               subscription packet 
             
             
               addFlag 
               val 
               Boolean indicating whether to 
               No 
             
             
                 
                 
               add (1) or remove (0) the 
             
             
                 
                 
               namespace (default is 1). 
             
             
               isFilter 
               val 
               Boolean indicating whether 
               No 
             
             
                 
                 
               subscription acts as a filter 
             
             
                 
                 
               (never forward matches) or 
             
             
                 
                 
               not (default is 0). 
             
             
                 
                 
               Filters are never propagated 
             
             
                 
                 
               between routers. 
             
             
               subscription 
               xpe 
               The subscription in the form 
               Yes 
             
             
                 
                 
               of an XPath string 
             
             
               seqNum 
               val 
               The update packet&#39;s sequence 
               Yes 
             
             
                 
                 
               number 
             
             
               prevSeqNum 
               val 
               The sequence number of the 
               Yes 
             
             
                 
                 
               preceding update packet 
             
             
                 
             
           
        
       
     
   
     FIG. 19  shows a sample Subscription Update Request Message  70 , which is used from a subscriber to an XML router (as opposed to the version above which is used between XML routers). This message can contain a plurality of SubscriptionPacket elements  71 , each of which describes one subscription being updated (either added or removed). Within the SubscriptionPacket element  71 , the subscription element  72  defines both XML namespaces  73  (of which there can be a plurality or none, and only relate to the subscription element  72 ) and an xpe  74 . In the example subscription element  72 , two namespaces have been defined (prefixes “sol” and “google”) and used in the xpe  74 . In the example subscription element  75 , no namespaces have been defined as the xpe  76  does not use any. While the SubscriptionUpdate message  70  from a subscriber to an XML router does not use a separate definition of namespaces as in message  62  of  FIG. 18 , that technique could also be used in the messaging from subscribers if there is a number of namespace definitions that could be shared across a large number of subscriptions from a single subscriber. The components of the Subscription Update Request Message  70  used from subscribers to the router are shown in Table 18 below. 
   
     
       
             
           
             
             
             
             
           
         
             
               TABLE 18 
             
           
           
             
                 
             
             
               Subscription Update Request Message (Subscriber to Router) 
             
           
        
         
             
                 
                 
                 
               Manda- 
             
             
               Tag 
               Attribute(s) 
               Description 
               tory? 
             
             
                 
             
             
               SubscriptionUpdate 
                 
               Packets abbreviated name 
               Yes 
             
             
               senderId 
               val 
               The sending endpoint&#39;s 
               No 
             
             
                 
                 
               unique id 
             
             
               subscriberId 
               val 
               The id of the subscriber 
               Yes 
             
             
                 
                 
               for which the update 
             
             
                 
                 
               applies 
             
             
               PacketList 
                 
               Tag indicates beginning of 
               Yes 
             
             
                 
                 
               the list of update packets 
             
             
               SubscriptionPacket 
                 
               Tag indicates beginning 
               Yes 
             
             
                 
                 
               of a subscription packet 
             
             
               addFlag 
               val 
               Boolean indicating whether 
               No 
             
             
                 
                 
               to add (1) or remove (0) 
             
             
                 
                 
               the subscription (default 
             
             
                 
                 
               is 1). 
             
             
               isFilter 
               val 
               Boolean indicating whether 
               No 
             
             
                 
                 
               subscription acts as a 
             
             
                 
                 
               filter (never forward 
             
             
                 
                 
               matches) or not (default 
             
             
                 
                 
               is 0, i.e. not a filter) 
             
             
               subscription 
               Xpe, 
               The subscription in the 
               Yes 
             
             
                 
               namespace 
               form of an Xpath string 
             
             
                 
               definitions 
               with namespace 
             
             
                 
                 
               definitions (if applicable) 
             
             
                 
             
           
        
       
     
   
     FIG. 20  shows a sample Subscription Update Response Message  80 , which is sent in response to a received Subscription Update Request Message (from a router or a subscriber, i.e. a response to message  62  of  FIG. 18  or message  70  of  FIG. 19 ). The components of the Subscription Update Response Message  80  are shown in Table 19 below. 
   
     
       
             
           
             
             
             
             
           
         
             
               TABLE 19 
             
           
           
             
                 
             
             
               Subscription Update Response Message 
             
           
        
         
             
                 
               Attri- 
                 
               Manda- 
             
             
               Tag 
               bute(s) 
               Description 
               tory? 
             
             
                 
             
             
               SubscriptionUpdateResponse 
                 
               Message&#39;s abbreviated 
               Yes 
             
             
                 
                 
               name 
             
             
               senderId 
               val 
               The responding 
               Yes 
             
             
                 
                 
               router&#39;s id 
             
             
               isOk 
               val 
               Boolean value indi- 
               Yes 
             
             
                 
                 
               cating whether the 
             
             
                 
                 
               update packets were 
             
             
                 
                 
               all processed 
             
             
                 
                 
               successfully or not 
             
             
                 
             
           
        
       
     
   
     FIG. 21  shows a sample Add Subscriber Request Message  81 . The components of the Add Subscriber Request Message  81  are shown in Table 20 below. This message is sent by subscribers of the XML router to the XML router. 
   
     
       
             
           
             
             
             
             
           
         
             
               TABLE 20 
             
           
           
             
                 
             
             
               Add Subscriber Request Message 
             
           
        
         
             
                 
               Attri- 
                 
               Manda- 
             
             
               Tag 
               bute(s) 
               Description 
               tory? 
             
             
                 
             
             
               AddSubscriber 
                 
               Message&#39;s abbreviated name 
               Yes 
             
             
               senderId 
               val 
               The sending endpoint&#39;s unique id 
               No 
             
             
               username 
               val 
               The new subscriber&#39;s username 
               No 
             
             
               password 
               val 
               The new subscriber&#39;s password 
               No 
             
             
               address 
               val 
               The new subscriber&#39;s network 
               Yes 
             
             
                 
                 
               address 
             
             
               name 
               val 
               The new subscriber&#39;s name 
               Yes 
             
             
                 
             
           
        
       
     
   
     FIG. 22  shows a sample Add Subscriber Response Message  82 . The components of the Add Subscriber Response Message  82  are shown in Table 21 below. This message is sent by the XML router back to a subscriber of the XML router in response to a received Add Subscriber Request Message. 
   
     
       
             
           
             
             
             
             
           
         
             
               TABLE 21 
             
           
           
             
                 
             
             
               Add Subscriber Response Message 
             
           
        
         
             
                 
               Attri- 
                 
               Manda- 
             
             
               Tag 
               bute(s) 
               Description 
               tory? 
             
             
                 
             
             
               AddSubscriberResponse 
                 
               Message&#39;s abbreviated 
               Yes 
             
             
                 
                 
               name 
             
             
               senderId 
               val 
               The responding router&#39;s 
               Yes 
             
             
                 
                 
               unique id 
             
             
               isOk 
               val 
               Boolean value indicating 
               Yes 
             
             
                 
                 
               whether the new 
             
             
                 
                 
               subscriber was created 
             
             
                 
                 
               or not 
             
             
                 
             
           
        
       
     
   
     FIG. 23  shows a sample Remove Subscriber Request Message  83 . The components of the Remove Subscriber Request Message  83  are shown in Table 22 below. This message is sent by subscribers of the XML router to the XML router. 
   
     
       
             
           
             
             
             
             
           
         
             
               TABLE 22 
             
           
           
             
                 
             
             
               Remove Subscriber Request Message 
             
           
        
         
             
                 
               Attri- 
                 
               Manda- 
             
             
               Tag 
               bute(s) 
               Description 
               tory? 
             
             
                 
             
             
               RemoveSubscriber 
                 
               Packets abbreviated name 
               Yes 
             
             
               senderId 
               val 
               The sending endpoint&#39;s unique 
               No 
             
             
                 
                 
               id 
             
             
               username 
               val 
               The subscriber&#39;s username 
               No 
             
             
               password 
               val 
               The subscriber&#39;s password 
               No 
             
             
               subscriberId 
               val 
               The id of the subscriber to 
               Yes 
             
             
                 
                 
               remove 
             
             
                 
             
           
        
       
     
   
     FIG. 24  shows a sample Remove Subscriber Response Message  84 . The components of the Remove Subscriber Response Message  84  are shown in Table 23 below. This message is sent by the XML router back to a subscriber of the XML router in response to a received Remove Subscriber Request Message. 
   
     
       
             
           
             
             
             
             
           
         
             
               TABLE 23 
             
           
           
             
                 
             
             
               Remove Subscriber Response Message 
             
           
        
         
             
                 
               Attri- 
                 
               Manda- 
             
             
               Tag 
               bute(s) 
               Description 
               tory? 
             
             
                 
             
             
               RemoveSubscriberResponse 
                 
               Packets abbreviated 
               Yes 
             
             
                 
                 
               name 
             
             
               senderId 
               val 
               The responding 
               Yes 
             
             
                 
                 
               router&#39;s unique 
             
             
                 
                 
               id 
             
             
               isOk 
               val 
               Boolean value indi- 
               Yes 
             
             
                 
                 
               cating whether the 
             
             
                 
                 
               subscriber was 
             
             
                 
                 
               deleted or not 
             
             
                 
             
           
        
       
     
   
   When parsing an IRP protocol message, the following rules must be implemented by the receiver to ensure backwards and forwards compatibility:
         1. If the first (outermost) element (the message type) is not a recognized message for the protocol (XLSP or XSMP), the message is discarded. The mandatory attribute, if present on the outermost element, can be used to indicate whether the sender indicates this message is mandatory or not to support. Receipt of a non-understood mandatory message indicates a protocol error.   2. The {“version=x.y”} attribute must be present in the first element, and is compared to the protocols own internal version number, p.q, as follows:
           a. If x.y=p.q, then the protocol versions are the same (both the major version portion x and the minor version portion y).   b. If x&gt;p, then the received message is of a higher major version than that supported by the receiving node, indicating a non-backwards compatible change to the protocol. The receiver must discard the message, and preferentially produce a log or alarm to indicate that a version mismatch exists.   c. If x&lt;p, then the received message is of an older version number than what the node supports, but the major version number has been changed, indicating a major change to the protocol which is not backwards compatible. The receiver must discard the message, and preferentially produce a log or alarm to indicate that a version mismatch exists.   d. if x=p and q&gt;y, then the received message is older than the local implementation, and backwards compatibility rules exist for interpreting and handling the message.   e. If x=p and y&gt;q, then the received message is newer than the local implementation (but the major version numbers are the same), and the receiver will attempt to parse the message, obeying the rules given in the next two points.   
           3. If a received field is unknown by the receiver (that is, the XML element name is not recognized), handling of the message is dependent on the {“mandatory=”} attribute:
           a. If the field contains a {“mandatory=FALSE”} attribute, or the {“mandatory”} attribute is omitted, then the receiver ignores the field, but parses the remainder of the message as normal.   b. If the field contains a {“mandatory=TRUE”} attribute, then the receiver must discard the message.   
           4. If a particular message field is omitted by the sender, then the action of the receiver is defined by its internal {“mandatory”} attribute for that field (ie stored in an internal data dictionary).
           a. If the field is tagged as {“mandatory=FALSE”}, then the receiver assigns a suitable default value to the field.   b. If the field is tagged as {“mandatory=TRUE”} attribute, then the receiver must discard the message.   
               

   It should be noted that in the example messages, the first element (the one that defines the message type, such as element  31  of  FIG. 4 ) can also carry the mandatory attribute like any other element. This can indicate to the receiver whether it is a protocol error or not that this new message which is not understood is being discarded. 
   When a message is discarded, if the message was a request message that is understood by the receiver, then a response message can optionally be sent back indicating that the request message was rejected. The way in which this is done depends upon the exact syntax of the response message. For example, the response message may have an “isOk” tag to carry whether the request message was processed successfully or not. 
   Note that other encoding schemes of protocol messages are also possible using XML. For example, instead of the outermost XML element indicating the message type, an attribute can carry the message type. It will be appreciated by those skilled in the art that numerous XML encoding schemes can be used to achieve the same result. Also, namespaces could be used for some or all of the XML message tags, including the message type. 
   An exemplary embodiment of the invention has been described. It will be appreciated by persons skilled in the art that many variants are possible within the scope of the invention. 
   All references mentioned above are herein incorporated by reference. Reference has been made herein to copending provisional applications, which are incorporated by reference. Such incorporation by reference should also be taken to include the non-provisional applications based thereon whose serial numbers will be inserted when they become available.