A High-Performance Architecture of an XML Processor For SIP-based Presence
Fadi El-Hassan, Raymond Peterkin, Mohamed Abou-Gabal, Dan Ionescu
School of Information Technology and Engineering (SITE)
University of Ottawa
800 King Edward Av., Ottawa, ON, Canada
With the widespread popularity of XML, many communica-
tion and multimedia standards are being developed based
completely or partially on XML. The Session Initiation Pro-
tocol is a signaling mechanism - frequently used for Mul-
timedia applications - that comprises XML-based “pres-
ence” information particularly useful in Instance Messag-
ing. Theprocess ofXMLparsingandserializationisneeded
repeatedly during the exchange of presence notification
messages in such systems. However, XML processing is
known to be time-consuming. In instant messaging systems,
especially when mobile users are involved, presence update
notification is frequent and has to be fast to save mobility
time andbattery resources. In this paper,we present a high-
performance architecture of an XML processor customized
for efficiently processing presence information. Our FPGA
implementation results show that at least two bytes of XML
data can be parsed on average in each clock cycle, which
leads eventually to a high-throughputprocessor.
Key Words: XML Parsing, XML Serialization, SIP, Pres-
1. Introduction and Background
In Internet Protocol (IP) networks, the Session Initiation
Protocol (SIP)  has gained much attention as the signal-
ing protocol of choice for establishing sessions in multime-
dia applications such as Voice over IP (VoIP), Instant Mes-
saging (IM), and presence notification. In a network, the
presence status of a user, device, or a service is published
by its presence entity called presentity . Devices could
be, for example, cell phones, PDAs, or laptops. Services
couldbe a softphoneora videophoneapplication,IM,Short
Message Service (SMS), or Multimedia Message Service
(MMS). A watcher sends a SUBSCRIBE message asking
for an update on the presence status of a specific entity. Ac-
cordingly, this watcher receives NOTIFY messages about
the presence of the specified entity. If the presence status
changes considerably over time, NOTIFY messages are to
be sent frequentlyto the subscriber. The presencestatus can
be represented in its basic form as either “closed” to indi-
cate unavailability or “open” to indicate the opposite .
In SIP-based presence, The Internet Engineering Task
Force (IETF) standardized the first XML-based presence
format called Presence Information Data Format (PIDF)
. Extensions to PIDF, such as Rich Presence Exten-
sions to the Presence Information Data Format (RPID) ,
were followed. In the SIP notification process, a NOTIFY
message carries the XML-based presence information of a
presentity and sends it to a corresponding subscriber. Upon
reception, the receiver resources, that include an XML pro-
cessor, parse the SIP NOTIFY message along with its at-
tached XML-based presence. Figure 1 illustrates the SIP
presence basic mechanism.
P U B L I S H
S U B S C R I B E
N O T I F Y
Figure 1. SIP-based Presence Mechanism
A general software-based XML parser such as SAX,
StAX, or DOM can be used. When frequent notifications
are needed, processing of the carried presence information
lead to a scalability issue. For a number of resources that
a single watcher may have subscribed to, each of the cor-
responding presentities can send to that single subscriber
an XML-based PIDF/RPID document every time any of
its presence information varies. The scalability issue can
become worse due to limited memory and processing re-
sources and short battery lifetime of a target such as a mo-
bile device. Therefore, faster notification-message process-
ing is sought. While some solutions try to enhance the han-
dling of notification messages, from the bandwidth point-
of-view or at the level of the presence server itself, other
solutions seek software or hardwaremechanisms at the pro-
At the bandwidth and server level, some mechanisms
aimed to reduce the volume of notifications such as load-
sharing , Resource List Server (RLS) , partial notifi-
cation , and SIP messages compression .
In the software-based processing level, in addition to
SAX, StAX, and DOM parsers, other techniques such as
schema-specific XML parsing  and parallel processing
(e.g. ) were reported in literature to be faster than gen-
eral XML parsing techniques.
in literature such as , where a programmable state ma-
performance results are reported.
In this paper, a hardware-based XML processor is de-
signed to specifically parse and serialize presence informa-
tion with high-performance. The proposed XML processor
offloads the XML part of notification messages from SIP
stack, which results in higher performance and higher pro-
The rest of the paper is organized as follows. Section 2
describes PIDF and provides an example of its use. A high-
level description of the proposed XML processor is given
in section 3, followed by a detailed description of differ-
ent modules and state machines in section 4. Since most
modules and state machines are similar in parsing and se-
rialization processes, section 5 identifies these similarities.
Results of our XML processing approach are discussed in
section 6. Finally, a conclusion is stated in section 7.
2. Presence Information Data Format
As mentioned earlier, the basic form of the SIP-based
presence is the XML-based PIDF standardized by IETF
. Taking a look at the PIDF example in Figure 2, the
reader can see the kind of presence information carried by
SIP notification messages.
This standard includes an XML element called “tuple”
under which a basic presence status is defined as either
“open” or “closed” to indicate availability (message accep-
tance) or unavailability (non message-acceptance) of spe-
cific users, devices, or services. Since more than one tuple
may exist in the PIDF document, a unique id is given for
each tuple. In addition, PIDF can contain contact address,
timestamp, notes, and other optional information. The ex-
tensible nature of XML provided PIDF the opportunity for
expansion, which was eventually the case in subsequent
IETF works (e.g. ,). The presentity URI consists of
the value of the attribute “entity” as indicated in the third
line of the example in Figure 2.
<xml version="1.0" encoding="UTF-8"?>
Figure 2. Presence Information Data Format
Note that the PIDF document may appear in a SIP PUB-
a SIP NOTIFY message to notify watchers who subscribed
to get such presence information.
3. Architecture Overview
The XML processor’s main task is to process the XML-
based presence information in either a SIP NOTIFY or a
PUBLISH message. Figure 2 shows an example of PIDF
SIP presence. To offload the XML part of a SIP mes-
sage during both transmission and reception, two process-
ing mechanisms must run simultaneously: one for serializ-
ing presence data into XML PIDF and the other for parsing
an XML PIDF document. These two processes are particu-
larly needed in the SIP presence server in order to achieve
high-performance processing. In addition, end users may
want to receive presence information of an entity and pub-
lish theirownpresenceat the same time. Theblockdiagram
of the XML processor is shown in Figure 3.
In this architecture, four dual-port memory modules al-
low simultaneous read and write operations that can be per-
formed by two internal processors as well as by the outside
interface. While an XML PIDF document is being written
via oneportof a memorymodule,the otherportcan beused
in reading the document after a slight latency period. Si-
multaneous writing and reading of XML data is performed
in the upperleft memorymodulein the parsingprocess, and
in the bottom right memory module in the serialization pro-
cess. At the same time, a presence information update of
another entity is written via one port of a memory module,
and accessed after a slight latency period via the other port
of the memory module. Simultaneous writing and reading
of such informationis performedin the upper right memory
module in the serialization process, and in the bottom left
memory module in the parsing process.
In some cases, end users – typically mobile users – may
not need simultaneous parsing and serialization processes.
ence data. Then, both processes can be done sequentially.
The architecture of such an XML engine needs fewer mem-
ory modules. Therefore, a modified version of the architec-
ture is llustrated in Figure 4.
X M L
M e m o r y
M e m o r y
X M L
M e m o r y
M e m o r y
X M L
Figure 3. Block Diagram of the XML Proces-
X M L
M e m o r y
Access / Update
M e m o r y
Figure 4. Block Diagram of the Modified XML
4. Parsing Architecture
For the XML processor to analyze presence informa-
tion effectively, there are some requirements that need to
be taken into consideration. These requirements are sum-
marized as follows:
• Character Encoding Validation,
• XML Well-Formedness,
• XML Validation.
To support these requirements, the XML processor has
two key components: an XML skeleton and a Content Ad-
dressable Memory(CAM). The skeleton represents the tags
which are essential in an XML presence document. The
CAM is configured with the skeleton, so that its entries are
compared with the XML presence document being parsed.
One benefit of this matching decision stage resides in its
natural capability of partially ensuring character encoding
validation and XML well-formedness as well as XML vali-
dation against the presence skeleton. Further natural checks
are left to state machines described later in this paper.
4.1. XML Skeleton
Instead of using a DTD (Document Type Definition) or
an XML Schema to parse and validate an XML document,
a derived tokenized skeleton is used. In the example of a
PIDF document, shown in Figure 2, its corresponding tok-
enized skeleton is derived and illustrated in Table 1.
Table 1. A DerivedTokenized SkeletonofanXML
Example of SIP PIDF
The skeleton is used in configuringthe CAM prior to the
parsing process. Then, the XML characters of the docu-
ment are matched with the contents of the CAM. If a match
is found, a token ID is produced and delivered to a state
machine for further processing. All attributes and their val-
ues are not included in the skeleton in order to keep it in its
lightweight form. Therefore, when comparing them with
the CAM contents, there will be no hit. Further checks on
the attributes and their values are done in a later stage.
The correct sequence of XML characters can be checked
against the skeleton. However, if matching occurs in a dif-
ferent sequence, the engine must accept it in some cases.
For instance, if a string containing the character “>” con-
catenated with one, two, or three whitespaces appears in the
XML stream, it will be matched with a hit in the CAM and
will be given the token id “16” even if the previousmatched
string was not given the token id “15”. In other cases, the
sequence must be strictly respected. For instance, after a
string “</st” is matched and given a token id “14”, the
string “atus” is a normal occurrence in SIP PIDF and will
be matched with a hit and be given a token id “15”. If the
string “</pr” is matched and given the token id “19” right
after the token id “14” was given to the previous matched
string, a parsing error must be flagged. These checks are
done by means of a state machine.
4.2. Internal Architecture
The internal architecture of the XML Parsing Processor
is depicted in Figure 5.
C A M
Parsed Words Writer
R A M
R A M
32 bits32 bits
Figure 5. General Architecture of XML Pars-
While XML-basedSIP Presence (e.g. a PIDF document)
port of the dual-port XML memory. The other port of the
memory can be used simultaneously for reading the XML-
based data. At the beginning, this reading port must not be
used for a latency of one or more clock cycles to ensure that
the same location in the memory is not accessed via differ-
ent ports in the same clock cycle. The right of accessing
memory ports is done by means of arbiter logic.
Thereare 32bits ofXML data whichare readandpassed
to a collection of four FIFOs. Each FIFO handles 8 bits
of data. A FIFO Control module identifies any XML tag
that comes out of each of the four FIFOs outputs and sends
its findings to two modules: the XML Parsing State Ma-
chine and the CAM. Accordingly, the XML Parsing State
Machine makes its parsing state transition and sends back
its decision to the FIFO Control module for synchronizing
4.2.1 The CAM
Before the parsing process begins, the CAM is configured
with a SIP presence skeleton. The CAM includes matching
logic to ensure that the received XML data conform to the
skeleton configured in the CAM. If any string is matched, it
will be given an ID which will be used in further processing
tasks, instead of the original matched data, in order to boost
the parsing performance.
The CAM decision outputs are sent to the XML Parsing
State Machine as well as to the SIP presence state machine.
The CAM match decision has the effect of keeping track of
the well-formedness of the XML data and character valida-
tion. If the data have been identified as unmatched, the re-
sponsibility of further checking the well-formedness of the
XML data is fulfilled via the XML Parsing State Machine
and the SIP Presence State Machine.
4.2.2 The XML Parsing State Machine
The XML Parsing State Machine is depicted in Figure 6.
E n d
Figure 6. XML Parsing State Machine
Starting from its initial state, the state machine makes
a transition to the StartPI state upon the reception of the
first valid XML data event. This state indicates the begin-
ning of the processing instruction of an XML document.
The six subsequentstates ensure the well-formednessof the
whole processinginstructionthat includes the XML version
andencodingattributes accordingto the requirementsofthe
PIDF specifications . A transition to the StartDelimiter
state occurs on the detection of the ‘<’ character, while the
detection of the ‘>’ character leads to a transition to the
EndDelimiter state. The detection of a string right after ‘<’
allows a transition to the StartTAG state, while the pres-
ence of ‘/’ after ‘<’ leads to the EndTAG state. If an addi-
tional string is detected while the current state is StartTAG,
a transition is made to the GetAttrib state in order to get
the name of the attribute. Subsequently, the state machine
gets to the GetValue state in order to seize the value of the
attribute. The outputs of the XML Parsing State Machine
are forwardedto the SIP Presence State Machine for further
processing. A signal is sent to the FIFO Control module for
synchronization purposes from each state.
4.2.3 The SIP Presence State Machine
According to the control signals received from the XML
parsing state machine, the SIP presence state machine starts
the last stage of the parsing process and performs two roles.
First, it ensures that all tokens do not violate the PIDF spec-
ification for SIP presence. Second, it sends the parsed data
in an organized fashion to the memory controller of a dual-
port memory module. This memory controller is named in
Figure 5 “Parsed Words Writer.” Sometimes we refer to this
module as “The Writer” for simplicity.
W r a p
E n d _ Q
Figure 7. SIP Presence State Machine for For-
warding SIP Presence Data to the Writer
The SIP Presence State Machine is illustrated in Fig-
ure 7. The first six states, just coming after the initial state,
make sure that the XML-based object being parsed con-
forms to the PIDF specifications. These states are partic-
ularly referring to the “presence” keyword as well as to the
“entity” attribute and its value that must be included. The
value of this attribute represents the URI of the entity (pre-
sentity) that is publishing its presence (Figure 2 - 3rd line).
The next state is “WaitTupleID” where the state machine
waits until the parser’s detection of a “tuple” which is a
PIDF keyword. If no tuple is detected, and no other op-
tions exist, the state machine steps to the “EndPresence”
state. According to the PIDF specification, if a tuple exists,
it must have an ID as well as a “status” element. Once the
parser delivers the tuple ID value, the state machine makes
transitions to two consecutive states to capture the ID data
and send it to the Writer. The next three states are used to
capture the presence status “basic” element that can be typ-
ically either “open” or “closed”. In the case that another
tuple exists, the state machine returns to the “WaitTupleID”
W r a p
E n d _ Q
Figure 8. A State Machine for Forwarding Ad-
ditional SIP Presence Options to the Writer
If other optional elements/attributes are detected, a tran-
sition to the “MainWait” state occurs prior to switching to
another set of states (Figure 8). This set of states capture
these options/attributes as well as their values and sends
them to the Writer. Subsequently, a return to the “Main-
Wait” state is made from the “WrapEnd QValue” state. If
no further actions are to be done, the state machine steps to
the “EndPresence”state. Note that the “MainWait” states in
Figure 7 and Figure 8 are identical.
has two main tasks. Its first task is writing parsed data into
the dual-port memory by acting as a memory controller. Its
othertask is reportingexplicitlyto the interfacethe memory
addresses in which some main presence data are written.
Through these addresses, direct access to important pres-
ence information is possible. If all parsed data are needed,
the Writer providesthe first and last addresses ofthe written
parsed data (Figure 5).
5. The Serializing Process
The aim of the serializing processor is to serialize SIP
presence information into XML-based PIDF format. The
serializing process can be done simultaneously with the
parsing process, as in Figure 3, where the two processes are
needed in the SIP presence server. For the end-user, the se-
rializing process can be done sequentially with the parsing
process, as in Figure 4.
The functionality of the serializing process can be Download full-text
viewed as the reverse process of parsing. More specifically,
XML start and end delimiters as well as other charactersare
added to the presence information update that is read from
one of the dual-port memory modules (the one in the bot-
tom of Figure 4). This process results in strings that include
the added characters. These strings are matched against the
CAM contents for validation. If there is a hit, the matched
strings are used in building the PIDF document. Otherwise,
strings can be formulated as attributes and attribute values
by reading data in the locations indicated by address sig-
nals (equivalentto address signals in Figure 5 in the parsing
process). Note that the module used in writing parsed data
in Figure 4 is used in reading the presence information up-
date during the serializing process. Eventually, an XML
document having the format of PIDF is built using a state
machine identical to the SIP Presence State Machine (Fig-
ures 7 and 8). The serialized PIDF document is then stored
in a dual-port memory prior to be accessed by the outside
interface and sent to a SIP user.
6. Implementation Results
The implementationof the XML processor requiredsev-
eral design decisions. In particular, the size of the CAM
used as well as that of each of the two dual-port memory
modules is 32 bits x 256 words. The XML documents used
for parsing are all assumed to be in PIDF; and their size
ranges from 216 bytes up to 776 bytes. The XML docu-
ment of the largest size contains two tuples, where each tu-
ple contains different IDs and different status information.
In addition, it contains a contact address, a timestamp, and
a final note sentence.
Table 2. SIP-based Presence Parsing Results
Nb. of parsed
bytes per 1
The XML processor is implemented on Altera’s FPGA
the number of logic elements (LEs) used are 21,963 out of
41,250 i.e.53% of the total LEs available on the chip. Test-
in Table 2, that at least 2 bytes of XML data are parsed on
average in each clock cycle. Using an operationalclock fre-
quency of 25 MHz, the processing throughput ranges from
434Mbps to 476Mbps for XML PIDF documentsof differ-
ent size. Using an operational clock frequency of 50 MHz,
the processing throughput ranges from 869 Mbps to 953
Mbps for XML PIDF documents of different size.
An architecture of a hardware-based XML processor for
SIP-based presence is presented, implemented and tested
on Altera’s Stratix FPGA. The results show that at least two
bytes of XML presence data can be processed in each clock
cycle. This leads to high processing throughput that ranges
from 0.43 Gbps to 0.95 Gbps, depending on the documents
size and the maximumoperationalclock frequency. The ac-
celeration power of the processor, using just Stratix FPGA,
can be no less than 20 times a software-based processor.
These results are even more promising with newer process
technologies of FPGA/ASIC devices.
 C. Bormann, Z. Liu, R. Price, and G. C. (Ed.). Applying
Signaling Compression (SigComp) to the Session Initiation
Protocol (SIP). RFC 5049, IETF, August 2006.
 K.ChiuandW.Lu. A Compiler-basedApproach toSchema-
specific XML Parsing. The first Intern. Workshop on High
Performance XML Processing, May 2004.
 M. Lonnfors, E. Leppanen, H. Khartabil, and J. Urpalainen.
Presence Information Data Format (PIDF) Extension for
Partial Presence. RFC 5262, IETF, September 2008.
 J. V. Lunteren, T. Engbersen, J. Bostian, B. Carey, and
C. Larsson. XML Accelerator Engine . 1st Intern. Work-
shop on High Performance XML Processing, May 2004.
 Y. Pan, W. Lu, Y. Zhang, and K. Chiu.
Balancing Scheme for Parallel XML Parsing on Multicore
CPUs. 7th IEEE Intern. Symp. on Cluster Computing and
the Grid (CCGrid’07), May 2007.
 A. B. Roach, B. Campbell, and J. Rosenberg. A Session Ini-
tiation Protocol (SIP) Event Notification Extension for Re-
source Lists. RFC 4662, IETF, August 2006.
 J. Rosenberg. A Data Model for Presence. RFC 4479, IETF,
 J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston,
J. Peterson, R. Sparks, M. Handley, and E. Schooler. SIP:
Session Initiation Protocol. RFC 3261, IETF, June 2002.
 H. Schulzrinne, V. Gurbani, P. Kyzivat, and J. Rosenberg.
RPID – Rich Presence Extensions to the Presence Informa-
tion Data Format (PIDF). RFC 4480, IETF, July 2006.
 K. Singh and H. Schulzrinne. Failover and Load Sharing in
SIP Telephony. Intern. Symp. on Performance Evaluation of
Comp. and Telecom. Systems (SPECTS), July 2005.
 H. Sugano, S. Fujimoto, G. Klyne, A. Bateman, W. Carr,
and J. Peterson. Presence Information Data Format (PIDF).
RFC 3863, IETF, August 2004.
A Static Load-